21/03/2012

What About Http Header Injection?

Intro 

HTTP Header Injection is an old vulnerability that has been documented very well since 2006 from  Amit Klein. Nowadays lots of products have implemented anti HTTP Header Injection mechanisms. The basic attacks someone can perform through header injection are numerous(e.g. Apache 2.0.55 mod_proxy and Sun Java System Web Proxy Server 4.0, DeleGate 8.11.5).

The key characters that are used to perform that attack are CRLF and LF characters. By saying LF and CRLF attacks I mean the character set of , %0a and %0d the CRLF character is represented as %0d%0a. Generally speaking some can say that an HTTP Header Injection attack can do three types of attacks:
  1. HTTP Response Smuggling
  2. HTTP Splitting
  3. HTTP Request Smuggling
  4. File Download Injection   
Expanding on attacks more:
  • Cross-Site Scripting (XSS): Until now, it has been impossible to mount XSS attacks on sites through a redirection script when the clients use IE 7.0 and above unless the Location header can be fully controlled. With HTTP Response Splitting, it is possible to mount an XSS attack even if the Location header is only partially controlled by the attacker.
  • Web Cache Poisoning (meaning temporary defacement): This is a new attack. The attacker simply forces the target (i.e. a cache server of some sort) to cache the second response in response to the second request. An example is to send a second request to “http://web.site/index.html”, and force the target (cache server) to cache the second response that is fully controlled by the attacker. This is effectively a defacement of the web site, at least as experienced by other web site clients, who use the same cache server. Of course, in addition to defacement, an attacker can steal session cookies, or “fix” them to a predetermined value.
  • Cross User attacks (user specific temporary defacement): As a variant of the attack, it is possible for the attacker not to send the second request. This seems odd at first, but the idea is that in some cases, the target may share the same TCP connection with the server, among several users (this is the case with some cache servers). The next user to send a request to the web server through the target will be served by the target with the second response the attacker generated. The net result is having a client of the web site being served with a resource that was crafted by the attacker. This enables the attacker to “deface” the site for a single page requested by a single user (a local, temporary defacement). Much like the previous item, in addition to defacement, the attacker can steal session cookies and/or set them.
  • Hijacking pages with user-specific information: With this attack, it is possible for the attacker to receive the server response to a user request instead of the user. Therefore, the attacker gains access to user specific information that may be sensitive and confidential.
Where to look for Header Injections

In order to look for this vulnerability, the tester needs to identify all user controlled input that influences one or more headers in the response, and check whether he/she can successfully inject a CR+LF sequence in it. The headers that are the most likely candidates for this attack are: 
  • Location
  • Set-Cookie
About the HTTP Location header

The HTTP Location header is returned in responses from an HTTP server under two circumstances:

1.To ask a web browser to load a different web page. It is passed as part of the response by a web server when the requested URI has:
  • Moved temporarily
  • Moved permanently
In this circumstance, the Location header should be sent with an HTTP status code of 3xx.

2. To provide information about the location of a newly-created resource.In this circumstance, the Location header should be sent with an HTTP status code of 201 or 202. While the INTERNET standard RFC 1945 (HTTP 1.0) requires a complete absolute URI for redirection, the most popular web browsers tolerate the passing of a relative URL as the value for a Location header.

 About the HTTP Set-Cookie header 

The HTTP Set-Cookie header is sent only if the server wishes the browser to store cookies. Set-Cookie is a directive for the browser to store the cookie and sends it back in future requests to the server (subject to expiration time or other cookie attributes), if the browser supports cookies and cookies are enabled.

An example of Http Header Injection

The following example leads according to OWASP Top 10 to Unvalidated Forwards and Redirects which is characterized to as A10 (low risk). 

The Client Http Request:
GET /changelocale.do?lang=el_GR&return=b98f6%0d%0a35306e9b215 HTTP/1.1
Host: my.victim.gr
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20100101 Firefox/10.0.2
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip, deflate
Proxy-Connection: keep-alive
Referer: http:// my.victim.gr /info/index.do
Cookie: JSESSIONID=679F1E163E33F1985E9595D7CA99AA50; JSESSIONIDSSO=B72AD94DC4A73B7BB3B0C0D908AC14D4
DNT: 1

