OH MY DC Abusing OIDC all the way to your cloud

OH MY DC Abusing OIDC all the way to your cloud

Speakers: Aviad Hahami

Conference: DEF CON 32

YouTube: https://www.youtube.com/watch?v=asd33hSRJKU

Overview

In the DEF CON 32 talk "OH MY DC Abusing OIDC all the way to your cloud," security researcher Aviad Hahami from Palo Alto Networks delves into the critical security implications of OpenID Connect (OIDC) within Continuous Integration/Continuous Delivery (CI/CD) pipelines. Hahami highlights a significant shift in authentication practices for machine-to-machine interactions, moving away from vulnerable hardcoded secrets or traditional API keys towards a more robust, identity-based approach facilitated by OIDC. The central premise of the talk is to expose potential pitfalls and misconfigurations that can arise when OIDC is integrated into CI/CD workflows, ultimately leading to unauthorized access to cloud environments.

The presentation aims to educate a broad audience, from those new to OIDC to seasoned security professionals and bug bounty hunters. For newcomers, it provides a foundational understanding of OIDC and its role in modern CI/CD. For experienced users, Hahami promised to reveal common misconfigurations and advanced exploitation techniques that could compromise cloud resources. The talk emphasizes that while OIDC offers a more secure alternative to static credentials, its complex implementation within dynamic CI/CD environments introduces new vectors for attack, particularly when configurations are not meticulously managed by either the user or the CI vendor itself.

Aviad Hahami's research focuses heavily on the CI domain, building on previous work such as an Azure CLI information leakage vulnerability (CVE-2023-28269, scoring 8.6). This background underscores the practical relevance of his findings, positioning the talk as a crucial exploration into an evolving threat landscape where CI/CD pipelines serve as critical conduits to an organization's most sensitive cloud assets. By understanding how OIDC can be abused, organizations can proactively strengthen their security posture and prevent sophisticated supply chain attacks originating from their CI infrastructure.

Background

▶ Watch: Introduction to O my DC talk and speaker (0:00)

Modern software development heavily relies on Continuous Integration (CI) and Continuous Delivery (CD) pipelines to automate the build, test, and deployment processes. A typical CI/CD workflow begins when a developer performs an action (e.g., a push or pull request) on a Version Control System (VCS) provider like GitHub or GitLab. This action triggers a webhook notification to a CI provider (e.g., GitHub Actions, GitLab CI, CircleCI, Jenkins), which then spins up a virtual machine or container. This machine executes predefined tasks—such as linting, building, compiling, and crucially, deploying code or artifacts to various cloud environments like GCP, AWS, or Docker Hub.

A fundamental challenge in this machine-to-machine interaction is authentication. Historically, organizations have relied on hardcoding secrets directly into repositories or using CI provider-managed secrets. Both methods present significant security risks. Hardcoded secrets are easily discoverable and often lead to widespread breaches when repositories are compromised. While CI provider secrets offer a marginal improvement by centralizing secret management, they remain static credentials that, if leaked, can grant persistent unauthorized access. The industry has seen numerous incidents where such secret leakages have led to major security compromises, making these approaches increasingly untenable.

This is where OpenID Connect (OIDC) emerges as a transformative solution. OIDC is an authentication layer built on top of the OAuth 2.0 framework. While OAuth 2.0 is primarily an authorization protocol, OIDC extends it to provide identity verification. Instead of relying on long-lived, static credentials, OIDC enables machines (like CI/CD runners) to obtain short-lived, cryptographically signed tokens known as ID tokens. These tokens assert the identity of the requesting entity and contain various "claims" about that identity, which can then be used by a target resource (e.g., a cloud provider) to make authorization decisions.

