HTTP Desync Attacks: Request Smuggling Reborn(portswigger.net) |
HTTP Desync Attacks: Request Smuggling Reborn(portswigger.net) |
The vector is subtle differences in HTTP header parsing between your front end (reverse proxy, load balancer etc) and your back end (web server).
"New Relic deployed a hotfix and diagnosed the root cause as a weakness in an F5 gateway. As far as I'm aware there's no patch available, meaning this is still a zeroday at the time of writing.".
Edit: other major companies he revealed were affected were: PayPal, Trello, Redhat.
There are a few reasons your company might be safe:
1. All your sites serve https directly from web servers (no https termination and passthrough as internal http traffic)
2. You use Cloudflare and you cannot reach your sites directly (article says that Cloudflare rewrites all headers so probably avoids problem)
3. Your front end is properly hardened and it prevents malformed or duplicate headers
4. Your front end does not reuse connections to your web server (maybe the quickest emergency bandage?)
5. Your front/back end do not allow chunking (or pipelining).
This is going to affect so many major sites, and requires patches to critical infrastructure: pass me the popcorn so I can watch this horror show unfold.
I don't see that using HTTP/2 is realistic.
(a) Are you saying that using HTTP/2 from the browser makes headers in your infrastructure secure?
(b) Some of our enterprise clients use security proxies (e.g. Cisco WSA) which do not support HTTP/2 and force connections from the browser to use HTTP1.1. Aside: Cisco WSA is super crappy: we have recorded a repeatable corruption that passed information between HTTPS sessions (It was a obsolete device so we didn't report it to Cisco or the client - but I would bet good money there are plentiful major security flaws with Cisco WSA).
(c) If you are suggesting using HTTP/2 between frontend and backend, that seems unrealistic to implement.
From other thread:
> If you have a front-end and a back-end, and they talk to eachother using HTTPS, that's exploitable
I couldn't understand how - surely packets would be completely broken (how can you append a valid packet to an HTTPS request, or get a valid HTTPS reply to an another connection?)
Perhaps a spiffy name, an icon, and a cool website would give this more visibility HAHA!
PS: I am surprised this isn't getting more attention on HN - it seems like a really fatal security issue that will affect heaps of sites - oh well.
What was the timelines involved here? PayPal, Trello, and others were contacted over the course of this investigation. It would be nice to know what their response times were to such a serious vulnerability.
Trello patched it in roughly 10 days. In general I found companies took longer to patch this issue than other similar-severity vulnerabilities, probably because it's conceptually unfamiliar so I frequently had to spend quite a while explaining it, and the patch itself appears to be challenging sometimes too.
Regarding HTTPS between the frontend and backend, remember that's just HTTP over a TLS stream instead of TCP. As long as the frontend still reuses these TLS streams, it's exploitable. To be clear, this is in a scenario where the front-end terminates the HTTPS connection from the client then routes requests over a pool of persistent HTTPS connections to the backend. Does that make sense? Since I've been exploiting this from a black-box perspective, I can't really tell for sure whether I've successfully exploited any websites actually doing this.
And yeah it would have been nice of this had done better on HN but between presenting it at two major security conferences and adding automated detection to a popular web scanner, it ought to achieve decent awareness over the next few months. Hopefully.
Regarding point 5, the front-end doesn't need to support pipelining at all, and the back-end doesn't require it either in most cases. Regarding chunk support, yeah you could patch this by disabling chunked requests on both systems, but if only one system disables it that pretty much just makes the situation worse.
I think your first point could be misread. If you have a front-end and a back-end, and they talk to eachother using HTTPS, that's exploitable. What's not exploitable is when you don't have a frontend at all, or your frontend isn't doing any kind of request parsing (ie it's a network load balancer).
I think that’s exactly what he was trying to say in the first point. Anyway thanks for stressing that, it helped me understand better what is happening.
EDIT: Basically, chunked transfer encoding is not an option for any front-end systems (reverse proxies / load balancers of any kind). Also note that because there exist apps that associate authentication state with connections (though they're not supposed to), one should generally avoid mixing traffic from different users onto one connection.