The following security advisory is sent to the securiteam mailing list, and can
be found at the SecuriTeam web site: http://www.securiteam.com
- - promotion
The SecuriTeam alerts list - Free, Accurate, Independent.
Get your security news from a reliable source.
http://www.securiteam.com/mailinglist.html
- - - - - - - - -
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.
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 ("\r\n"), 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>
http://www.watchfire.com/resources/HTTP-Request-Smuggling.pdf
ADDITIONAL INFORMATION
The information has been provided by <mailto:orysegal@netvision.net.il>
Ory Segal .
The original article can be found at:
<http://www.watchfire.com/resources/HTTP-Request-Smuggling.pdf>
http://www.watchfire.com/resources/HTTP-Request-Smuggling.pdf
========================================
This bulletin is sent to members of the SecuriTeam mailing list.
To unsubscribe from the list, send mail with an empty subject line and body to:
list-unsubscribe@securiteam.com
In order to subscribe to the mailing list, simply forward this email to:
list-subscribe@securiteam.com
====================
====================
DISCLAIMER:
The information in this bulletin is provided "AS IS" without warranty of any
kind.
In no event shall we be liable for any damages whatsoever including direct,
indirect, incidental, consequential, loss of business profits or special
damages.
