2024-08-07 –, Florentine A
In cloud environments, static and long-lived credentials are highly discouraged as they often get leaked and are the cause for most publicly known cloud data breaches. To solve this problem, cloud providers such as AWS, Azure and Google Cloud support "keyless authentication" through OpenID Connect (OIDC), allowing you to exchange JSON Web Tokens (JWTs) signed by trusted identity providers for cloud credentials. Keyless authentication is especially popular for CI/CD, and enables pipelines to seamlessly authenticate to a cloud environment.
Keyless authentication is easy to configure—and unfortunately, to misconfigure. In this talk, we demonstrate that AWS IAM roles using keyless authentication are, in many cases, insecurely configured and allow unauthenticated attackers to retrieve cloud credentials and further compromise the environment. We share our research where we have identified dozens of vulnerable roles in the wild; in particular, we were able to compromise AWS credentials of an account belonging to the UK government, and pivot from there to an internal code repository. Finally, we showcase not only how to identify vulnerable roles in your environment, but also how to use higher-level guardrails to ensure that a human mistake doesn't turn into a data breach.
I have included a rough structure below.
- AWS IAM introduction
- IAM users, long-lived credentials and their problems
- "IAM roles", what they are and how to assume them
- IAM role trust policy concept and examples
- tl;dr of most common causes for cloud data breaches based on real-world data: long-lived access keys
- OIDC with IAM roles
- How it works (hands-on + demo)
- How it can go wrong
- Impact
- Hunting for vulnerable roles
- How to find role ARNs in the wild (Sourcegraph, GitHub code search, wordlists...)
- Our process to scan for misconfigured roles
- What we found
- How to apply this to your environment
- Pentester/red teamer: chain several known techniques (find account ID based on public S3 bucket then brute-force role names, OSINT to find account ID / role names, well-known roles wordlists...)
- Defender/blue teamer: guardrails to put in place (e.g. org-custom GitHub OIDC provider, SCPs, scanning the environment)
- Conclusion / similar attack vectors in other services
Christophe lives in Switzerland and works on cloud security research and open source at Datadog. He previously worked as a software developer, penetration tester and cloud security engineer. Christophe is the maintainer of several open-source projects such as Stratus Red Team, GuardDog, CloudFlair, Adaz, and the Managed Kubernetes Auditing Toolkit (MKAT).