The core OIDC flow, in its vanilla version, involves a client (user or machine) attempting to log in, being redirected to an Identity Provider (IdP), authenticating with the IdP, receiving an ID token, and then presenting this token to a Relying Party (RP) (the resource server) to gain access. Unlike traditional OAuth, which might return an access token and refresh token, OIDC focuses on the ID token, which is a JSON Web Token (JWT). These JWTs are Base64-encoded strings, typically consisting of three parts: a header, a payload (the body), and a signature. The header specifies the token's type and the signing algorithm, used for verifying the token's integrity. The payload, or ID token body, is a JSON dictionary containing claims, which are statements about the entity (e.g., sub for subject, iss for issuer, aud for audience, exp for expiration). These claims are central to how the identity of the CI machine is asserted and how access is granted.

In the context of CI/CD, the CI provider acts as the IdP, issuing ID tokens to the ephemeral CI machines. The critical distinction is that a CI invocation runs in the context of the user who configured the CI integration, meaning the machine is associated with that user's identity. This identity, asserted through the OIDC ID token and its claims, then allows the CI machine to assume roles or access resources in cloud environments without ever handling static, long-lived credentials directly. This architectural shift significantly improves security by reducing the attack surface associated with credential leakage, but it also introduces new complexities around token issuance, claim validation, and trust boundaries that attackers can exploit if not properly configured.

Key Findings

▶ Watch: CI/CD explained in one slide for beginners (2:20)

While the provided transcript segment primarily establishes the foundational understanding of OIDC and CI/CD, it clearly sets the stage for a deep dive into misconfigurations and abuses of OIDC setups within CI environments. The talk's title, "Abusing OIDC all the way to your cloud," and the speaker's stated agenda items—"no configs," "advanced configurations, misconfigurations," and "what happens when the CI vendor makes the misconfig"—strongly indicate the core findings revolve around vulnerabilities arising from improper OIDC implementation.

The central finding, implicitly, is that despite OIDC being a more secure alternative to static credentials, its complexity introduces new attack vectors. These vectors can be broadly categorized into:

1. User-Side Misconfigurations: Developers or security teams, when integrating OIDC with their cloud providers, may improperly configure the Relying Party (RP) (e.g., an AWS IAM role or GCP service account) to validate the incoming OIDC ID tokens. This could involve overly permissive trust policies that accept tokens with insufficient or easily forgeable claims, or that don't correctly verify the issuer or audience of the token. Such misconfigurations can allow an attacker who gains control over a CI runner to craft or manipulate an OIDC token that is then accepted by the cloud provider, granting unauthorized access to sensitive resources.

1. CI Vendor-Side Misconfigurations or Vulnerabilities: A more insidious finding, as hinted by Hahami, is when the CI vendor itself (acting as the Identity Provider) introduces misconfigurations or has vulnerabilities in how it generates and issues OIDC ID tokens. If the CI vendor's OIDC implementation is flawed, it could issue tokens with incorrect or mutable claims, or tokens that can be requested by unauthorized entities. This could potentially allow an attacker to bypass the intended security controls at a fundamental level, gaining a legitimate-looking ID token that can be leveraged for cloud access, even if the user's configurations are otherwise sound. Such a finding would highlight a critical supply chain risk, where the security of cloud deployments is dependent on the CI vendor's OIDC robustness.

1. Lack of Granular Control ("No Configs"): The term "no configs" in the agenda suggests that default OIDC setups provided by CI vendors might be too broad or lack the necessary granularity for secure access control. Without specific, restrictive configurations, OIDC tokens might inherently carry more permissions than necessary or be too generic in their claims, making them easier for attackers to abuse. This implies that simply enabling OIDC integration without further hardening can still leave organizations exposed.

Ultimately, the key findings underscore a critical message: the shift to identity-based authentication in CI/CD is a step forward, but it moves the security challenge from protecting static secrets to correctly validating and trusting dynamic identities. Any weakness in this chain—whether at the token issuance, claim generation, or token validation stage—can be exploited to achieve full compromise of connected cloud environments.

Technical Deep Dive

▶ Watch: OIDC overview: Solving credentials with identities (4:30)

The technical core of Aviad Hahami's talk revolves around the intricate interplay of CI/CD pipelines and OpenID Connect (OIDC) for machine-to-machine authentication. The fundamental problem OIDC solves in this context is how an ephemeral CI runner, without static credentials, can securely authenticate to and gain authorization from cloud providers like AWS, GCP, or Docker Hub.

