3 ms·

The disclosure timeline is interesting: - theflow0 submitted a report to PlayStation. Oct 25th (8 months ago) - PlayStation rewarded theflow0 with a $20,000 b

The disclosure timeline is interesting: - theflow0 submitted a report to PlayStation. Oct 25th (8 months ago) - PlayStation rewarded theflow0 with a $20,000 bounty. Nov 12th (7 months ago) - shoshin_cup PlayStation staff closed the report and changed the status to Resolved. Apr 4th (3 months ago) - theflow0 requested to disclose this report. Apr 4th (3 months ago) - sazerac HackerOne staff agreed to disclose this report. Jun 10th (9 days ago) I generally refuse to participate in Bug bounty programs through intermediaries like HackerOne, because they severely restrict and delay your ability to disclose. After having been denied a bug bounty for reporting a vulnerability directly, and often spent frustrating amounts of time just trying to get a response even from major companies, I've basically given up completely on bug bounty programs, and will likely go for full disclosure in the future (with a note to the corresponding security team for awareness). For smaller issues, the bounties often don't even fairly compensate the (usually significant) effort spent communicating with the security team if you value your time at a competitive hourly rate, and payment is hit or miss. Not worth giving up your right to talk about the issues in exchange.

roastedpeacock 4y ago
Not saying public bug-bounty programs such as this are perfect. Those around a certain date in the past remember strongly when the situation with public research was more precarious and Sony attempting lawsuits, prosecutions and other utterly horrible attempts at 'damage-control' with the PS3. In that light and with the researcher being able to disclose his research after public security-patch it does appear more amicable.
robocat 4y ago
From a $ perspective, most bug bounty programs look rather uneconomic to me, which I presume is by design. Bounty programs require a hacker to reveal their secret. That cripples a hacker’s negotiation strength, and the hacker cedes nearly all control (as you point out). Are there any organisations which can authenticate a vulnerability, without the hacker revealing the vulnerability itself? Vulnerability authentication seems like a hard problem: * powerful adversaries will wish to “steal” the vulnerability for themselves, * the hacker will want to remain anonymous, * the hacker needs to believe they will be safe and their vulnerability will not be stolen, * legal, social, and financial incentives would be difficult to align for such an organisation to even exist. In a “safe jurisdiction” three-letter-agency and legal issues would probably be prohibitive (can’t aid extortion etcetera), and in other looser jurisdictions there would be powerful dark threats (far dominating over any legal issues). * in most markets authentication is handled by organisations doing repeat transactions so that their incentive is to be trustworthy. However in this market government or blackhat organisations will want to create fronts or suborn organisations. I guess on the dark markets there are authentication options for black hats. Any links to discussions about that? Can vulnerability authentication be solved for white hats?
- iancarroll 4y ago
  Practically, HackerOne is already in the business of validating vulnerability reports, and they did so here. The real problem is that HackerOne takes a commission on vulnerability reports but does not protect the researcher if the program doesn't pay for the validated report. Other platforms like Bugcrowd do protect you (which is probably sufficient for the problem you describe), but HackerOne strangely does not. There's already a trusted intermediary, you don't really need to hide the report from the company -- the intermediary just needs to provide protections to both sides.
  - Shank 4y ago
    disclaimer/context: I'm a HackerOne customer (I manage a program, and heavily compared Bugcrowd to HackerOne prior to purchase). > Practically, HackerOne is already in the business of validating vulnerability reports, and they did so here. This is true of some programs, but not all. Only for programs that HackerOne manages and triages for is this the case. Companies can and do refuse the triage service. The triage service, and H1 staff are incredibly devoted to the hacker side of things. H1 staff routinely advises when we should pay more, when we should award bounties on borderline issues, and offers their mediation process if a hacker disagrees with our judgement. They push us (and I assume other companies) to increase the scope of your program, to increase bounty payouts, and to decrease complexity with complying with program rules. > The real problem is that HackerOne takes a commission on vulnerability reports but does not protect the researcher if the program doesn't pay for the validated report. I manage a HackerOne program, and at least on our contract, this isn't as straightforward as you might expect. We pay for HackerOne's services with a tiered billing structure based on how many bounties we pay out. If we pay out $1500 we pay out $1500 flat, nothing skimmed off the top. If we pay out more than $x, we have to pay for an additional consumption tier irrespective of whether or not we pay out bounties up to the max on that tier. > Other platforms like Bugcrowd do protect you (which is probably sufficient for the problem you describe), but HackerOne strangely does not. For the most part, Bugcrowd has its own set of problems, which is offputting to a lot of people, including my team. Specifically, Bugcrowd’s Vulnerability Rating Taxonomy [0] includes many things, particularly in the P4/P5 categories, that are extremely noisy. In both cases, both companies don't pay out on dupe reports, for example. [0]: https://bugcrowd.com/vulnerability-rating-taxonomy https://bugcrowd.com/vulnerability-rating-taxonomy
