Supply Chain Vuln Compromised Core AWS GitHub Repos & Threatened the AWS Console

https://www.wiz.io/blog/wiz-research-codebreach-vulnerability-aws-codebuild

by uvuv • 6 months ago

160 34 6 months ago

chuckadams3• 6 months ago

Breaking this down, several of AWS's core repos like the JS SDK use an allowlist of which contributor ids can run workflow actions in their PRs. The list was a regex, contained several short ids, and wasn't anchored with ^$, so if it allowed user 12345, then any userid containing 12345 could run their own actions on the PR, including one that exfiltrated access tokens. So they spammed GH with user creation requests, got an id that matched, and they were in like Flynn.

Said tokens didn't have admin access, but had enough privileges to invite other users to become full admins. Not sure if they were rotated, but github tokens are usually long-lived, like up to a year. Hey, isn't AWS the one always lecturing us to use temporary credentials? To be fair, AWS did more than just fix the regex, they introduced an "approve workflow run" UI unto the PR process that I think GH is also using now (not sure about that).

cyberax2• 6 months ago

Said tokens didn't have admin access, but had enough privileges to invite other users to become full admins.

Ah... Github permissions. What fun.

Github actually has a way to federate with AWS for short-lived credentials, but then it screws everything up by completely half-assing the ghcr.io implementation. It's only available using the old deprecated classic access tokens.

catlifeonmars5• 6 months ago

Right? How is it that you still need a PAT or a custom app installation to access a registry?

fowl2• 6 months ago

Yeah wow! Even most "trusted" contributors shouldn't have this level of access. Is there really no way of scoping tokens with more granularity?

bflesch• 6 months ago

At least the vuln was old enough so that they couldn't blame AI for it, otherwise the article would read different ;)

chuckadams3• 6 months ago

Ironically (?) an AI code review would very likely have noticed the overly-permissive regex.

TacticalCoder• 6 months ago

The list was a regex ...

Regexpes for security allow lists: what could possibly every go wrong uh!?

whatever1• 6 months ago

Another success story for Regexes! Let's keep using this cryptic mess!

pxc• 6 months ago

I met regexes when I was 13, I think. I spent a little time reading the Java API docs on the language's regex implementation and played with a couple of regex testing websites during an introductory programming class at that age. I've used them for the rest of my life without any difficulty. Strict (formal) regexes are extremely simple, and even when using crazy implementations that allow all kinds of backreferences and conditionals, 99.999% of regexes in the wild are extremely simple as well. And that's true in the example from TFA! There's nothing tricky or cryptic about this regex.

That said, what this regex wanted to be was obviously just a list. AWS should offer simpler abstractions (like lists) where they make sense.

bink2• 6 months ago

As a security dude I spend way too much of my time fixing missing anchors or unescaped wildcards in regex. The good news is that it's trivial to detect with static analysis tooling. The bad news is that broken regex is often used for security checks.

edoceo• 6 months ago

https://xkcd.com/1171/

SkiFire132• 6 months ago

Sometimes I wish regexes were full matches by default and required prefixing and postfixing with `.*` to get the current behaviour

McAdam• 6 months ago

happens to the best of us

teeklp• 6 months ago

Oh no, is the AWS Console ok?

mikesurowiec• 6 months ago

I worked on docs at GitHub which are open source, synced to an internal repo, and deployed on internal infra. I recall jumping through many hoops to make it work safely. These were workflows that had secrets access for deployments, and I recall zipping files, doing some weird handoffs/file filtering between different workflows based on the triggers and permissions. Security folks were really quick to find any gaps =)

Glad to see a few more security knobs on actions these days!

themafia• 6 months ago

I always wondered if their decision to limit availability of CodeCommit had something to do with the overall quality of the underlying implementation. It always came off as an "also ran" product without any real care or effort put into it. Either that or the team responsible for creating it ultimately left the company.. anyways..

This article lends some credibility to that notion.

btown• 6 months ago

To escalate privileges, we abused the token’s repo scope, which can manage repository collaborators, and invited our own GitHub user to be a repository administrator.

From everything I know about pentesting, they should have stopped before doing this, right? From https://hackerone.com/aws_vdp?type=team :

You may only interact with accounts you own or with explicit written permission from AWS or the account owner

bink2• 6 months ago

I think it comes down to what you do with the access. Since this is a public repo I don't think I'd be too upset at the addition of a new admin so long as they didn't do anything with that access. It's a good way to prove the impact. If it were a private repo I might feel differently.

az226• 6 months ago

It’s possible that AWS is a Wiz customer, which would allow them to do more stuff.

rand846633• 6 months ago

I’d guess that we would not have had the pleasure of reading this article if wiz was payed by AWS. There were multiple high impact bug in 2025 that we read about here, where security researchers had to turn down small six figure bounties to avoid NDAs…

InitialBP• 6 months ago

This comes entirely down to the scope of the agreement for the assessment. Some teams are looking for you to identify and exploit vulns in order to demonstrate the potential impact that those vulnerabilities could have.

This is oftentimes political. The CISO wants additional budget for secure coding training and to hire more security engineers, let the pentesting firm demonstrate a massive compromise and watch the dollars roll in.

A lot of time, especially in smaller companies, it's the opposite. No one is responsible for security and customers demand some kind of audit. "Don't touch anything we don't authorize and don't do anything that might impact our systems without explicit permissions."

Wiz is a very prominent cloud security company who probably has incredibly lucrative contracts with AWS already, and their specialty, as I understand it, is identifying full "kill chains" in cloud environments. From access issues all the way to compromise of sensitive assets.

jacquesm• 6 months ago

I try to avoid regexes like the plague, it is right up there with passing stuff into SQL strings. It is tempting enough to be used but it always goes wrong, no matter how good your sanitation. Even if the original author gets it right sooner or later someone will tweak the regex just a little to allow some edgecase and accidentally open the door to a whole pile of other cases. It's just too finicky and too powerful.

tnkuehne• 6 months ago

How did they create so many GitHub accounts? I used login with GitHub in the past to prevent spam but I feel like, after hearing this, I need to check for something like account age to prevent spam.

bstsb• 6 months ago

they explain in the article how they create hundreds of “bot” accounts using github apps, which seemingly aren't subject to the same rate limiting and captchas as user accounts

Supply Chain Vuln Compromised Core AWS GitHub Repos & Threatened the AWS Console

Related Stories