I've done some research on this and written some PoC code that I'd like to add. A couple of key points:
Token used to write to cache is valid for 6 hours is not invalidated after workflow finishes. (working as intended per GitHub)
Cache keys/version are set client side, no server side validation at all (working as intended per GitHub).
Cache file itself is not validated when there is a cache hit (it is just a zstd compressed archive), so a poisoned cache entry can overwrite scripts, package.json, etc, even if the intended cache value is a specific directory.
Feel free to add or I can create a PR (will end up re-writing most of the existing information), unfortunately the Scribe Security article was fairly light on how to actually poison caches. Fortunately, I like sharing knowledge to help people hack all the things :)
Hi @AdnaneKhan !
Sry, I don't read very frequently the issues. Would you mind sending a PR with these additions? I take a look to those much frequently
The current GitHub Actions cache poisoning section (https://cloud.hacktricks.xyz/pentesting-ci-cd/github-security/abusing-github-actions/gh-actions-cache-poisoning) is a bit light on details.
I've done some research on this and written some PoC code that I'd like to add. A couple of key points:
package.json
, etc, even if the intended cache value is a specific directory.POC Code to write to cache and steal cache tokens: https://github.com/AdnaneKhan/ActionsCacheBlasting
Feel free to add or I can create a PR (will end up re-writing most of the existing information), unfortunately the Scribe Security article was fairly light on how to actually poison caches. Fortunately, I like sharing knowledge to help people hack all the things :)