A nasty Google Cloud bug could let hackers use it to launch attacks

Cybersecurity researchers from Orca Security have uncovered a new bug in the Google Cloud Build service which could allow threat actors to gain almost full access to Google Artifact Registry code repositories. The repercussions of the flaw, the researchers are saying in their report, are quite dire. 

The researchers named the vulnerability Bad.Build, saying it allows threat actors to impersonate the service account for the Google Cloud Build managed continuous integration and delivery service (CI/CD). This, in turn, lets them run API calls against the artifact registry, effectively seizing control over application images. 

With full control granted, the attackers can proceed to add malicious code, in theory disrupting different supply chains and reaching countless endpoints. 

A separate security firm, Rhino Security Lab, also came across the same vulnerability, but with a somewhat more complex exploit. Rhino’s method includes the use of GCP API and exfiltrated Cloud Build Service Account access tokens. 

Orca, on the other hand, abuses cloudbuilds.builds.create permissions to gain elevated privileges, allowing threat actors to tweak Google Kubernetes Engine (GKE) docker images, essentially running code inside the docker container, as root. 

Analysis: Why does it matter?

By abusing Bad.Build, threat actors can run so-called “supply chain” attacks. Taking advantage of the flaw, hackers and other cybercriminals can inject malware into application images, which would later be used by different organizations on numerous networks and endpoints. The malware can be used for all kinds of malicious activity, from stealing sensitive data, to deploying ransomware, and from installing cryptominers to running Denial of Service (DoS) attacks. 

Furthermore, if the malicious apps end up being deployed on-premise or in a semi-SaaS environment, victim organization’s customers can also be at risk, not unlike what happened to SolarWinds.  To make sure your organization doesn’t end up compromised, consider following Orca’s recommendations, which include paying close attention to the behavior of the default Google Cloud Build service account. 

“Applying the Principle of Least Privilege and implementing cloud detection and response capabilities to identify anomalies are some of the recommendations for reducing risk:”, the company says. That includes adhering to least privilege, prioritizing risks that endanger your critical business assets, and using Cloud Detection & Response to detect dangerous anomalies.

What have others said about the flaw? 

Soon after the discovery of the flaw, Google reached out to the media, thanking Orca for their effort in the discovery of the flaw: “We created our Vulnerability Rewards Program specifically to identify and fix vulnerabilities like this one. We are appreciative of Orca and the broader security community’s participation in these programs,” Google’s spokesperson said. “We appreciate the work of the researchers and have incorporated a fix based on their report as outlined in a security bulletin issued in early June.”

The fix already been issued is definitely good news, as the destructive potential of Bad.Build is quite extensive. Commenting on the findings, Orca security researcher Roi Nisimi described the impact as “diverse”: “The potential impact can be diverse, and applies to all organizations that are using the Artifact Registry as their main or secondary image repository,” Nisimi said. “The first and immediate impact is disrupting the applications relying on these images. This can lead to DOS, data theft and the spreading of malware to users. “As we have seen with the SolarWinds and recent 3CX and MOVEit supply chain attacks, this can have far reaching consequences.”

In its writeup, BleepingComputer said the fix Google Security Team implemented at first was partial, revoking the logging.privateLogEntries.list permission from the default Cloud Build Service Account, unrelated to Artifact Registry. 

“It is important to note that this measure did not directly address the underlying vulnerability in the Artifact Registry, leaving the privilege escalation vector and the risk of a supply chain attack intact,” the publication said.

“However, Google’s fix doesn’t revoke the discovered Privilege Escalation (PE) vector. It only limits it – turning it into a design flaw that still leaves organizations vulnerable to the larger supply chain risk,” Nisimi added. “It’s therefore important that organizations pay close attention to the behavior of the default Google Cloud Build service account. Applying the Principle of Least Privilege and implementing cloud detection and response capabilities to identify anomalies are some of the recommendations for reducing risk.”

Speaking to TechTarget Editorial, Nisimi said that the flaw is still fully exploitable even with the partial mitigation. “You can look at it as something that will probably never be revoked, because it is within the design of [GCP],” he said. “They decided not to revoke it, so it is a risk within the platform that will stay there forever, creating an opportunity and privilege for attackers to escalate privileges.”

Google told its customers to modify the default Cloud Bild Service Account permissions and remove entitlement credentials that are unaligned with the Principle of Least Privilege (PoLP).

Go deeper

If you want to learn more, start by learning what is Google Cloud Storage,  and our in-depth guide on the best cloud computing services around. Also, read our best endpoint protection services guide, as well as our list of the best malware removal software today.