
HTTP Desync Attacks: Request Smuggling Reborn - karma20
https://portswigger.net/blog/http-desync-attacks-request-smuggling-reborn
======
robocat
This is incredible and it looks like it could affect massive numbers of sites
- unfortunately the article doesn't summarise the problem very well.

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.

~~~
sciurus
When a security engineer I know learned about this, they described it as "the
next heartbleed" and it's hard not to concur. The scope and impact of this
class of attack is _much_ bigger than anyone realized prior to this research.

~~~
robocat
Heartbleed again - yep. Maybe there's not much discussion yet because it
doesn't have some cool marketing, or perhaps everyone is scrambling to
mitigate the issue for their infrastructure?

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.

~~~
albinowax_
Hi, I'm the author of the article.

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).

~~~
lhuser123
> 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

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.

------
Steltek
I've been waiting to hear more about this since the abstract was published.

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.

~~~
albinowax_
You can now see the PayPal timelines here:
[https://hackerone.com/reports/488147](https://hackerone.com/reports/488147)
[https://hackerone.com/reports/510152](https://hackerone.com/reports/510152)

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.

