
Slack account takeovers using HTTP Request Smuggling - bartkappenburg
https://hackerone.com/reports/737140
======
arkadiyt
Protecting against request smuggling:

\- If you don't have a proxy fronting traffic, no action required

\- If you're behind Fastly/Cloudflare [1] or Akamai [2], no action required /
they protect against this attack

\- If you're behind AWS Cloudfront, no action required / they protect against
this attack

\- If you're behind AWS ALB, you're vulnerable by default but can opt-in to
protection by enabling the "routing.http.drop_invalid_header_fields.enabled"
attribute [3]. They initially had it on by default but it broke customers

\- If you have a different proxy (e.g. some other provider or your own nginx,
haproxy before 2.0.6 [2], etc), you might be vulnerable

[1]: [https://portswigger.net/research/http-desync-attacks-
request...](https://portswigger.net/research/http-desync-attacks-request-
smuggling-reborn)

[2]: [https://portswigger.net/research/http-desync-attacks-what-
ha...](https://portswigger.net/research/http-desync-attacks-what-happened-
next)

[3]:
[https://docs.aws.amazon.com/elasticloadbalancing/latest/APIR...](https://docs.aws.amazon.com/elasticloadbalancing/latest/APIReference/API_LoadBalancerAttribute.html)

~~~
judge2020
Regarding Cloudflare/fastly, you do need to make sure you're only allowing
requests that originate from the proxy, either via IP-based firewall rules or
something like CF's authenticated origin pulls [0]. Otherwise someone could
find your origin server's IP and potentially perform this attack (and
generally bypass your security settings).

0: [https://support.cloudflare.com/hc/en-
us/articles/204899617-A...](https://support.cloudflare.com/hc/en-
us/articles/204899617-Authenticated-Origin-Pulls)

~~~
ckuehl
Also keep in mind that if you use IP-based whitelisting, an attacker can
register their own CF/Fastly account and target your origin server with
whatever CDN settings they want (assuming they can discover your origin
server). With Fastly at least you can even do this from the free tier.

~~~
jaywalk
Took me a second to wrap my head around what you were saying, so I'll point it
out: they'd be pointing their CDN account to your origin server, and making
requests through it.

~~~
judge2020
Same for Cloudflare - to mitigate this your server should only respond to the
correct HOST header for your website.

