Hidden in plain sight: Brute-forcing Slack private files
1–10 of 53 posts
Re: Hidden in plain sight: Brute-forcing Slack private files
#2Github does something similar, if you drag an image into the textarea in their issue tracker, it uploads the image to (I think) a public URL. I've considered what this could mean for teams with private projects who might e.g. attach screenshots with sensitive information.
Here's an example of an image uploaded via the GH issue tracker. Definitely public.
https://cloud.githubusercontent.com/assets/95562/7319912/200...
Re: Hidden in plain sight: Brute-forcing Slack private files
#3Damn, over a year to fix this? It's good that they did in the end, but the timeline is just crazy.
Re: Hidden in plain sight: Brute-forcing Slack private files
#4Github does something similar, if you drag an image into the textarea in their issue tracker, it uploads the image to (I think) a public URL. I've considered what this could mean for teams with private projects who might e.g. attach screenshots with sensitive information. Here's an example of an image uploaded via the GH issue tracker. Definitely public. https://cloud.githubusercontent.com/assets/95562/7319912/200...
The good news is that github puts a uuid in the url, so its unguessable.
Slack, on the other hand, didn't have a big unguessable number... they had a very small number you could brute-force.
Re: Hidden in plain sight: Brute-forcing Slack private files
#5The correct answer for using URLs as capabilities (which is what a 'secret URL' really is: a capability to a resource, which can be handed out, copied &c.) is to use a 256-bit value as part of the URL. Thus, rather than 'http://example.invalid/TEAM-DOC-SHORT-RAND/' use 'http://example.invalid/w6uP8Tcg6K2QR905Rms8iXTlksL6OD1KOWBxT.... If you're really paranoid, double the length. I guarantee it won't be guessed, in either case.
Re: Hidden in plain sight: Brute-forcing Slack private files
#6Summary from my read of this: (the article does a great job of couching the process of exploiting this, as well as motivating why these numbers are too low, but here are the vulnerabilities...)
- Slack chose to use a 6-hexadigit/24-bit "secret code" as the only/final code required to download "privately" shared files. That's way too short; people have botnets almost that big, such that even aggressive IP-based rate-limiting wouldn't stand a chance.
They might have also made these fairly common mistakes (which served to compound the vulnerability):
- Returning different/distinguishable error codes when the request matches correctly on some parts but not all. This allows attackers to guess each in turn.
- Considering values such as the "file ID" to provide additional security/entropy, when in fact these IDs are generated semi-sequentially, and thus a moderately-sophisticated attacker can narrow the search space dramatically.
- Considering values such as the "filename" to provide more security/entropy; however, you can make no guarantees about the length or uniqueness of filenames, so you shouldn't consider that a security feature at all.
Re: Hidden in plain sight: Brute-forcing Slack private files
#7The correct answer for using URLs as capabilities (which is what a 'secret URL' really is: a capability to a resource, which can be handed out, copied &c.) is to use a 256-bit value as part of the URL. Thus, rather than ' http://example.invalid/TEAM-DOC-SHORT-RAND/' use ' http://example.invalid/w6uP8Tcg6K2QR905Rms8iXTlksL6OD1KOWBxT... . If you're really paranoid, double the length. I guarantee it won't be guessed, in…
Yes, exactly this. It's not rocket science; it's odd how much effort Slack put into implementing (and then reimplementing in a slightly less broken fashion) a clearly wrong solution.
Re: Hidden in plain sight: Brute-forcing Slack private files
#8Github does something similar, if you drag an image into the textarea in their issue tracker, it uploads the image to (I think) a public URL. I've considered what this could mean for teams with private projects who might e.g. attach screenshots with sensitive information. Here's an example of an image uploaded via the GH issue tracker. Definitely public. https://cloud.githubusercontent.com/assets/95562/7319912/200...
The problem is not with having public urls. The problem is with public urls that don't have enough random numbers or if these numbers aren't generated by a CSPRNG.
Re: Hidden in plain sight: Brute-forcing Slack private files
#9Github does something similar, if you drag an image into the textarea in their issue tracker, it uploads the image to (I think) a public URL. I've considered what this could mean for teams with private projects who might e.g. attach screenshots with sensitive information. Here's an example of an image uploaded via the GH issue tracker. Definitely public. https://cloud.githubusercontent.com/assets/95562/7319912/200...
The good news is that github puts a uuid in the url, so its unguessable. Slack, on the other hand, didn't have a big unguessable number... they had a very small number you could brute-force.
UUIDs are (usually) generated in a systematic fashion, so large parts of them are often possible to determine ahead of time.
Re: Hidden in plain sight: Brute-forcing Slack private files
#10This should indeed inform potential users of additional security risks of using Slack, especially for communication of corporate confidential information. That said, this isn't a realistic threat to my own social use of Slack.