Who will offer $36,000 for finding a bug?
Yes, it has happened. And, by the the greatest company of the planet: Apple.
Apple offered a bug bounty of $36,000 for HTTP request smuggling vulnerabilities in core web apps.
From the prize, you can well understand the magnanmity of the bug.
After finding critical HTTP request smuggling vulnerabilities in three of Apple's core web applications, a security researcher says they got $36,000 in bug bounties.
The bug hunter, a 20-year-old hacker who goes by the online name "Stealthy," said that they used the same method to poison the queues on the domains. This allowed them to get access to data and take over accounts without the user having to do anything.
What does "Smuggling HTTP Requests" mean?
An attack method known as HTTP request smuggling involves interfering with the exchange of requests between front end and back end servers.
The attacker takes advantage of the weakness by changing the request, so that it includes another request in its body. The Content-Length and Transfer-Encoding headers are used wrongly to do this. When the attack works, the second request is hidden in the body of the first request and then processed.
What does it do and how does it work?
Basically, two HTTP headers are used during the attack:
- The size of the request body is shown in the Content-Length Header (in bytes).
- Transfer-Encoding Header: set to chunked to send the request body in pieces (separated by newline). A chunk ends with a 0.
This attack works if all of the following are true:
- Over the same network connection, the front-end server sends multiple requests to the back-end server.
- The back-end doesn’t agree with the front-end about where each message ends.
- The attacker sends a message that isn't clear, and the back-end server reads it as two separate HTTP requests.
- The attacker prepares the second request to carry out malicious action that the first request cannot.
The above request can be seen as two separate ones:
This weakness can only be exploited by people who know how to do it.
Note that HTTP Smuggling does not take advantage of any vulnerabilities in the web application that is being targeted. By taking advantage of how web servers read HTTP messages, this vulnerability can lead to the following:
- Execute Unauthorized Commands
- Gain Privileges
- Bypassing security controls
- Access/Modify Data
- Session Hijacking
- Cache poisoning
How to find out?
You can find this vulnerability manually by following the steps below, or you can use the smuggler extension for Burp Suite. Here are some steps for exploiting and finding a vulnerability by hand.
Types of HTTP Smuggling Attacks
There are three main ways to exploit HRS vulnerabilities:
CL-TE: the front-end server uses the Content-Length header and the back-end server uses the Transfer-Encoding header.
TE-CL: the front-end server uses the Transfer-Encoding header and the back-end server uses the Content-Length header.
TE-TE: the front-end and back-end servers both support the Transfer-Encoding header, but one of the servers can be induced not to process it by obfuscating the header in some way.
CL-TE
In this situation, the front-end server uses the Content-Length header and the back-end server uses the Transfer-Encoding header. A simple HTTP request smuggling attack can look like this:
POST / HTTP/1.1
Host: www.example.com
Content-Length: 13
Transfer-Encoding: chunked
0
SMUGGLED
The Content-Length header tells the front-end server that this request is 13 bytes long, which is the length of SMUGGLED. This request is sent to the server in the back.
The back-end server looks at the Transfer-Encoding header and thinks that chunked encoding is being used for the message body. It handles the first chunk, which is said to have a length of zero. Because of this, the request is considered to be over. The SMUGGLED bytes that come next are not processed, and the back-end server will see them as the beginning of the next request in the sequence.
TE-CL
In this case, the front-end server uses the Transfer-Encoding header and the back-end server uses the Content-Length header.
A simple HTTP request smuggling attack can look like this:
POST / HTTP/1.1
Host: www.example.com
Content-Length: 3
Transfer-Encoding: chunked
8
SMUGGLED
0
The front-end server looks at the Transfer-Encoding header and thinks that chunked encoding is being used for the message body.
It works on the first chunk, which is said to be 8 bytes long, up to the start of the line following SMUGGLED.
It processes the second chunk, which is said to have a length of zero. Because of this, the request is considered to be over.
This request is sent to the server in the back.
The back-end server looks at the Content-Length header and sees that the request body is 3 bytes long, up to the start of the line following 8.
The bytes that come after SMUGGLED are not processed, and the back-end server will see them as the beginning of the next request in the sequence.
TE-TE Behavior: Obfuscating the TE Header
In this case, both the front-end and back-end servers can handle the Transfer-Encoding header, but one server can be made to ignore it by obfuscating it in some way.
The Transfer-Encoding header could be obfuscate in an almost infinite number of ways. For example:
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: 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
Transfer-Encoding
: chunked
Each of these methods takes a small step away from what the HTTP specification says. In the real world, code that implements a protocol specification rarely follows it exactly, and it is common for different implementations to allow different variances from the specification.
To find a TE-TE vulnerability, you need to find a variation of the Transfer-Encoding header that only one of the front-end or back-end servers processes, while the other server ignores it.
Depending on whether the front-end or back-end server can be tricked into not processing the obfuscated Transfer-Encoding header, the rest of the attack will be the same as for the CL-TE or TE-CL vulnerabilities already described.
How to Avoid HTTP Request Smuggling:
- Making the front-end server understand confusing requests
- Making the back-end server reject unclear requests and disconnect from the network.
- Reusing back-end connections should be disabled.
- For back-end connections, use HTTP/2.
- Use the same web server software for the front and back ends.
- Prefer a WAF with built-in mitigation for detecting unusual request.