Posts

Overview I identified a High risk vulnerability impacting GitHub’s dependabot-core repository that could have allowed an attacker to conduct a supply chain attack on GitHub users by backdooring the Dependabot containers. The cause of the vulnerability was a race condition in a workflow that maintainers would trigger to perform integration testing on approved pull requests prior to merging. Background Continuous Integration / Continuous Delivery (CI/CD) pipelines for Open-Source (and even closed source!) projects have a concept of an approval gate. This is a step that an authorized actor must perform before pipeline execution can continue. This pattern is common for running integration tests that require access to secrets or creating preview environments on code originating from fork pull requests. ...

Introduction On February 21st, hackers associated with the North Korea based Lazarus group stole almost 1.4 Billion dollars in Ethereum from Bybit, the third largest cryptocurrency exchange in the world. Lazarus pulled off this hack through a sophisticated operation that tricked legitimate signers into approving a malicious smart contract interaction. Bybit’s signers saw a legitimate transaction, but they ended up signing a malicious one. The night of the attack, Safe quickly claimed that they were not hacked. ...

In this post, I demonstrate Cacheract, which is an open source proof-of-concept for ‘Cache Native Malware’ that exploits GitHub Actions cache misconfigurations.

Summary Shortly after Hugo Vincent of Synactiv published his blog post on the Dependabot actor confusion technique, I set out to identify interesting repositories vulnerable to the this attack technique. One repository I quickly found was that of the Release Drafter reusable GitHub Action. Anyone with a GitHub account could have used a pull request with the Dependabot actor confusion technique to obtain a GITHUB_TOKEN that could modify the tags associated with the action. This means that ALL downstream users of this action using it via tags (which are mutable!) instead of SHA would be vulnerable to a supply chain attack. ...

Overview In just over a week from now, I’ll be speaking at Black Hat 2024 and DEF CON 32 along with my co-presenter John Stawinski. Our talks will focus on attacks against self-hosted runners on public repositories, illustrated by real world case studies involving companies you’ve definitely heard of. Our research campaign leading to these talks exceeded every expectation that I had when we started it. One of the bug bounties was for a whopping $100,000! ...

Enter the Nightmare What if there was a supply chain attack that could provide an attacker with direct access to core infrastructure within thousands of companies worldwide. What if that attack required no social engineering and could be executed within a few hours? Between April 2nd, 2024 and May 21st, 2024 that attack would have been possible, and the only prerequisite would be signing up for an account on GitHub. ...

Introduction UPDATE 01/23/25 - Some of the techniques in this blog post no longer apply, however the core technique is still valid: Cache poisoning allows workflow lateral movement. The big change is that you can no longer write to the cache after the workflow job finishes, these means you have to get creative by performing the entire poisoning operation in-build. Thankfully, we now have Cacheract. I’ve personally been working on a tool to detect Pwn Request vulnerabilities at scale, and one of the “false positive” cases was when a workflow checked out and ran user-controlled code, but only had a GITHUB_TOKEN with read access and no secrets. This makes it just as secure as a workflow on pull_request, right? I turned out to be wrong. There is a way to escalate by smashing caches, turning GitHub’s cache eviction features into a weapon, and replacing cache entries with new, poisoned entries. The best part? It’s all working as intended. In this blog I will introduce GitHub Actions privilege escalation and lateral movement technique I’m going to call “Actions Cache Blasting”. ...

Introduction Recently, I reported a “Pwn Request” vulnerability in Google’s Flank repository. Flank is described as a “Massively parallel Android and iOS test runner for Firebase Test Lab” and is an official Google open source project. The vulnerability allowed anyone with a GitHub Account to steal Google service account credentials which were used as a repository secret along with obtaining access to a GITHUB_TOKEN with write access. Google’s VRP rewarded me with a $7,500 bug bounty for this report as a Software Supply Chain compromise under the “Standard OSS Project” tier. ...

Overview John Stawinski and I have been conducting research and submitting bug bounty reports focusing on a specific type of poisoned pipeline execution attack that I like to refer as “Self-Hosted Runner Takeover”. It manifests when a public repository has an attached non-ephemeral self-hosted runner without requiring approval for workflows on the pull_request trigger. One of the organizations we discovered the vulnerability in was Astar network. According to Wikipedia, Astar Network is a blockchain that aims to become Polkadot’s “smart contract hub” and serves as a parachain for Polkadot. ...

Introduction I’ve been doing a lot of scanning and reporting of GitHub Actions injection and pwn request vulnerabilities throughout GitHub. Most of my scanning and testing focused on workflows - that is yaml files in the .github/workfows directory - and my regexes didn’t look at files in other directories, such action.yml, which is used as the entry-point for any repository that functions as a reusable GitHub Action. At Defcon Asi Greenholts and his team from Palo Alto Networks outlined the risk of a compromise of a reusable GitHub Action and how an attacker can exploit an action for an initial foothold, and then poison specific tags in order to target other actions and repositories. That talk had me think about looking for issues in reusable actions themselves. ...