This was his mistake. This is a huge no-no. You never dump data unless you have permission. It's against the terms of most bounty programs.
* Day 1: Report RCE
* Day 2: Report finding from dumped file
* Day 4: RCE's gone
* Day 8: Asked not to dump files using RCEs in the future
* Day 26: Paid out for the RCE.
* Day 40: Bug based on dump is rejected
* Day 41: Report new bug based on dump, which shouldn't have been accessible for over a month!
* Day 41+: All hell breaks loose.
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 often have wide-open rules of engagements, where you (as a consultant) win big by, for instance, dumping the CEO's mail spool. But those projects also start with several meetings worth of negotiating rules of engagement.
Vulnerability assessments virtually never have those rules of engagement!
Nobody that I know of runs a bug bounty program on pentest norms. To do so would be grossly irresponsible, because on every network with more than 1000 hosts I've ever tested, ever, RCE behind the firewall is gameover for the whole test: you can get everything.
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 background. But please, continue to defend your friend whose multi-billion company had a month to cycle their popped keys and failed to do so, 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.
I agree with you that something seems off, but you're happily giving all the charity to FB and none to this guy, which is your prerogative but hardly makes for good conversation.
1. Second finding is declined.
2. New third finding, which includes AWS credentials that this person should not have had, is written and submitted.
3. Stamos calls Synack.
I believe the relative timing of these events is, in fact, established.
Now: stipulate that I'm right, even if you're not sure. Does your opinion of the story change?
I don't understand why a company would ever say "you can snoop around in our stuff" without very clearly stating what they can do. You're leaving open a legal loophole where a blackhat can claim to be a whitehat.
60 accounts on the admin console are not users, and he did not touch the buckets with actual user data.
> As described above, I used the web interface to gain code execution, but at this point I still hadn't actually gained access to the web interface as a normal user.
He had code execution, there was no need for him to go any further.
An apparent refusal to admit that in the write up is making it hard to put 100% support behind him.
There is no excuse: dumping the user table was too far.
Facebook went rather far too, of course.