Damn, over a year to fix this? It's good that they did in the end, but the timeline is just crazy.
Maybe someone needed time to brute force all those tasty files hanging around ;)
Hidden in plain sight: Brute-forcing Slack private files
11–20 of 53 posts
Re: Hidden in plain sight: Brute-forcing Slack private files
#12Earlier quoted context omitted.
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.
Not in guid v4
Re: Hidden in plain sight: Brute-forcing Slack private files
#13Github 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.
Doesn't help how complex your URL is if legitimate users can pass it to anyone else who can then access the file without proper authorization.
Re: Hidden in plain sight: Brute-forcing Slack private files
#14The 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…
Don't forget that it should ideally be cryptographically random. If the sequence is predictable (like based on an auto incrementing number or on time) then you might still be able to guess a 256-bit number.
Re: Hidden in plain sight: Brute-forcing Slack private files
#15The best part of the story actually comes at the end, back-and-forth messaging with slack about the bug report
Re: Hidden in plain sight: Brute-forcing Slack private files
#16Earlier quoted context omitted.
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.
Doesn't help how complex your URL is if legitimate users can pass it to anyone else who can then access the file without proper authorization.
It does help. Malicious users intending to share files can do so without having a public URL.
Re: Hidden in plain sight: Brute-forcing Slack private files
#17The 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.
Re: Hidden in plain sight: Brute-forcing Slack private files
#18> We apologize for the delayed reply. We track these issues via our internal bug system, and only reply to the reporter once the bug is resolved internally. We generally ignore messages asking for updates, as we receive a high volume of these (even for non-issues).
This rationalization is illogical, which usually means someone is in conflict. From a logical standpoint, externally, it could be they are fixing something OR don't know about it OR don't care.
Given the conflicting rationalization, I'd say they didn't know about it and then made up an excuse instead of owning it.
Re: Hidden in plain sight: Brute-forcing Slack private files
#19Earlier quoted context omitted.
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.
Doesn't help how complex your URL is if legitimate users can pass it to anyone else who can then access the file without proper authorization.
Preventing legitimate users from sharing the data with malicious users is essentially what DRM is, and as we all know DRM is never perfect and rarely any good at all.
It's much more important to prevent malicious users from being able to access these files without the help of legitimate users. Which seems like an obvious thing to do, but it's what Slack has failed at here. It's impossible to tell from that one GitHub URL whether they get this right or not.
Re: Hidden in plain sight: Brute-forcing Slack private files
#20> We apologize for the delayed reply. We track these issues via our internal bug system, and only reply to the reporter once the bug is resolved internally. We generally ignore messages asking for updates, as we receive a high volume of these (even for non-issues). This rationalization is illogical, which usually means someone is in conflict. From a logical standpoint, externally, it could be they are fixing somethin…
It probably means that they're not prioritising vulnerability reports. Which is their prerogative honestly, but it doesn't make researchers happy to work with you.
The biggest 'fault' here I think lies squarely with HackerOne. They should've enforced their own guidelines and given me the option to publish in their system after 180 days. But I still don't have that option.