HTTP HEADER ATTACK - Part 1

Hello friends.I am CodeNinja a.k.a. Aakash Choudhary.

As I promised to make tutorial on HTTP HEADER ATTACK to my friend Tayyab Qadir [Leet Kid :P] so now i am making this
tutorial so keep watch and learn Thanks.

If you want to learn this attack you should understand HTTP first. Here is some important sites :->

1. http://code.tutsplus.com/tutorials/http-the-protocol-every-web-developer-must-know-part-1--net-31177
2. http://code.tutsplus.com/tutorials/http-the-protocol-every-web-developer-must-know-part-2--net-31155
3. http://www.skeletonscribe.net/2013/05/practical-http-host-header-attacks.html
4. http://code.tutsplus.com/tutorials/using-web-debugging-proxies--net-29828
5. http://www.sans.org/reading-room/whitepapers/testing/penetration-testing-web-application-dangerous-http-methods-33945
6. http://learn.onemonth.com/understanding-http-basics
7. https://danielmiessler.com/study/http/

All above are very very awesome for understand HTTP.

Step 1:- What is HTTP & cause or harm by this attack ?

ANS :-   Web servers often broadcast server information by default.
This can include information such as the operating system (Linux, Windows, etc),
the operating system version, what kind of web server you are running (IIS, Apache, etc.) and
in some cases web server modules installed.

This information is stored in http headers, and sent along with every web page request made by a user visiting your page.

As a result, it is very easy for anyone to find out what kind of settings such a server is using.

By itself, this information is harmless, although it does give away some information about your website setup.

A dedicated attacker can use this information to find and craft attacks specific to your system,

or automated attacks may search for specific configurations to attack.

Although it is difficult to prevent someone from finding this information using other methods,
disabling server headers reduces the likelihood of attacks on the site.

I know how to secure website from this attack :D but not much full but atleast i know :P




Step 2:-  How many ways there to attack on HTTP ?

ANS :- Here what i saw on this attack possible :-

1. HTTP REQUEST SMUGGLING :- Cache Poisoning,Session Hijaking,XSS
2. HTTP RESPONSE SPLITTING :-  Cross-User Defacement,Cache Poisoning,XSS,Page Hijacking
3. HTTP Parameter Polution Attack
We must know about Header types in HTTP & Status Code like  200,301,404

Must to know Important Headers :-  https://www.owasp.org/index.php/List_of_useful_HTTP_headers

We must know about HTTP Methods :-
-------------------------------------------------
GET
POST
TRACE
DELETE
PUT
HOST
X-FORWARDED-FOR
Referer
User-agent
HTTPOnly
OPTIONS
CONNECT


NOTE: If we while inspecting HTTP  see this :- Allow: GET,HEAD,POST,TRACE,OPTIONS    Then it is good news for us because
now we know that what methods are allow in target website and we can do many attacks based on this :D.

Most applications only use few HTTP headers:

