David KrauseI've been frustrated with #bugbounty programs for a while now. They aren't setup up at all to receive any reports that aren't traditional webapp vulnerabilities. Things like infrastructure vulnerabilities, malware, C2 comms, phishing don't fit into their box. They don't have CWEs for them and are usually on out-of-scope infrastructure. But many organizations think that they don't need any other way to contact their #infosec team besides the bug bounty program for example security.txt.
I reported some #OWASSRF #ProxyNotShell via #HackerOne because I wanted to alert those companies that they hadn’t patched their Exchange Server, not because I necessarily wanted a bounty. But these programs require that you obtain RCE proof otherwise they are closed out. I’m not going to do that because Exchange Server is typically not in scope which would be illegal to do. I also don’t want to step on any webshells that may have already been deployed by other attackers.
Brad Larsen@krausedw I wish exposed credentials were not out of scope so often
Alun Jones@bradlarsen @krausedw I understand the thought, but it's a bad fit for a bug bounty, unless it hits a number of criteria. Handlers are going to want to provide a fix to a vulnerability. How did the credentials escape?
If by a vulnerability, great, that can be identified and fixed. Bounty is likely.
If stolen by malware in the browser/phone/ISP/etc, that's basically unfixable, especially since that's a valued asset to some reporters, and they won't want to give it up and see it fixed. Bounty unlikely.
If it's just a credential stuffing, because a user has the same password on facebork, that's not a fixable technical vulnerability. Bounty unlikely.
If it's a credential in a source control repo that should never have escaped, that's a team that can be driven to a smarter technical solution and the vulnerability fixed. Bounty likely.
All credential exposures are not equal. Note that likelihoods described above are my personal preferences, and may not match your target BB programme.
If by a vulnerability, great, that can be identified and fixed. Bounty is likely.
If stolen by malware in the browser/phone/ISP/etc, that's basically unfixable, especially since that's a valued asset to some reporters, and they won't want to give it up and see it fixed. Bounty unlikely.
If it's just a credential stuffing, because a user has the same password on facebork, that's not a fixable technical vulnerability. Bounty unlikely.
If it's a credential in a source control repo that should never have escaped, that's a team that can be driven to a smarter technical solution and the vulnerability fixed. Bounty likely.
All credential exposures are not equal. Note that likelihoods described above are my personal preferences, and may not match your target BB programme.
@bradlarsen @krausedw OK, I can't explain that one, that seems like a definite, fixable, team-responsible, code-specific vuln. Maybe if it's old code (cred no longer valid, already fixed, etc), or third party library, but those would be uncommon. Different programmes, of course, have their own reasons.