‘HTTP Request Smuggling’

Summary

‘The whitepaper explaines a technique to perform web based attacks by ‘smuggling’ HTTP requests.
HTTP Request Smuggling works by taking advantage of the discrepancies in parsing when one or more HTTP devices are between the user and the web server. This technique enables various attacks, such as web cache poisoning and bypassing web application firewall protection.

Credit:

‘The information has been provided by Ory Segal .
The original article can be found at: http://www.watchfire.com/resources/HTTP-Request-Smuggling.pdf


Details

Overview:
The HTTP Smuggling technique is performed by sending multiple specially crafted HTTP requests that cause two attacked entities to see two different sets of requests, allowing the hacker to smuggle a request to one device without the other device being aware of it.
In web cache poisoning attack, this smuggled request will trick the cache server into unintentionally associate a URL to another URL’s page (content), and caching this content for the URL.
In the web application firewall attack, the smuggled request can be a worm (like Nimda or Code Red) or buffer overflow attack targeting the web server.
Finally, because HTTP Request Smuggling enables the attacker to insert or sneak a request into the flow, it allows the attacker to manipulate the web server’s request/response sequencing which can allow for credential hijacking and other malicious outcomes.

Technical Details:
HTTP Request Smuggling (‘HRS’) is a new hacking technique that targets HTTP devices. Indeed, whenever HTTP requests originating from a client pass through more than one entity that parses them, there is a good chance that these entities are vulnerable to HRS. For the purposes of this paper, we demonstrate HRS in three common settings:
 * a web cache (proxy) server deployed between the client and the web server (W/S);
 * a firewall (F/W) protecting the W/S;
 * a web proxy server (not necessarily caching) deployed between the client and the W/S.
HRS relies on similar techniques to those set out in previous white papers. However, unlike HTTP Splitting, for example, to be effective HRS does not require the existence of an application vulnerability, such as a vulnerable asp page on the W/S. Instead, it is capable of exploiting small discrepancies in the way HTTP devices deal with illegitimate or borderline requests. As a result, HRS can be used successfully in significantly more sites than many other attacks.

What damage can HRS inflict?
As we attempt to show, in the cache-server and W/S setting, an attacker can launch a smuggling attack in order to poison the cache server. Typically, the attacker can change the entries in the cache, so that an existing (and cacheable) page A would be cached under URL B. In other words, a client requesting page B would be served with the contents of page A. Obviously, this change of ‘wiring’ could render a website totally unusable. Imagine what would happen if a site’s homepage, http://SITE/ , always responds with the contents of http://SITE/request_denied.html. In sites that allow the client to upload his or her own HTML pages and/or images, the damage can be much worse since a hacker can point URLs in the site to his or her uploaded pages, effectively deforming the site.
In the second setting we examined, in which a web application F/W is installed before the W/S, smuggling can bypass some of the F/W’s web-application defenses. This is because the F/W does not apply some of its web application security rules to the smuggled request because it does not see it, as we explain below. This enables an attacker to smuggle in malicious requests (e.g., worm-like attacks, buffer overflows, etc.), which directly compromise the W/S security. Unlike the web cache poisoning attack in the first example, where the attacked entity is the cache server, in this case the attacked entity is the W/S itself.
In the third setting, in which clients use a proxy server that shares a TCP connection to the W/S, it is possible for one client (the attacker) to send a request to the W/S with a second client’s credentials. It is also possible to exploit a vulnerability in the web application (using the same fundamental vulnerability used in cross-site scripting attacks, dubbed XSS [7,8]) to steal client credentials without the need to actually contact the client, making it a potentially stronger attack than cross-site scripting.