------
wpietri
I was unfamiliar with request smuggling; here's an explainer:
[https://portswigger.net/web-security/request-
smuggling](https://portswigger.net/web-security/request-smuggling)

The first in-band signalling attack I came across was the blue box [1],
invented in the late 1960s. It still occasionally worked in the 1980s on older
phone systems. It amazes me that we're still creating new systems vulnerable
to in-band attacks.

[1]
[https://en.wikipedia.org/wiki/Blue_box](https://en.wikipedia.org/wiki/Blue_box)

~~~
JangoSteve
Can someone explain the redirect/cookie-stealing part of this? I read through
the post explaining request smuggling, and then re-read their exploit
description, and the request smuggling part all makes sense. However, I don't
fully understand the significance of the 301 in relation to the browser
sending the attacker's server the cookie with the request.

If the back-end server is already proxying whatever request it receives from
the front-end proxy server, why was it necessary to first get it to redirect
an HTTP 1.1 header to an https request? The only thing I could think of was
that maybe it has something to do with getting the unencrypted cookie, but
according to their description, the forwarded request with the cookie doesn't
happen until after the redirect to https anyway.

I know I'm missing something obvious here.

~~~
terom
The collab_2.png screenshot shows `User-Agent: ... Slack/4.1.2 ...
Electron/6.0.10 ...`, so it's their own desktop app doing the
[https://slackb.com/..](https://slackb.com/..). HTTP 301 ->
[https://*.burpcollaborator.com](https://*.burpcollaborator.com) request.
Perhaps their client implements its own quirky redirect-following, which keeps
the the original `Cookie: ...` headers in the redirected request?

I find it hard to believe that any browser would keep the original `Cookie:
...` headers in a redirected request to a different origin.

~~~
JangoSteve
Interesting! That's definitely something I missed, thank you.

I still wouldn't expect an Electron app to subvert basic browser sandboxing by
default, particularly where they wouldn't have expected to need to redirect
users to other domains with cookies intact. It seems like they'd need to go
out of their way to enable that.

I wonder if it has to do with the sign-in tokens they send or otherwise
allowing the user to move between the browser and the app within their
account. For example, when you're in the app and click "Manage Users" and it
sends you to a management dashboard in the browser. or when you click a link
with an auth token in the browser and it launches you into the app.

------
gavingmiller
Anyone know if the `smuggler` tool used is available online? Can't find any
reference to it in github or elsewhere, and I'm not familiar with it.

Edit: Found it here: [https://github.com/gwen001/pentest-
tools/blob/master/smuggle...](https://github.com/gwen001/pentest-
tools/blob/master/smuggler.py)

~~~
dt3ft
Thank you, I was looking for this as well.

------
mcherm
> I did not expect for this finding to go from submit to fix/bounty in a
> matter of 24 hours.

I didn't expect that either. I am very pleasantly surprised. I hope my own
company would do as well as Slack did here, but I am not certain whether we
would.

~~~
caymanjim
This was probably a one-line code fix in the end. I'm sure they added extra
tests and guards, but at its core, this is a trivial change. I've worked at
less-than-agile companies before, but if the turnaround on something like this
is more than 24 hours, that's pretty bad.

------
Lex-2008
Greatly detailed report and impressive resolution speed, indeed, but sadly it
fell behind the cracks regarding disclosure.

~~~
andrekorol
What do you mean by "it fell behind the cracks regarding disclosure"?

~~~
harrier
After the issue was resolved the reporter was asked to wait before disclosure.
The reporter waited three months before asking about it again. After that
there was response but it took another month the approve the disclosure.

~~~
andrekorol
Oh, now I get it. Thanks for the clarification.

------
phonebucket
I'm impressed by how competent and professional some independent security
researchers are.

How do people learn this stuff? Are there any resources that anyone here can
recommend?

~~~
JMTQp8lwXL
In this particular instance, it's a savvy understanding of the HTTP protocol.
Both the 'Transfer-Encoding' and 'Content-Length' headers have opposite goals:
one says how many bytes of response body data there is; the other signals that
it is limitless until (IIRC) an empty newline is transmitted.

Realizing that different systems resolve the question of "Well, what should I
(the system) do when I get both headers?" and you realize you can break the
atomicity of the HTTP request-- which opens up a really interesting (and
severe) class of exploits.

I'm not very good at finding vulnerabilities, beyond the obvious sql-injection
attack types that we are generally trained to avoid. I imagine, however,
getting good at finding these is a skill that can be learned with time.
Alternatively, finding vulnerabilities might be more akin to pharmaceutical
developments: with a 1,000 swings, you're missing at least 950 of them, or
more. A dash of luck in there.

~~~
tptacek
It probably helps to know that this particular bug was a major announcement at
Black Hat last year, by James Kettle, who is a vulnerability research
celebrity. So lots of people are looking for this particular bug.

Black Hat talks are eventually published online for free; here's this one:

[https://www.youtube.com/watch?v=upEMlJeU_Ik](https://www.youtube.com/watch?v=upEMlJeU_Ik)

~~~
JMTQp8lwXL
Given how widely publicized request smuggling was, I'm surprised it's still a
problem for apps with large user bases like Slack.

~~~
lonelappde
Other commenters note that some platforms intentionally leave this vuln open
because closing it breaks some buggy clients. Convenience over security.

~~~
JMTQp8lwXL
I suppose if having account takeovers is worth the convenience-- sure, it's a
tradeoff each company will have to make individually.

------
anonfunction
> Re: disclosure - a redacted disclosure will be fine, but we'll need to hold
> off for a little bit while we perform our investigation. We'll keep you
> updated in the meantime, and once we've concluded there wasn't a customer
> impact we can disclose this. Thanks for your patience!

Does this mean they wouldn't want to disclose it if the same exploit was used
against users by another hacker?

~~~
jaywalk
No, it means they'd want affected customers to hear it from them first.

------
Bhilai
Original Paper for those interested - [https://portswigger.net/research/http-
desync-attacks-request...](https://portswigger.net/research/http-desync-
attacks-request-smuggling-reborn)

------
ec109685
The fact that you can steal cookies like this is such a flaw in the way the
web works. We need to move to tokens that the browser is in control of that
provides this device has access to this resource.

------
londons_explore
And the real lesson here is HTTP probably isn't a good protocol between your
proxies and your backends, and you should probably use HTTP/3 to fully
eliminate this entire class of bug.

~~~
SahAssar
HTTP/2 also works to fix this, right?

~~~
kevin_thibedeau
Proxies would be forced to keep track of headers.

------
fiberoptick
Wow, an ATO exploit that only received a $6,500 bounty? This signals to
grey-/black-hat researchers that their research efforts or Slack bug
disclosures are best directed elsewhere..

~~~
NikolaeVarius
The literal hacker themselves indicated it was a fair payout.

I don't understand unsolicited complaining for other people.

~~~
pathseeker
>I don't understand unsolicited complaining for other people.

If you observe someone getting paid a much lower-than-market amount for
something you can complain that the company is being cheap and likely driving
away a lot of potential sellers (security researchers in this case) regardless
of how happy the one person is.

~~~
tptacek
This is not a below-market rate.

~~~
fiberoptick
I noticed that throughout this thread you have been making this assertion.
Could you share any data or citations to support this?

Would you feel any differently about the value of this bug if it affected,
e.g. Google or Facebook?

~~~
tptacek
No, I would not feel differently about it. The same dynamic would apply.

People on HN seem generally to believe that for any malicious activity you
could do with a bug, there's a bidding group of willing buyers somewhere on
some darknet site. That's not the case. Random bugs like this may get passed
around, but the bugs that command a price all fit a couple specific molds:
they're things you can drop into someone's existing operational process.

A Firefox drive-by RCE has some value: many organizations are set up to
actively exploit Firefox browsers. So does an iOS jailbreak: lots of people
stockpile iOS jailbreaks, for malware implants and for other purposes.

An important common thread among the bugs with liquid markets is that they
have a meaningful half-life: once they're burned, it still takes time to
eradicate the vulnerable installations. Serverside bugs are fixed worldwide
instantaneously. You can see this dynamic in how grey-market payments are
tranched.

~~~
pathseeker
This ignores the black market. This exploit would have been extremely valuable
to insider trading rings.

------
_em_
is there any website which teaches these kind of hacking? I am interested in
it but not as a full time job.

