Grand Theft Actions Abusing Self Hosted GitHub Runners

Grand Theft Actions Abusing Self Hosted GitHub Runners

Speakers: Adnan Khan, Security Engineer, Security Researcher, Bug Bounty Hunter; John Stawinski, Red Team Security Engineer at Prastorian, CICD Security Researcher

Conference: DEF CON 32

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

Overview

In "Grand Theft Actions," Adnan Khan and John Stawinski expose a pervasive and critical vulnerability within the GitHub Actions ecosystem: the insecure configuration of self-hosted runners. Their research highlights how a common misconfiguration—the use of non-ephemeral self-hosted runners on public repositories—creates a broad attack surface that can be exploited for widespread supply chain attacks. The speakers reveal that numerous prominent organizations and projects have, at some point, utilized these runners in a manner susceptible to compromise, demonstrating the severe implications for software supply chain security.

The talk delves into the mechanics of how attackers can gain persistent code execution on internal infrastructure by leveraging seemingly innocuous actions, such as submitting a pull request to fix a typo. This seemingly minor interaction can be weaponized to modify workflow files, leading to arbitrary code execution on compromised self-hosted runners. Khan and Stawinski's findings underscore the critical need for organizations to re-evaluate their GitHub Actions security posture, particularly concerning the lifecycle and trust boundaries of their CI/CD infrastructure, to mitigate the risk of sophisticated supply chain compromises.

Background

▶ Watch: Introduction to Grand Theft Actions and topic (0:00)

GitHub Actions provides powerful automation capabilities, enabling developers to build, test, and deploy code directly from their repositories. At the core of this system are runners, which are the servers that execute the workflows defined in .yml files. GitHub offers two primary types of runners:

1. GitHub-hosted runners: These are managed by GitHub, updated frequently, support various operating systems and architectures, and are inherently ephemeral. This means they are provisioned for a single workflow job and then immediately torn down, ensuring a clean slate for each execution and preventing persistence.
2. Self-hosted runners: These are deployed and managed entirely by the end-user or organization. While offering greater control over the environment and access to internal resources, their security becomes the user's sole responsibility. The "path of least resistance" when configuring these runners often leads to a non-ephemeral setup, where the runner persists across multiple workflow jobs. This stateful nature, while convenient, introduces significant security risks.

The speakers' vulnerability research campaign originated from a red team engagement in August 2022. During this operation, John Stawinski, then new to red teaming, accidentally tripped a Canary, leading to their eviction from a client network. Through social engineering, they managed to obtain a GitHub access token. This token was then leveraged to execute a workflow and achieve persistence on a non-ephemeral self-hosted runner located within the client's network, ultimately allowing them to regain access and achieve their objective.

This initial success led to the development of the Gato tool and a subsequent talk at Schmucon in January 2023, titled "Phantom of the Python." The early research highlighted that even a seemingly trivial action, such as fixing a typo in a public repository, could be exploited. If that repository utilized a non-ephemeral self-hosted runner, a pull request modifying the workflow file could grant an attacker persistent code execution. This specific vulnerability was successfully demonstrated against the GitHub Actions runner images repository and was accepted as a critical finding. The realization that these misconfigurations were widespread across public repositories prompted Khan and Stawinski to expand their research, even breaching Microsoft's perimeter by achieving code execution on a domain-joined machine through Microsoft Deep Speed, underscoring the severity and broad applicability of this attack vector.

Key Findings

▶ Watch: Demonstrating widespread insecure self-hosted runner usage (2:00)

The core of Khan and Stawinski's research revolves around the pervasive and insecure deployment of non-ephemeral self-hosted GitHub runners. Their key findings highlight a critical gap in organizational security practices:

1. Widespread Misconfiguration: The speakers identified that numerous organizations and projects, including several prominent entities, were using self-hosted runners on their public GitHub repositories in an insecure manner. This widespread misconfiguration indicates a systemic issue rather than isolated incidents.
2. Critical Supply Chain Attack Potential: The identified vulnerabilities were not theoretical; many cases could have led to "widespread critical supply chain attacks." This means that an attacker could compromise the build and release processes of affected organizations, potentially injecting malicious code into software distributions, impacting downstream users and customers.
3. Persistence through Pull Requests: The primary attack vector demonstrated involves leveraging the non-ephemeral nature of self-hosted runners. By submitting a pull request (even for a minor change like a typo fix) to a public repository that triggers a workflow on such a runner, an attacker can inject malicious code into the workflow definition. Because the runner persists, this malicious code executes on the same, already configured machine, granting the attacker persistent access and control.
4. GitHub's Broad Attack Surface: The research emphasizes that GitHub Actions, while powerful, presents a "broad attack surface" that exposes organizations to compromise, especially when self-hosted runners are used without proper security considerations. This surface includes not only the runner itself but also the workflow definitions, repository permissions, and the interaction model with external contributions.
5. Validation by GitHub: The vulnerability demonstrated against the official "GitHub actions runner images repository" was accepted as a critical vulnerability. This validation by GitHub itself underscores the severity and legitimacy of the attack vector identified by Khan and Stawinski.