Referer: to know where the clients come from
Cookie: to retrieve the cookies
User-Agent: to know what browser users use like :Mozilla
X-Forwarded-For: to get the source IP address (even if it's not the best method to do this).

The Host header is mainly used by the web server to know what web site you are trying to access
If we put the IP address in the Host header or an invalid hostname, we can sometimes get another website and
get extra-information from this.

------------------------------------------------

Requirements :-
-------------------------------------------------
1. RefControl addon
2. User-Agent Switcher
3. Netcat
4. Wireshark
5. TELNET
6. NMAP
7. HTTP HEADERS
8. Burpsuite

We should have understanding of above things.
--------------------------------------------------



STEP 3:- Identify Vulnerability

ANS:-   Check everything to detect vulnerability in any website. Like to identify HTTP HEADER ATTACK vulnerability on
website just  open site and check  its REQUEST & RESPONSE in Headers. We can use WIRESHARK,BURPSUITE or HEADER addons

LIKE :-
Web applications that do not properly sanitize user input before using it as an HTTP header value are vulnerable
to header injection (also called Response Splitting).

Now i am explaining   ===>   HTTP HEADER ATTACK

HTTP headers have the structure “Key: Value”, where each line is separated by the CRLF combination.
If the user input is injected into the value section without properly escaping/removing CRLF characters
it is possible to alter the HTTP headers structure.
A CRLF (New line) injection adding malicious characters into HTTP headers without proper input filtering.

HTTP Response Splitting is a application attack technique which enables various new attacks
such as web cache poisoning, cross user defacement, hijacking pages with sensitive user information and XSS.
The attacker sends 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.


You see CRLF combination. What is this ?  This is :- Carriage Return (\n) + Line Feed(\r)

So what is actually HTTP ? This is a Protocol which is used to communicate between Our Browser and Web Server.
REQUEST & RESPONSES is what important thing in HTTP.

HTTP Request :- When we fill form anc click SUBMIT button then it goes to Web Server  where Web Server check is that
filling form is correct or not so this is called REQUEST.


HTTP RESPONSE :- So when Web Server  show us message like Form is submitted or if we login successfully then we login
on page so this is what Web Server give Response of what we Request.

So if we fill log in details by inputing our name & password and then INSPECTING HTTP using tools like BURPSUITE or
HTTP HEADER addons and see is our input is not sanitizing by web server then we can  Attack  :P



GENERATE HTTP TRAFFIC :-

We can use telnet or netcat  for this purpose

e.g. :-

1.	telnet   192.168.56.102/vulnerable 80
	GET / HTTP/1.1
	Host: 192.168.56.102/vulnerable

NOTE: Some time we see 400 Bad Request so we can also try this   HTTP/1.0 instead of HTTP/1.1

2.Also can use this
	echo "GET /HTTP/1.0\r\nHost:vulnerable\r\n\r\n" | nc vulnerable 80

	Where  \r\n  is our CRLF Remember I discussed about this already above :P
We can also use  %0d or %0a  instead of  \r or \n   respectively


We can use many important things like HTML ENCODING,DOUBLE ENCODING,URL ENCODING  because somethimes it can be very
HELPFUL :D

3. Also we can try with JEFF method instead of GET. If you try with JEFF method and see Response 200 OK then it is
vulnerable with JEFF method BUT  if we see 405 or 501 error then JEFF method not work.

4.HOST :- It is a header that allows a web server to host multiple websites on the same IP address





		############################# HTTP REQUEST #############################

This is what happens when you open your browser and navigate to www.google.com.
An HTTP request to www.google.com is initiated.
	GET / HTTP/1.1
	Host: www.goole.com
	Accept: text/html
	User-Agent: Mozilla/5.0 (Windows;  U;
	Windows NT 6.1; it; rv:1.9.2.2)
	Gecko/20100316 Firefox/3.6.2 GTBDFff
	GTB7.0
	Connection: keep-alive

What we see here are the Headers, called HTTP Request Headers for this request.

Now lets understand the above Requests one by one.

1.) GET / HTTP/1.1 --->  Request Method
This is the type of our request (also known as HTTP Verb).
GET is the request type when we type a website URL in our location bar and hit enter.
Other Verbs are POST, PUT,DELETE, OPTIONS, TRACE etc etc


2.) /   ---> Path
This is the file we are requesting.
The home page of a website is always "/".

Other pages can be requested such as: /downloads/index.php.

We always refer to the root folder to specify the requested file (hence the leading "/").


3.) HTTP/1.1  ---> Protocol
This is the HTTP protocol version our browser is talking.
This basically hints the web server which language will be used in the communication

4.) Host: www.google.com  ---> Host header
This is the beginning of HTTP Request Headers.
HTTP Headers have the following structure:   Header-name:Header-value.

The Host header allows a web server to host multiple websites on the same IP address.

This means that we will have to specify which website we are interested in, in the Host header.

www.google.com  <---- This is Host Value

After each Request header we find its corresponding value.
In this case we want to reach the host --> www.google.com.

Note: Host value + Path   makes the full URL we are requesting: The home page of www.google.com.

5.) Accept: text/html  ----> Accept Header
This header is used by the browser to specify which document type is expected as the result of this request.


6.)     User-Agent: Mozilla/5.0 (Windows;  U;
	Windows NT 6.1; it; rv:1.9.2.2)
	Gecko/20100316 Firefox/3.6.2 GTBDFff
	GTB7.0

-----> Host User Agent

The user agent reveals the browser version, operating system and language to the remote web server.
All web browsers have their own identification user agent.
This is how most web site recognize the type of browser in use.


7.) Connection: keep-alive   ----> Header Connection
With HTTP 1.1 we can keep our connection to the remote web server open for a given time using the value "Keep-alive".

All the requests to the web server will go through this connection
without reinstating a new connection every time (as in HTTP 1.0).

################################################################################################################

		###################### HTTP RESPONSE ##########################

In response to the HTTP Request,
the web server will respond with the requested resource preceded by a number of Headers.

These headers will be used by the web browser to interpret the content carried in the Response content.

Check these in HEADERS ===>

1.) Cache-Control: private,max-age=0   ==========> Cache Header

The cache headers allow the Browser and the Server to exchange information about cached contents.

