Live data from Hacker News

Hidden in plain sight: Brute-forcing Slack private files

ibuildings.nl

21–30 of 53 posts

Re: Hidden in plain sight: Brute-forcing Slack private files

#21
post #17
post #15

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.

To be fair, most of the bad correspondence was from 2014. Their new representative 'Leigh' appears to be doing excellent work. Also we're still happy users of Slack, I would just never trust them with secrets :-).

Re: Hidden in plain sight: Brute-forcing Slack private files

#22
post #2

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

Careful, being unguessable is not one of the properties required of a UUID. All a UUID guarantees is that two UUIDs generated by the specified procedure will never match, even if they're generated by different computers not in communication with each other. But it does not guarantee that an attacker cannot generate the same UUID generated by somebody else if they follow a different procedure.

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

#23
post #5

The 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

#24
post #12

Earlier 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

Unfortunately that is not necessarily true, as nothing requires a UUIDv4 generator to use a cryptographically secure source of randomness.

Re: Hidden in plain sight: Brute-forcing Slack private files

#25

Summary 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…

Also important to note it took Slack over a year to fix this issue often with long stretches of silence even with requests from the bug hunter.

Re: Hidden in plain sight: Brute-forcing Slack private files

#28
post #5

The 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/

The guideline for unguessability in that TR just says to use a UUID. UUIDs are ugly, and quite long for the amount of randomness they contain. I prefer Slack's new 10*base36 solution.

Re: Hidden in plain sight: Brute-forcing Slack private files

#30
post #29

What 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?

Not to mention making public file sharing explicit instead of implicit, or at least giving the option to exclude specific files from a public URL.
Post reply on HN