Skip to main content
G
genadi_mak
Inspiring
April 22, 2020
Question

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

  • April 22, 2020
  • 7 replies
  • 4586 views

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

This topic has been closed for replies.

7 replies

WolfShade
WolfShade
Legend
April 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,

 

^ _ ^

pete_freitag
pete_freitag
Participating Frequently
April 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.

Charlie Arehart
Community Expert
Charlie ArehartCommunity Expert
Community Expert
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


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)
Charlie Arehart
Community Expert
Charlie ArehartCommunity Expert
Community Expert
April 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)
pete_freitag
pete_freitag
Participating Frequently
April 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-error-page 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.

WolfShade
WolfShade
Legend
April 23, 2020

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

 

V/r,

 

^ _ ^

G
genadi_makAuthor
Inspiring
April 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-guide.pdf

 

    WolfShade
    WolfShade
    Legend
    April 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

      G
      genadi_makAuthor
      Inspiring
      April 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.

        WolfShade
        WolfShade
        Legend
        April 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,

         

        ^ _ ^

        G
        genadi_makAuthor
        Inspiring
        April 23, 2020

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

        WolfShade
        WolfShade
        Legend
        April 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,

         

        ^ _ ^

        G
        genadi_makAuthor
        Inspiring
        April 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/"

         

        WolfShade
        WolfShade
        Legend
        April 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,

         

        ^ _ ^

        G
        genadi_makAuthor
        Inspiring
        April 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.

        Terms & ConditionsAccessibility statement
        Using the community Terms of use Privacy Cookie preferences Do not sell or share my personal information ad choicesAdChoices