Let's break down the CI/CD and OIDC flow:

1. CI Trigger and Runner Provisioning: When a developer pushes code to a Version Control System (VCS) like GitHub, the VCS sends a webhook to the configured CI provider. The CI provider then provisions a temporary execution environment, often a virtual machine or container, known as a CI runner. This runner is isolated and configured according to the project's workflow (e.g., a .github/workflows/*.yml file for GitHub Actions).

1. Identity Association: Crucially, the CI provider associates this runner's execution with the identity of the user or organization that configured the CI integration. As Hahami emphasizes, "A CI invocation is in the context of the owner of the CI integration." This means the runner, though a machine, implicitly carries the identity context of its human owner.

1. OIDC ID Token Request: Within the CI runner, when an action requires access to an external cloud resource (e.g., deploying to an S3 bucket or a Kubernetes cluster), it initiates an OIDC flow. The CI runner, acting as a client, requests an ID token from the CI provider, which now functions as the Identity Provider (IdP). This request is typically made via a specific API endpoint or an environment variable exposed by the CI system. For example, GitHub Actions exposes an ACTIONS_ID_TOKEN_REQUEST_URL and ACTIONS_ID_TOKEN_REQUEST_TOKEN.

1. ID Token Generation and Claims: The CI IdP (e.g., GitHub's OIDC provider) generates a JSON Web Token (JWT), which is the OIDC ID token. This token is cryptographically signed by the IdP and contains a set of claims in its payload. These claims are key-value pairs that assert information about the identity and context of the CI job. Common claims relevant to CI/CD OIDC include:

• iss (Issuer): Identifies the IdP (e.g., https://token.actions.githubusercontent.com).
• aud (Audience): Identifies the recipient(s) that the JWT is intended for (e.g., the AWS account ID or GCP project ID).
• sub (Subject): Identifies the principal that is the subject of the JWT. In CI/CD, this often includes granular information about the repository, branch, workflow, or environment, such as repo:octo-org/octo-repo:ref:refs/heads/main or environment:production.
• exp (Expiration Time): The time after which the JWT must not be accepted.
• iat (Issued At Time): The time at which the JWT was issued.
• jti (JWT ID): A unique identifier for the JWT.
• ref, repository, workflow, environment: GitHub-specific claims providing context about the CI job.

1. ID Token Presentation and Validation: The CI runner then presents this short-lived ID token to the Relying Party (RP), which is the cloud provider (e.g., AWS IAM, GCP IAM). The cloud provider, configured to trust the CI IdP, performs several critical validation steps:

• Signature Verification: It verifies the token's cryptographic signature using the public keys provided by the CI IdP's OIDC discovery endpoint. This ensures the token was indeed issued by the legitimate CI provider and hasn't been tampered with.
• Claim Validation: It validates the claims within the token against predefined policies. This is where misconfigurations often arise. For instance, an AWS IAM Trust Policy for an OIDC Identity Provider might specify conditions like:

Here, the Condition block is crucial. It dictates that the role can only be assumed if the sub claim matches a specific repository and branch, and the aud claim matches the expected audience.

Potential Misconfigurations and Abuse Vectors (as hinted by the talk's agenda):

The danger lies in how these claims are validated and what policies are set:

• Overly Permissive sub Claims: If the sub claim in the cloud provider's trust policy is too generic (e.g., repo:octo-org/: or even just ), an attacker who can trigger a CI job in any* repository or branch within the organization might be able to assume a powerful role. This is the essence of "no configs" or default, insecure setups.
• Incorrect aud Validation: If the cloud provider doesn't correctly validate the aud (audience) claim, a token intended for one service might be accepted by another, leading to unauthorized access.
• Mutable Claims or Weak IdP: If the CI vendor's OIDC implementation has flaws, it might issue tokens where certain claims (like ref or environment) can be manipulated by an attacker controlling the CI workflow. For example, if an attacker can make a pull request that modifies the ref claim to appear as a protected branch, they could bypass security checks. This falls under "when the CI vendor makes the misconfig."
• Lack of Granular Policies: Without fine-grained policies that tie specific OIDC claims (e.g., environment, workflow, actor) to specific permissions, an attacker gaining control of a low-privilege CI job could elevate their access by simply obtaining an OIDC token that is broadly trusted.

The talk, by focusing on these areas, aims to illustrate how an attacker can exploit weaknesses in the OIDC issuance or validation process to obtain a valid-looking ID token, assume a privileged role in a cloud environment, and gain unauthorized access, effectively "abusing OIDC all the way to your cloud."

Demo / Proof of Concept

▶ Watch: Understanding ID tokens, JWTs, and claims (6:00)

The provided transcript segment for Aviad Hahami's talk, while outlining a comprehensive agenda, concludes before detailing any specific live demonstration or proof-of-concept (PoC). The speaker introduces the concepts of CI/CD, OIDC, ID tokens, and claims, and then repeats the agenda, indicating that the core exploitation scenarios ("no configs," "advanced configurations, misconfigurations," and CI vendor misconfigurations) were to be covered later in the presentation.

However, based on the talk's title, its stated objectives for bug bounty hunters, and the technical background provided, potential PoC scenarios would likely involve demonstrating how a compromised or misconfigured CI pipeline could be leveraged to forge or misuse OIDC ID tokens to gain unauthorized access to cloud resources.

A typical PoC for this type of vulnerability would involve:

1. Establishing a Vulnerable CI Setup: This could involve a GitHub Actions workflow or a GitLab CI pipeline configured with an OIDC integration to an AWS, GCP, or Azure cloud environment. The vulnerability would be introduced either through an overly permissive trust policy on the cloud provider side (e.g., an IAM role allowing assumption based on a broad sub claim like repo:org/:) or by simulating a flawed CI vendor OIDC issuance where certain claims could be manipulated.
2. Attacker Action within CI: An attacker, perhaps through a malicious pull request or by gaining control of a repository, would execute a CI job. This job would be designed to:

• Request an OIDC ID token from the CI provider.
• (In the case of a CI vendor misconfiguration) Manipulate certain claims within the token request or exploit a flaw in the token issuance to obtain a token with more permissive claims than intended.
• (In the case of an RP misconfiguration) Present the legitimately issued (but broadly claimed) OIDC ID token to the cloud provider's Security Token Service (STS) (e.g., AWS STS AssumeRoleWithWebIdentity).

1. Unauthorized Cloud Access: If successful, the attacker's CI job would receive temporary credentials (e.g., AWS access key, secret key, session token) for the assumed role. The PoC would then demonstrate the use of these credentials to perform unauthorized actions, such as:

• Listing S3 buckets or EC2 instances not meant to be accessible.
• Deploying malicious code to a production environment.
• Exfiltrating sensitive data from cloud storage.
• Modifying cloud infrastructure.

Such a demonstration would effectively illustrate how a chain of trust, once established via OIDC, can be broken or abused if any link (the CI IdP's issuance, the token's claims, or the cloud RP's validation) is weak. While the details are not in the provided transcript, the speaker's emphasis on "saving weekends" for users and providing "new ideas for exploitation" for bounty hunters strongly suggests that practical demonstrations of these attack paths were a core part of the full presentation.

Defensive Implications

▶ Watch: CI provider's role in machine identity association (7:30)

Understanding the potential for OIDC abuse in CI/CD pipelines, even from the foundational concepts presented, reveals several critical defensive implications for organizations:

1. Implement Granular OIDC Trust Policies: This is paramount. When configuring cloud roles or service accounts to trust OIDC ID tokens from CI providers, do not use overly broad sub (subject) claims or generic conditions. Instead, define highly specific conditions based on claims like repo, ref, environment, workflow, and actor. For example, an AWS IAM role should only be assumable if the sub claim matches repo:my-org/my-app:ref:refs/heads/main AND environment:production, preventing tokens from development branches or other repositories from accessing production resources.
2. Validate All Relevant Claims: Ensure that cloud provider trust policies rigorously validate all critical OIDC claims (iss, aud, sub, exp, etc.). The aud (audience) claim, in particular, should explicitly match the intended recipient of the token (e.g., your AWS account ID or GCP project ID). Failing to validate the iss (issuer) claim could allow tokens from an entirely different OIDC provider to be accepted.
3. Principle of Least Privilege: Grant only the absolute minimum permissions necessary to the OIDC-assumed roles. If a CI job only needs to read from an S3 bucket, its associated role should not have write or delete permissions. This limits the blast radius if an OIDC token is compromised.
4. Regularly Review CI/CD Configurations and OIDC Trust Policies: As CI/CD workflows evolve, so too should their associated OIDC configurations. Periodically audit both the CI workflow files (e.g., .github/workflows/*.yml) and the cloud provider's IAM policies to ensure they align with the principle of least privilege and that no overly permissive OIDC trust relationships have been introduced.
5. Monitor CI/CD and Cloud Access Logs: Implement robust logging and monitoring for both CI job executions and cloud API calls made using OIDC-federated identities. Look for unusual activity, such as roles being assumed from unexpected branches, environments, or repositories, or attempts to access resources outside the scope of the CI job's legitimate function. Alerts should be configured for suspicious OIDC token requests or role assumptions.
6. Stay Informed on CI Vendor Security Advisories: Pay close attention to security advisories and best practices published by your CI provider (e.g., GitHub, GitLab). If a CI vendor-side vulnerability in OIDC issuance is discovered, rapid patching and re-evaluation of trust policies may be necessary. The speaker's point about "when the CI vendor makes the misconfig" highlights this critical dependency.
7. Secure Your Version Control System (VCS): Since CI workflows are triggered by VCS events, securing your GitHub, GitLab, or other VCS instances is foundational. Implement strong authentication (MFA), restrict repository access, and monitor for unauthorized changes to workflow files, as these can be direct attack vectors to manipulate OIDC token requests.
8. Educate Developers: Developers are often on the front lines of configuring CI/CD. Educate them on secure OIDC practices, the importance of granular claim validation, and the risks associated with overly permissive policies. This proactive education can prevent many common misconfigurations.

By adopting these defensive strategies, organizations can significantly reduce the risk of OIDC abuse in their CI/CD pipelines and protect their cloud environments from sophisticated supply chain attacks.

Key Takeaways

• OIDC is the Future of CI/CD Authentication: OpenID Connect (OIDC) is replacing static credentials for machine-to-machine authentication in CI/CD, offering a more secure, identity-based approach using short-lived tokens.
• ID Tokens are Central: OIDC relies on ID tokens, which are JSON Web Tokens (JWTs) containing "claims" that assert the identity and context of the CI job (e.g., repository, branch, workflow).
• Misconfigurations are the Primary Threat: The security of OIDC in CI/CD heavily depends on correct configuration. Overly permissive or improperly validated claims in cloud provider trust policies are a significant vulnerability.
• CI Vendor Security Matters: Flaws or misconfigurations in the CI vendor's OIDC implementation, which acts as the Identity Provider, can also lead to critical vulnerabilities, allowing attackers to forge or misuse ID tokens.
• Granular Policies and Least Privilege are Essential: Implement strict, granular trust policies based on specific OIDC claims (e.g., repo, ref, environment) and adhere to the principle of least privilege for roles assumed via OIDC.
• Continuous Auditing and Monitoring: Regularly review CI/CD workflows and cloud IAM policies, and actively monitor CI job executions and cloud access logs for suspicious OIDC token requests or role assumptions.

About the Speaker(s)

Aviad Hahami is a security researcher at Palo Alto Networks, specializing primarily in the CI (Continuous Integration) domain. His work focuses on identifying and analyzing security vulnerabilities within CI/CD pipelines and related technologies. Hahami has a background in bug bounty hunting and has published notable research, including an Azure CLI information leakage vulnerability that received an 8.6 severity score. Beyond his professional research, Aviad has diverse interests, including DJing, graph theory, and FPV drones. This DEF CON 32 talk marks his debut as a speaker at the conference.