4 ms·
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 f
by dogecoinbase 11y ago
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 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.
- emerongi 11y agoI agree. If there's no clear rule "all data stays in our network", dumping data is not an unreasonable move. I don't care whether some experts in their offices mull about what's alright to do in a pentest or when finding vulnerabilities for a bounty program - most people aren't experts in that sector, so better make it clear. The researcher is in the right here.
- tptacek 11y agoNot only is dumping data an unreasonable move, but it's one that will get you referred to prosecutors. That didn't happen here, but it just did happen somewhere else last week. Don't ever do that.
- emerongi 11y agoI wouldn't do that (I'd be scared to death about what would happen, even without reading this article). But I also don't find it an unreasonable move. Just make it clear - you dump data, we're going to sue you. Right now, the researcher is in the clear, even though what he did was incredibly stupid. 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.
- tptacek 11y agothen 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.
- dogecoinbase 11y agoThe "then" isn't temporally proximal. The quoted e-mails (unless you feel like asserting that they're fake, which I think is the next step in your arguments in this thread) demonstrate that he's trying to work within the unwritten rules of the program and asking for clarification in good faith. Then after that, rather than attempting any communication with his, Stamos threatens his employment. 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.
- tptacek 11y agoRead the timeline again and then the post. 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?
- dogecoinbase 11y agoNot really, no. Your should not have had is still presupposing a set of bug-bounty-hunter-professional-guidelines that don't actually exist unless they're specified in the program guidelines, and from a philosophical perspective the actual security vulnerability under discussion now is that their sec team is so lackluster that they can't or won't change out a credential set known to have been externally accessible (and, the critical point, to anyone who could have found this not-particularly-obscure vuln, not just this researcher).