These findings collectively paint a concerning picture where the convenience of self-hosted runners, combined with a lack of understanding or adherence to best security practices, opens organizations to significant and far-reaching supply chain risks.

Technical Deep Dive

▶ Watch: Origin story: Red team discovery of runner persistence (2:45)

The technical underpinning of the "Grand Theft Actions" vulnerability lies in the fundamental difference between ephemeral and non-ephemeral self-hosted GitHub Actions runners and the trust model surrounding public repositories.

GitHub Actions workflows are defined in YAML files within the .github/workflows/ directory of a repository. These workflows specify a series of jobs, and each job runs on a designated runner. When a workflow is triggered (e.g., by a push, pull request, or scheduled event), GitHub dispatches the job to an available runner that matches the specified labels (e.g., runs-on: ubuntu-latest for GitHub-hosted, or runs-on: self-hosted, linux for a self-hosted runner).

The critical distinction is the runner's lifecycle:

• Ephemeral runners (like all GitHub-hosted runners and properly configured self-hosted ones) are spun up, execute a single job, and are then destroyed. This ensures that any changes or malicious code executed during one job are completely wiped before the next, preventing persistence.
• Non-ephemeral self-hosted runners, conversely, remain active and retain their state between workflow jobs. This means the underlying operating system, installed tools, and any modifications made during one workflow execution persist for subsequent jobs. This persistence is the lynchpin of the "Grand Theft Actions" attack.

Consider a public GitHub repository that accepts contributions via pull requests and uses a non-ephemeral self-hosted runner for its CI/CD pipeline. The typical workflow for a pull request (PR) involves:

1. A contributor forks the repository.
2. They make changes in their fork and create a PR to the original repository.
3. The PR triggers a workflow in the original repository, which includes steps like linting, testing, and building. This workflow executes on the designated runner.

The vulnerability arises when a malicious actor submits a PR that, under the guise of a legitimate change (e.g., fixing a typo, updating documentation), subtly modifies a workflow file (e.g., build.yml). This modification could introduce a new step or alter an existing one to execute arbitrary commands on the runner. For instance, a seemingly harmless run step could be altered to include a curl command to download a payload, establish a reverse shell, or exfiltrate sensitive data.

Crucially, because the runner is non-ephemeral, any malicious changes made during the execution of this PR's workflow will persist on the runner. Subsequent workflow jobs, even legitimate ones from trusted contributors or internal developers, will then execute on this already compromised machine. This grants the attacker a persistent foothold within the organization's network, often with the same privileges as the CI/CD system itself.

