Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

wiz.io

Post reply on HN
Print view View original

11–20 of 40 posts

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

#11

Post by pxc »

whatever1 wrote: post #9
chuckadams wrote: post #2

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,…

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

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.

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

#12

Post by btown »

> 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

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

#13

Post by bink »

btown wrote: post #12

> 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

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.

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

#14

Post by bink »

chuckadams wrote: post #2

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,…

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.

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

#15

Post by chuckadams »

bflesch wrote: post #6
chuckadams wrote: post #2

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,…

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

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

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

#16

Post by edoceo »

bink wrote: post #14
chuckadams wrote: post #2

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,…

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.

https://xkcd.com/1171/

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

#17

Post by catlifeonmars »

chuckadams wrote: post #15
bflesch wrote: post #6

Earlier quoted context omitted.

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

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

This is a good point. On my GH I’ve disabled Copilot reviews because the vast majority of them are false positives, but I’m reconsidering that position as it might still be worth it to wade through the spurious reviews just to catch some real issues.

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

#18

Post by catlifeonmars »

cyberax wrote: post #5
chuckadams wrote: post #2

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,…

> 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.

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

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

#19

Post by catlifeonmars »

pxc wrote: post #11
whatever1 wrote: post #9

Earlier quoted context omitted.

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

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…

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

Agree. I would understand if there was some obvious advantage here, but it doesn’t really seem like there is a dimension here where regex has an advantage over a list. It’s (1) harder to implement, (2) harder to review, (3) much harder to test comprehensively, (4) harder for users to use (correctly/safely).

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

#20

Post by whatever1 »

pxc wrote: post #11
whatever1 wrote: post #9

Earlier quoted context omitted.

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

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…

[flagged]
Post reply on HN