Live data from Hacker News

Hidden in plain sight: Brute-forcing Slack private files

ibuildings.nl

51–53 of 53 posts

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

#51

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.

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.

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

#52

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.

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.
Post reply on HN