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

61–70 of 562 posts

Re: Instagram's Million Dollar Bug

#61

Post by tptacek »

three14 wrote: post #58
tptacek wrote: post #49

Earlier quoted context omitted.

Do you see what a ridiculous no-win situation this is? Option 1: Call the pentest firm he works for. Option 2: Threaten legal action. Option 3: This dude might still be walking around with god knows what shit he's pulled out of S3 buckets or lord knows what else was accessible with those AWS keys or what other keys were in other S3 buckets or wow i'm having a small panic attack just trying to complete that sentence

How about Option 4: calling him ?

I don't know whether they tried, or if they didn't, why they didn't. Like I wrote below[1], I'm wondering what the rest of the story is. This isn't the first person to have submitted an RCE to Facebook, but it's the first person to get Facebook to go nuclear over a submission. Why?

[1]: https://news.ycombinator.com/item?id=10754627

Re: Instagram's Million Dollar Bug

#62

Post by Qualman »

daveloyall wrote: post #38

In my opinion, the author is feigning shock... He claims to have downloaded the content listed below. And he is surprised that Facebook responds coldly? Note the string "private keys" in this list... Doesn't the author know how long it will take them to recover from this breech? How much it will cost them? On the other hand, it does sort of re-enforce the idea that he should be paid handsomely, doesn't it? :) * Stati…

Is this not the point of a Whitehat bounty program? To entice someone to discover and disclose a bug in a trustworthy manner?

If they react this way, and can't trust people to attempt to find exploitable security holes on their system (even those that yield private keys), then what is the point at all? The only people that find them then, are not going to be as cooperative about it.

> Doesn't the author know how long it will take them to recover from this breech? How much it will cost them?

This is not the author's fault. He did nothing but disclose bugs that Facebook themselves set in place, and seemed to be very open with them about it, at that.

Re: Instagram's Million Dollar Bug

#63

Post by joslin01 »

tptacek wrote: post #39
joslin01 wrote: post #27

The thing that gets to me is the lack of gratitude on Facebook's end. Instead, they turn him into the villain for breaking imaginary rules. What would have been the harm in slapping him on the wrist and giving him some sort of reward for exposing a huge vulnerability? Instead, they eat the reward and shit on the guy who produced it. Real classy FB.

Did you read the whole post? He got paid on the RCE.

Yea I did and I realize he got paid out a little, but it was short of the $1 million.

I realize a million is a bit unrealistic, but if you're going to make a public statement, at least back it up or prove to the guy why his findings don't constitute a "million-dollar bug". It's not right to just cold-shoulder the guy and hide behind vague rules that were never clearly outlined. In fact, you might even conclude Facebook brought his behavior on themselves by making such a statement as "if a million-dollar bug is found, we'll pay it out." $2500 is nothing when you're thinking $1,000,000

Re: Instagram's Million Dollar Bug

#64

Post by tptacek »

dogecoinbase wrote: post #52
tptacek wrote: post #36

Earlier quoted context omitted.

No, that's the next step in an external penetration test , which is not the same thing as a vulnerability assessment. In an external pentest, you get a set of netblocks and rules of engagement, and you get as far as you can. That's why it's called a "penetration test". In a vulnerability assessment, you get a target (usually an application), and you find as many flaws in that target as you can. Big annual pentests of…

You're HN's anointed expert, so I suppose all I can say is that's not my experience. Among the many reasons bug bounties are bad ideas is that they generally fail to write clear rules -- as Facebook did. As written, what he did is not against the rules and while it may fall into some best-practices bucket you assert to be universal, that's hardly sufficient for a field in which participants can come from any backgrou…

then responded by threatening a researcher's employment after multiple conciliatory e-mails.

That is NOT what happened. Look at the timeline again.

* He popped the server.

* He submitted the RCE.

* He submitted dumped file from the compromise as a finding.

* They fixed the RCE.

* They told him not to dump files.

* They paid out the RCE finding.

* A month later, they declined to pay out on the dumped file.

* In response, he submits a new finding, with AWS creds that he stored for more than a month after they shut down the server

* (Whatever else happens that day)

* Stamos calls Synack.

Re: Instagram's Million Dollar Bug

#65

Post by tptacek »

joslin01 wrote: post #63
tptacek wrote: post #39

Earlier quoted context omitted.

Did you read the whole post? He got paid on the RCE.

Yea I did and I realize he got paid out a little, but it was short of the $1 million. I realize a million is a bit unrealistic, but if you're going to make a public statement, at least back it up or prove to the guy why his findings don't constitute a "million-dollar bug". It's not right to just cold-shoulder the guy and hide behind vague rules that were never clearly outlined. In fact, you might even conclude Facebo…

Nobody is going to pay you a million dollars in 2015 for the 2013 Rails YAML bug in a stale server. Nobody is going to pay you a million dollars for a reliable Firefox RCE, and those take months to prove out and develop, and there's a liquid market for them.

Re: Instagram's Million Dollar Bug

#66

Post by troebr »

daveloyall wrote: post #38