Cached contents save bandwidth because prevent the browser from requesting unmodified contents when the
same resource is to be used.

2.) Server:gws    ========> Server Header

The Server header advertises the banner of the Web Server. Apache and IIS are common web servers.

In above example Google uses a custom webserver banner as "gws" (Google
Web Server).


3.) Via: 1.0 .:8001(squid) ======> Via Header

The Via header is present when a connection has traversed a proxy.
A proxy is a special web server that caches contents for faster delivery

4.) <PAGE CONTENT>  =====> Content

This is the content of the requested resource.
The content can be a web page html, a document, or a binary file.
The type of content is contained in the Content-type header.





Take a look on HTTP Response Splitting Attack :-

	############################### HTTP RESPONSE SPLITTING #########################################

The idea behind it is, you find a website that takes user submitted data, and writes it to the HTTP header.
An example of this is a Location: redirect. Heres the PHP code that takes a website, and redirects you to it.

http://site.com/redirect.php?page=http://www.google.com

<?php
header("Location: $_GET['page']");
?>

In this attack we have to see Response COdes like 200 OK,404,302 etc etc.

SCENARIO :-
Consider a server which accepts user input through some form or search or anything which is sent as POST data.
The server does not sanitize the user input, allowing the user to enter any arbitrary data.
Each line in HTTP header is separated by CR/LF.
CR means carriage return and LF means line feed, this is crucial while parsing because it tells the end of line.

The attacker cleverly crafts another request inside the input field.
Suppose in headers if we see    " lang=en "  has user influence, so the attacker can send data as :

1. The value ‘en’.
2. CR/LF – %0d%0a for Windows or %0a for Linux
3. A response with Content Length 0 [we don’t bother about this response.]
4. CR/LF – %0d%0a  for Windows or %0a for Linux
5. A response which contains malicious content
[For e.g. Javascript which will download malware when the page is visited]

Note :- If we are WINDOWS user we use CR/LF  & if we are LINUX user we use LF


What we can do with HTTP Response Splitting Attack ? ---->
	– Cross-site Scripting (XSS) attacks
	– Cross User Defacement
	– Web Cache Poisoning
	– Page Hijacking
	– Browser Cache Poisoning
	– Browser Hijacking



Now in next section i am including *ATTACK* section as example so that we learn more but remember i will teach
practically attack in my 2nd Part of Tutorial.

	################# HTTP Response Splitting - The Attack examples ########################

