glassechidna / actions2aws Goto Github PK

Hi.
Thank you for sharing your solution 😀.
I just came across your implementation and had a look at your diagram. I’m asking myself how the lambda makes sure the requested credentials are delivered to an action belonging to your repos/org? What’s preventing a malicious GitHub action with any valid GitHub repo and any valid user session token from generating a key pair calling the api and getting your aws creds ?
Any thoughts on this ?
Kind regards
Rocco

Anyone with knowledge of the endpoint url for lambda and the AWS accountId has the capability to assume the role. This is because there is no way to verify the token that comes in is actually from github.

Any one can create a Personal Access Token (as well as any one inside a private org with READ access to any repo for private org repos) which can trick the lambda into granting credentials.

Until GitHub provides the capability to verify token issuer (via OAuth2.0 JWKs for examples), I recommend Do not use this repository to grant access to AWS.

I think this is a very neat idea, great job on coming up with it!

A couple of attacks come to mind, this is one of them.

Could a malicious PR obtain credentials? An attacker:

1. Forks the repo
2. Changes the workflow to send the creds to themself
3. Creates a PR.
4. The action runs, the lambda generates creds, and the subverted job sends them on to the attacker.

Or is that what this check is protecting against? The comment mentions forks, I'm not familiar enough with the github api to know if this is protecting against PRs running in the genuine repo but sourced from a fork.

If this is already protected against (and the lambda won't return creds for PRs sourced from forks), then I think it would be worth mentioning in the README.

I think there is a potential attack on the integrity of the public key.

An attacker can call the API at any point, and specify any run/job/step combo for which to search the output for a public key. If they can get their own public key included in the output of any step of any job, they can then obtain creds for the victim's account by calling the API specifying where it should look.

Whilst this won't be exploitable against all workflows, according to Project Zero's research:

almost any project with somewhat complex Github actions is vulnerable to this bug class

It's not obvious to users that if you're using actions2aws then allowing attacker-controlled text to appear in the output of any job grants that attacker access to your AWS account.

One mitigation would be to make the job/step config part of the lambda deployment, so it's not under attacker control.