Full Report
OpenID Connect (OIDC) is a common authorization service. Of course, AWS supports a way to authorize services outside of AWS to assume IAM roles using it. Besides this post, they have many other cases where the permissions of OIDC are incorrect and this leads to a privilege escalation. The service of focus this time is Gitlab The default trust policy for OIDC Gitlab authentication contains the principal (Gitlab.com), an action for AssumeRoleWithWebIdentity and an optional condition key of gitlab.com:sub. This is either a group, project or branch that is allowed to submit this. The reason there is a misconfiguration is the optional condition key - aka, fails open. The sub field on the JWT - who is permitted to assume the role - is not a required field. If this is not included, then there are a wide variety of ways to assume the role in AWS. The example policy used for the test does not include the sub at all but only the aud. To exploit this, an attacker needs to create a valid JWT for the sts:AssumeRoleWithWebIdentity invocation. Doing this only requires having an account on Gitlab, creating a project with CI and support for JWT generation. In the CI, we can simply output the GITLAB_OIDC_TOKEN and this will work for us. In AWS, we can then use the token with a call to sts:AssumeRoleWithWebIdentity to assume the role now. Generating a trust policy for Gitlab in the AWS console is created insecure by default, which is terrifying. In the case of Github Actions and Terraform Cloud, AWS made changes to require specific fields. Overall, a good and concise write up on a common AWS misconfiguration.
Analysis Summary