Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Hidden in plain sight: Brute-forcing Slack private files

ibuildings.nl

Post reply on HN
Print view View original

41–50 of 53 posts

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

#41

Post by Drdrdrq »

fishtoaster wrote: post #36

This reminds me of my experience with Imgur's private images. A few years ago, I wrote a little js tool to browse random Imgur images by guessing their urls (i.imgur.com/ ) until it found one that succeeded. It would add the found image to an infinite-scrolling page. It was kinda fun to browse, and a lot of people seemed to enjoy playing with it. After a couple years, though, Imgur suddenly started blocking access to…

I had a similar experience, though I was on the other side. Under brute force login attack IT guy suggested I change login HTTP method from GET to POST (which is more appropriate anyway). While I agreed with him that this is better, I pointed out that this is very easy to circumvent. However he proved me wrong - the attacks stopped after that (and I am quite sure it is not because they gained access). Not all attackers are very determined...

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

#42

Post by MichaelGG »

mikeash wrote: post #39
MichaelGG wrote: post #37

Earlier quoted context omitted.

Basically the whole "version" UUIDs is a stupid fever dream. Any sane implementation should return 16 random bytes and be done. The fact that there's a spec for this and it's longer than 2 sentences is just wrong.

I think they were just afraid of the birthday paradox. But I agree, just grabbing some random bytes really is the way to go. Although, I'm a bit afraid of the birthday paradox, maybe we should use 20 bytes instead....

The idea that a UUID should have a "version" and the random one uses 122 bits instead of 128 bits sorta makes ya wonder how concerned they were.

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

#43

Post by arice »

relaxnow wrote: post #20
kordless wrote: post #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 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.

Great feedback, thanks.

The 180 day guidance you reference falls under a "Last Resort" clause when "... the Response Team [is] unable or unwilling to provide a disclosure timeline". (which, at first glance, might not have been the case here?)

These "Last Resort" scenarios have not yet been fully codified. As a safety precaution, the workflow is still initiated manually with support as these scenarios are extremely rare and littered with edge cases. We've been learning a lot from studying disclosures like this one and you can expect to see the "Last Resort" workflow codified in the product in the future.

Now that the report has been Resolved, you should see the normal disclosure options available. Please always feel free to send me a note if you have any questions or feedback on our disclosure workflows - especially if we don't support your preferred route.

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

#44

Post by wahsd »

relaxnow wrote: post #40
wahsd wrote: post #26

Dude! You have got to take a better profile picture. Really? Smug eastern block open collar look with an earbud in? No good. No good at all.

Heh, well it is an old picture, I'll see if I can't get a better one made. I didn't join IT for my looks though so hopefully it doesn't stand in the way of your enjoyment of the content.

No, it doesn't. I was just kidding. It was the first thing that caught my eye. No worries, it seems the white-knight brigade is out to defend your honor though.

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

#45

Post by jasonwatkinspdx »

MichaelGG wrote: post #37
mikeash wrote: post #35

Earlier quoted context omitted.

The random ones don't have to be unpredictable randomness, either. For example, you might seed a good RNG with the local MAC address and boot time and then use that to generate v4 UUIDs. As far as I can tell, this would be perfectly legal and should produce UUIDs that are as likely to be unique as any other, but they would also be easy for an attacker to predict.

Basically the whole "version" UUIDs is a stupid fever dream. Any sane implementation should return 16 random bytes and be done. The fact that there's a spec for this and it's longer than 2 sentences is just wrong.

Yeah, spot on. At least now in 2015 using 16 bytes for id's and hashes no longer seems like a lot of memory or storage.

It pains me to see people inventing weird id schemes for every app and api.

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

#46

Post by the_wolf »

Simple how-to instructions:

  1. log into slack

  2. share a private file

  3. go to:
> https://api.slack.com/web

  4. generate API token

  5. copy the link to your private file, and paste as plain text.

  6. a file id is in the link, somewhere

  7. try out the file id by visiting links like:
> https://slack.com/api/files.info?token=#secret!&file=???????...?

  8. see also:
> https://api.slack.com/methods/files.info

  9. in the JSON output you will CTRL+F to see an address like:
> https://slack-files.com/#########-?????????-!!!!!!!!!

  10. slackbot warns you, and only you, once and only once 
      that someone found that link. this notification may
      get buried, or forgotten about. it is your only chance
      to revoke the public link.

  11. if you forget about that link, and it goes viral with 
      millions of visits, lots of luck gentlemen!

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

#47

Post by dang »

wahsd wrote: post #44
relaxnow wrote: post #40

Earlier quoted context omitted.

Heh, well it is an old picture, I'll see if I can't get a better one made. I didn't join IT for my looks though so hopefully it doesn't stand in the way of your enjoyment of the content.

No, it doesn't. I was just kidding. It was the first thing that caught my eye. No worries, it seems the white-knight brigade is out to defend your honor though.

I thought it was pretty obvious that you were just kidding, but it's the sort of comment that is hard to interpret correctly, and anyone who missed the jovial tone would have thought it was pretty mean.

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

#48

Post by wzm »

Do a google search for site:https://s3.amazonaws.com/uploads.hipchat.com/ , Atlassian does the same thing, and hasn't really addressed customer questions about it for a long time. https://help.hipchat.com/forums/138883-suggestions-ideas/sug... is a long running Atlassian support ticket for this.

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

#49

Post by wtbob »

relaxnow wrote: post #14
wtbob wrote: 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…

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.

> Don't forget that it should ideally be cryptographically random.

I thought that went without saying, nut yes, it must be cryptographically random (not ideally—it must be).

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

#50

Post by willvarfar »

mikeash wrote: post #22
willvarfar wrote: post #4

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

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

The github sourcecode is not open-source, but they've open-sourced a lot of other code in which they seem to be using Ruby's `SecureRandom::uuid()` function in the same kind of context for generating what they term 'opaque ids'.
Post reply on HN