Home Blogs Profile Contribution Policies Contact About

Desynk Attack: HTTP Request Smuggling



Introduction:

HTTP Request Smuggling works by taking advantage of the discrepancies in parsing when one or more HTTP devices/entities (e.g. cache server, proxy server, web application firewall, etc.) are in the data flow between the user and the web server. HTTP Request Smuggling enables various attacks – web cache poisoning, session hijacking, cross-site scripting and most importantly, the ability to bypass web application firewall protection. It sends multiple specially-crafted HTTP requests that cause the two attacked entities to see two different sets of requests, allowing the hacker to smuggle a request to one device without the other device being aware of it. In the web cache poisoning attack, this smuggled request will trick the cache server into unintentionally associating a URL to another URL’s page (content), and caching this content for the URL. In the web application firewall attack, the smuggled request can be a worm (like Nimda or Code Red) or buffer overflow attack targeting the web server. Finally, because HTTP Request Smuggling enables the attacker to insert or sneak a request into the flow, it allows the attacker to manipulate the web server’s request/response sequencing which can allow for credential hijacking and other malicious outcomes. For more, you can visit the 2005 Documentation page.

Above Image shows that the simple smuggled request is send by client on the left side (Frontend Server). When request parsed by the Backend server break the request and wait send first request's response & wait for next request, in which it will append the headers to the next request and gives the response.


# Here you can view the normal response from the server

HTTP/1.1 200 OK
Connection: Keep-alive
Content-Lenth: 23

This is simple response

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

# Now Observe below response from the server with injected payload.

HTTP/1.1 200 OK
Connection: Keep-alive
Content-Lenth: 23

This is simple responseHTTP/1.1 200 OK
Connection: Keep-alive
Content-Lenth: 23

This is simple response



Background Concept:

Application server validate http request length on the basis of two headers.
1. Transfer-Encoding
2. Content-Length

On Live senario server has multiple load balancer or Frontend and Backend server which process the request. We are aim to exploit improper validation of request on application.
Assume, We have 4 different senarios,
1. Frontend server is validating the request length via Transfer-Encoding and Backend server validating via Content-Length headers.
2. Frontend server is validating the request length via Content-Length and Backend server validating via Transfer-Encoding headers.
Frontend server is validating the request length via Content-Length and Backend server validating via Content-Length headers.
4. Frontend server is validating the request length via Transfer-Encoding and Backend server validating via Transfer-Encoding headers.

To learn more types of attack visit This Blog.



Transfer-Encoding and Content-Length Header:

Transfer-Encoding
When the server needs to send large amount of data, chunked encoding is used by the server because it did not exactly know how big (length) the data is going to be. In HTTP terms, when server sends response Content-Length header is omitted by the server. Instead server writes the length of current chunk in hexadecimal format followed by \r\n and then chunk, followed by \r\n (Content begins with chunk size in hex followed by chunk).
This feature can be used for progressive rendering; however the server needs to flush the data as much as possible so that client can render content progressively.
This feature is often used when server pushes data to the client in large amounts - usually in large size (mega/giga). For more visit Stackoverflow page.

Content-Length:
The Content-Length entity-header field indicates the size of the entity-body, in decimal number of OCTETs, sent to the recipient or, in the case of the HEAD method, the size of the entity-body that would have been sent had the request been a GET. For more visit Stackoverflow page.


Live Demo with CTF:


I have build CTF lab with Nachiket Rathod on Request Smuggling attack. Visit to download and play FinitHicDeo CTF.

Calculating Transfer-Encoding header:
Observe below example:

GET / HTTP/1.1
Host: 192.168.0.105
Content-Length: 4
Transfer-Encoding: chunked

2c
GET /path HTTP/1.1
Host: 127.0.0.1:8080


0


On above example we are having the TE-CL Vulnerability on server. Let me explain all values one by one.
- "Content-Length" header in request is set according to the size of the "2c\r\n" bytes. According to method, we are calculating the total size of first line of the content. Here we also calculating the "\r\n" new line feed.
- "Transfer-Encoding" header is calculated by total bytes of the content. Here we are having simple HTTP GET request which size is 44 till the header ends, after "\r\n\r\n0" which indicate to stop. Decimal 44 is now converted to hexadecimal which gives "2c". The reason we have added "2c" before the content is the total hexadecimal value of the content. - After the "0" we have to add two "\r\n" line feed and send the request to the server.

If you send below request to the CTF server. which gives the response with the flag.



GET /a HTTP/1.1
Host: 192.168.0.109
Content-Length: 4
Transfer-Encoding: chunkedasd

2c
GET /flag HTTP/1.1
Host: 127.0.0.1:8080


0

GET /a HTTP/1.1
Host: 127.0.0.1:8080
    





Ending notes:

For learn more you can visit PortSwigger's Labs. They provide free and has almost every attacks labs for practice. Also, visit writeups to stay upto date with latest attack techniques.


Thanks For Reading
Husseni Muzkkir




References:

https://medium.com/@knownsec404team/protocol-layer-attack-http-request-smuggling-cc654535b6f
https://www.cgisecurity.com/lib/HTTP-Request-Smuggling.pdf
https://github.com/mymuzzy/FinitHicDeo
https://i.blackhat.com/USA-19/Wednesday/us-19-Kettle-HTTP-Desync-Attacks-Smashing-Into-The-Cell-Next-Door.pdf



Comment Section:

Writer: You can write a comment to help me to improve this blog or ask below


Write a Comment









I also think you'll like...





More Blogs
Back to top ↑