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