Potential AWS critical vulnerability

[wparad]

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.

[aidansteele]

Hi @wparad, sorry I didn't see this until just now. I'm not sure I understand the threat - can you please demonstrate? I have an endpoint deployed at https://a0gy7ozvrj.execute-api.us-east-1.amazonaws.com/ with account ID 304520749683. Can you share the access key ID (i.e. the string beginning ASIA...) that you are able to retrieve?

(It's worth noting that this repo shouldn't be used anyway now that GitHub can issue OIDC tokens, but I'm still very curious to understand the vulnerability you describe)

[wparad]

Nope, I was totally wrong.

Initiall I thought it exposed the same vulnerability that https://www.vaultproject.io/docs/auth/github has, but it doesn't

All that are doing here, is same way all encrypted messages are sent usually, providing a public key, and having the service pull that and encrypt the credentials with it before sending it back. I was initially thinking that the either public key or the github token from the runner were being sent in the request, but since the service is pulling all this data, the only vulnerability here is DDoS on your endpoint.

That is my bad, I shouldn't have opened this.