[dantillberg]

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

[joshstrange]

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.

[jwilkins]

Interestingly, I put the same bug in at HackerOne 9 months ago. It was closed as not applicable. So they had at least two independent reports of the same bug and failed to understand it, acknowledge it and then fix it.

Way to go slack.

If you have any critical data passing through slack, when you get owned, you won't be able to say say it wasn't entirely preventable.

[jwilkins]

One thing I can add from my analysis is that there aren't seperate counters for files/teams/etc. there's only one. So if a given id is used by a team, it won't be used as a file id.