Information leakage fix due to invalid host generating response with too much information

Report · Apr 22, 2020

Hi,

Our site was tested by one of the security scanner companies and found known vulnerability. It sounds as "Information Leakage is an application weakness where an application reveals sensitive data".

I need help to update server settings to hide error details, not do display server technlogy details.

They run curl command as:

C:\curl\bin\curl.exe -i -s -k -X "GET" -H "Accept: application/json,text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5" -H "Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7" -H "Accept-Language: en-us,en;q=0.5" -H "Host: whs'check" -H "User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:67.0) Gecko/20100101 Firefox/67.0 Software Security Group" "https://www.[mysite.com]/"

The output is resulting in java stack error as:

<!doctype html><html lang="en"><head><title>HTTP Status 400 – Bad Request</title><style type="text/css">h1 {font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;font-size:22px;} h2 {font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;font-size:16px;} h3 {font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;font-size:14px;} body {font-family:Tahoma,Arial,sans-serif;color:black;background-color:white;} b {font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;} p {font-family:Tahoma,Arial,sans-serif;background:white;color:black;font-size:12px;} a {color:black;} a.name {color:black;} .line {height:1px;background-color:#525D76;border:none;}</style></head><body><h1>HTTP Status 400 – Bad Request</h1><hr class="line" /><p><b>Type</b> Exception Report</p><p><b>Message</b> The character [&#39;] is never valid in a domain name.</p><p><b>Description</b> The server cannot or will not process the request due to something that is perceived to be a client error (e.g., malformed request syntax, invalid request message framing, or deceptive request routing).</p><p><b>Exception</b></p><pre>java.lang.IllegalArgumentException: The character [&#39;] is never valid in a domain name.
        org.apache.tomcat.util.http.parser.HttpParser$DomainParseState.next(HttpParser.java:966)
        org.apache.tomcat.util.http.parser.HttpParser.readHostDomainName(HttpParser.java:842)
        org.apache.tomcat.util.http.parser.Host.parse(Host.java:66)
        org.apache.tomcat.util.http.parser.Host.parse(Host.java:40)
        org.apache.coyote.AbstractProcessor.parseHost(AbstractProcessor.java:293)
        org.apache.coyote.ajp.AjpProcessor.prepareRequest(AjpProcessor.java:1062)
        org.apache.coyote.ajp.AjpProcessor.service(AjpProcessor.java:523)
        org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:66)
        org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:808)
        org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1498)
        org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49)
        java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
        java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
        org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
        java.lang.Thread.run(Thread.java:745)

The culprit is: "Host: whs'check". Where the illegal character single quotation "'".

I ran the test with different characters. I replaced "'" with "|" or "{". The application is generating just 400 error with no java stack as:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN""http://www.w3.org/TR/html4/strict.dtd">
<HTML><HEAD><TITLE>Bad Request</TITLE>
<META HTTP-EQUIV="Content-Type" Content="text/html; charset=us-ascii"></HEAD>
<BODY><h2>Bad Request - Invalid Hostname</h2>
<hr><p>HTTP Error 400. The request hostname is invalid.</p>
</BODY></HTML>

I tried few things like adding an entry to server.xml file

<Connector port=".... relaxedQueryChars="'">

Also, I tried to add to catalina.properties

tomcat.util.http.parser.HttpParser.requestTargetAllow='
or
tomcat.util.http.parser.HttpParser.requestTargetAllow="'"

Nothing seem to work.

We run CF2016 with Tomcat 8.5.42

Thank you

Report · Apr 23, 2020

If an apostrophe or any other non alphanumeric character is part of the host name, then the host name is the issue. I have no idea what "whs'check" is, but it's obviously the culprit. Remove the apostrophe, and the issue should resolve itself.

V/r,

^ _ ^

Report · Apr 23, 2020

Sorry, may be I was not clear. I know the issue. But this a deliberate attempt to hack the host name, basically it is a security check. I am trying to find a way to hide the error details, not do display server tech details.

Report · Apr 23, 2020

If I understand correctly, you want to trigger this information to be emailed to you, and just show a generic error message to the user?

V/r,

^ _ ^

Report · Apr 23, 2020

No, I just want the error detail in the form of java stack to be hidden and error details did not include server information as this is a security issue.

The error is generated by curl command below. It is not visible otherwise.

 C:\curl -i -s -k -X "GET" -H "Accept: application/json,text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5" -H "Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7" -H "Accept-Language: en-us,en;q=0.5" -H "Host: whs'check" -H "User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:67.0) Gecko/20100101 Firefox/67.0 Mercer Software Security Group" "https://www.mysite.com/"

