Introduction
Orca Security has recently identified a design flaw in Google Cloud Build service, named “Bad.Build.” This flaw poses a serious security risk as it enables attackers to execute Privilege Escalation, granting them unauthorized entry into Google’s Artifact Registry’s code repositories.
The consequences of this vulnerability extend to the software supply chain, as attackers can exploit it to manipulate application images with malicious intent. Consequently, unsuspecting users and customers who install the tampered applications may fall victim to infections.
This situation reminds us of the significant impact witnessed in past supply chain attacks like SolarWinds, 3CX, and MOVEit, emphasizing the far-reaching implications of such security lapses.
How it works?
Google Cloud Build stands as a continuous integration/continuous delivery (CI/CD) service offered within the Google Cloud ecosystem. It plays a vital role in cloud-based applications by seamlessly interacting with other essential services such as the Artifact Registry and the App Engine.
The flaw at hand results from an issue with excessive privileges. Specifically, the “logging.privateLogEntries.list” action inadvertently permits the listing of audit logs to an unintended role, namely “roles/cloudbuild.builds.builder.”
Regrettably, this default role is assigned to the cloud build service account. This situation poses a grave risk since audit logs contain sensitive information, revealing all permissions associated with the project. This unintended access grants attackers the ability to impersonate the cloud build account, thereby acquiring knowledge about which actions can be performed by different Google accounts. Consequently, this opens the door to lateral movement and privilege escalation, presenting an extremely dangerous security vulnerability.
Impersonating the build service account only requires the cloudbuild.builds.create permission, which many predefined roles have, and which are granted to developers in any reasonable CI/CD environment using Cloud Build. So if you have access to one such developer’s account, creating a tailored build configuration file will actually run the gcloud logging read command, which will list the permissions.
But the problem does not stop here: the Google Cloud Build service account is highly privileged, with many actions for interacting with the Goggle’s Artifact Registry.
Exploiting the vulnerability that enables impersonation of the default Cloud Build service account, malicious actors gain the ability to tamper with images stored in Google’s Artifact Registry by injecting malicious code. Consequently, any applications built from these compromised images become susceptible to potential consequences, including Denial-of-Service (DoS) attacks, data theft, and the spread of malware.
The severity of the situation escalates when these manipulated applications are intended for deployment in customers’ environments, whether on-premise or semi-SaaS. This expands the risk beyond the supplying organization’s infrastructure, leading to a supply chain attack that infiltrates and compromises the customers’ environments. Such attacks are akin to previous incidents seen in software supply chain breaches, such as the SolarWinds breach. The implications of such an attack can be severe, causing widespread harm and affecting multiple organizations within the supply chain
There was a similar privilege escalation PoC by Rhino Security Labs, which exploited in a different way the excessive privileges of the default Cloud Build account.
Why is it dangerous?
The severity of this vulnerability lies in its potential for attackers to exploit the Artifact Registry and introduce malicious code into artifacts. As a result, any applications built from these compromised images become susceptible to various adverse effects.
These effects include the possibility of Denial-of-Service attacks, data theft, and the propagation of malware. Moreover, if these compromised applications are subsequently deployed on-premise or in a semi-SaaS environment, the risk extends beyond the victim organization to impact their customers as well. This scenario resembles the supply chain attack witnessed in the SolarWinds incident, highlighting the potential consequences for both the organization and its customer base.
-
Xygeni recommendation
Apply the principle of Least Privilege
- Xygeni Sensor monitors user actions in the systems where it is deployed and shares them with our core platform, which identifies unusual behavior or deviations from normal patterns, such as unusual login times or locations, large data transfers, or changes in user access rights that are out of the range of the ‘normal’ user behavior modeled.
Xygeni’s policies and audit enforce best practices in access controls, multi-factor authentication requirements, and role-based permissions applications to limit user access to critical systems and data.
These tools monitor user actions, such as code changes, system access, or data transfers, and compare them against predefined policies and behavioral patterns. They also flag suspicious activities, such as unauthorized access, excessive privileges, or unusual data transfer patterns.
How the Vulnerability Was Handled
Upon notifying the Google Security Team of the vulnerability, they took action by revoking the logging.privateLogEntries.list permission from the default Cloud Build service account. They acknowledged that while the setIamPolicy audit logs are relevant for auditing purposes, granting access to these logs from the cloud build service account’s perspective was unnecessary.
However, it’s crucial to understand that this response did not directly address the root vulnerability within the Artifact Registry. As a result, the privilege escalation vector and the potential risk of a supply chain attack remained unaffected. Essentially, Google’s fix limited the issue but did not eliminate it entirely, leaving organizations still exposed to significant software supply chain risks.
In response to the situation, Google advised its customers to modify the permissions of the default Cloud Build Service Account by removing any entitlement credentials that deviated from the Principle of Least Privilege (PoLP). This measure aims to enhance security by ensuring that accounts only have the minimum necessary privileges to perform their intended tasks.
To defend against this privilege escalation attack, it is necessary to restrict the permissions granted to the Cloud Build Service Account and to be careful granting the cloudbuild.builds.create permission to any users in your organization. Most importantly, you need to know that any user who is granted cloudbuild.builds.create, is also indirectly granted all the permissions granted to the Cloud Build Service Account. If that’s alright with you, then you may not need to worry about this attack vector, but it is still highly recommended to modify the default permissions granted to the Cloud Build Service Account.
Google recommends this succinctly, but does not provide further details:
“If you don't plan to perform an action as part of the build process, we recommend that you revoke the corresponding permission from the Cloud Build service account to comply with the security principle of least privilege.”
Timeline
Rhino Security Labs posted about the privilege escalation issue and created a PoC python script * for it.
Orca Security reported their findings to the Google Security Team.
Google conducted an investigation and implemented a partial fix in response.
*More info here
However, it’s essential to note that Google’s remedy did not entirely eliminate the discovered Privilege Escalation (PE) vector. Instead, it restricted its impact, effectively transforming it into a design flaw that still exposes organizations to the broader risk of a supply chain attack. Consequently, additional measures are necessary for security teams to safeguard against this lingering risk.
Conclusion
Excessive privileges granted to the default Google Cloud Build account could be leveraged by adversaries to mount an attack by using a developer account allowing to create a cloud build. Attackers may exfiltrate a container image, tamper it with malicious behavior, and then push it to the Artifact Registry, in a software supply chain attack that may have devastating consequences.
Google’s response leaves the mitigation work to the organizations using the Cloud Build service, which need to revoke the privileges to control the risk. One may ask Google to provide additional help in the future for handling security issues with their CI/CD system.
References
- Working-As-Intended: RCE to IAM Privilege Escalation in GCP Cloud Build. Rhino Security Labs.
- Bad.Build: PE & RCE Vulnerabilities in Google Cloud Build. Orca Security.
- Security Bulletin. Google Cloud.
Know more about Xygeni Platform, download Xygeni's platform datasheet