technion 4y ago
There's a pretty relevant blog that recently came up on this: https://soatok.blog/2022/06/14/when-soatok-used-bugcrowd/ https://soatok.blog/2022/06/14/when-soatok-used-bugcrowd/
- BonoboIO 4y ago
  Just wow ... what a trainwreck.
- tgsovlerkhgsel 4y ago
  The PoC requirement seems to be there to help the triage team filter out the many garbage reports they get. Having seen a glimpse of what you get out of a bug bounty program (lots and lots of people with no clue submitting bogus reports) I understand why companies are doing that, but especially for a commercial company, their triage burden is not my problem. I'm doing them a massive favor by reporting it, and as mentioned above I'm not getting paid adequately for it... so either they do the triage properly (yes, that's a lot of work), or they pay me to spend time to give them a clearer proof... or they don't get the vulnerability reported/responsibly disclosed. Ironically, if you went through one of the platforms initially and they responded like that, you can't just go full disclosure anymore without violating the platform ToS, just like this post showed. The absolute minimum that such platforms should do would be report closed = NDA lifted, but since they're more dependent on their paying customers than the researchers, they won't do that.
Mandatum 4y ago
Friend just disclosed a 7 vuln chain RCE in a Fortune20 company. Affected all cloud and on-prem versions. They denied it as it was under NDA during a "scheduled" pentest (their client paid them to pentest and they alerted the vendor letting them know they'd be doing it during a 2 week period like most cloud vendors). For someone to spend weeks developing that many vulnerabilities to get an RCE and then get nothing from the vendor other than "haha technically we don't have to pay you" - there is zero reason to not go through agencies that sell to governments (ZDI, Zerodium, etc). You'll get paid and now the bug won't get patched. Congratulations vendor, you played yourself.
- rtpg 4y ago
  I feel like all these takes seem to not really consider the idea that some people enjoy security work but do not want to be part of criminal enterprises, especially in the age of ransomware. Gaming devices have always been special I think cuz basically every heavy gamer pirates games as a kid (no money!) and there’s a very legit “I just want my device to run software” feeling, but I think generally people want shit to be fixed.
  - feduphackers 4y ago
    There’s another path - open source disclosure. I’m not seeking pay, I’m not using it. I’m just putting it right out there in the open. Should the wrong parties abuse it, oh well. At this point in life, I feel “responsible disclosure” is just a PR tool for shit-birds to use to dodge accountability. The only thing they will respond to is pain.
    - rtpg 4y ago
      I do not understand the "oh well if it gets exploited" vibe. It's not the company that suffers in that case, but users of the software! Now, you might want to somehow tell these users about this, so they can get off of the software. And there's this balancing act in that case... In the abstract universe where I have a nasty exploit and the company wants to ignore it, I suppose I would just try to loudly publish a first step which is like "hey, I have this PoC which gives me RCE with this software, and the company is ignoring it", without revealing the methodology at first. Perhaps at least publishing some mitigation strategies. I am not a security researcher, but I understand that this would be hard. But I think it's not honest to say that just dumping an exploit to the world is the best alternative to stonewalling.
nimbius 4y ago
the biggest news about this for, well, hackers is obviously theflow0 is back in the game! theyve been instrumental in the homebrew PS4 scene as covered by modern retro gamer on youtube.
Shank 4y ago
disclaimer: I manage a HackerOne program. > After having been denied a bug bounty for reporting a vulnerability directly, and often spent frustrating amounts of time just trying to get a response even from major companies, I've basically given up completely on bug bounty programs, and will likely go for full disclosure in the future (with a note to the corresponding security team for awareness). I personally believe that if a bug bounty program denies your report / closes it out as N/A or out-of-scope, you should be able to disclose it. The whole point of bug bounty is practically "legal extortion". The buy-in is that you're getting security details in exchange for payment. If you're not paid, the information shouldn't be used or worthy of payment. The security issue's severity should command a level of payment. If it fails to command this, surely the company doesn't think it's valuable, right? > I've basically given up completely on bug bounty programs, and will likely go for full disclosure in the future (with a note to the corresponding security team for awareness). I think you should still report to bounty programs, at least ones with "HackerOne managed" badges on them, because at least HackerOne will try to reproduce the issue / triage it. If you want you can go full disclosure, but believe it or not, smaller companies with people like me at the helm are more than happy to pay out bounties. We may not have big company budgets, but we really do take things seriously, and we enjoy rewarding people who find interesting problems. For the record, emails to security@ company are practically inundated with false positive "bug bounty" reports from researchers who have very low signal. HackerOne/Bugcrowd are often just better ticket management systems, because when you get 10 of the same report about something that isn't a security problem a day, real issues slip through the cracks. HackerOne's triage team is very good at identifying an exceptional issue and raising it up to us, which was often difficult pre-H1 via security@ emails. Also, more and more, GDPR data deletion requests get flooded to privacy@ and security@. When this happens, the security inbox looks more like GDPR/low hanging fruit zone than an actual "important security issue that needs attention immediately" zone.

roastedpeacock 4y ago

Not saying public bug-bounty programs such as this are perfect. Those around a certain date in the past remember strongly when the situation with public research was more precarious and Sony attempting lawsuits, prosecutions and other utterly horrible attempts at 'damage-control' with the PS3. In that light and with the researcher being able to disclose his research after public security-patch it does appear more amicable.

robocat 4y ago

From a $ perspective, most bug bounty programs look rather uneconomic to me, which I presume is by design. Bounty programs require a hacker to reveal their secret. That cripples a hacker’s negotiation strength, and the hacker cedes nearly all control (as you point out). Are there any organisations which can authenticate a vulnerability, without the hacker revealing the vulnerability itself? Vulnerability authentication seems like a hard problem: * powerful adversaries will wish to “steal” the vulnerability for themselves, * the hacker will want to remain anonymous, * the hacker needs to believe they will be safe and their vulnerability will not be stolen, * legal, social, and financial incentives would be difficult to align for such an organisation to even exist. In a “safe jurisdiction” three-letter-agency and legal issues would probably be prohibitive (can’t aid extortion etcetera), and in other looser jurisdictions there would be powerful dark threats (far dominating over any legal issues). * in most markets authentication is handled by organisations doing repeat transactions so that their incentive is to be trustworthy. However in this market government or blackhat organisations will want to create fronts or suborn organisations. I guess on the dark markets there are authentication options for black hats. Any links to discussions about that? Can vulnerability authentication be solved for white hats?

iancarroll 4y ago
Practically, HackerOne is already in the business of validating vulnerability reports, and they did so here. The real problem is that HackerOne takes a commission on vulnerability reports but does not protect the researcher if the program doesn't pay for the validated report. Other platforms like Bugcrowd do protect you (which is probably sufficient for the problem you describe), but HackerOne strangely does not. There's already a trusted intermediary, you don't really need to hide the report from the company -- the intermediary just needs to provide protections to both sides.
- Shank 4y ago
  disclaimer/context: I'm a HackerOne customer (I manage a program, and heavily compared Bugcrowd to HackerOne prior to purchase). > Practically, HackerOne is already in the business of validating vulnerability reports, and they did so here. This is true of some programs, but not all. Only for programs that HackerOne manages and triages for is this the case. Companies can and do refuse the triage service. The triage service, and H1 staff are incredibly devoted to the hacker side of things. H1 staff routinely advises when we should pay more, when we should award bounties on borderline issues, and offers their mediation process if a hacker disagrees with our judgement. They push us (and I assume other companies) to increase the scope of your program, to increase bounty payouts, and to decrease complexity with complying with program rules. > The real problem is that HackerOne takes a commission on vulnerability reports but does not protect the researcher if the program doesn't pay for the validated report. I manage a HackerOne program, and at least on our contract, this isn't as straightforward as you might expect. We pay for HackerOne's services with a tiered billing structure based on how many bounties we pay out. If we pay out $1500 we pay out $1500 flat, nothing skimmed off the top. If we pay out more than $x, we have to pay for an additional consumption tier irrespective of whether or not we pay out bounties up to the max on that tier. > Other platforms like Bugcrowd do protect you (which is probably sufficient for the problem you describe), but HackerOne strangely does not. For the most part, Bugcrowd has its own set of problems, which is offputting to a lot of people, including my team. Specifically, Bugcrowd’s Vulnerability Rating Taxonomy [0] includes many things, particularly in the P4/P5 categories, that are extremely noisy. In both cases, both companies don't pay out on dupe reports, for example. [0]: https://bugcrowd.com/vulnerability-rating-taxonomy https://bugcrowd.com/vulnerability-rating-taxonomy

technion 4y ago

There's a pretty relevant blog that recently came up on this: https://soatok.blog/2022/06/14/when-soatok-used-bugcrowd/ https://soatok.blog/2022/06/14/when-soatok-used-bugcrowd/

BonoboIO 4y ago
Just wow ... what a trainwreck.
tgsovlerkhgsel 4y ago
The PoC requirement seems to be there to help the triage team filter out the many garbage reports they get. Having seen a glimpse of what you get out of a bug bounty program (lots and lots of people with no clue submitting bogus reports) I understand why companies are doing that, but especially for a commercial company, their triage burden is not my problem. I'm doing them a massive favor by reporting it, and as mentioned above I'm not getting paid adequately for it... so either they do the triage properly (yes, that's a lot of work), or they pay me to spend time to give them a clearer proof... or they don't get the vulnerability reported/responsibly disclosed. Ironically, if you went through one of the platforms initially and they responded like that, you can't just go full disclosure anymore without violating the platform ToS, just like this post showed. The absolute minimum that such platforms should do would be report closed = NDA lifted, but since they're more dependent on their paying customers than the researchers, they won't do that.

Mandatum 4y ago

Friend just disclosed a 7 vuln chain RCE in a Fortune20 company. Affected all cloud and on-prem versions. They denied it as it was under NDA during a "scheduled" pentest (their client paid them to pentest and they alerted the vendor letting them know they'd be doing it during a 2 week period like most cloud vendors). For someone to spend weeks developing that many vulnerabilities to get an RCE and then get nothing from the vendor other than "haha technically we don't have to pay you" - there is zero reason to not go through agencies that sell to governments (ZDI, Zerodium, etc). You'll get paid and now the bug won't get patched. Congratulations vendor, you played yourself.

rtpg 4y ago
I feel like all these takes seem to not really consider the idea that some people enjoy security work but do not want to be part of criminal enterprises, especially in the age of ransomware. Gaming devices have always been special I think cuz basically every heavy gamer pirates games as a kid (no money!) and there’s a very legit “I just want my device to run software” feeling, but I think generally people want shit to be fixed.
- feduphackers 4y ago
  There’s another path - open source disclosure. I’m not seeking pay, I’m not using it. I’m just putting it right out there in the open. Should the wrong parties abuse it, oh well. At this point in life, I feel “responsible disclosure” is just a PR tool for shit-birds to use to dodge accountability. The only thing they will respond to is pain.
  - rtpg 4y ago
    I do not understand the "oh well if it gets exploited" vibe. It's not the company that suffers in that case, but users of the software! Now, you might want to somehow tell these users about this, so they can get off of the software. And there's this balancing act in that case... In the abstract universe where I have a nasty exploit and the company wants to ignore it, I suppose I would just try to loudly publish a first step which is like "hey, I have this PoC which gives me RCE with this software, and the company is ignoring it", without revealing the methodology at first. Perhaps at least publishing some mitigation strategies. I am not a security researcher, but I understand that this would be hard. But I think it's not honest to say that just dumping an exploit to the world is the best alternative to stonewalling.

nimbius 4y ago

the biggest news about this for, well, hackers is obviously theflow0 is back in the game! theyve been instrumental in the homebrew PS4 scene as covered by modern retro gamer on youtube.

Shank 4y ago

disclaimer: I manage a HackerOne program. > After having been denied a bug bounty for reporting a vulnerability directly, and often spent frustrating amounts of time just trying to get a response even from major companies, I've basically given up completely on bug bounty programs, and will likely go for full disclosure in the future (with a note to the corresponding security team for awareness). I personally believe that if a bug bounty program denies your report / closes it out as N/A or out-of-scope, you should be able to disclose it. The whole point of bug bounty is practically "legal extortion". The buy-in is that you're getting security details in exchange for payment. If you're not paid, the information shouldn't be used or worthy of payment. The security issue's severity should command a level of payment. If it fails to command this, surely the company doesn't think it's valuable, right? > I've basically given up completely on bug bounty programs, and will likely go for full disclosure in the future (with a note to the corresponding security team for awareness). I think you should still report to bounty programs, at least ones with "HackerOne managed" badges on them, because at least HackerOne will try to reproduce the issue / triage it. If you want you can go full disclosure, but believe it or not, smaller companies with people like me at the helm are more than happy to pay out bounties. We may not have big company budgets, but we really do take things seriously, and we enjoy rewarding people who find interesting problems. For the record, emails to security@ company are practically inundated with false positive "bug bounty" reports from researchers who have very low signal. HackerOne/Bugcrowd are often just better ticket management systems, because when you get 10 of the same report about something that isn't a security problem a day, real issues slip through the cracks. HackerOne's triage team is very good at identifying an exceptional issue and raising it up to us, which was often difficult pre-H1 via security@ emails. Also, more and more, GDPR data deletion requests get flooded to privacy@ and security@. When this happens, the security inbox looks more like GDPR/low hanging fruit zone than an actual "important security issue that needs attention immediately" zone.