Example 1: web cache poisoning (HTTP REQUEST smuggling through a web cache server)
Our first example demonstrates a classic HRS attack. Suppose a POST request contains two ‘Content-Length’ headers with conflicting values. Some servers (e.g., IIS and Apache) reject such a request, but it turns out that others choose to ignore the problematic header. Which of the two headers is the problematic one? Fortunately for the attacker, different servers choose different answers. For example, SunONE W/S 6.1 (SP1) uses the first ‘Content-Length’ header, while SunONE Proxy 3.6 (SP4) takes the second header (notice that both applications are from the SunONE family). Let SITE be the DNS name of the SunONE W/S behind the SunONE Proxy. Suppose that ‘/poison.html’ is a static (cacheable) HTML page on the W/S. Here’s the HRS attack that exploits the inconsistency between the two servers:

1 POST http://SITE/foobar.html HTTP/1.1
2 Host: SITE
3 Connection: Keep-Alive
4 Content-Type: application/x-www-form-urlencoded
5 Content-Length: 0
6 Content-Length: 44
7 [CRLF]
8 GET /poison.html HTTP/1.1
9 Host: SITE
10 Bla: [space after the ‘Bla:’, but no CRLF]
11 GET http://SITE/page_to_poison.html HTTP/1.1
12 Host: SITE
13 Connection: Keep-Alive
14 [CRLF]

[Note that each line terminates with a CRLF (‘rn’), except for line 10.]
Let’s examine what happens when this request is sent to the W/S via the proxy server. First, the proxy parses the POST request in lines 1-7 (in blue), and encounters the two ‘Content-Length’ headers. As we mentioned earlier, it decides to ignore the first header, so it assumes the request has a body of length 44 bytes. Therefore, it treats the data in lines 8-10 as the first request body (lines 8-10, in purple, contain exactly 44 bytes). The proxy then parses lines 11-14 (in red), which it treats as the client’s second request. Now let’s see how the W/S interprets the same payload, once it has been forwarded to it by the proxy.
Unlike the proxy, the W/S uses the first ‘Content-Length’ header: as far as it’s concerned, the first POST request has no body, and the second request is the GET in line 8 (notice that the GET in line 11 is parsed by the W/S as the value of the ‘Bla’ header in line 10). To summarize, this is how the data is partitioned by the two servers:
                                 1st request        2nd request
            SunONE Proxy          lines 1-10        lines 11-14
            SunONE W/S            lines 1-7         lines 8-14

Next, let’s see which responses are sent back to the client. The requests the W/S sees are ‘POST /foobar.html’ (from line 1) and ‘GET /poison.html’ (from line 8), so it sends back two responses with the contents of the ‘foobar.html’ page and the ‘poison.html’ page, respectively. The proxy matches these responses to the two requests it thinks were sent by the client – ‘POST /foobar.html’ (line 1) and ‘GET /page_to_poison.html’ (line 11). Since the response is cacheable (we assumed ‘poison.html’ is a cacheable page), the proxy caches the contents of ‘poison.html’ under the URL ‘page_to_poison.html’, and voila the cache is poisoned! Any client requesting ‘page_to_poison.html’ from the proxy would receive the ‘poison.html’ page.
A technical note: Lines 1-10 and 11-14 have to be sent in two separate packets, since SunONE Proxy doesn’t pipeline requests on the same packet.
Special cases:
More powerful attacks A much more powerful defacement can be achieved if the attacked site shares its IP address with another site (under the attacker’s control) – as would typically be found in a shared (virtual) hosting scenario. In such a case, the proxy server may still share the TCP connection to the ‘server’ (identified by its IP address) even though logically the traffic may be destined to different sites. The attacker then only needs to set up his/her own site (with the same IP address of the attacked site) and use a Host header (line 9) pointing at this site (e.g. ‘Host: evil.site’). Another variation is using a proxy request (assuming the backend web server is willing to serve it), i.e. at line 8, and sending GET http://evil.site/page.html …
Both methods enable the attacker full control over the cached content.

For more examples see the full paper at: http://www.watchfire.com/resources/HTTP-Request-Smuggling.pdf

Categories: Reviews