Loading…
Identifying vulnerabilities in GitHub Actions & AWS OIDC Configurations
TinderTinder
Summary
In 2021, GitHub released OpenID Connect support for GitHub Actions to let workflows retrieve short-lived cloud session tokens instead of storing static secrets. Tinder Security Labs discovered widespread IAM role misconfigurations that allow external repositories to assume target roles and access AWS resources. The primary issue stems from IAM trust policies that authenticate the GitHub identity provider but omit strict validation on the subject claim. Researchers located exposed role identifiers via public workflow searches and confirmed that arbitrary external GitHub Actions workflows could assume them, including roles within AWS official repositories. Remediation requires configuring trust policies to restrict the audience and validate repository namespaces, while unauthorized assumptions can be detected in CloudTrail logs.
Context
OpenID Connect integration between GitHub Actions and cloud providers can introduce security vulnerabilities when organizations misconfigure IAM trust policies without properly restricting which external repositories are authorized to assume roles.
Approach / What changed
Researchers performed black-box testing by discovering IAM role ARNs via GitHub code search, attempting role assumptions from an external workflow, releasing an automated scanner, and reporting vulnerable roles across multiple organizations including AWS.
Takeaways
- Omission of the subject (sub) claim check in an AWS IAM trust policy allows any arbitrary GitHub repository to assume the role via GitHub Actions OIDC.
- Successful role assumption events are recorded in AWS CloudTrail logs, where the username attribute includes the requesting repository and organization name.
- Securing OIDC IAM roles requires configuring trust policies to enforce exact audience values and strict repository namespace matching in the subject claim.
Related reading
Tinder ·
How to Categorize and Prevent Risks of Sensitive Links in URLScan
Security integrations with URLScan can accidentally index sensitive links when API calls are executed with public visibility. Tinder Security Labs constructed targeted queries to uncover exposed links across file-sharing services, enterprise ticketing platforms, and single sign-on portals. Investigations revealed that exposed links included document magic links containing contracts and bank details, as well as active new-hire registration links that allowed attackers to complete registration workflows and configure two-factor authentication. In one SSO query alone, researchers discovered 1,300 indexed invitation links, with 20 to 50 new links appearing daily. The researchers collaborated with URLScan to purge the exposed indexes from public searches and advised organizations to configure security scanning tools to use private or unlisted visibility settings.
TinderGithub ·