• An HTTP message response includes two parts :
	– Message Headers – metadata that describes a request or response
		- Each terminated by a carriage return (\r) and a linefeed (\n) (But remember about OS like window or chrome)

			GET http://www.google.com/ HTTP/1.1\r\n
			Host: www.google.com\r\n
			User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
			rv:1.9.0.1; Google-TR-5.7.806.10245-en) Gecko/2008070208
			Firefox/3.0.1 Paros/3.2.13\r\n
			Accept: text/html,application/xhtml+xml,application/xml;
			q=0.9,*/*;q=0.8\r\n
			Accept-Language: en-us,en;q=0.5\r\n
			Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7\r\n
			Keep-Alive: 300\r\n
			Proxy-Connection: keep-alive\r\n

Please notice   \r\n there :D

• Then the Message Body which is the raw data of the response
			<HTML>\r\n
			<HEAD>\r\n
			<TITLE>Your Title Here</TITLE>\r\n
			</HEAD>\r\n
			<BODY>\r\n
			</BODY>\r\n
			...
			</HTML>\r\n



• The Message Headers are also separated from the message body a carriage return/linefeed pair
			GET http://www.google.com/ HTTP/1.1 \r\n
			Host: www.google.com \r\n
			User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.1; Google-TR-
			5.7.806.10245-en) Gecko/2008070208 Firefox/3.0.1 Paros/3.2.13 \r\n
			Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 \r\n
			Accept-Language: en-us,en;q=0.5 \r\n
			Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 \r\n
			Keep-Alive: 300 \r\n
			Proxy-Connection: keep-alive \r\n
			\r\n
			<HTML>
			<HEAD>
			<TITLE>Your Title Here</TITLE>



• Those two consecutive carriage-return-linefeed pairs are the source of
HTTP response splitting vulnerabilities
• The HTTP response splitting vulnerability is not the attack, it is simply the
path that makes it possible
• The key to the attack is ability for an attacker to modify the message
headers
• HTML is stateless, so neither the web server nor the browser has any
problem with this seemingly odd behavior



------------------------------------------------------------------------------------------

• Now Let’s understand how a normal page redirection works in HTTP
	– Example: A page containing a redirect script:

	protected void processRequest(HttpServletRequest aRequest, HttpServletResponse
	aResponse) throws ServletException, IOException {
	redirect(“http://www.new-url.com”, aResponse);
	}
	– A request like:
		– would redirect to:
			http://www.test.com/offer.jsp?page=http://www.test.com/freechecking
		– How do the headers work behind the scenes?
			http://www.test.com/freechecking

• Under the hood, the request is ->
		GET /latestoffer.jsp?page=http://www.test.com/freechecking HTTP/1.1\r\n
		Host: www.bank.com \r\n
		...
		\r\n

• The server responds with an HTTP 302 (redirect)
		HTTP/1.1 302 Found \r\n
		...
		Location: http://www.test.com/freechecking \r\n
		NOTE: THIS COULD BE THE USER INPUT IN HEADER
		...
		\r\n

• The browser then fetches the new page
		GET / HTTP/1.1 \r\n
		Host: http://www.test.com/freechecking \r\n
		...
		\r\n

• The server responds with HTTP 200 (found) and the page
		HTTP/1.1 200 OK \r\n
		...
		\r\n

• But the user can input something that terminates the response and initiates an attack

For Window user :-
		/latestoffer.jsp?page=anything%0d%0aContent-
		Length:%200%0d%0d%0a%0aHTTP/1.1%20200%20OK%0d
		%0aContent-Type:%20text/html%0d%0a
		Content-Length:%2019%0d%0a%0d%0a<html>Attack</html>

For Linux User :-

		/latestoffer.jsp?page=anything%0aContent-
		Length:0%0a%0aHTTP/1.1 200 OK
		%0aContent-Type: text/html %0a
		Content-Length: 19%0a%0a<html>Attack</html>

URL Encoded is important --->
			- ":" by %3A
			- "space" by %20
			- "carriage return" by %0A
			- "," by %2c
			- "/" by %2F
			- "<" by %3C
			- ">" by %3E

Use this site for this purpose :- http://yehg.net/encoding/

Now come to the that attack example again :-

		/latestoffer.jsp?page=anything%0d%0aContent-
		Length:%200%0d%0d%0a%0aHTTP/1.1%20200%20OK%0d
		%0aContent-Type:%20text/html%0d%0a
		Content-Length:%2019%0d%0a%0d%0a<html>Attack</html>

There notice -> Content-Length:%2019%0d%0a%0d%0a<html>Attack</html>
		- Remember that we need two \r\n sequences between the headers and the body


This results in ---->
		HTTP/1.1 302 Moved Temporarily

			Location: http://www.test.com/latestoffer.jsp?page=anything  <--- HTTP RESPONSE
			Content Length: 0
			HTTP/1.1 200 OK		---------|
			Content-Type: text/html		 |   We INSERTED HTTP Response
			Content-Length: 19		 |
			<<Anything you want>>	---------|

Then :-
		Server: gws			---------|
		Content-Type: text/html			 | This is what Superfluous Data mean which is our expecting data
		Content-Length:%2019			 |
		<html>Attack</html>			 |
		.....				---------|



Explanation :-
	• The dangerous part of this, is <<Anything you want>>
	• A script that can take over the user's browser or steal cookie information
		– A redirection to a different host and web page
		– A page that mimics another site and collect credentials
		– It can poison the web cache leading to site defacement
	• However, the exploit is not complete
	• There are now two responses, but only one request
	• The web server will simply hold the second response
	• The attacker has to issue another request
	• In the simplest case, simply send http://www.test.com
	• How the attacker does this is dependent on the situation and the attackers goals

	 See the following example of cache poisoning -->

First Understand :->
	– A site has a proxy server for web pages
	– The attacker and victims are behind the proxy server
	– When a response is received by the proxy server, it saves it to answer future requests
	– So the proxy server saves both responses from the attack
	– If the second response defaces a real page, or creates a page with a malicious
	  JavaScript embedded, everyone on the network will get it

Second - Browser Cache Poisoning :->
	• We creates an HTTP Response Splitting attack based on a URL
			http://somesite.com/start.php?first=xxx<script> ...
			</script>&lang=fr%0d%0aContent-Length:0%0d%0a
			HTTP/1.1%20200%20Found%0d%0aContent-
			Length:550%0d%0a ...

		• and seduces a victim into clicking on it
		• The web servers first response contains a Cross-site Scripting attack
		• The script issues an Ajax request that sends the second request
		• And the victim’s web cache (and any proxy server) is poisoned





Now the main question arise in every's mind is that how we can DISCOVER this attack? Yeah i know i know but don't
worry. I am here to tell you this too.So lets start :


	************************  HTTP Response Splitting Discovery ****************************

 • Check for any data outside of the Trust Boundary that is used in any HTTP header
	– Try inserting a carriage return/linefeed pair i.e. \r(%0a) or \n(%20) to see it is allowed to pass through
	– If so, we have a vulnerability
	– Be suspicious of redirects in code – they often use information stored in the client

 • Be aware that Post data can also be used in an attack
	– It may be advantageous, because URL's have limited length
	– It requires that the attack be perpetrated via a script so it is more difficult to implement



Useful Resources :-

1. https://www.mnot.net/cache_docs/
2. http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html   <--- This is useful to understanding HTTP headers

###################################################################################################################



	################################ HTTP REQUEST SMUGGLING (HRS) ###################################


FROM OWASP :-

The HTTP Request Smuggling attack explores an incomplete parsing of the submitted data done by an
intermediary HTTP system working as a proxy. HTTP Request Smuggling consists of sending a specially formatted
HTTP request that will be parsed in a different way by the proxy system and by the final system,
so the attacker could smuggle a request to one system without the other being aware of it.
This attack makes it possible to exploit other attacks, like Cache Poisoning, Session Hijacking, Cross-site Scripting (XSS) and most importantly, the ability to bypass web application firewall protection.

HRS is can be used to poison web-caches and bypass security solutions such as web application firewalls
as well as for the delivery of malicious payloads such as worms, viruses, and those used to exploit
known vulnerabilities in web and application servers.


OWASP is great to understand this attack as i read :- https://www.owasp.org/index.php/HTTP_Request_Smuggling


If between Client and Server there is so many HTTP Devices/entities use like Cache Server,Proxy Server,WAF then
HRS attack is very useful here.


HRS sends multiple, specially crafted HTTP requests that cause the two attacked devices to see different
sets of requests, allowing us as attacker to smuggle a request to one device without the other device being aware
of it.
It is capable of exploiting small differences in the way HTTP devices deal with illegitimate or borderline requests


###################################################################################################################



	####################### HTTP PARAMETER POLUTION (HPP) #############################


To understand this attack we have to understand the Behaviour of WEB Technologies.Different web use different technologies.
Like if you search " header attack " on GOOGLE  then you get following result :-
	https://www.google.co.in/?gws_rd=ssl#q=header+attack   --->  header attack

on YAHOO :-
	https://in.search.yahoo.com/search?p=header+attack&fr=yfp-t-704   ---> header attack


Notice the parameter  used by both GOOGLE & YAHOO

So in this attack our main task is to find out that is parameter  vulnerable or not. Mean we have to analyze that
is application does not sanitize the "PARAMETER" of website URL.

So this attack is generally use to bypass WAF (Web Application Firewall) by targeting on PARAMETERS.

As attacker we have to find out the unsanitize parameter of website. Like:-
Consider this URL:- http://www.testsite.com/category=1&page=2&id=3

So there is 3 Parameters  Developers used.
	- 1. category=1
	- 2. page=3
	- 3. id=3
So as attacker we have to find out that which parameter out of those 3 is unsanitize so that we perform attack.
If any of those parameters or all  is not sanitize properly then we can perform attack there :D .

So HPP  attacks on HTTP GET/POST parameters by injecting query string

One of example of HPP :-  http://www.testsite.com/Injection=<script&injection=>alert(aakash)></script>




FROM OWASP :-
1.Submit an HTTP request containing the standard parameter name and value, and record the HTTP response. E.g. page?par1=val1

2.Replace the parameter value with a tampered value, submit and record the HTTP response. E.g. page?par1=HPP_TEST1

3.Send a new request combining step (1) and (2). Again, save the HTTP response. E.g. page?par1=val1&par1=HPP_TEST1

4.Compare the responses obtained during all previous steps. If the response from (3) is different from (1) and the response from (3) is also different from (2), there is an impedance mismatch that may be eventually abused to trigger HPP vulnerabilities.

Also for testing this vulnerability we should check Search Page not  login page  because ub term of Login page we may get
Invalid Username or Password



You see we used & to seperate query, We can also use  " ; "


NOTE: It doesn't mean that we see these parameters in URL only. We can also see these parameters in HTTP Headers.
LIKE :-
	- Cookie: par=1; par=2


Very Good Resources :=>
1. https://www.owasp.org/images/b/ba/AppsecEU09_CarettoniDiPaola_v0.8.pdf
2. http://www.slideshare.net/embyte/http-parameter-pollution-vulnerabilities-in-web-applications-black-hat-eu-2011
#####################################################################################################################