CRLF or HTTPRS: Carriage Return and Line Feed/ HTTP Response Splitting.

##Introduction:

After a long time, I am writing about a new thing, new thing cause I’ve learned it last night. Visited couple of sites from last night, and wondering that how I was in dark about “Carriage Return and Line Feed”.

##Description:

CRLF injection attacks are not as well known as some other attacks, but when used against vulnerable applications, CRLF injections can be just as effective and devastating .It is fairly simple, yet extremely powerful web attack.  Hackers are actively exploiting this web application vulnerability to perform a large variety of attacks that include XSS cross-site scripting, cross-user defacement, positioning of client's web-cache, hijacking of web pages, defacement and a myriad of other related attacks.  A number of years ago a number of CRLF injection vulnerabilities were also discovered in Google’s Adwords web interface.

Link:  www.hackingspirits.com/vuln-rnd/adwords-crlf-injection.pdf

CRLF  is a very significant sequence of characters for programmers. These two special characters represent the End Of Line (EOL) marker for many Internet protocols, including, but not limited to MIME (e-mail), NNTP (newsgroups) and more importantly HTTP.  When programmers write code for web applications they split headers based on where the CRLF is found. If a malicious user is able to inject his own CRLF sequence into an HTTP stream, he is able to maliciously control the way a web application functions.

The essence of HTTP Response splitting is the attacker's ability to send a single HTTP request that forces the web server to form an output stream, which is then interpreted by the target as two HTTP responses instead of one response, in the normal case. The first response may be partially controlled by the attacker, but this is less important. What is material is that the attacker completely controls the form of the second response from the HTTP status line to the last byte of the HTTP response body. Once this is possible, the attacker realizes the attack by sending two requests through the target. The first one invokes two responses from the web server, and the second request would typically be to some "innocent" resource on the web server. However, the second request would be matched, by the target, to the second HTTP response, which is fully controlled by the attacker. The attacker, therefore, tricks the target into believing that a particular resource on the web server (designated by the second request) is the server's HTTP response (server content), while it is in fact some data, which is forged by the attacker through the web server - this is the second response.

HTTP Response Splitting attacks take place where the server script embeds user data in HTTP response headers. This typically happens when the script embeds user data in the redirection URL of a redirection response (HTTP status code 3xx), or when the script embeds user data in a cookie value or name when the response sets a cookie.

In the first case, the redirection URL is part of the Location HTTP response header, and in the second cookie setting case, the cookie name/value is part of the Set-Cookie HTTP response header.

The essence of the attack is injecting CRs and LFs in such manner that a second HTTP message is formed where a single one was planned for by the application. CRLF injection is a method used for several other attacks which change the data of the single HTTP response send by the application, but in this case, the role of the CRLFs is slightly different - it is meant to terminate the first (planned) HTTP response message, and form another (totally crafted by the attacked, and totally unplanned by the application) HTTP response message (hence the name of the attack). This injection is possible if the application (that runs on top of the web server) embeds un-validated user data in a redirection, cookie setting, or any other manner that eventually causes user data to become part of the HTTP response headers.

With HTTP Response Splitting, it is possible to mount various kinds of attacks:

#Cross-User Defacement

An attacker can make a single request to a vulnerable server that will cause the sever to create two responses, the second of which may be misinterpreted as a response to a different request, possibly one made by another user sharing the same TCP connection with the sever. This can be accomplished by convincing the user to submit the malicious request themselves, or remotely in situations where the attacker and the user share a common TCP connection to the server, such as a shared proxy server.

In the best case, an attacker can leverage this ability to convince users that the application has been hacked, causing users to lose confidence in the security of the application.

In the worst case, an attacker may provide specially crafted content designed to mimic the behavior of the application but redirect private information, such as account numbers and passwords, back to the attacker.

#Cache Poisoning

