Google Told Researcher 'Nice Catch!' Then Denied Bug Bounty For Flaw It Still Hasn't Fixed (theregister.com) 38
Security researcher Justin O'Leary says Google initially accepted his Config Connector privilege-escalation report as a high-priority, high-severity bug, then denied a bounty by declaring the behavior "working as intended." According to The Register, a Google rep initially praised O'Leary's report with a "Nice catch!" before the cloud giant reversed course, declaring that no vulnerability existed and therefore no fix or reward was warranted. "The bug report, however, is still marked high-priority and accepted," the publication notes. The alleged flaw, dubbed ConfigConfusion, could let a Kubernetes namespace user exploit an overprivileged service account to become a GCP organization owner with only a few lines of YAML and little apparent audit visibility. O'Leary details the incident in a blog post. The Register reports: According to O'Leary, Config Connector doesn't perform an authorization check, and this allows any Config Connector service account with org-level permissions to bypass Identity and Access Management (IAM) authorization and gain the highest level of control (roles/owner) to an entire GCP Organization -- the root node of all of a company's resources within Google Cloud. On March 27, a Google security engineer accepted O'Leary's report and told him: "Nice catch!" The employee said that they filed a bug based on O'Leary's report with the relevant product team and assured him the Chocolate Factory's security squad would work with relevant Google Cloud people to fix the flaw. "We'll work with the product team to ensure this issue is address. We'll let you know when the issue was fixed," the engineer said. "In the meantime, review the payment option selected in your bughunters.google.com profile."
Google assigned the bug P1 priority and S1 severity, signifying a flaw worthy of urgent repair because it affects a large percentage of users and can disrupt core organizational functions. "I figured that was the end of that," O'Leary said in a phone interview with The Register. Eleven days later, on April 7, he received a new message from a Google Security Bot reversing the earlier decision. The Reg viewed the email, and O'Leary included a screenshot in his Thursday writeup. The message said that the Cloud Vulnerability Reward Program panel decided that the "security impact of this issue does not meet the criteria to qualify for a reward."
After reviewing the bug report, Google determined the software "is working as intended," the message continued. It also noted that the program's decision not to pay a bounty "does not mean that the product team won't fix the issue." Nearly three months later, the case remains P1/S1 with the status "in progress (accepted)." Google hasn't assigned a CVE or issued a fix. O'Leary didn't receive any reward for his research. [...] "This is a pattern," O'Leary told [The Register]. "This is just how these trillion-dollar companies deal with people like me. In my day job, we use GKE, and it's incredibly frustrating on my end, when I find a critical vulnerability in the system that's being widely used, and I can't even get the vendor to patch their own stuff." A Google spokesperson told The Register: "The issue reported does not qualify for a reward because the GCP IAM authorization bypass is only exploitable if an attacker has access to a Config Connector Service Account that's been granted the Organization Admin role by the organization (i.e., it is privileged). Additionally, an attacker would first need to gain entry to an organization's environment (e.g., an exposed container) in order to leverage the privileged Config Connector instance and execute commands with administrative authority, such as the IAM bypass. Granting this level of access to the Config Connector Service Account goes against Google Cloud's publicly shared best practices and the principle of least privilege."
Google assigned the bug P1 priority and S1 severity, signifying a flaw worthy of urgent repair because it affects a large percentage of users and can disrupt core organizational functions. "I figured that was the end of that," O'Leary said in a phone interview with The Register. Eleven days later, on April 7, he received a new message from a Google Security Bot reversing the earlier decision. The Reg viewed the email, and O'Leary included a screenshot in his Thursday writeup. The message said that the Cloud Vulnerability Reward Program panel decided that the "security impact of this issue does not meet the criteria to qualify for a reward."
After reviewing the bug report, Google determined the software "is working as intended," the message continued. It also noted that the program's decision not to pay a bounty "does not mean that the product team won't fix the issue." Nearly three months later, the case remains P1/S1 with the status "in progress (accepted)." Google hasn't assigned a CVE or issued a fix. O'Leary didn't receive any reward for his research. [...] "This is a pattern," O'Leary told [The Register]. "This is just how these trillion-dollar companies deal with people like me. In my day job, we use GKE, and it's incredibly frustrating on my end, when I find a critical vulnerability in the system that's being widely used, and I can't even get the vendor to patch their own stuff." A Google spokesperson told The Register: "The issue reported does not qualify for a reward because the GCP IAM authorization bypass is only exploitable if an attacker has access to a Config Connector Service Account that's been granted the Organization Admin role by the organization (i.e., it is privileged). Additionally, an attacker would first need to gain entry to an organization's environment (e.g., an exposed container) in order to leverage the privileged Config Connector instance and execute commands with administrative authority, such as the IAM bypass. Granting this level of access to the Config Connector Service Account goes against Google Cloud's publicly shared best practices and the principle of least privilege."
That's OK (Score:2, Insightful)
Toldl (Score:2)
Well then (Score:5, Insightful)
You know what to do, security researchers. Next time you find an exploit just publish it, because Google obviously doesn't want your feedback.
Re: (Score:2)
Sell it on the open market and you'll profit.
This is why "responsible disclosure" isn't (Score:5, Insightful)
It's time to discard not just the practice, but the entire concept, because the industry has proven that it concocted this nonsense as a one-sided deal, and that it will screw anyone/everyone at every possible opportunity. It's time for researchers to abandon any attempt to collaborate with companies, because it doesn't work.
What should they do instead? Just drop the vulnerabilites and let the companies deal with the fallout. They're too cheap, too lazy, and in too much of a hurry to make sure their products/services are secure before they start selling them, so they deserve what they get. Let them burn.
No. Not at all. (Score:2)
You should still disclose the vulnerability to the company, and tell them they have 90 days before you publish it.
If you just publish it, you are putting all their users at immediate risk of being exploited by criminals who view your publication and immediately weaponize it. That is why you must disclose it to the company first, so they can get a fix out BEFORE you go public with it.
If you are unwilling to do this, then don't publish the finding.
Re: (Score:1)
"No responsible disclosure" means just that. No 90 day window because that's still "responsible disclosure". Why should I give 90 days grace for a bounty that isn't going to be paid anyway?
Re: (Score:2)
You should give a 90 day window so you don't become an enabler of crime.
The bug bounty is there to incite you to look for bugs at all. If there isn't a bug bounty program, or you don't think it will pay out, then don't go looking for bugs.
If you find a bug anyway, and want to do the right thing, then you responsibly disclose it (whether you get paid or not). If you don't want to do the right thing, then you just ignore the bug and don't publish it.
If you publish the bug without giving the company 90 days
Re: (Score:3)
You should give a 90 day window so you don't become an enabler of crime.
The company that wrote the bug in the first place is the enabler of the crime. In 99% of these cases, if you look at their unit tests you'll only see positive tests. Fail at best practices.
Announcing the exploit publicly allows people who use the software to take proper protections (like putting behind a firewall).
Just refuse to help cloud providers (Score:2)
Re: (Score:2)
nope, pay up or get fucked
Re: (Score:2)
Re: (Score:2)
This isn't the first, or the tenth, or the hundredth time this has happened to some security researcher dealing with some company.
It's absolutely not even the thousandth time a researcher has submitted an invalid report, then whined about not getting paid for it.
Re: (Score:2)
They're too cheap, too lazy, and in too much of a hurry to make sure their products/services are secure before they start selling them,
If the company doesn't have a QA team, if the company doesn't have negative unit tests, if the company hasn't trained their employees in secure coding practices, if the company doesn't have a system to avoid SQL injection exploits, etc
Then the company is at fault.
Seems defensible. (Score:5, Interesting)
From their bounty program page at https://bughunters.google.com/... [google.com] :
"Insecure customer configurations (such as unconditionally injecting shared secrets or misconfiguring security-related settings) rather than a product vulnerability.}
If their published standards indicate that giving the connector that level of admin permissions is excessive, and the access needed to exploit this is as clearly a set of poor security management as the last paragraph of the summary implies, then, "Yes, it should be corrected, and no, it's not bounty worthy" seems a reasonable stance to take. It sits right in the zone of that definition.
You could have the argument, but it's not clear to me that Google has it wrong.
Re: Seems defensible. (Score:2)
If their published standards indicate that giving the connector that level of admin permissions is excessive, and the access needed to exploit this is as clearly a set of poor security management as the last paragraph of the summary implies, then, "Yes, it should be corrected, and no, it's not bounty worthy" seems a reasonable stance to take. It sits right in the zone of that definition.
You could have the argument, but it's not clear to me that Google has it wrong.
Well I am sure they are not wrong in that they have legal cover to refuse the bounty.
I think they probably are wrong in excluding all config related bugs from their bounty program. Chained exploits are becoming increasing attack vectors so "you need elevated privileges" is not the moat it used to be. And GCP takeover is a big cost to bear. "We can prove it was your fault for not reading our docs carefully enough" will probably not be the salve their customers want in case of exploit. Security is hard and pr
Re: (Score:3)
I'm gonna AI me a new minivan! (Score:2)
Re:Seems defensible. (Score:4, Interesting)
Answer: not at all.
In fact, it would help them, because it'd go a little way toward repairing the reputation they've spent the past several years damaging. And it'd be a far better choice -- in every possible way -- than trying to weasel out of it as they've done in this case.
What Google (and Microsoft, and others) have done by abusing the good faith and trust of security researchers has convinced a lot of them that they're better off just selling information to anyone who can/will pay. It's less aggravating and it has a higher payout. This isn't good for anyone, and 100% of the blame lies with these enormously wealthy corporations -- who could easily afford the expense, but are too greedy and too short-sighted to understand the damage they're doing.
Re: (Score:2)
But how much credit is really due when the literal purpose of the tools to run as a Service Account with scoped permissions to sync changes from Kubernetes to GCP. There should be some pretty serious warnings saying that whatever access you give the Service Account is the access you gave... But the whole point of the tool is to shift from making changes directly in GCP to be in Kubernetes through a proxy Service Account.
Bug bounties bleeding dry by people overstating severity is also damaging.
Re: (Score:2)
How would it have damaged Google to (a) give credit where it's due and (b) cut a $50,000 check?
For a report that isn't a vulnerability? Well, it would have cost them $50k, and they'd have gotten nothing for that money -- other than to encourage researchers to submit invalid reports.
Re: (Score:2)
It's more than reasonable. The whole point of the product is make configs in Kubernetes format and a Service Account will sync the changes. So in essence roles that are given to the Service Account are basically given to users who direct the Service Account on what to do.
User --(Creates)--> Kubernetes Custom Resource which define GCP Settings --(Watched by)--> Config Connector --(Sync as Service Account with scoped access)--> GCP Config
If you give the Service Account rights to edit permissions, the
Re: (Score:2)
"giving the connector that level of admin permissions"
An exploit would not require *being given* that level or permissions but rather *obtaining* that level of permissions, i.e. chaining exploits. If Google can prove that it is not possible that there will ever be an exploit that would give that level of permission which could then be chained then Google would be justified at calling it just a misconfiguration. (Google cannot prove that.)
Even then, I would say it's a design flaw if you allow a configuration
Nightmare Eclipse (Score:4, Insightful)
Pay the bounty.
The two other possible outcomes are Nightmare Eclipse (she's really on a roll!) or 0day sales on DNM's.
It doesn't even matter whether a decision to fix is made.
Gosh, you'd think $GOOG was broke.
Overstating (Score:2)
Re: (Score:2)
The two other possible outcomes are Nightmare Eclipse (she's really on a roll!) or 0day sales on DNM's.
But it's not a vuln. So it would be worth nothing.
We want to keep the backdoor a bit longer (Score:3)
Google: Nice Catch!
NSA: Hey, we still need it!
Google: Invalid and we don't fix it any time soon.
Re: (Score:2)
This is what happened
LLM trained on security breaches are getting real good at finding tiny security flaws, probably unwinding years or even decades of intentional security flaws for various agencies
Re: (Score:2)
Doesn't even have to be crafted. You bet agencies sit on a lot of zero days they are not burning yet and now that pile is melting away.
Re:We want to keep the backdoor a bit longer (Score:4, Informative)
Actual Engineering Team: It's not a bug. Proxied access through a Service Account is the whole point of what this product does. Maybe our docs should have more warnings or we should put in another layer like the competing tool [crossplane.io] if people are going to get confused and shoot themselves in the foot.
Google Non-Specialist: Invalid, but we'll keep a case open to idiot-proof already acceptable behavior.
Re: (Score:2)
Google Non-Specialist: Nice Catch!
Actual Engineering Team: It's not a bug. Proxied access through a Service Account is the whole point of what this product does. Maybe our docs should have more warnings or we should put in another layer like the competing tool [crossplane.io] if people are going to get confused and shoot themselves in the foot.
Google Non-Specialist: Invalid, but we'll keep a case open to idiot-proof already acceptable behavior.
This is correct. Mod parent up.
The new Google motto (Score:3)
Pick from any of the following:
-- Don't be good
-- Don't be sensible
-- Don't be responsible
-- Don't be averse to being a dickhead
It would be great if somebody sponsored a "choose a new motto for Google" contest. Maybe Louis Rossman - he'd likely have the balls to do it if YouTube wasn't so important for him. Hell, he might do it anyway - he seems like a really scrappy give-zero-shits kind of guy.
Not a story (Score:1)
The Google response that actually explains the âoevulnerabilityâ makes it clear that I wasted time reading this article.
Establishing a better business model (Score:2)
The message is clear. If you find a vulnerability, don't go to a tech bro, hat in hand, hoping for a reward. Flog it on the dark web to the highest bidder.