PortSwigger’s James Kettle dusts off the request smuggling text books to demonstrate new ways of breaking through the web ecosystem
Those who find themselves lying awake fearing for the stability of some of the web’s primary building blocks should prepare for some more sleepless nights, thanks to hacker James Kettle.
Presenting at Black Hat USA today, the PortSwigger Web Security researcher demonstrated how isolated HTTP requests can be exploited to poison web caches and desynchronize entire systems – including those belonging to major companies such as PayPal and Red Hat.
“These days we rely on layer upon layer of abstraction to have the faintest understanding of what is really happening on a website,” Kettle told The Daily Swig ahead of this year’s conference in Las Vegas.
“We tell people things like ‘HTTP is stateless’ and ‘If you send one request, you get one response’, but what if both of those were kind of wrong?”
Smuggling requests
HTTP desync vulnerabilities present a security issue that’s been overlooked, Kettle said, who was able to exploit multiple well-known systems using a somewhat forgotten technique that relies on the agreement made between front and back end severs – a method called ‘HTTP request smuggling’.
First discovered in 2005, HTTP request smuggling draws upon the HTTP protocol and the way in which content moves across modern information systems via HTTP requests, or messages.
Taking advantage of the obscure boundaries between where one HTTP request starts and the next begins
“HTTP requests are placed back to back over these screens, and every server is expected to work out where requests stop and start,” Kettle said, explaining how the requests are understood based on the front end and back end deciding how long they are.
“But what happens if, as an attacker, we send an ambiguous message? What if it gets interpreted as a different length by the front end and back end system?”
Then there’s a problem, Kettle said, particularly if your front end is hosted by a third-party, which makes any configuration to your affected system somewhat out of your hands.
“With request smuggling we can effectively specify an arbitrary prefix that gets put at the start of the next request, that’s the essence of request smuggling,” Kettle said.
“You are specifically creating something that makes the front end and back end disagree on how long the message is, and the effect of that is some the message may spill over onto the next message.”
Poisoning the wire
An HTTP request smuggling attack is trigged by a malicious actor sending messages that are chunked and also specify a content-length, Kettle explained. Messages must be interpreted differently by the front end and back end systems in order for the attack to work.
“If both servers support chunked encoding, all you’ve got to do is try to hide the Transfer-Encoding header from one of the servers in the chain – and there’s loads of ways to do that,” Kettle said.
“Probably the easiest single attack that you can do with request smuggling is bypassing security rules on the front end system,” he said, providing an example of one-well known software vendor that had their front end configured to block requests to try to fetch-admin.
“By using request smuggling and sending a follow up myself, the back end thought I was accessing /admin, and that was the page that I was able to get access to.”
Kettle found a number of vulnerable websites, including PayPal’s main login page. Here, he was able to use request smuggling in order to poison the web cache, from which he could have stolen user’s passwords as they logged in.
PayPal issued a fix for the issue, but the researcher was able to bypass these mitigations – earning him $18,900 and $20,000 in bug bounties, respectively.
“The most vulnerable system is one that has lots of proxies, lots of layers, and caches, things like that,” Kettle said, adding how mitigation was difficult due to the web’s growing complexity.
“The system that is easiest to exploit is one with lots of modern functionality, like caching data, and such.”
James Kettle presented his latest research at Black Hat 2019
Desync adventures
Kettled bagged more than $70,000 in bounties during his desyncing adventures, with the biggest single payout having come from PayPal – the $20,000 for bypassing the issued fix.
Half of his winnings have gone to local charities, he said.
“My favorite example has to be PayPal,” Kettle said. “If we’re looking at a technical level, then the web cache deception one is really sneaky, but it’s still hypothetical.”
In addition to the white paper (PDF) an open source HTTP desync detection tool was released as part of Kettle’s presentation, providing a safe method to find vulnerable sites based on an HTTP request timeout.
RELATED Black Hat Briefings: Assessing the impact of last year’s pioneering security research
