The best part of the story actually comes at the end, back-and-forth messaging with slack about the bug report
definitely, I'm disappointed with slacks responses. We did a trial and have had some correspondence with their support team which has been excellent to date. So I assumed they were above some of this silicon valley elitism. I'm glad to see this kind of public disclosure. We have been a customer since that initial trial, we stopped using hipchat.
Hidden in plain sight: Brute-forcing Slack private files
21–30 of 53 posts
Re: Hidden in plain sight: Brute-forcing Slack private files
#22Github 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.
It's the difference between avoiding collisions between cooperating entities, and avoiding collisions from malicious entities.
For example, a version 1 UUID is just the combination of the computer's MAC address and the current time. This is sufficient to guarantee uniqueness (as long as you don't duplicate MAC addresses, and you wait at least 100 nanoseconds between generating successive UUIDs) but will be pretty easy to guess if you have a rough idea of when the UUID was generated and which manufacturer might have made the NIC on the machine where it was generated.
More abstractly, a version 4 UUID is just a couple of identifying bits and 122 random bits, but the nature of the random bits is not specified. Your UUID generator may well use a PRNG that is not cryptographically secure, which could still be good enough for cooperative uniqueness, but not good enough to avoid predictability. (For example, a PRNG seeded with the machine's MAC address and boot time would fit this.)
In short, don't rely on a UUID being secret unless you know exactly how it's being generated, all the way down to the underlying random number generator. And if you're going that far, you might as well just read 16 bytes from /dev/random and be done with it.
Re: Hidden in plain sight: Brute-forcing Slack private files
#23The 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…
Re: Hidden in plain sight: Brute-forcing Slack private files
#24Earlier quoted context omitted.
UUIDs are (usually) generated in a systematic fashion, so large parts of them are often possible to determine ahead of time.
Not in guid v4
Re: Hidden in plain sight: Brute-forcing Slack private files
#25Summary 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-l…
Re: Hidden in plain sight: Brute-forcing Slack private files
#26Re: Hidden in plain sight: Brute-forcing Slack private files
#27Re: Hidden in plain sight: Brute-forcing Slack private files
#28The 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…
w3 has some guidelines on capability urls: http://www.w3.org/TR/capability-urls/
Re: Hidden in plain sight: Brute-forcing Slack private files
#29Re: Hidden in plain sight: Brute-forcing Slack private files
#30What kills me is that this seems like such an unforced error. Just make 256-bit random tokens. They're private URLs. Who cares how ugly they are?