Mitigating new HTTP Request Smuggling techniques with BIG-IP ASM
Recently new techniques to exploit Request Smuggling vulnerabilities were disclosed in Amit Klein’s BlackHat talk “HTTP Request Smuggling in 2020 – New Variants, New Defenses and New Challenges (308KB PDF)” . Those techniques were demonstrated on an Abyss web server when placed in front of Squid proxy acting also as a caching server. In this blog post we will go through the new techniques and suggest possible ways to mitigate them using BIG-IP ASM.
Technique: Header SP/CR junk
The first request smuggling technique showed in Amit’s talk was named "Header SP/CR junk”, it is exploited by sending a Content-Length followed by either a carriage return character (0x0d) or a space character.
Figure 1: Example request exploiting the “Header SP/CR junk” request smuggling technique taken from the research white paper.
It was found that Abyss web server sees both Content-Length headers but will parse the body according to the last (malformed) one, therefore Abyss will consider the request body length to be 3 bytes. The other bytes of the request body are considered by Abyss to be part of a new request. Squid proxy that stands before Abyss will parse the valid Content-Length header declaring a body of 36 bytes while ignoring the second unrecognized one. This condition causes a desynchronization between Squid and Abyss and will allow a request smuggling attack to take place.
Technique: Wait for It
The next request smuggling technique discussed in Amit’s research was named “Wait for It”, in this technique the attacker sends only one Content-Length header, the same malformed one we saw in the previous example.
Figure 2: Example request exploiting the “Wait for It” request smuggling technique taken from the research white paper.
In this request smuggling technique Squid proxy that stands before Abyss web server will parse the request as having Content-Length of 0 bytes (as it doesn’t contain a valid Content-Length Header) and will pass a request with empty body to Abyss, while as we discussed before, Abyss will parse the invalid Content-Length header and will expect a body of 33 bytes.
In this case Abyss will wait for 30 seconds for the body to arrive and then will send the response to Squid, then Squid will pass to Abyss what it sees as the next request (the red squared part in the above image). Once Abyss server receives it, it will consume 33 bytes from it (as the body of the previous request) and will treat the smuggled GET request to “/b.html” as an additional request.
Technique: CR header
The next and last technique showed in the research paper is called “CR header” in this case the attacker sends a Content-Length header preceded by a carriage return character.
Figure 3: Example request exploiting the “CR header” request smuggling technique taken from the research white paper.
In this case Abyss behavior is pretty similar to the one we discussed in the “Wait for it” technique, meaning Squid will pass a request containing body of 0 bytes (because Squid didn’t find a valid Content-Length header), but Abyss will treat the Content-Length header preceded by the CR character as a valid Content-Length header and will expect a body of 33 bytes.
Because squid did not forward a body Abyss will again wait for 30 seconds before sending the response back to Squid. Then Squid will forward what it sees as the next request (The GET request to “a.html”) but again Abyss will consume the first 33 bytes and will treat the GET request to “b.html” as an additional request.
Mitigating the vulnerabilities using BIG-IP ASM
BIG-IP ASM customers under any supported BIG-IP version are protected against the request smuggling techniques discussed in the research paper with recently released signatures. The exploitation attempts will be detected by attack signatures which can be found in signature sets that include the “Other Application Attacks” attack type.
Figure 4: “CR Header” request smuggling technique blocked by signature id 200018085
Figure 5: “Header SP/CR junk” request smuggling technique blocked by signature id 200018086