GH Actions - Cache Poisoning

Impara l'hacking di AWS da zero a eroe con htARTE (HackTricks AWS Red Team Expert)!

Altri modi per supportare HackTricks:

• Se vuoi vedere la tua azienda pubblicizzata su HackTricks o scaricare HackTricks in PDF Controlla i PACCHETTI DI ABBONAMENTO!

• Ottieni il merchandising ufficiale di PEASS & HackTricks

• Scopri The PEASS Family, la nostra collezione di NFT esclusivi

• Unisciti al 💬 gruppo Discord o al gruppo Telegram o seguici su Twitter 🐦 @hacktricks_live.

• Condividi i tuoi trucchi di hacking inviando PR ai repository di HackTricks e HackTricks Cloud su GitHub.

Per ulteriori dettagli consulta il post originale https://scribesecurity.com/blog/github-cache-poisoning/

Cache Poisoning

L'azione Git action/cache introduce un meccanismo di caching nel processo di Continuous Integration (CI), che comprende due fasi critiche:

1. Esecuzione dell'azione: Questa fase prevede la ricerca e il recupero dei dati memorizzati nella cache durante l'esecuzione della CI. La ricerca utilizza una chiave di cache univoca, che produce due risultati:

• Cache-hit: I dati richiesti vengono trovati nella cache e vengono quindi recuperati per un utilizzo immediato.

• Cache-miss: Non vengono trovati dati corrispondenti nella cache, il che comporta un nuovo download dei file e delle directory necessari, simile a una richiesta di primo accesso.

2. Azione post workflow: Questa fase è dedicata alla memorizzazione nella cache dei dati dopo il workflow della CI. In particolare, se si verifica un cache-miss durante l'azione di esecuzione, lo stato corrente delle directory specificate viene memorizzato nella cache utilizzando la chiave fornita. Questo processo è automatizzato e non richiede una chiamata esplicita.

Misure di sicurezza: Isolamento della cache e restrizioni di accesso

Per mantenere la sicurezza e garantire l'isolamento della cache, vengono applicate restrizioni di accesso che creano una separazione logica tra i diversi branch. Ad esempio, una cache creata per il branch Feature-A (con base nel branch principale) non sarà accessibile a una pull request per il branch Feature-B (anch'essa basata nel branch principale).

L'azione di cache segue un ordine di ricerca specifico:

• Prima cerca cache hits nello stesso branch dell'esecuzione del workflow.

• Se non riesce, estende la ricerca al branch padre e agli altri branch upstream.

È importante sottolineare che l'accesso alla cache è limitato al branch, estendendosi a tutti i workflow ed esecuzioni di un determinato branch. Inoltre, GitHub impone una politica di sola lettura per le voci di cache una volta create, vietando eventuali modifiche.

Implicazioni reali: Da un attacco di workflow a bassi permessi a uno di workflow ad alto permesso

Uno scenario illustrativo di CI mostra come un attaccante potrebbe sfruttare il cache poisoning per elevare i privilegi da un workflow a bassi permessi a uno ad alto permesso:

• Si assume che il workflow Unit-test, responsabile dell'esecuzione dei test unitari e degli strumenti di copertura del codice, utilizzi uno strumento compromesso o vulnerabile. Questo workflow utilizza l'azione Git action/cache, rendendo la cache accessibile a qualsiasi workflow.

• Il workflow Release, incaricato di compilare e rilasciare l'artefatto dell'applicazione, ottimizza le sue operazioni memorizzando nella cache le dipendenze di Golang.

In questo scenario, il workflow dei test unitari introduce una voce di cache malevola sostituendo una libreria di logging Golang legittima (`go