Adnan Khan's Blog

I’ve been quite busy with hacking in my spare time, and most of my time has been dedicated to hacking, and most of my writing time has been allocated to reports.

Now that I’m allowed to talk about some of my most impressive hacks I plan to post detailed writeups here so that the security community can be on the lookout for these kinds of attacks. The most significant vulnerability I reported was one that provided a path to backdoor the GitHub Actions runner images used for hosted builds on GitHub.com. After a long wait, GitHub resolved the report at the Critical severity and paid out a $20,000 bounty.

The summary of the vulnerability included in my report on July 22nd, 2023 is as follows:

The actions/runner-images repository is vulnerable to an attack triggered by a malicious pull request from a repository contributor. This is because it uses non-restricted and non-ephemeral self-hosted runners to build the images that are used throughout GitHub Actions. It is trivial to become a repository contributor by submitting a small PR, such as a typo fix. I used a brand new test account and fixed a single character typo to become a contributor.

A contributor can modify or create a workflow file in their fork that runs on the pull_request trigger and set the job to run on either the azure-builds or macos-vmware build runners. This workflow can fork off a process that persists beyond that single job. This allows an attacker to obtain persistence on the build runners that build ALL of GitHub’s hosted build runner VMs. ¹

When a build job is picked up, an attacker can steal secrets from that build or introduce backdoors to build images. The secrets provide lateral movement paths to GitHub/Azure’s build engineering organization for the azure-builds agent. For the VMWare agent that is used to build GitHub’s macOS runner images, the secrets and network persistence could allow an attacker to pivot to the GitHub’s macOS private cloud.

From an impact perspective this is simultaneously:

• Arbitrary code/command execution on a server in our production network
• Access to sensitive production user data or access to internal production systems
• Accessing another user’s data in the GitHub Actions service

If a sophisticated attacker with the resources to avoid initial detection took advantage of this vulnerability, the impact would be systemic and impact every GitHub client that uses GitHub hosted runners. It could lead to extremely sensitive information disclosure from companies around the world as well as supply chain attacks impacting thousands of companies’ software builds.

Disclosure Timeline

• July 22nd, 2023 – Reported to GitHub
• July 26th, 2023 – Immediate Fixes Made to Repository
• July 26th, 2023 – Report Triaged
• November 14th, 2023 – Resolved as Critical Misconfiguration vulnerability and bounty paid out.

Stay tuned for the full details – this was quite a hack, and I will say that this vulnerability class impacted far more than just GitHub. After reporting this, I teamed up with my colleague and friend John Stawinski to set out and report vulnerabilities like this across all of GitHub, we focused on organizations with bug bounty programs and safe harbor provisions.

Our efforts led to a long list of reports and overtly demonstrated vulnerabilities – some that we can disclose and others that we cannot.

1. Only GitHub knows if these builds were copied off into the production pool or if there was another internal build process. Even so, there was a path to merge code into the main branch with this vulnerability, and my full writeup will present the path an attacker could have taken. ↩︎