In my opinion, the author is feigning shock... He claims to have downloaded the content listed below. And he is surprised that Facebook responds coldly? Note the string "private keys" in this list... Doesn't the author know how long it will take them to recover from this breech? How much it will cost them? On the other hand, it does sort of re-enforce the idea that he should be paid handsomely, doesn't it? :) * Stati…

I would tend to agree.

Facebook's point is that he found a vulnerability, and exploited it instead of stopping there. I kind of understand their point of view though. "See you have a vulnerability there, and then I can get access to this, and then this, and see now I have the password of your user, and then I'm just one click away from accessing all the instagram pictures I want."

Although Facebook's handling of the problem is poor (why didn't the CSO call the author directly to get things squared out? He does not talk to people who are not C*O?), they do have a point.

I think the author acted in good faith, but got carried away by his findings unfortunately.

Re: Instagram's Million Dollar Bug

#68

Post by danso »

Animats wrote: post #53

The initial bug in Ruby/Rails is striking in its stupidity.[1] You can send something to Ruby/Rails in a session cookie which, when unmarshalled, stores into any named global variable in the namespace of the responding program . It's not a buffer overflow or a bug like that. It's deliberately designed to work that way . It's like doing "eval" on untrusted input. This was on YC years ago.[2] Why was anything so idioti…

I think you're overextrapolating here, though I admit my knowledge on this isn't totally up to date.

As I understand it, Ruby's Marshal function, which takes text data and deserializes it, is not safe by default. So, is that a flaw of Ruby? I guess...except that this kind of serialization seems to be a standard feature in languages (well, Ruby and Python, the two things I currently use):

https://docs.python.org/3/library/pickle.html

> Warning The pickle module is not secure against erroneous or maliciously constructed data. Never unpickle data received from an untrusted or unauthenticated source.

So the true bug seems to be that in Rails ActiveSupport (in a deprecated class, which uses some of Ruby's fun meta magic to deal with missing methods -- so basically, the classic obfuscation of functionality as a tradeoff for some sugary magic, all in a deprecated function that likely no one revisits), you can trigger a set of functions and routines in which the final decoding step, for whatever reason, ends up invoking Ruby's Marshal (via Rack: http://www.rubydoc.info/github/rack/rack/Rack/Session/Cookie...)

Re: Instagram's Million Dollar Bug

#69

Post by dsacco »

As a security researcher and engineer, I'd like to point out the following, without taking sides:

1. Facebook is not going ballistic because this is a RCE report. They have received high and critical severity reports many times before and acted peaceably, up to and including a prior RCE reported in 2013 by Reginaldo Silva (who now works there!).

2. The researcher used the vulnerability to dump data. This is well known to be a huge no-no in the security industry. I see a lot of rage here from software engineers - look at the responses from actual security folks in this thread, and ask your infosec friends. Most, perhaps even all, will tell you that you never pivot or continue an exploit past proof of its existence. You absolutely do not dump data.

3. When you dump data, you become a flight risk. It means that you have sensitive information in your possession and they have no idea what you'll do with it. The Facebook Whitehat TOS explicitly forbid getting sensitive data that is not your own using an exploit. There is a precedent in the security industry for employers becoming involved for egregious "malpractice" with regards to an individual reporting a bug. A personal friend and business partner of mine left his job after publicly reporting a huge breach back in 2012 (I agree with his decision there), and Charlie Miller was fired by Accuvant after the App Store fiasco. Consider that Facebook is not the first company to do this, and that while it is a painful decision, it is not an insane decision. You might not agree with it, but there is a precedent of this happening.

I'm not taking sides here. I don't know that I would have done the same as Alex Stamos here, but it's a tough call. I do believe the researcher here is being disingenuous about the story considering that a data dump is not an innocuous thing to do.

I'm balancing out the details here because I know it will be easy to see "Facebook calls researcher's employer and screws him for reporting a huge security bug" and get pitchforks. Facebook might be in the wrong here, but consider that the story is much more nuanced than that and that Facebook has an otherwise excellent bug bounty history.

Edited for visibility: 'tptacek mentioned downthread that Alex Stamos issued a response, highlighting this particular quote:

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.

Viewed in this light (and I don't believe Stamos would willfully fabricate a story like this), it is very reasonable to escalate to an employer if they seem to be affiliated with a security researcher's report.

Re: Instagram's Million Dollar Bug

#70

Post by Zikes »

iMerNibor wrote: post #55
daveloyall wrote: post #38

In my opinion, the author is feigning shock... He claims to have downloaded the content listed below. And he is surprised that Facebook responds coldly? Note the string "private keys" in this list... Doesn't the author know how long it will take them to recover from this breech? How much it will cost them? On the other hand, it does sort of re-enforce the idea that he should be paid handsomely, doesn't it? :) * Stati…

What if he hadn't found out about it, but someone else had already taken the files? Facebook might've never known

That's the Catch-22 of whitehat, isn't it? The whole idea is to find breaches and report them, but any worthwhile breach is going to expose sensitive data. How could you possibly know you've found a hole unless you've peered through it?
Post reply on HN