They're bounties. You aren't selling the bug. It's like that on every bug bounty program; very few of them will give you line-item prices for bugs by bug class.
He's spinning what happened, now that his actions are public. It's not like the reporter wasn't responding to his emails. Alex Stamos only called the guy's boss to intimidate, bully, and threaten him with legal action. He admits what he did but thinks it wasn't wrong and won't apologize. His sense of ethics seem to be one-sided.
Someone needs to call Zuckerberg to let him know about the aggressive and unethical behavior of his employee.
>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.
This is pretty questionable, and seems more like a hastily made up excuse. If Alex wasn't acting with malicious intent then the logical approach would've been to ask the researcher if he's operating on behalf of synack.
Especially that Alex does not mention lawyering up at any point in his post. That's something that Wes reported though: "Alex then stated that he did not want to have to get Facebook's legal team involved, but that he wasn't sure if this was something he needed to go to law enforcement over." (from the original blog post).
Yes it is complete bullshit. This account is full of minimizing Facebook's role in this when we all know that contacting the employer was a straight forward intimidation tactic that is unfortunately all to common in infosec (because it works).
> His account on our portal mentions Synack as his affiliation
Note 'his account' here is just his Facebook account. So you can rewrite that line as 'his Facebook account lists him as employed at Synack'
> he has interacted with us using a synack.com email address
That would be a crazy new precedent if we use email addresses as authority
> and he has written blog posts that are used by Synack for marketing purposes.
having written blog posts is even crazier.
Were Alex genuine in thinking this was Synack he would have copied Wes on the email and/or he would have asked him. He straight up went behind his back and over his head.
Facebook had a bounty program that was very respected and operated well. I don't understand how they've completely fucked this up and turned it into a pissing contest.
Just say sorry, forgive the guy for the data download, clarify that it was against the rules anyway, give the guy $20k, apologize for contacting his employer and just get it over with.
This way it is just going to drag on for days now and everybody has already forgotten that it was the reporter who made the first mistake.
I really, really don't get this.
edit: tip to researchers - create a new alias for each bug you report. once the bug is all done and settled claim it under your real/public name. avoid blowback, everyone gets it at least once.
He phoned the researcher's CEO and subtly threatened legal action. This is spin at it's finest.
I agree the researcher shouldn't have escalated/pivoted once they had access, that in itself breaks their ToS for the bug bounty program. However in doing so the vuln went from "so-so" to "holy shit".
Whether this policy for disabling pivoting is realistic/a bit of a cop-out from the vendor is arguable. In the real world an attacker wouldn't hesitate, however FB can't have people crawling around their internal network, potentially breaking or leaking user information.
The researcher, with all of his experience (incl a 24K bount payout from MS) should be aware of the above. However less ethically inclined hackers would have sold this access for $100K+.
EDIT: User ryanlol has made a good point, I thought they included fucking around within the server to break ToS. But their page does not indicate that. From the article it says:
> Intentional exfiltration of data is not authorized by our bug bounty program
However the ToS only talks about USER data. AWS S3 keys aren't included we can assume.
Once RCE is confirmed, any further access from there would break ToS. It's bullshit, and kind of a cop-out - but it's a trade-off that these companies have to make. Otherwise we could employ techniques like social engineering to gain internal access, then start pen-testing from within the network.
Not interact with other accounts without the consent of their owners.
Edit: whoops I mis-read this a bit, but the point still stands - he escalated using AWS keypair that did not belong to him, and he had no consent of the owner.
He phoned the researcher's CEO and subtly threatened legal action. This is spin at it's finest.
Or, he got in touch with the company he thought the researcher was affiliated with, to discuss what he felt was a very serious issue without involving lawyers. The classic outrage case is when a big company starts sending scary letters signed by lawyers, first thing. Maybe we should be less outraged when someone goes out of his way to be reasonable.
He didn't. Also, he made a phone call and made every effort to give the benefit of the doubt to someone who, perhaps not maliciously and through naiveté, did something very silly and then made it even sillier by making it look hard to distinguish from extortion.
The best possible outcome there would have been a grumpy letter from lawyers asking him to sign an affidavit he's destroyed all the data he picked up. The worst would have been people in suits packing away his every computing device at 4 am. None of this happened and it seems the main reason it didn't is 'Alex Stamos is not a dick and Facebook lets him not be a dick'. That's a good outcome, by any measure.
He might've just got hashes from those private keys, for proof. It's not clear if he actually took all these keys. To me this would seem like a responsible, easy and realistic way of proving you could've taken the keys if you were malicious.
The whole point is kinda moot, seeing how they did not have proper auditing and can't know if the keys were taken either way.
I am really disappointed at Facebook for their stance in this situation. The blog post written by Alex reaches far too into the personal attack territory.
> We were surprised because he did not mention these actions in his previous correspondence with us.
Painting a picture/creating a narrative, poor us, we're surprised.
> it was reasonable to believe that Wes was operating on behalf of Synack
Filling in affiliations, or using a company address during parts of communication could very well have been out of detailing legitimacy as well as convenience. You can not, and should not infer a researcher operates on behalf of their company when reporting a bug, and as a CSO and someone who acts as a security researcher you KNOW that we always distance ourselves from our workplace when reporting or talking about security.
> Wes to set a precedent that anybody can exfiltrate unnecessary amounts of data
Logging in, grabbing keys but not touching user data is most certainly not breaking your ToS. Yet you paint it as unethical here. Where do you draw the line? Internal network names? Internal IP's, passwd files?
> one of my engineers involved in this issue once found a great (and in his case, original) RCE
Really, "and in his case, original"? Come on, act professional you're presenting one of the largest companies in the world.
> we have no evidence that Wes or anybody else accessed any user data
DING! DING! DING! Yet using terms like "intentional exfiltration of data" to draw grey areas that convenience you.
Normally the thing we do with rapidly developing stories, i.e. when a new post adds significant information, is bury the previous thread and leave the new one up. But my sense is that people wouldn't prefer that in this case, and since the current post is already being discussed in (edit: at the top of) the other thread, we'll leave that one up instead.
Normally we do that, but the specific comments in this thread wouldn't make sense in the other one. So it's probably not a good idea this time.
The obvious solution is to support aggregating related URLs, and we will do that eventually, but there are other things that need to be done first (I don't just mean that have higher priority, but that are literal prerequisites). In the meantime, it's partial manual fixes for the lot of us.
It seems this post has now been removed from the front page. I understand your reasons for not wanting to have two similar discussions simultaneously. However, the two posts paint two different sides of the same story. How are people going to read this side of the story if it's been hidden?
The top subthread there links to this post, and the top several subthreads are substantive defences of its position. Anyone who wants to read the other side of the story will have little trouble finding it.
I'm struggling to comprehend those in support of the researcher? As a security researcher myself, this is just something you do not do. There was nothing more to be gained after he had those API keys - for any other researcher its game over, you won.
As far as I'm concerned anything that happens to you after that point is of your own making
"the bug, which is less critical than several other public reports that we have rewarded and celebrated"
The bug lead to full access to critical data, and possibly to full control of their servers. It's interesting what these other "more critical" bugs were.
"Not very original" != "not critical". Alex seems to imply these are equivalent.
I don't quite get Facebook's position here. This guy demonstrated that all of Instagram's data is publicly accessible. By jerking him around, they are resting a lot of money on their belief that he's not a black hat hacker. If they were wrong, they're looking at the mother of all data leaks. Would they want to tread a least somewhat gently with him, instead of treating him like he is black hat? I mean, luckily for them he's not, but what if they were wrong?
41 comments
[ 193 ms ] story [ 1311 ms ] threadWait, how does that work? Are there negotiations involved in Bug Bounties? But there's no leverage once the bug has been exposed!
Someone needs to call Zuckerberg to let him know about the aggressive and unethical behavior of his employee.
This is pretty questionable, and seems more like a hastily made up excuse. If Alex wasn't acting with malicious intent then the logical approach would've been to ask the researcher if he's operating on behalf of synack.
This guy was definitely acting in bad faith when he called the guy's boss and not the guy himself first.
> His account on our portal mentions Synack as his affiliation
Note 'his account' here is just his Facebook account. So you can rewrite that line as 'his Facebook account lists him as employed at Synack'
> he has interacted with us using a synack.com email address
That would be a crazy new precedent if we use email addresses as authority
> and he has written blog posts that are used by Synack for marketing purposes.
having written blog posts is even crazier.
Were Alex genuine in thinking this was Synack he would have copied Wes on the email and/or he would have asked him. He straight up went behind his back and over his head.
Facebook had a bounty program that was very respected and operated well. I don't understand how they've completely fucked this up and turned it into a pissing contest.
Just say sorry, forgive the guy for the data download, clarify that it was against the rules anyway, give the guy $20k, apologize for contacting his employer and just get it over with.
This way it is just going to drag on for days now and everybody has already forgotten that it was the reporter who made the first mistake.
I really, really don't get this.
edit: tip to researchers - create a new alias for each bug you report. once the bug is all done and settled claim it under your real/public name. avoid blowback, everyone gets it at least once.
I agree the researcher shouldn't have escalated/pivoted once they had access, that in itself breaks their ToS for the bug bounty program. However in doing so the vuln went from "so-so" to "holy shit".
Whether this policy for disabling pivoting is realistic/a bit of a cop-out from the vendor is arguable. In the real world an attacker wouldn't hesitate, however FB can't have people crawling around their internal network, potentially breaking or leaking user information.
The researcher, with all of his experience (incl a 24K bount payout from MS) should be aware of the above. However less ethically inclined hackers would have sold this access for $100K+.
EDIT: User ryanlol has made a good point, I thought they included fucking around within the server to break ToS. But their page does not indicate that. From the article it says:
> Intentional exfiltration of data is not authorized by our bug bounty program
However the ToS only talks about USER data. AWS S3 keys aren't included we can assume.
This is a tricky situation.
Except it doesn't?
Updated original reply.
Not interact with other accounts without the consent of their owners.
Edit: whoops I mis-read this a bit, but the point still stands - he escalated using AWS keypair that did not belong to him, and he had no consent of the owner.
Edit: I feel that your edit is still stretching the terms a bit. It seems pretty clear that this isn't the abuse that the clause intends to prevent.
Also, the guy seems to only have verified that the credentials worked.
Or, he got in touch with the company he thought the researcher was affiliated with, to discuss what he felt was a very serious issue without involving lawyers. The classic outrage case is when a big company starts sending scary letters signed by lawyers, first thing. Maybe we should be less outraged when someone goes out of his way to be reasonable.
The best possible outcome there would have been a grumpy letter from lawyers asking him to sign an affidavit he's destroyed all the data he picked up. The worst would have been people in suits packing away his every computing device at 4 am. None of this happened and it seems the main reason it didn't is 'Alex Stamos is not a dick and Facebook lets him not be a dick'. That's a good outcome, by any measure.
The whole point is kinda moot, seeing how they did not have proper auditing and can't know if the keys were taken either way.
> We were surprised because he did not mention these actions in his previous correspondence with us.
Painting a picture/creating a narrative, poor us, we're surprised.
> it was reasonable to believe that Wes was operating on behalf of Synack
Filling in affiliations, or using a company address during parts of communication could very well have been out of detailing legitimacy as well as convenience. You can not, and should not infer a researcher operates on behalf of their company when reporting a bug, and as a CSO and someone who acts as a security researcher you KNOW that we always distance ourselves from our workplace when reporting or talking about security.
> Wes to set a precedent that anybody can exfiltrate unnecessary amounts of data
Logging in, grabbing keys but not touching user data is most certainly not breaking your ToS. Yet you paint it as unethical here. Where do you draw the line? Internal network names? Internal IP's, passwd files?
> one of my engineers involved in this issue once found a great (and in his case, original) RCE
Really, "and in his case, original"? Come on, act professional you're presenting one of the largest companies in the world.
> we have no evidence that Wes or anybody else accessed any user data
DING! DING! DING! Yet using terms like "intentional exfiltration of data" to draw grey areas that convenience you.
They've definitely screwed the pooch on this one.
https://news.ycombinator.com/item?id=10754194
Normally the thing we do with rapidly developing stories, i.e. when a new post adds significant information, is bury the previous thread and leave the new one up. But my sense is that people wouldn't prefer that in this case, and since the current post is already being discussed in (edit: at the top of) the other thread, we'll leave that one up instead.
The obvious solution is to support aggregating related URLs, and we will do that eventually, but there are other things that need to be done first (I don't just mean that have higher priority, but that are literal prerequisites). In the meantime, it's partial manual fixes for the lot of us.
The bug lead to full access to critical data, and possibly to full control of their servers. It's interesting what these other "more critical" bugs were.
"Not very original" != "not critical". Alex seems to imply these are equivalent.