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 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 :
Further explanation will be given in the practice part.
Transfer-Encoding.Content-Length (TE.CL)
In TE.CL RS (Request Smuggling) the front-end server uses the Transfer-Encoding header and the back-end server uses the Content-Length header. We can craft the follow HTTP request to exploit :
Further explanation will be given in the practice part.
Transfer-Encoding.Transfer-Encoding (TE.TE)
When the front-end and back-end both support Transfer-Encoding header, you can obfuscate one the TE header so one of the server will be induced not to process the request. Here are ways to obfuscate the Transfer-Encoding header :
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.
After identifying a probable request smuggling vulnerability, you can try to trigger differences in the contents of the application's responses. This involves sending two requests to the application in quick succession:
An "attack" request that is designed to interfere with the processing of the next request.
In this case, the front-end processes the Transfer-Encoding header and does the following operations
handles the message body as using chunked encoding which is stated 124 (0x7c) bytes long
reads up to the beginning of the line following the second request
processes the second chunk, which is stated to be empty (since it ends with a 0)
finishes parsing the request
This request is forwarded to the back-end server. The back-end uses the Content-Length header and does the following operations
determines that the request is 4 bytes long (meaning it stops reading at the start of the line following 7c).
The following bytes, starting with GET, are left unprocessed, and the back-end server will treat these as being the start of the next request in the sequence and thus return a 404 status code.
When using the Burp Repeater, testers must always ensure that the "Update Content-Length" option is unchecked for TE.CL since modifying the Content-Length is required to trigger the vulnerability. The trailing sequence \r\n\r\n must be included following the final 0.
Using smuggler.py
Tools like smuggler.py (Python) can be used to identify potential HTTP request smuggling vulnerabilities.
# for a single hostsmuggler.py-u $URL# for a list of hostscatlist_of_hosts.txt|python3smuggler.py
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.
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.
