Hacker News Reader

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.

I’m a bit confused by who is doing what. Can you clarify?

Was your friend the one paid to do the pentest? And during that 2 week period your friend was doing the pentest they found the 7 vuln chain RCE?

Or did they find the vulns during a period in time someone else was pentesting the company?

My understanding:

There's three parties: 1. Cloud service provider, 2. Client, 3. Tester

Client pays Tester to find vulns in Client's setup, including third party tools used by Client. Client notifies Cloud that there will be testing, and presumably the ToS allow such pentesting. In the process Tester discovers vulns in Cloud.

The AWS rules are complicated https://aws.amazon.com/security/penetration-testing/, for Google Cloud, you don't need to notify https://support.google.com/cloud/answer/6262505?hl=en#zippy=..., Microsoft used to require notification but no longer does https://docs.microsoft.com/en-us/azure/security/fundamentals... and seems to allow pentesting their services as long as you don't DoS them or exploit found vulnerabilities beyond a proof of concept.

Not sure how to think about that. I'd expect a pen tester to live of the money they get for the pentest and not make extra money with bounties from the time spent during that pentest. If the bug was in the software of another vendor then that's not as clear, but I'm still not sure if the pentester should be entitled to a bounty. If anything, maybe the client should get the bounty as they hired and paid for the pentester to find vulns?

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.

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.

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.

Sometimes, but not always, the stock market reacts by tanking the stock price. So the company does sometime get punished. For some vulnerabilities the end user does still end up paying more anyway though.

A hack has never impacted the stock price for a company for more than a week. Look at Equifax, it had almost doubled it's stock price between 2017 and 2022. That company should be dead.

Sony, Deloitte, Marriott, Tumblr, Disney, Maersk..

There's no repercussions for companies who are hacked. Until GDPR style fines are dealt, and companies are taken out back by regulatory agencies and shot - this will continue.

The thing you miss is CIO DGAF because he has paper trial covering his ass - pays for all kinds of corporate placebos (antivirus, waf), even did a pentest. Worst case scenario they will get in the news and get free advertising to >50% of clueless population.

There's a pretty relevant blog that recently came up on this:

https://soatok.blog/2022/06/14/when-soatok-used-bugcrowd/

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.

Just wow ... what a trainwreck.

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?

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.

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

"From a $ perspective, most bug bounty programs look rather uneconomic to me, which I presume is by design."

It depends. If you're a graduate with multiple FAANG offers in the US, they're not worth it. If you're in a developing country, they're worth it a lot.

Unfortunately, that also means that people who have good skills are less likely to participate and people who don't have marketable skills have an apparent incentive to try (they will not get the money, but the promise/possibility still lures them to submit reports) resulting in an absolutely atrocious quality of reports.

I don't think authentication is useful for white hats. A whitehat can just report it (which he'd do anyways) and then either get the bounty or not. The only benefit of authentication would be for the receiving company, and that's called triage and exists as a service (as we see in the full timeline, it was used here).

> authenticate a vulnerability, without the hacker revealing the vulnerability itself

In principle, with standalone software that can be run under emulation, including OSes and device software, it's possible to publish a verifiable, zero-knowledge proof of execution of the exploit leading to some state (e.g. root access or changing a file) without revealing how it's done.

The principle is similar to public key crypto: Everyone can verify the proof, only those with knowledge of the secret input can produce the proof.

The proof does not contain the actual execution steps because that would reveal the secret input, but it may contain before and after states for the verifier to convince themselves an exploit took place between them, along with a cryptography-style proof that the after state is reachable under this emulator using secret input known by the hacker.

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.

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.

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.