The Server Http Response:
HTTP/1.1 302 Moved Temporarily
Date: Fri, 09 Mar 2012 13:09:55 GMT
Server: Apache/2.0.46 (Red Hat)
Set-Cookie: JSESSIONIDSSO=B72AD94DC4A73B7BB3B0C0D908AC14D4; Expires=Thu, 01-Jan-1970 00:00:10 GMTLocation: http:// my.victim.gr /b98f635306e9b215
Content-Language: el-GR
Content-Length: 0
Connection: close
Content-Type: text/html;charset=ISO-8859-7

In this example we can see that the variable return set's the Location Http Header to an internal redirect (same domain redirect , url), which is not such a big issue.  From that example we can understand that an attacker does not have to aim particularly for the Http Location header or Http Set-Cookie header. Redirects can happen by manipulating also the variable that are written to Http Headers.

Another example

While using the same web application by manipulating the return variable we can create to Open redirection attacks:

Http Client Request:

GET //changelocale.do?locale=rrr&return=http://www.google.com HTTP/1.1
Host: my.victim.gr
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20100101 Firefox/10.0.2
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip, deflate
Proxy-Connection: keep-alive
Cookie: JSESSIONID=9B012A669272DAE64F37A9F299C712F8
DNT: 1

Http Server Response:
HTTP/1.1 302 Moved Temporarily
Date: Wed, 21 Mar 2012 12:48:02 GMT
Server: Apache/2.0.46 (Red Hat)
Set-Cookie: JSESSIONID=A1945F44A0286E2861C7FF29622C9092; Path=/
Location: http://www.google.com
Content-Language: 3fa28
2f5a989697
Content-Length: 0
Connection: close
Content-Type: text/html;charset=ISO-8859-1

Following the redirect would go to www.google.com
HTTP/1.1 302 Found
Location: http://www.google.gr/
Cache-Control: private
Content-Type: text/html; charset=UTF-8
Set-Cookie: JSESSIONID=; expires=Mon, 01-Jan-1990 00:00:00 GMT; path=/; domain=www.google.com
Set-Cookie: JSESSIONID=; expires=Mon, 01-Jan-1990 00:00:00 GMT; path=/; domain=.www.google.com
Set-Cookie: JSESSIONID=; expires=Mon, 01-Jan-1990 00:00:00 GMT; path=/; domain=google.com
Set-Cookie: JSESSIONID=; expires=Mon, 01-Jan-1990 00:00:00 GMT; path=/; domain=.google.com
Set-Cookie: PREF=ID=32220ea34784094e:FF=0:TM=1332331816:LM=1332331816:S=HH0lu29CjkyrKw96; expires=Fri, 21-Mar-2014 12:10:16 GMT; path=/; domain=.google.com
Set-Cookie: NID=58=YNMgIzggmzZizztb1UOjCBemBW8lNc6OM2uRV95769PX-bxF_gFS759DYRUsqIC671ZdNVDhWW9O4f4LSr-baWhGX61rZPyrcPjMCNpEzgdw5PHaqJAPjTXG3pZtkKjr; expires=Thu, 20-Sep-2012 12:10:16 GMT; path=/; domain=.google.com; HttpOnly
P3P: CP="This is not a P3P policy! See http://www.google.com/support/accounts/bin/answer.py?hl=en&answer=151657 for more info."
Date: Wed, 21 Mar 2012 12:10:16 GMT
Server: gws
Content-Length: 218
X-XSS-Protection: 1; mode=block
X-Frame-Options: SAMEORIGIN

Explanation: So we managed to perform a Location Http Header injection without using the CRLF character. We injected a URL to the variable , then received two 302 http redirects and then we were sent to google.com.

References:

  1. http://lists.grok.org.uk/pipermail/full-disclosure/2006-February/042358.html
  2. http://packetstorm.codar.com.br/papers/general/whitepaper_httpresponse.pdf
  3. https://www.owasp.org/index.php/Testing_for_HTTP_Splitting/Smuggling_(OWASP-DV-016)#HTTP_Splitting
  4. http://en.wikipedia.org/wiki/HTTP_location
  5. http://en.wikipedia.org/wiki/HTTP_cookie