The Gato tool, developed by the speakers and their team, was designed to identify these specific misconfigurations at scale. It likely scans GitHub repositories for workflow files (.github/workflows/*.yml) that specify runs-on: self-hosted or similar labels, and then analyzes the repository's settings to determine if external contributors can trigger workflows on these runners, especially when they are non-ephemeral.

The trust boundary is severely blurred in such scenarios. A public repository's CI/CD system, designed to validate external contributions, inadvertently becomes an ingress point for attackers if the underlying infrastructure (the self-hosted runner) is not properly isolated and reset after each use. The compromise of Microsoft's perimeter through Deep Speed, a large-scale machine learning training system, further illustrates the high-value targets accessible via these types of CI/CD attacks, potentially leading to code execution on domain-joined machines with significant internal access.

Demo / Proof of Concept

▶ Watch: Introduction of Gato tool and deeper research (3:20)

While the talk does not include a live, step-by-step demonstration in the provided transcript, the speakers explicitly detail a significant proof of concept that validates their findings. They state, "I demonstrated that vulnerability against GitHub actions runner images repository, which was accepted as a critical vulnerability."

This demonstration involved exploiting the very mechanism described in the technical deep dive:

1. Identification of Target: The GitHub Actions runner images repository was identified as using a non-ephemeral self-hosted runner for its CI/CD processes. Being an official GitHub repository, its compromise would have significant implications, validating the criticality of the vulnerability.
2. Crafting the Exploit: The attacker (Adnan Khan in this case) would have crafted a pull request. The visible change in the PR might have been as innocuous as "fixing a typo" or making a minor documentation update.
3. Workflow Modification: Hidden within the PR, or as part of the seemingly legitimate changes, was a modification to one of the repository's GitHub Actions workflow files (e.g., a .yml file). This modification would introduce a command or script designed to achieve persistence or execute arbitrary code on the self-hosted runner.
4. Execution and Persistence: When the pull request was submitted, it triggered the CI/CD workflow on the non-ephemeral self-hosted runner. The malicious code embedded in the modified workflow file then executed on this persistent machine. This granted the attacker a persistent foothold, allowing for further actions such as data exfiltration, lateral movement, or software supply chain poisoning.
5. Critical Acceptance: The fact that GitHub accepted this as a critical vulnerability underscores the severity of the attack. It confirms that the ability to gain persistent code execution on their own infrastructure via a simple pull request was a significant security flaw.

This proof of concept effectively showcased how a seemingly low-privilege action (a pull request from an external contributor) could escalate to high-impact code execution and persistence, leveraging the insecure configuration of self-hosted runners. It serves as a stark warning about the dangers of mixing public contribution models with stateful, persistent CI/CD infrastructure.

Defensive Implications

▶ Watch: Critical vulnerability: typo fix for runner persistence (4:00)

The "Grand Theft Actions" research provides critical insights for organizations to secure their GitHub Actions deployments and mitigate the risk of supply chain attacks. Defenders should prioritize the following strategies:

1. Mandate Ephemeral Runners: This is the most crucial defensive measure. Organizations must configure all self-hosted runners to be ephemeral. This means that each runner instance should be destroyed and recreated after every single workflow job. This prevents attackers from gaining persistence, as any malicious changes or backdoors introduced during one job will be wiped clean before the next. If ephemeral runners are not feasible, consider robust sandboxing or virtualization solutions that reset the runner environment.
2. Strict Isolation and Least Privilege: Self-hosted runners, by their nature, run within an organization's network. They should be deployed in highly isolated network segments, separate from sensitive production systems or internal development environments. Furthermore, the user accounts and permissions under which the runner agent operates should adhere strictly to the principle of least privilege, having only the necessary access to perform their designated tasks and nothing more. Avoid running runners on domain-joined machines or machines with excessive network access.
3. Review Workflow Trigger Mechanisms: Carefully evaluate which events trigger workflows on self-hosted runners. For public repositories, avoid triggering workflows on pull_request events from forks if those workflows run on self-hosted runners. Instead, consider using pull_request_target with extreme caution and strict permissions, or manual approval steps for external contributions before running them on sensitive infrastructure.
4. Code Review and Workflow Hardening: Implement rigorous code review processes for all changes, especially those affecting .github/workflows/ files. Static Application Security Testing (SAST) tools can help identify suspicious workflow modifications. Additionally, harden workflows by explicitly defining permissions using permissions: blocks and minimizing the scope of tokens (e.g., GITHUB_TOKEN). Avoid using if: ${{ github.event_name == 'pull_request' }} for jobs running on self-hosted runners from untrusted sources.
5. Monitor Runner Activity: Implement robust logging and monitoring for all self-hosted runner activity. Look for unusual process execution, unexpected network connections, unauthorized file modifications, or attempts to install new software. Integrate runner logs with SIEM solutions for real-time alerting on suspicious behavior.
6. Supply Chain Security Best Practices: Beyond runners, adopt broader supply chain security practices. Use pinned actions (specifying a full commit SHA instead of a major version tag) to prevent upstream action maintainer compromises. Scan dependencies for known vulnerabilities. Implement digital signing for artifacts to ensure their integrity.
7. Regular Audits and Penetration Testing: Periodically audit GitHub Actions configurations, repository settings, and self-hosted runner deployments. Conduct penetration tests that specifically target CI/CD pipelines and self-hosted runners to identify and remediate misconfigurations before attackers can exploit them.
8. Understand the Trust Model: Organizations must clearly understand the trust boundaries they are establishing. If a public repository allows anyone to submit a PR that directly executes on an internal, persistent machine, that machine effectively becomes exposed to the internet. This level of trust is rarely acceptable for sensitive infrastructure.

By implementing these defensive measures, organizations can significantly reduce their exposure to the types of supply chain attacks demonstrated in "Grand Theft Actions" and better protect their software development lifecycle.

Key Takeaways

• Non-ephemeral self-hosted GitHub Actions runners are a critical security risk: Their persistence across workflow jobs creates a persistent foothold for attackers if compromised.
• Widespread misconfigurations enable supply chain attacks: Numerous organizations use these runners insecurely on public repositories, making them vulnerable to critical supply chain compromises.
• Simple pull requests can lead to code execution and persistence: Attackers can leverage seemingly innocuous PRs (e.g., typo fixes) to modify workflow files and execute arbitrary code on persistent self-hosted runners.
• The Gato tool helps identify these vulnerabilities: Developed by the speakers, Gato assists in discovering insecure self-hosted runner configurations.
• Prioritize ephemeral runners and strict isolation: Defenders must adopt ephemeral runners and isolate self-hosted runners in secure, least-privilege environments to prevent compromise and persistence.
• GitHub Actions presents a broad attack surface: The powerful automation capabilities require careful security architecture, especially regarding external contributions and the trust boundaries of CI/CD infrastructure.

About the Speaker(s)

Adnan Khan is a security engineer by day, who also actively engages in security research and bug bounty hunting in his spare time. His work on "Grand Theft Actions" demonstrates his expertise in uncovering critical vulnerabilities within modern software development ecosystems.

John Stawinski is a red team security engineer at Prastorian, specializing in offensive security. He is also a dedicated CI/CD security researcher, with "Grand Theft Actions" being a significant contribution to this field. Outside of cybersecurity, John is noted for his collegiate wrestling background and his appreciation for the animated series "Avatar: The Last Airbender."