The impact of a maliciously constructed response can be magnified if it is cached either by a web cache used by multiple users or even the browser cache of a single user. If a response is cached in a shared web cache, such as those commonly found in proxy servers, then all users of that cache will continue receive the malicious content until the cache entry is purged. Similarly, if the response is cached in the browser of an individual user, then that user will continue to receive the malicious content until the cache entry is purged, although the user of the local browser instance will be affected.

#Cross-Site Scripting

Once attackers have control of the responses sent by an application, they have a choice of a variety of malicious content to provide users. Cross-site scripting is common form of attack where malicious JavaScript or other code included in a response is executed in the user's browser.

The variety of attacks based on XSS is almost limitless, but they commonly include transmitting private data like cookies or other session information to the attacker, redirecting the victim to web content controlled by the attacker, or performing other malicious operations on the user's machine under the guise of the vulnerable site.

The most common and dangerous attack vector against users of a vulnerable application uses JavaScript to transmit session and authentication information back to the attacker who can then take complete control of the victim's account.

#Page Hijacking

In addition to using a vulnerable application to send malicious content to a user, the same root vulnerability can also be leveraged to redirect sensitive content generated by the server and intended for the user to the attacker instead. By submitting a request that results in two responses, the intended response from the server and the response generated by the attacker, an attacker can cause an intermediate node, such as a shared proxy server, to misdirect a response generated by the server for the user to the attacker.

Because the request made by the attacker generates two responses, the first is interpreted as a response to the attacker's request, while the second remains in limbo. When the user makes a legitimate request through the same TCP connection, the attacker's request is already waiting and is interpreted as a response to the victim's request. The attacker then sends a second request to the server, to which the proxy server responds with the server generated request intended for the victim, thereby compromising any sensitive information in the headers or body of the response intended for the victim.

##Proof-Of-Concept:

Header Injection:

Vulnerable document is “rdt.php”

Injected Header Data:

</p>
<p>%0d%0aContent-Type: text/html%0d%0aHTTP/1.1 200 OK%0d%0aContent-Type: text/html%0d%0a%0d%0a%3Chtml%3E%3Cfont color=red%3Ehey%3C/font%3E%3C/html%3E</p>
<p>

If the user follows the link, the HTTP request will look like:

</p>
<p>GET /rdt.php?page=%0d%0aContent-Type: text/html%0d%0aHTTP/1.1 200 OK%0d%0aContent-Type: text/html%0d%0a%0d%0a%3Chtml%3E%3Cfont color=red%3Ehey%3C/font%3E%3C/html%3E HTTP/1.1\r\n</p>
<p>Host: abc.org\r\n</p>
<p>User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.6) Gecko/20050317 Firefox/1.0.2\r\n</p>
<p>Accept: text/xml,application/xml,application/xhtml xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5\r\n</p>
<p>Accept-Language: en-us,en;q=0.5\r\n</p>
<p>Accept-Encoding: gzip,deflate\r\n</p>
<p>Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7\r\n</p>
<p>Keep-Alive: 300\r\n</p>
<p>Connection: keep-alive\r\n</p>
<p>\r\n</p>
<p>

##Fix:

The CRLF vulnerability is extremely easy to patch. The following code example assumes the input is set to “$_POST['input']”

</p>
<p>if (eregi('n', $_POST['input'])) //This checks for the new line character in the POST variable</p>
<p>{ //start if..</p>
<p>die(&quot;CRLF Attack Detected&quot;); //exit program if CRLF is found in the variable</p>
<p>} //end if..</p>
<p>

##Conclusion:

“Carriage Return and Line Feed” will be famous Attack Method for next generation. Because it not well-known to people. Everybody keeps eyes on SQLi or on XSS. But in upcoming times, it will hard to find a SQLi/XSS vulnerable site or Web-app.

## References:

**Web Sites

**Books

**Blogs

You can follow any responses to this entry through the RSS feed. You can leave a response, or trackback from your own site.

Tagged Carriage Return and Line Feed, CRLF, HTTP Response Splitting, HTTPRS