A critical misconfiguration in AWS’s CodeBuild service allowed complete takeover of the cloud provider’s own GitHub repositories and put every AWS environment in the world at risk, according to Wiz security researchers.

The Wiz kids disclosed this supply chain snafu to AWS in August, and the cloud giant fixed the security issue in September, before a cybercriminal or government-backed goon stumbled upon the misconfiguration and abused it to spark a worldwide meltdown.

This, we’re told, prevented a bigger-than-SolarWinds supply chain attack – so be sure to thank your friendly neighborhood security researchers before you go to sleep tonight. 

“This vulnerability compromised a core library used in the AWS Console itself – the central nervous system of the cloud,” Wiz vulnerability researcher Yuval Avrahami told The Register. “SolarWinds gave attackers access to corporate networks. This could have given attackers code execution in the very interface administrators use to manage their entire infrastructure.”

It’s worth noting that last March, Google announced its intention to acquire Wiz for $32 billion and integrate its cloud security offerings into the Google Cloud platform, which competes directly against AWS. The deal has been approved by US regulators but is awaiting approval in the EU and elsewhere.

Breaking the code(build)

In an analysis shared with The Register ahead of publication, Avrahami and co-authors detailed the supply chain vulnerability they dubbed CodeBreach. 

It exists in CodeBuild, AWS’s managed continuous integration (CI) service that commonly connects to GitHub repos. And it’s caused by two missing characters in the webhook filters – rules that an event must meet to trigger a build – that are supposed to defend against untrusted pull requests.

Avrahami added the security threat may extend well beyond AWS.

“This vulnerability exploits a blind spot in CI/CD [continuous integration/continuous delivery] security, not a flaw unique to AWS,” he told us. “This specific risk – granting excessive privileges to external contributors via automated CI/CD builds – is a universal challenge. Whether using GitHub Actions, Jenkins, or Cloud CI services like AWS CodeBuild, every major cloud provider and tech company faces this exact risk in their open-source supply chains.”

This vulnerability exploits a blind spot in CI/CD security, not a flaw unique to AWS

In a statement published in the Wiz report, an AWS spokesperson said the cloud provider investigated and fixed the issues, and determined that the configuration flaw identified by the researchers had “no impact” on any customer environment or AWS service.

“AWS took a number of steps to mitigate all issues discovered by Wiz, as well as additional steps and mitigations to protect against similar possible future issues,” the statement said. “The core issue of actor ID bypass due to unanchored regexes for the identified repos was mitigated within 48 hours of first disclosure,” the statement continued, adding that AWS also enacted “further protections of all build processes that contain Github tokens or any other credentials in memory.”

But wait, there’s more: AWS also says it audited all other public build environments to ensure that no similar security flaws exist across its open source projects. Plus, it audited the logs of all public build repositories and associated CloudTrail logs, which “determined that no other actor had taken advantage of the unanchored regex issue demonstrated by the Wiz research team.”

Poking around the CI pipeline

The Wiz team started poking around in Amazon’s CI pipeline following an attempted supply-chain attack on the Amazon Q VS Code extension caused by a similar CodeBuild issue.

First, the researchers decided to search for GitHub repositories connected to public CodeBuild projects.

“When set to public, CodeBuild projects expose their settings via a publicly accessible dashboard and automatically link to it in the status of any commit that triggers a build. From the dashboard, anyone can view the project’s build logs and configurations – including the exact webhook filters being used,” they wrote in the report.

They found four that were active and configured to run builds on pull requests:

• The AWS SDK for JavaScript (aws/aws-sdk-js-v3)
• AWS Libcrypto (aws/aws-lc)
• Amazon Corretto Crypto Provider (corretto/amazon-corretto-crypto-provider)
• The Registry of Open Data on AWS (awslabs/open-data-registry)

All four projects used the ACTOR_ID webhook filter, a safety feature that provides an allow-list of approved GitHub user IDs. Only these trusted users can trigger a build.

The filter was a regular expression (regex) pattern – but it wasn’t anchored. “Without the start ^ and end $ anchors to require an exact match, a regex engine doesn’t look for a string that perfectly matches the pattern, but one that merely contains it,” the researchers wrote. “This meant that any GitHub user ID that is a superstring of an approved ID could bypass the filter.”

Creating a repo admin out of thin air

Next, the security sleuths figured out how to register a new GitHub user ID that contained an existing maintainer’s ID. For this, they used GitHub Apps, which allows users to create an app – this generates a corresponding bot user that can interact with pull requests and a unique confirmation URL – and has a feature that allows users to automate app creation requests. 

Wiz automated 200 of these app creation requests via GitHub Apps in the hopes that one of these would capture a user ID that could bypass the ACTOR_ID filter. It worked, and now Wiz had a trusted maintainer ID for the AWS SDK for JavaScript repository.

The researchers then prepared a pull request that looked like a routine contribution to fix a legit issue. Inside, however, they hid the payload: an NPM package dependency designed to execute in the build environment and extract the GitHub credentials.

“Moments later, we had successfully obtained the GitHub credentials of the aws-sdk-js-v3 CodeBuild project,” they wrote.

They escalated privileges and created a repository administrator who could push code to the main branch, approve pull requests, and exfiltrate repository secrets, providing “a clear path for supply chain attacks.”

Any intermediate developer could execute it. The real challenge is stealth: crafting a payload that looks benign enough in the case someone inspects the library code

An attacker could inject malicious code into the JavaScript SDK right before its latest release is published (this happens on a weekly basis), thus infecting all downstream users. And according to Wiz, the scope of such an attack is “staggering.” The cloud security outfit says 66 percent of cloud environments include the JavaScript SDK, and one of these users is the AWS Console.

The researchers also used this same method to gain full admin-level privileges to “several” other repositories, including one that they said looked to be AWS’ private mirrors of the JavaScript SDK.

At this point, realizing the takeover’s “potential impact,” Wiz turned their research over to AWS.

According to Avrahami, this type of attack required a “surprisingly low” level of technical expertise.

“This attack relies on standard developer workflows – forking a repo and submitting a pull request – rather than sophisticated exploits,” he told The Register. “Any intermediate developer could execute it. The real challenge is stealth: crafting a payload that looks benign enough in the case someone inspects the library code.”

Plus, it’s an attack vector that appeals to both “nation-state actors seeking espionage and cybercriminal syndicates seeking scale,” Avrahami added. “Once in control of the repositories, they could have injected backdoors into the SDK to harvest credentials from millions of applications, exfiltrate sensitive data, or target the AWS Console itself to manipulate cloud infrastructure undetected.” ®