CyberSecurity SEE

Google Cloud Build Vulnerability Allows for Privilege Escalation and Code Tampering

Google Cloud Build Vulnerability Allows for Privilege Escalation and Code Tampering

A recently discovered vulnerability in Google Cloud Build has raised concerns about the security of software artifacts stored in Artifact Registry. The vulnerability, named Bad.Build, allows attackers to tamper with and inject malware into container images hosted on the platform. This poses a significant risk to any applications that use these compromised images, as they could be infected with malware, experience denial-of-service attacks, or suffer data theft.

Orca Security, a cybersecurity research firm, first identified the flaw while analyzing an application programming interface (API) call request related to a Google cloud platform resource. They promptly reported the issue to Google, who investigated and released a fix for the vulnerability in June. However, Orca has criticized the fix, stating that it only partially addresses the issue, making it insufficient to mitigate the risk fully.

Roi Nisimi, a cloud threat researcher at Orca, emphasized the supply chain risk associated with the Bad.Build flaw. Attackers can maliciously tamper with application images, leading to widespread infections and compromised user systems. Nisimi draws comparisons to the SolarWinds, 3CX, and MOVEit supply chain attacks, highlighting the potential far-reaching consequences of such an exploit.

According to Orca Security, the flaw arises from a design issue related to the default permissions granted to the Google Cloud Build service. These excessive permissions give adversaries an easy route to access audit logs containing a complete list of permissions associated with all Google Cloud Platform (GCP) accounts in a given project. This information becomes valuable for attackers, facilitating lateral movement and privilege escalation within the environment.

By using a GCP account with the permission to create a new build (cloudbuild.builds.create), Orca’s researchers found they could impersonate the Cloud Build service account and view all project permissions. Nisimi clarified that an attacker would require insider access or unauthorized access to a user with this permission. With just three lines of code, an attacker can build a public Gcloud image on the Cloud Build servers, escalating their privileges and executing actions allowed by the Cloud Build Service Account.

Google’s initial fix for Bad.Build removed the logging permission from the default Cloud Build service role. As a result, the service lost access to audit logs that listed the project’s permissions after any change. However, there are multiple other roles with the cloudbuild.builds.create permission that could be abused similarly. If organizations do not specifically revoke default permissions for the Google Cloud Build service, any user with the cloudbuild.builds.create permission can manipulate images and inject malicious code.

A Google spokesperson, when asked about the flaw and the claim of a partial fix, provided limited information. They acknowledged the work done by researchers and stated that Google had implemented a fix based on their report, as detailed in a security bulletin released in early June.

Google’s advisory on the vulnerability explains that when users enable the Cloud Build API, a default service account is created to execute builds on their behalf. Previously, this service account had default access to private logs, but as of the June 8 security bulletin, that permission has been revoked to adhere to the principle of least privilege.

Nisimi highlighted that Google’s perspective seems to be that organizations are responsible for further securing access in more advanced scenarios. While Google acknowledges the supply chain attack risk, they emphasize the importance of organizations limiting the cloudbuild.builds.create permission to reduce the potential for a supply chain attack.

In conclusion, the Bad.Build vulnerability in Google Cloud Build has highlighted the potential risks associated with compromised container images stored in Artifact Registry. Orca Security’s discovery raises concerns about malware infections, denial-of-service attacks, and data theft that can impact applications using these images. While Google has released a fix, Orca believes it is insufficient to fully mitigate the vulnerability. It is crucial for organizations to revoke default permissions and limit access to minimize the risk of a supply chain attack.

Source link

Exit mobile version