Integrazione continua e distribuzione continua (CI/CD) pipelineSvolgono un ruolo fondamentale nel facilitare lo sviluppo semplificato del software. Eppure, come questi pipelinediventano sempre più cruciali, l'imperativo di proteggerli dalle vulnerabilità diventa più pronunciato. Questa indagine approfondita si concentra sull'affrontare un rischio importante identificato nell'OWASP Top-10 CI/CD Rischi per la sicurezza: avvelenato Pipeline Esecuzione (DPI).
Cos'è avvelenato Pipeline Esecuzione (DPI)
Secondo OWASP Top-10 CI/CD Rischi per la sicurezza, “Avvelenato Pipeline (DPI) il rischio si riferisce alla capacità di un utente malintenzionato con accesso ai sistemi di controllo del codice sorgente – e senza accesso all'ambiente di creazione – per manipolare il processo di compilazione inserendo codice/comandi dannosi nella build pipeline configurazione, essenzialmente "avvelenare" il pipeline ed eseguire codice dannoso come parte del processo di creazione"
In poche parole, Avvelenato Pipeline L'esecuzione (DPI) viene prodotta quando l'attaccante può modificare il file pipeline logica.
Ci sono due varianti:
- DPI diretti (D-PPE): In uno scenario D-PPE, l'aggressore modifica il file di configurazione CI in un repository a cui hanno accesso, inviando la modifica direttamente a un ramo remoto non protetto sul repository o inviando un PR con la modifica da un ramo o un fork. Dal momento che il CI pipeline l'esecuzione è definita dai comandi nel file di configurazione CI modificato, i comandi dannosi dell'aggressore vengono infine eseguiti nel nodo di build una volta completata la build pipeline E 'attivato.
- DPI indiretti (I-PPE): In alcuni casi, la possibilità di D-PPE non è disponibile per un avversario con accesso a un SCM repository (ad esempio se il pipeline è configurato per estrarre il file di configurazione CI da un ramo separato e protetto nello stesso repository). In uno scenario del genere, invece di avvelenare il pipeline stesso, un utente malintenzionato inserisce codice dannoso nei file a cui fa riferimento il file pipeline (ad esempio: script a cui si fa riferimento all'interno del file pipeline file di configurazione)
In entrambi i casi, GitHub eseguirà il file modificato pipeline senza necessità di revisione o approvazione preventiva.
Individuazione precoce dei DPI
Come possiamo rilevare questo tipo di vulnerabilità?
Vediamo questo esempio pipeline :
name: PR CI
on:
pull_request:
branches: [ main ]
env:
MY_SECRET: ${{ secrets.MY_SECRET }}
jobs:
pr_build_test_and_merge:
runs-on: ubuntu-latest
steps:
# checkout PR code
- name: Checkout repository
uses: actions/checkout@v4
# Simulation of a compilation
- name: Building ...
run: |
echo $MY_SECRET
mkdir ./bin
touch ./bin/mybin.exe
# Simulation of running tests
- name: Running tests ...
id : run_tests
run: |
echo Running tests..
chmod +x runtests.sh
./runtests.sh "${{ github.event.pull_request.user.login }}" "${{ github.workflow }}"
echo Tests executed. E il contenuto di uno script di shell fittizio (runtests.sh):
#!/usr/bin/bash
echo "Executing Tests script [from user $1 at $2]" >> runtests.out
exit 0Migliori pipeline è piuttosto semplice: il suo scopo è quello di fornire al revisore alcuni suggerimenti preliminari per la Pull Request (PR) processo di accettazione:
- Verrà attivato pull_request (cioè ogni volta che viene creata una PR)
- Controlla il codice PR (ovvero il codice contribuito)
- Farà la costruzione
- Eseguirà test sul codice contribuito (ad esempio eseguendo uno script di shell)
I passaggi n. 3 (effettuare la compilazione) e n. 4 (eseguire il test) falliranno se il codice non viene compilato o non supera i test. Quindi, questi passaggi costituiscono una condizione necessaria, ma non sufficiente, per accettare la PR. In caso di esito positivo, l'amministratore del repository procederà a rivedere il codice fornito e, in base a ciò, accetterà/rifiuterà/commenterà il PR.
Scanner Xygeni
Xygeni fornisce una CLI (il "Scanner Xygeni”) che può essere incorporato in a pipeline o eseguirlo da riga di comando. Lo scanner Xygeni elaborerà il file pipelineserve per verificare le vulnerabilità e, se viene fornito un PAT GitHub, si connetterà a GitHub per scoprire le vulnerabilità a livello di organizzazione/repo.
Inventario Xygeni
Quando eseguiamo Xygeni Scanner su questo repository, scopre un insieme utile di risorse (the Inventario Xygeni). L'inventario sarà popolato con molti tipi diversi di CI/CD attività, Quali:
- Migliori SCM Sistema dove è archiviato il repository
- Migliori SCM plugin installato/utilizzato
- Migliori Repository del codice stessa
- Migliori SCM Organizzazione a cui appartiene il repository
- Migliori CI/CD Pipelinese Lavoro
- Migliori CI/CD Sistema eseguendo il pipelines
- IaC Risorse definito nel repository
- Esterno dipendenze
- eccetera..
Nel nostro esempio, possiamo filtrare l'inventario in base a un tipo di risorsa specifico (SCM- e asset correlati al CICD), quindi possiamo vedere che:
- SCM il sistema è GitHub Cloud
- Il repository è archiviato in GitHub Cloud e appartiene a una specifica organizzazione GitHub
- Ci sono due pipelineè alimentato da GitHub (CI/CD sistema)
- Ogni pipeline contiene un passaggio specifico
Selezionando quanto sopra pipeline possiamo vedere alcune vulnerabilità:
- At pipeline livello, è vulnerabile ad entrambi Direct and DPI indiretti.
Possiamo vedere i dettagli di quelli avvelenati Pipeline Vulnerabilità di esecuzione
Xygeni rileva che lo è vulnerabili ai D-PPE perché viene attivato su un Pull Request evento e non ci sono controlli di sicurezza aggiuntivi, quindi qualsiasi utente del repository può modificare l' pipeline e tali modifiche verranno eseguite senza alcuna revisione o approvazione.
Nello stesso senso, anche Xygeni rileva che lo è vulnerabili all’I-PPE a causa della chiamata allo script di shell da parte di pipeline: qualsiasi utente del repository può modificare lo script della shell e tali modifiche verranno eseguite senza alcuna revisione o approvazione.
Vuoi saperne di più?
Sfruttare i DPI
Per sfruttare i DPI consideriamo uno scenario in cui ci siano due tipi di utenti repository:
- An utente interno (uno sviluppatore interno che lavora su quel repository), con autorizzazioni di scrittura sul repository
- An utente esterno (uno sviluppatore in outsourcing che lavora su quel repository ma con permessi di lettura sul repository), cioè non è autorizzato a diramare il repository e costretto a lavorare su un fork.
Immaginiamo che entrambi siano aggressori dannosi (o impersonati da un attore dannoso). Il repository contiene qualche segreto ed entrambi lo vogliono per rubare il segreto del repository e inviarlo a un server controllato dagli hacker. Per farlo, approfitteranno degli Avvelenati Pipeline Vulnerabilità di esecuzione del pipeline.
In entrambi i casi (utente esterno e interno), aprono un Pull Request con le stesse modifiche:
- Migliori pipeline e lo script della shell vengono modificati a leggi il segreto dall'ambiente e inviarlo a un server controllato dagli hacker
Le modifiche potrebbero essere le seguenti:
Entrambi gli utenti creeranno un Pull Request con le modifiche. Al momento della creazione del PR, GitHub eseguirà entrambe le modifiche (senza necessità di revisione o approvazione preventiva), risultando quanto segue:
Lo stesso per gli utenti di scrittura e lettura, in entrambi i casi vengono eseguiti D-PPE e I-PPE, con la differenza che l'utente letto non è in grado di accedere ai segreti. (!!!!)
Questo motivo è perché, nel caso di PR proveniente da un fork, GitHub non consente l'accesso ai segreti del repo. Sebbene l'utente letto non possa leggere i segreti, può comunque eseguire qualsiasi altro programma. Un tipico esempio di attacco è la creazione di PR che scaricano un crypto miner, quindi il runner GitHub eseguirà il crypto miner quando esegue un crypto miner avvelenato pipeline.
Questo non è un ambiente sicuro, ovviamente!! Cosa potrebbe fare l'amministratore del repository per evitarlo?
Dopo aver cercato su Google, l'amministratore del repository decide di modificare il file pipeline essere attivato su a pull_request_target evento. Perché? Perché pipelineGli s attivati su pull_request_target non consentono l'esecuzione pipeline modifiche, cioè nonostante qualsiasi modifica dell'utente l'"originale" pipeline sarà eseguito.
Seguendo il nostro esempio, l'attacco sarà lo stesso di prima. Cosa accadrà dopo questo? pipeline modifica?
Come previsto, Il D-PPE non viene eseguito ma, poiché l'I-PPE esiste ancora, l'utente letto è ora in grado di accedere al segreto del repository!!!
Qual è il motivo per cui l'utente letto ora ha accesso ai segreti? sebbene il pipeline non può essere modificato, è comunque possibile modificare lo script della shell. Quando pipeline viene attivato su pull_request_target, verrà eseguito in modalità privilegiata so sarà anche lo script della shell, facendo sì che lo script della shell abbia accesso ai segreti del repository!!
Misure preventive
GitHub fornisce alcune misure per proteggersi da PR dannosi.
Norme sulla tutela delle filiali
Con GitHub puoi definire le regole di protezione dei rami sui rami selezionati.
Per i tuoi rami protetti, puoi specificare una policy that richiede a pull request prima di fondersi (oltre a condizioni aggiuntive come il numero richiesto di approvazioni, revisioni da parte dei proprietari del codice, ecc.)
Un paio di condizioni che meritano una considerazione speciale sono:
- "Consenti agli attori specificati di ignorare i requisiti pull requests".
- "Non consentire di ignorare le impostazioni di cui sopra".
Mentre la maggior parte delle condizioni aggiungono rigore alla politica, queste la allentano e ciò potrebbe comportare una porta aperta ad attività dannose, ad esempio, nel caso in cui le credenziali vengano rubate da attori “privilegiati”.
Limita le autorizzazioni GITHUB_TOKEN (privilegio minimo)
Limitare i permessi del token GitHub solo a quelli richiesti; in questo modo, anche nel caso in cui gli aggressori riescano a comprometterti pipeline, non potranno fare molto.
Evitare l'interpolazione delle stringhe utilizzando pipeline variabili d'ambiente
Ogni volta che usi alcune variabili di input nel tuo pipeline, tieni presente che dovrebbero essere considerati per impostazione predefinita come dati "non attendibili" (il loro contenuto è controllato dall'utente finale). Vedere Azioni non attendibili e flussi di lavoro sicuri and Impara le azioni di Github.
Dovresti sempre utilizzare le variabili di ambiente per inserire variabili di input all'interno degli script invece di utilizzare l'interpolazione delle stringhe.
Esecuzioni del flusso di lavoro e requisiti di approvazione
Per la percezione repository, GitHub consente di specificare come lavorare con PR “esterni”..
Le impostazioni dell'organizzazione GitHub ("Organizzazione >> Impostazioni >> Azioni >> Generale") consentono di specificare come gestire le PR esterne:
Di default, GitHub richiederà l'approvazione PR per i collaboratori alle prime armi, rendendo più complicati gli attacchi di richiesta malevoli. Anche così, l'attaccante potrebbe guadagnarsi la fiducia dei responsabili del progetto, ad esempio contribuendo con qualche innocente pull request prima del vero attacco.
In questo senso, il La terza opzione (Richiedere l'approvazione per tutti i collaboratori esterni) aggiunge un livello di controllo più elevato.
Per tour privati repository, GitHub fornisce anche un controllo utile sia a livello di organizzazione che di repository.
"Esegui flussi di lavoro da Pull Requests" (non selezionato per impostazione predefinita) consente agli utenti di eseguire flussi di lavoro da fork PR (utilizzando un GITHUB_TOKEN con autorizzazioni di sola lettura e senza accesso ai segreti). Selezionando questa opzione insieme all’ultima (“Richiedere l'approvazione per i flussi di lavoro dei fork PR”), è possibile raggiungere una politica simile ai repository privati (come mostrato sopra).
Come abbiamo visto nell'exploit PPE da parte di un utente letto, consentendo l'esecuzione di flussi di lavoro da fork pull requests non è sicuro!!
Le restanti opzioni (“Invia token di scrittura ai flussi di lavoro dal fork pull requests" e "Invia segreti e variabili ai flussi di lavoro da per pull requests") diminuire il livello di sicurezza applicato ai PR della forcella.
È possibile definire questa policy di fork a livello di organizzazione o a livello di repository. Se la policy è disabilitata a livello di organizzazione, non può essere abilitata a livello di repository. Tuttavia, se la policy è abilitata a livello di organizzazione, può essere disabilitata a livello di repository.
Ricapitolare
Ci auguriamo che tu abbia visto le implicazioni di averne alcuni pipeline vulnerabile all'Avvelenato Pipeline Esecuzione. E' troppo facile commit un vulnerabile pipeline, ed è difficile scriverne uno sicuro.
Pertanto è molto utile utilizzare lo scanner Xygeni per essere consapevoli di tali vulnerabilità.
Non puoi risolvere un problema se non sei consapevole della sua esistenza!!
Ma… c’è ancora una questione in sospeso… Come evitare l'I-PPE?
Questo sarà l’argomento del nostro prossimo post 🙂 … Avvelenato indiretto Pipeline Esecuzione (I-PPE) !!