Report · Apr 23, 2020

AFAIK, you can either display it by doing nothing (as you've noted, this is a security concern), or display a generic error message to the user. I don't think you can display part of the error message. Unless you create an error.cfm page and use reFindReplaceNoCase() to display only part of the error message. Which would be more work than just displaying a generic error message and sending the error details to an admin account.

V/r,

^ _ ^

Report · Apr 23, 2020

I have a generic error page but, it doesnt work here. It works fine from browser. But not from Curl.

Report · Apr 23, 2020

Okay.. I think I'm understanding a bit more.. curl returns the contents of a page and ideally places it into a string for the security company to retrieve and view. You want to limit the output from CF so that no one can see your internal information.

This sounds to me like more of a CFAdmin thing, or IIS/Apache thing, than a programming thing.

You _might_ be able to do what you want by limiting what IP addresses can see errors, or some other method in CFAdmin:

https://helpx.adobe.com/coldfusion/configuring-administering/using-the-coldfusion-administrator.html

Report · Apr 23, 2020

I checked CF Admin Debugging & Logging > Debugging IP Addresses. There was an entry for local machine IP. Will look up may be Tomcat has something on the subject.

Report · Apr 23, 2020

Just out of curiosity, have you followed the Lockdown Guide?

V/r,

^ _ ^

Report · Apr 23, 2020

Not the one you pointed. Its for 2019. Most of this one, yes

https://wwwimages.adobe.com/content/dam/acom/en/products/coldfusion/pdfs/coldfusion-2016-lockdown-gu...

Report · Apr 23, 2020

Folks, I agree that genadi_mak seems to have found an information disclosure issue. (And I would argue it has nothing to do with CF debug setting, error handling, or lockdown, as I will explain in a moment.) I think it would happen to anyone trying this against any CF site.

And you should report this to Adobe, genadi_mak. They may not see this thread here. I'd report it to cfinstal@adobe.com, at least, but really you should open a security report via PSIRT@adobe.com (as offered at https://helpx.adobe.com/security/alertus.html). They are always interested in closing such holes. You could point them to this thread, but really what you offer in the original note is the key: the CURL and the stack trace shown.

To be clear, I see the problem also, and in my case on CF2018 (which is on Tomcat 9). And I DO have an error handler setup, and it's NOT being made from a browser whose IP is in the allowed debug ouput address list. (BTW, that list affects ONLY debugging output. It does NOT affect errors, not even whether the "robust exception" error output is shown or not.)

And in case readers have not tried it, note that it happens even when requests to the web site in question are going through IIS or Apache. The request gets passed into CF (because the web servers passes it in), and then it's Tomcat that is barfing at the bad host header value.

And I suspect the problem is really in Tomcat (in spewing out that stack trace) rather than CF. Of course, CF runs atop Tomcat by default, so a problem with it flows to being a problem for CF.

And you may find elsewhere (in other forums, not related to CF) how the Tomcat folks have contended in reply to such problems that they are simply holding to the http spec on what should be allowed, and that's why they reject it.

(Genadi_mak, I'm thinking you have found those, since you refer to fixes they talk about there, like using the relaxedQueryChars or other features of the tomcat connector line in server.xml. BTW, you don't clarify WHICH connector you were changing it on. It should be the uncommented AJP one, for requests coming in via IIS or Apache.)

But anyway, I don't think what we should seek is how to fix that specific problem so that it doesn't happen. We need Adobe (or Tomcat) to fix it so that such a stack trace is not returned for such an error. If you instead fix Tomcat to "allow" that bad host name, the tool used by your security folks will just try other ways to "break in".

What we need here is to not have CF exposing this stack trace in the response output (and to be clear, it's disregarding any CF error handler we may have because it's a low-level Tomcat error, not a CFML error). This is why we need Adobe to solve this. (It may well be that some later version of Tomcat handles it differently. We using CF can't upgrade Tomcat ourselves, Adobe must update the Tomcat version embedded in CF for us.)

BTW, it's nothing unique to curl, either. The only reason one wouldn't see the problem in a browser is that they'd have to pass in a header on the request, which isn't done easily in browsers without using tools to maniplate the input.

I doubt that any aspect of the lockdown guide will help here, but I could be wrong. I will send a note to Pete Freitag to let him know about this discussion. He may well have a thought. And I may well have something wrong here, but I don't think so.

/Charlie (troubleshooter, carehart.org)

Report · Apr 23, 2020

The easiest way you can mitigate this (and a generally good practice) is to setup a default website on your web server that listens on the IP/port, and does not serve dynamic (CFML, ASP.NET, etc) requests. Then have the web server setup to serve your site only when the host header matches. This has the advantage of catching all the bots that are just hitting random IP addresses, you can simply serve up a static html page with a link to the main site (but really you woudn't be getting any legit human traffic).

As for this issue in Tomcat, it appears that because it is a URL parsing issue Tomcat is unable to know which web application should handle the issue. I would have though that having the <error-page> defined for status 400 would be sufficient, but according to this thread: https://stackoverflow.com/questions/52814582/tomcat-is-not-redirecting-to-400-bad-request-custom-err... you would have to use the ErrorReportValve to catch this in Tomcat and display a friendly HTML page.

Hope that helps!

Pete Freitag

Foundeo Inc.

Report · Apr 23, 2020

Okay, so I reached out to a co-worker to ask. His team, among others, are the ones who beat Red Team every time.

He says that curl is basically a text browser, for the most part. It encapsulates a page output and presents it in a string.

If you go into CFAdmin and set up a default error page, or if you use the onError() in application.cfc, to display a generic error message when something crashes, even using curl to 'hack' the information will fail. curl will just get whatever you decide it to have. Just like any other user.

So, use a default error page, or onError() in application.cfc for such events. curl will not get a stack trace, according to a security expert.

HTH,

^ _ ^

Report · Apr 23, 2020

In this case you would still get the stack trace, because the error is thrown by Tomcat before it hands the request off to CF.

Report · Apr 24, 2020

Thank you, WolfShade, Pete and Charle

I am leaning towards Charlie's version that this is a bug.

I already have the default website with static content on the IIS and I think it does what you are describing... I will doublecheck.

As far as custom error page, I have it configured and, anything happens in the app I am receiving email. This page is set in CF Admin and in the application. In this case as per Pete, I think the request does not reach CF.

What I am wondering if anyone has got Curl handy and try to run this against your installation to see what is the result:

C:\curl\bin\curl.exe -i -s -k -X "GET" -H "Accept: application/json,text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5" -H "Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7" -H "Accept-Language: en-us,en;q=0.5" -H "Host: whs'check" -H "User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:67.0) Gecko/20100101 Firefox/67.0 Software Security Group" "https://www.[mysite.com]/"

Thanks

Report · Apr 24, 2020

Well, I did already confirm that. See my first post, where I also confirmed that (like you) it happened despite a CF error handler, etc.

Have you yet reported it to Adobe, as I suggested?

/Charlie (troubleshooter, carehart.org)

Report · Apr 24, 2020

Yes, I sent email to WishBreeze@adobe.com

Thank you, Charlie

Report · Apr 24, 2020

I'm curious why you sent to that address, rather than either of the other two I offered above. It would seem wishbreeze is for feature requests for the old breeze product (which became connect, I think). Why would you send to that address?

/Charlie (troubleshooter, carehart.org)

Report · Apr 24, 2020

I did a google search to submit bug report, came back with this link https://www.adobe.com/products/wishform.html

When I selected Coldfusion from dropdown, I got that email...

Report · Apr 24, 2020

I will resend to PSIRT@adobe.com

Report · Apr 25, 2020

Just an FYI: the place to file bug reports and feature requests is instead tracker.adobe.com. You may have had that old wishform from years back, but it was supplanted by tracker some years ago. (And a google search for: coldfusion bug report, does come up with results pointing to tracker (and sites talking about it) rather than that wishform, thankfully.)

BTW, I hadn't suggested tracker because this didn't seem just a bug but a security bug. If you file a security bug, it gets removed from tracker once it's verified, for security reasons (and they would inform the PSIRT team).

That's why it's great to see that your next comment, that you would be send this also to that psirt address.

/Charlie (troubleshooter, carehart.org)

Report · May 12, 2020

Hi,

I got an update from Adobe with the solution which, worked for me. Here is the link

https://helpx.adobe.com/coldfusion/kb/invalid-host-information-disclosure.html

Thanks

Report · May 12, 2020

That's great to hear. Thanks for sharing it, and thanks to Adobe for addressing it. I'll do a blog post to try to bring more attention to it.

/Charlie (troubleshooter, carehart.org)

Adobe Community

Information leakage fix due to invalid host generating response with too much information