Google fixes “Bad.Build” Cloud Build flaw, researchers say it’s not enough
Researchers at Orca Security have found a design flaw in the Google Cloud Build service. Attackers would have been able to gain Privilege Escalation resulting in unauthorized access to code repositories in Google’s Artifact Registry.
The researchers dubbed the vulnerability Bad.Build and say it could have far reaching consequences comparable to supply chain attacks like those caused by exploitation of flaws in 3CX, MOVEit, and SolarWinds.
The vulnerability was fixed in June and according to Google no further user action is required. But the security researchers claim that Google’s fix only limits the discovered Privilege Escalation (PE) vector and organizations are still vulnerable to the larger supply chain risk.
Since the researchers go on to explain how the Bad.Build design flaw can be exploited, users of Google Cloud Build are under advice to take action. We’ll let you know what to do below (under Mitigation).
First, let’s have a look at the problem.
In traditional software development, programmers code an application in one computing environment only to find bugs or errors when deployed in another environment. To account for this, developers bundle their application together with all its related configuration files, libraries, and dependencies required to run in containers hosted in the cloud. This method is called containerization.
Google Cloud Build is a managed continuous integration and delivery (CI/CD) service provided by Google Cloud that makes it easy getting container images on the cloud. Cloud Build also provides pre-built images that you can reference in a Cloud Build config file to execute your tasks.
The Artifact Registry provides an overview of the packages you use while continuously monitoring and updating the state of those artifacts. This provides insight and control over the packages, images, and other dependencies used in your software development and delivery process.
The flaw uncovered by the researchers enables the impersonation of the default Cloud Build service account. By exploiting the flaw, an attacker can manipulate images in Google’s Artifact Registry and inject malicious code. If these images are intended to be used by customers of the supplying organization, the risk crosses from the supplying organization’s environment to their customers’ environments, constituting a supply chain attack.
When notified about the problem, Google revoked the logging.privateLogEntries.list IAM permission from the Cloud Build service account to adhere to the security principle of least privilege. When you enable the Cloud Build API in a project, Cloud Build automatically creates a default service account to execute builds on your behalf. This Cloud Build service account previously had the permission, which allowed the build to have access to list private logs by default. But, the revoked permission wasn’t related to Artifact Registry.
As a result, an attacker could use the artifactregistry permissions to download and exfiltrate an image that is being used inside Google Kubernetes Engine (GKE). They could then inject malicious code into the image and push it back to the artifact registry, which is then deployed once again to the GKE. Once the malicious image is deployed, the attacker can exploit it and run code on the docker container as root.
Mitigation
If there is anything the researchers made clear, is that it’s important that organizations pay close attention to the behavior of the default Google Cloud Build service account. Some important elements to keep in mind:
- Principle of least privilege. Limit permissions to what’s needed and keep track of given permissions.
- Implement cloud detection and response. If something goes wrong, it’s important to learn about it as early as possible.
- Prioritize risks, but don’t lose sight of the fact that a combination of two or more seemingly harmless vulnerabilities can be chained into a fatal attack.
Google denied Orca Security’s assessment, explaining that the access given to service accounts is the “nature of automated systems that run independently,” but both agreed that it’s important to check permissions and adjust them as you see fit, depending on your threat model.
Malwarebytes EDR and MDR remove
all remnants of ransomware and prevents you from getting reinfected. Want to learn more about how we can help protect your business? Get a free trial below.