Privilege escalation proof-of-concept for Google Cloud

Orca Security reports a privilege escalation vulnerability, "Bad.Build," in Google Cloud that could open the door to supply chain attacks by allowing an attacker to infect users and customers. “As we have seen with the SolarWinds and recent 3CX and MOVEit supply chain attacks, this can have far reaching consequences,” the researchers write. Google has closed the vulnerability. 

Orca’s report explains “By abusing this flaw that enables the impersonation of the default Cloud Build service account, an attacker can manipulate images in Google’s Artifact Registry and inject malicious code. Any applications built from the manipulated images are then affected, with potential outcomes including Denial-of-Service (DoS) attacks, data theft, and the spread of malware.” Orca Security did alert Google to this vulnerability, but they note that Google has removed a single permission from the default cloud build. Orca writes “The revoked permission wasn’t related to Artifact Registry, which turns the supply chain risk into a persistent one. In view of this, it’s important that organizations pay close attention to the behavior of the default Google Cloud Build Service Account to detect any possible malicious behavior. Applying the Principle of Least Privilege and implementing cloud detection and response capabilities to identify anomalies are some of the recommendations for reducing risk.”

Research method: looking at the possibility of lateral movement. 

The researchers were able to discover this vulnerability through mapping the users and discovering their permissions by what seems like a flaw in calling the API. The researchers note, “We noticed an interesting thing about this API call request. Each time the API call is invoked, the full Project’s permissions are included in the Message Body Request, not just the ones we edited. And this information can be found in the GCP audit logs, under the `request` field.” Such visibility is critical to understanding the possibility of lateral movement, “equal to solving a great piece of the puzzle on how to launch an attack. It would be extremely dangerous if this permission map ended up in the wrong hands.” Orca explains that by mapping user permissions they were able to determine which permissions would allow them to impersonate a Cloud Builder Account. By gaining the permission “cloudbuild.builds.create,” which is the default role assigned to a cloud builder account, they can use three lines of code to implement the impersonation account. 

The proof-of-concept supply chain attack. 

Orca lays out a supply chain attack proof-of-concept in five steps:

• STEP 1 Privilege Escalation using cloudbuild.builds.create
• STEP 2 Gaining access to Artifact Registry: Once an attacker obtains the ability to create builds, they can impersonate the Cloud Build Service Account and escalate privileges. This service account, by default, can run API calls against the artifact registry. 
• STEP 3 Image exfiltration: Through artifactregistry permissions the attacker can download and exfiltrate an image that is being used inside Google Kubernetes Engine (GKE).
• STEP 4 Infecting the image and pushing to Artifact Registry: The attacker can then inject malicious code into the image and push it back to the artifact registry, which is then deployed once again to the GKE.
• STEP 5 Supply Chain Attack and Remote Code Execution: Once the malicious image is deployed, the attacker can exploit it and run code on the docker container as root.

Recommendations.

After Orca reported this issue to Google, Google informed Orca that they would keep the default permissions on Google Cloud Build the same while removing the logging.privateLogEntries.list permission. As a result Orca explained that, “It’s important for security teams to be very aware of which accounts are entitled to this. If one is compromised, the consequences can be immense.” Further, it is recommended that security teams adjust the permissions granted to a Google Cloud Build Service account for the organization's specific needs. “In general, it’s recommended to continuously assess entitlement credentials and remove those that contradict the Principle of Least Privilege (PoLP),” Orca concluded. 

(Added, 6:00 PM ET, July 18th, 2023. Jeff Williams, co-founder and CTO at Contrast Security, drew some general lessons and offered historical context for software supply chain risks. “People often forget that their software supply chain isn’t just the 'ingredients' that become part of the code. The supply chain also includes all the tools that development teams use to write, test, build, and deploy their code," he wrote. "These tools used to be pretty simple command line tools. But as DevOps has taken off and software pipelines fully automate much of the process, these tools are now very complex. That leads to many opportunities for attackers to subvert organizations’ software." There are precedents for this kind of issue as well. "Bad.Build isn’t the first example of compromising the build pipeline. I found RCE’s in Jenkins in the mid-2000’s and first wrote about how build pipelines could be abused in a 2009 BlackHat talk called Enterprise Java Rootkits. Recently the SolarWInds breach really brought this into the public eye. But we are going to see these for many years to come, as development, test, and build environments are not well secured in many organizations." Fixing the problem isn't trivial. It involves a close look at how software is built. "Organizations should put some work into ensuring the integrity of the software they build. But it’s going to take some work over years to secure all the pieces that might allow an attacker to trojan software. Even developer laptops are critical – if an attacker can get into any developer’s machine, or subvert any tool that the developer downloads, they can attack the build pipeline even without a vulnerability like Bad.Build.”)