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

Instagram's Million Dollar Bug

exfiltrated.com

Post reply on HN
Print view View original

431–440 of 562 posts

Re: Instagram's Million Dollar Bug

#431

Post by jhchen »

ryaniscool wrote: post #412
jhchen wrote: post #392

Earlier quoted context omitted.

Guy discloses vulnerability. Facebook is not as impressed as guy would have hoped. Maybe it's because he's one of several people to disclose the same vulnerability. Maybe there are just a lot of vulnerabilities (they've paid out 4.3m in bounties). Guy's reaction to rejection: take hostages and threaten Facebook. Facebook moves to defense and cuts guy off. You are not a good neighbor for kidnapping someone's family to…

This is, of course, Facebook's narrative which conflict's with Wes's. One obvious hole I can see in Facebook's story is that they insinuate that Wes broke back into the server after they disputed the bounty. If this were true, they did nothing in response to the problems Wes found for over a month. If you look at Wes's timeline, he says access to the server was no longer possible a few days after he filed the second…

"With the newly obtained AWS key... I queued up several buckets to download, and went to bed for the night."

He definitely took data off of Facebook's server.

Also you misunderstand his access being denied was a firewall change earlier in his story. This was merely to speculate other systems he could have penetrated--completely separate from the S3 buckets he took data from.

From Facebook's perspective it could very well have seemed like he went back for the goods since he submitted three separate reports, the last of which triggered the response. But this is also irrelevant, the question is whether he took data off or not and this is unambiguously yes, by Wes's own admission.

Re: Instagram's Million Dollar Bug

#432

Post by lovelearning »

joshuahutt wrote: post #364
lox wrote: post #319

Earlier quoted context omitted.

Yes, exactly this. Without escalating an RCE, how would he have been able to expose this absolutely huge flaw? The initial report was inconsequential, but this seems like at the very least a much more than $2500 bug. If things like this are considered "unethical" it kind of makes finding million dollar bugs in a bug bounty close to impossible.

I agree. According to Stamos, though, there was no flaw: > The fact that AWS keys can be used to access S3 is expected behavior and would not be considered a security flaw in itself.

That surprised me too. Of course, AWS keys can be used to access S3, but I don't see how exposing private AWS keys on a public facing server can be "expected behavior".

Re: Instagram's Million Dollar Bug

#433

Post by dandelany »

eastonhockey19 wrote: post #318
dandelany wrote: post #296

Earlier quoted context omitted.

Alex said they "have no evidence" it happened, which is classic slippery legalese. From that phrase it is reasonable to infer either that they have evidence of absence, or absence of evidence, which are not the same thing.

It's standard wording for something like this even if they had 100% evidence of absence.

Correct. It's the standard wording, whether or not they actually have evidence. Therefore we cannot assume, as you have earlier in this thread, that they do in fact have it.

Re: Instagram's Million Dollar Bug

#434

Post by HappyTypist »

joshAg wrote: post #235
secalex wrote: post #131

Thank you to everybody who cautioned against judgment before hearing the whole story. Here is my response: https://www.facebook.com/notes/alex-stamos/bug-bounty-ethics...

I think the root cause of the problem is the unclear policy by FB. Privilege escalation can be hard to catch, and can be a separate bug in and of itself, even if it requires a separate exploit to get the initial privileges. The published policy didn't say anything about not doing what he did. I'm not going to argue that what he did should or shouldn't be ok, but FB has no control over what other people do. Yeah, mayb…

No, the root cause is having a 2 year old, known RCE that was only patched after this researcher got SSL certs and app signing certs.

Re: Instagram's Million Dollar Bug

#435

Post by [deleted] »

bigiain wrote: post #288
secalex wrote: post #244

Earlier quoted context omitted.

Different key, dude. We rotated what was exposed.

So this new rotated key I'm seeing that has an April 2015 start date is a different key to the one your team replaced after it expired and broke everything back in April? What a coincidence...

[deleted]

Re: Instagram's Million Dollar Bug

#436

Post by droopybuns »

agrot3ra wrote: post #227
bigiain wrote: post #223

Earlier quoted context omitted.

I can't work out how to not make this sound almost infinitely cynical, but their ssl key expires in 13 days - they only had to shut him up for another few weeks and they could have pretended they weren't currently MITM-able: https://www.instagram.com Not Valid After: Thursday, 31 December 2015 11:00:00 pm Australian Eastern Daylight Time Maybe they'll upgrade it to something better than: Signature algorithm SHA1withR…

Does this have anything to do with the SHA1 sunset on 31 December?

outstanding question.

Re: Instagram's Million Dollar Bug

#437

Post by ryanlol »

res0nat0r wrote: post #386
ryanlol wrote: post #224

Earlier quoted context omitted.

Why have you not rotated your private keys? notBefore=Apr 14 00:00:00 2015 GMT notAfter=Dec 31 12:00:00 2015 GMT (Feel free to respond here if you want to pay me the bug bounty for this)

$ echo | openssl s_client -connect www.instagram.com:443 2>/dev/null | openssl x509 -noout -dates notBefore=Apr 14 00:00:00 2015 GMT notAfter=Dec 31 12:00:00 2015 GMT AWS bucket creds are not the same thing as SSL certs and were most likely specific to only relevant s3 buckets which are totally separate from any load balancers.

I never claimed that AWS bucket creds were the same thing as SSL certs.

Re: Instagram's Million Dollar Bug

#438

Post by latkin »

tptacek wrote: post #135

Alex responds: https://www.facebook.com/notes/alex-stamos/bug-bounty-ethics... Critically: At this point, it was reasonable to believe that Wes was operating on behalf of Synack. His account on our portal mentions Synack as his affiliation, he has interacted with us using a synack.com email address, and he has written blog posts that are used by Synack for marketing purposes. Alex's timeline seems like it matches wha…

> his account on our portal mentions Synack as his affiliation

Can someone clarify exactly what portal is referred to here? Is it something besides https://www.facebook.com/whitehat/report/ ?

If not, this is a totally bogus excuse.

Re: Instagram's Million Dollar Bug

#439

Post by BHSPitMonkey »

jhchen wrote: post #410
blazespin wrote: post #406

Earlier quoted context omitted.

At no point did he take hostages. It's that sort of thinking that lead to all this drama in the first place. He did however disclose, which is pretty reasonable considering a lot of us are trusting these services to protect our information. What if Instagram blead all your browser information? So people can now fingerprint billions of people and figure out who (and their pictures) are surfing their sites? What if the…

Downloading data is where he crossed the line and what I meant by hostage: "Wes was not happy with the amount we offered him, and responded with a message explaining that he had downloaded data from S3 using the AWS key..."

You make "downloading" sound more sinister than it is. Downloading something from the network is the only way to see that it's there or know what it is. There is no substantial difference between downloading and viewing in this case.

Re: Instagram's Million Dollar Bug

#440

Post by BHSPitMonkey »

option_greek wrote: post #405
joshuahutt wrote: post #364

Earlier quoted context omitted.

I agree. According to Stamos, though, there was no flaw: > The fact that AWS keys can be used to access S3 is expected behavior and would not be considered a security flaw in itself.

If he thinks that is how it should be and nothing needs to be changed then god save their user data. He conveniently missed out the key separation and privilege escalation shown by the researcher.

Yeah, that's like gaining root access on a server and being told "well, the fact that those commands will execute is merely Linux working as designed". Talk about missing the point...
Post reply on HN