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! ...
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”. ...