HTTP Splitting attack while accessing ".jsp" in Coldfusion 10 server. How to remediate?

[sourabhs15895148]

When I send  a request similar to this. https://localhost/notexsistent.jsp. The response headers sent is:-

HTTP/1.1 404 /notexsistent.jsp

Date: Thu, 03 May 2018 08:52:13 GMT

Server: Apache

Cache-Control: public

Expires: Thu, 03 May 2018 08:52:13 GMT

Content-Type: text/plain; charset=UTF-8

The unresolved path appended after status code 404 is creating HTTP Splitting attack vector.

A request like this https://localhost/ss/%0Asomevalue:somevalue/notexsistent.jsp

response is:-

HTTP/1.1 404 /ss/

somevalue:somevalue/aaa.jsp

Date: Thu, 03 May 2018 08:57:25 GMT

Server: Apache

Cache-Control: public

Expires: Thu, 03 May 2018 08:57:25 GMT

Content-Type: text/plain; charset=UTF-8 

Thus injecting into response header. I am stuck as i am unaware of internal workings of Coldfusion.

[Charlie Arehart]

While someone may offer a specific answer for you about CF10, I would ask and note a few things:

• are you aware that Adobe no longer supports CF10 (since May 2017)? As such, they have not and will no longer offer security updates since then. This could be a problem remediated in 11 or 2016
• have you tried CF11 or 2016, to see if the problem exists there? you can install either for free (as the trial or developer edition), on any computer
• if you would choose to (or feel compelled to) ignore the two points above, are you on the latest available update of CF10. More at https://helpx.adobe.com/coldfusion/kb/coldfusion-10-updates.html
• Your issue may be a tomcat one (CF10 and above run on Tomcat). CF updates do sometimes update the Tomcat underlying CF (you cannot do it yourself), but it's possible that this is an issue fixed in a later version of Tomcat that CF10 never supported (the most recent updates to CF11 and 2016 did update Tomcat, to address a security issue, but again Adobe will NOT be offering such updates for CF10)
• and are you on the latest available Java update? Your issue may possibly be due to that (though unlikely, since JSPs are processed by Tomcat and THEN Java). But I'll note that if you're on CF10 update 13 or earlier, the latest JVM supported is Java 7 (which is itself no longer updated by oracle). If you're on CF10 update 14 or later, you can go to Java 8 (see http://blogs.coldfusion.com/coldfusion-10-and-11-support-with-java-8/), and the latest Java 8 is update 172. (For any reading this who may be on CF11, it was is update 3 that added support for Java 8. See Which JDK is supported with ColdFusion 9, 10, and 11? | Adobe ColdFusion Blog )

Hope that helps, albeit more along the lines of "teaching one to fish" than just providing the fish/your answer. 🙂

[sourabhs15895148]

Hi Charlie, thanks for the quick response,

I kept looking into the cause of this issue and found that web.xml at */cfusion/runtime/conf/ had a mapping entry as such 

    <!-- The mapping for the JSP servlet -->

    <servlet-mapping>

        <servlet-name>jsp</servlet-name>

        <url-pattern>*.jsp</url-pattern>

    </servlet-mapping>

and 

 <servlet>

        <servlet-name>jsp</servlet-name>

        <servlet-class>org.apache.jasper.servlet.JspServlet</servlet-class>

        <init-param>

            <param-name>fork</param-name>

            <param-value>false</param-value>

        </init-param>

        <init-param>

            <param-name>xpoweredBy</param-name>

            <param-value>true</param-value>

        </init-param>

        <load-on-startup>3</load-on-startup>

    </servlet>

   So i googled and found that we can handle errors in web.xml files too, so added this entry.

<error-page>

<error-code>404</error-code>

<location>/404.cfm</location>

</error-page>

404.cfm is in the webroot folder of coldfusion but the injection in header was still there. but now i could redirect the request to a cfm page of my choice so <cfheader statuscode="404"> worked like a charm.

Also the error handling entry can be added to web.xml at */wwwroot/WEB-INF/ and for some reason adding entry at both places; web.xml at */wwwroot/WEB-INF/ takes precedence.

This is my workaround for now. Charlie i am in the process of upgrading my CF10 server, will update here if it fixes the issue permanently.Just so you know i tested in CF18 beta i was able to inject into the response headers and I am curious about CF16, i am setting up the developer edition to figure out why it works fine.Is it the tomcat version or absence of mapping in the xml file. I am also suspicious if the "init-param" value for servlet play a role to the issue.

[Charlie Arehart]

I will add also that after writing the note, I realized that your offered URL was one I could easily try, so I did, against my CF2016 (update 6). The first URL gave the same response header. The second got a 400 instead. Is that what you are hoping to see? If so, then it seems CF2016 (and update 6) at least has the fix you need, and again if that's about the latest Tomcat update that CF added, note that CF11's latest update also added that.

[Charlie Arehart]

One more thought: I should have noted that I was making my request against CF2016 by way of IIS, and so using the CF web server connector. Your url shows you not specifying any port, and your headers show you using Apache, so you, too, are making your connection through the CF web server connector (between Apache and CF).

And it's worth noting that your problem on CF10 could also be due to your not having updated that web server connector. The original one (from 2012) was very buggy. Subsequent updates added new ones, and a few of the CF10 updates would indicate (in their technote) that after applying the update, one needed to then update the connector (which was and is a manual process, separate from the update--frustrating as that may be), so many missed it and suffer problems simply because of that.

I have a blog post on the topic back in 2013, and the info still stands (and applies as well to CF11, and less so to CF2016): http://www.carehart.org/blog/client/index.cfm/2013/9/13/why_you_must_update_cf10_webserver_connector

Again, I can't know if that WILL solve your problem, but it's something to consider.

[Charlie Arehart]

One more update on this: I find that a CVE about Tomcat indicates that a response splitting vulnerability was fixed in Tomcat (different minor updates for its different major versions):

Apache Tomcat HTTP Request Response Splitting Information Disclosure Vulnerability

And FWIW, it shows that for Tomcat 8, that particular response splitting vuln was fixed in Tomcat 8.5.8. Well, the latest Tomcat included per the latest CF2016 update is in fact 8.5.28 (that's 28, which is 20 greater than 8). In fact, CF2016 update 4 had upgraded Tomcat to 8.5.11, while update 1 had upgraded it to only 8.0.11. (More at https://helpx.adobe.com/coldfusion/release-note/coldfusion-2016-updates-release-notes.html​.)

So we would conclude from this that at least this specific vuln was fixed in CF 2016 as of update 4 or above.

And for CF11, which does not support Tomcat 8, but does come with Tomcat 7, that vuln report above said that vuln was fixed in Tomcat 7.0.73, and it was CF11 update 12 which updated Tomcat to 7.0.75, so one would want to be on that or later for this response splitting (or CRLF) vuln to be addressed. More on those CF11 updates at https://helpx.adobe.com/coldfusion/kb/coldfusion-11-updates.html