Cosa può andare storto con CI/CD pipelines?

Integrazione continua e consegna continua (CI/CD) pipelineSono il fondamento di qualsiasi organizzazione software che crea software in modo "moderno". L'automazione offre un grande potere, ma la maggior parte degli sviluppatori non comprende la responsabilità che comporta.

Sviluppatore: Sì, prendiamo CI/CD sicurezza seriamente e avere un forte controllo sui manutentori del codice, revisione commits prima delle fusioni; posti di lavoro e pipelines sono gestiti da personale senior, si prendono cura di non far trapelare segreti nel pipelineS. E lo strumento è stato installato da personale che conosce la cosa. Cosa può andare storto?

Gentile sviluppatore, CI/CD sistemi sono complessi. La sua ampia superficie di attacco ha attirato attori maligni. Meglio essere cauti e mai troppo sicuri di sé.

A volte la configurazione predefinita viene mantenuta e diventa la migliore amica degli hacker. Possono essere presenti difetti critici in CI/CD pipeline fonti, nella configurazione del sistema o attorno al processo e al contesto del pipeline e come viene attivato.

In questo post ci metteremo nei panni dei cattivi attori. Immagina di leggere le riflessioni di M3M3N70 (Memento Mori?) e La rabbia della palude da qualche parte nel dark web, probabilmente in una lingua non occidentale, ma non perdetevi mai che il male è diffuso in tutto il mondo.

Ai bei vecchi tempi era così facile...

M3M3N70: Ai bei vecchi tempi, la nostra attività era così semplice... Gli zero-day erano frutti a portata di mano, le app erano completamente aperte con vulnerabilità facili da sfruttare e potevamo spostarci lateralmente in un attimo.

La rabbia della palude: Fu#@Diavolo! C'è ancora qualcuno con il cervello in testa, ma le cose sono cambiate. I pezzi grossi hanno riflettuto molto su quella merda di AppSec.

M3M3N70: Sì. Ma i nuovi pazzi sono gli sviluppatori. Per noi è stato più facile usare gli strumenti che usano questi ragazzi. La CI, in particolare, è una miniera d'oro! I token di accesso al cloud, SCM credenziali, password del database di produzione, chiavi private SSH, credenziali di altri utenti CI… Passare dalle noiose cose dello sviluppo alla vera e propria sostanza è stato piuttosto banale.

Automazione per la creazione, il test e la distribuzione di software con un CI/CD strumento spesso ha bisogno di passare segreti ai comandi in più passaggi. E spesso vengono divulgati, con conseguenze infami.

PipelineAbbiamo bisogno di segreti che a volte vengono trapelati

M3M3N70: The code monkeys slipped their AWS keys in a pipeline on a GitHub commit, later they removed the thing but not changed git history. For our scripts it was trivial to scan the history, grab the key and wreak havoc.

Forse i bei vecchi tempi erano trovare nella storia di Git un .env file (lo sviluppatore ha dimenticato di aggiungerlo a .gitignore):

AWS_ACCESS_KEY_ID=AKIA...
AWS_SECRET_ACCESS_KEY=wJalrXUtn...
AWS_REGION=us-east-1
APP_FOLDER=...
S3BUCKET=...

che è stato utilizzato in un flusso di lavoro GitHub .github/deploy.yaml che conteneva qualcosa del genere:

jobs:
  build:
    name: Automated build and deployment into AWS
    runs-on: 	ubuntu-22.04
    steps:
      # Load environment from .env file
      - id: dotenv
        uses: falti/dotenv-action@v1.0.2
        
      - name: Configure AWS Credentials
        uses:
        with:
          args: --acl public-read --follow-symlinks --delete 
          aws-access-key-id: $
          aws-secret-access-key: $
          aws-region: $
      
      # ... build steps skipped ...
      
      -  name: Upload compiled code for deployment
         working-directory: $/packaged_app
         run: aws s3 cp my-app.zip s3://$ 
         
      - name: Deploy the app
        run: aws deploy create-deployment ...

M3M3N70: che cavolo! Quelle chiavi aws funzionavano! Abbiamo prima testato un cambiamento innocuo nell'app, poi abbiamo aggiunto il problema perché quei ragazzi sembravano inconsapevoli. Bingo! Che campagna...

Il malintenzionato ha semplicemente utilizzato le chiavi AWS per caricare un'applicazione modificata con malware e quindi ha eseguito il comando di distribuzione con tali credenziali. I segreti trapelati, insieme alle informazioni contenute nel file pipeline. “Che campagna!” probabilmente significa che Memento ha devastato la povera vittima.

Ciò che Memento ci dice qui è che una volta che si è verificata una perdita segreta, come le chiavi di accesso AWS nell'esempio, devi revocare il segreto (ruotare le chiavi sopra) subito. C'è sempre un finestra di esposizione tra le perdite commit e l'invalidazione segreta; riscrivere la storia di Git è difficile (anche lo stato autoritario più duro ha provato a riscrivere la storia, senza alcun risultato) e probabilmente inefficace (i nostri amici potrebbero aver clonato prima del deposito con la fuga di notizie segreta commit). Ruota immediatamente i tasti e prega mentre leggi i registri delle attività per l'account preso di mira durante la finestra di esposizione!

Probabilmente le organizzazioni dovrebbero vietare l'uso di segreti a lungo termine in CI/CD pipelinese sostituirli con credenziali temporali. Nell'esempio precedente con le chiavi AWS nelle operazioni GitHub, è più sicuro utilizzare un file Fornitore OpenID Connect (OIDC). per ottenere credenziali di breve durata necessarie per le azioni.

La rabbia della palude: Sei stato così fortunato! La perdita di script con chiavi hardcoded era una pratica comune ai vecchi tempi, anche su bucket S3 accessibili pubblicamente. Tutto quello che dovevi fare era attraversare gli oggetti nel secchio e fare qualche grepping per trovare cose interessanti.

A volte l'area utilizzata per la distribuzione (un bucket AWS S3 in questo esempio) era aperta alla lettura da parte di estranei, a causa di un difetto di configurazione (che non è stato rilevato). Che cosa La rabbia della palude usato era qualcosa del genere:

aws s3 ls --recursive s3://<bucket_name>/<path>/ | \
awk '{print $4}' | \
xargs -I FNAME sh -c "echo FNAME; \
  aws s3 cp s3://<bucket_name>/FNAME - | \
  grep '<regex_pattern>'"

Il bucket è stato probabilmente creato in un modello di provisioning che poteva essere automaticamente scansionato per individuare eventuali difetti di sicurezza.

La configurazione predefinita dello strumento era un giocattolo per noi

Per fare esempi concreti parliamo di Jenkins, uno degli strumenti CI più popolari.

La rabbia della palude: Ricordi la casella di controllo "Abilita sicurezza" in Jenkins e quante organizzazioni hanno scelto di non attivarla per comodità? E quelli "Chiunque può fare qualsiasi cosa"combinazioni di autorizzazioni predefinite? E quei fastidiosi plugin Jenkins, come il Plug-in GitHub OAuth? Il ragazzo che lo ha configurato ha selezionato sia "Concedi autorizzazioni di lettura a tutti gli utenti autenticati" che "Utilizza autorizzazioni repository GitHub", dandoci accesso a tutti i loro progetti.

(Mi scuso, Jenkins, per averti messo come esempio 😉

Mantieniti esperto (anche dipendente) dai principi di sicurezza. Uno è il Sicuro per impostazione predefinita principio: i controlli dovrebbero essere impostati di default sulle impostazioni più sicure possibili. La sicurezza dovrebbe essere integrata in CI/CD strumenti e pipelineparte da zero, piuttosto che essere un ripensamento. Ma la facilità d’uso e la comodità spesso si scontrano con la sicurezza.

Nel caso Jenkins, l'autenticazione integrata è troppo fragile: non utilizzare mai i meccanismi di autenticazione integrati in Jenkins. Meglio optare per un meccanismo di terze parti (SAML, LDAP, Google…), con plugin Role-based Authorization Strategy (“RBAC”). E sii estremamente cauto con il admin conto.

Prenditi cura di come lavoro e pipeline vengono gestiti i file in Jenkins. Lo stesso con Plug-in di configurazione come codice e i relativi file di configurazione, che si applicano alla configurazione Jenkins.

Passaggio da self-hosted CI/CD sistemi SaaS basati su cloud elimina alcuni potenziali rischi consentendo movimenti laterali all'interno della rete dell'organizzazione, ma ne aggiunge altri, come dover aprire connessioni esterne tra i sistemi interni esistenti e quelli esternalizzati CI/CD strumento.

Le organizzazioni dovrebbero esercitarecise la dovuta cura nell'indurimento del CI/CD sistema, iniziando con le impostazioni più restrittive e aprendosi gradualmente con i permessi minimi richiesti per l' pipeline gradini.

Configurazione della sicurezza in CI/CD strumenti potrebbero essere un'impresa complessa. Molti hanno plugin o estensioni che hanno la maggior parte delle vulnerabilità e devono essere aggiornati.

Gli scanner di configurazione errata della sicurezza per strumenti così complessi o i benchmark possono essere d'aiuto.

Inserimento del codice pipeline comandi per divertimento e profitto

M3M3N70: Hai mai utilizzato Untrusted Code Checkouts, che azioni e script vulnerabili sono vulnerabili all'iniezione di comandi?

Questa sezione mostra che il pipeline stesso potrebbe contenere errori di codifica che consentono a malintenzionati di inserire esecuzioni di codice arbitrarie nel file pipeline senza cambiare il pipeline fonte stessa. Ad esempio utilizzando un PR

Un primo esempio di an sfortunato flusso di lavoro GitHub:

# INSECURE. Provided as an example only.
on:
  pull_request_target #1

jobs:
  build:
    name: Build and test
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
        with:
          ref: $ #2

      - uses: actions/setup-node@v1
      - run: |
          npm install #3
          npm build
      # ... more steps ...

La combinazione di pull_request_target l'attivazione del flusso di lavoro con un checkout esplicito di un PR non attendibile è una pratica pericolosa che può portare alla compromissione del repository. Nell'esempio, la sfortunata combinazione di:

• pull_request_target evento, che per impostazione predefinita ha l'autorizzazione di scrittura sul repository di destinazione e sui segreti del repository di destinazione, anche da fork esterni, e viene eseguito nel contesto del repository di destinazione del PR,
• controlla il codice PR dalla fonte, repository non attendibile,
• attivare qualsiasi script che possa operare su contenuti controllati dalle PR, come nel caso di npm installe
• non utilizzare una condizione per l'attivazione pull_request_target evento da eseguire solo se al PR viene assegnata una sorta di etichetta "questo PR è stato controllato" (gli utenti esterni non possono assegnare etichette al PR).

Un secondo esempio prende input non attendibili (da un problema, un commento o pull request) come sorgente per gli argomenti passati a un pipeline comando tramite espressioni. Questo è il pipeline versione della vulnerabilità di command injection del sistema operativo.

- name: Check title
  run: |
    title="$"
    if [[ ! $title =~ ^.*:\ .*$ ]]; then
      echo "Bad issue title"
      exit 1
    fi

L'operazione di esecuzione genera uno script di shell temporaneo basato sul modello, con $ sostituito, rendendolo vulnerabile all'iniezione di comandi di shell. Un utente malintenzionato con un account GitHub falso potrebbe creare un problema con un titolo a"; bad_code_goes_here;#e bum! 

La rabbia della palude: Oh, quei ragazzi stavano aprendo la porta all'iniezione di comando semplicemente aprendo un problema...

C'erano vulnerabilità di esecuzione del codice nelle azioni GitHub, come gajira-commento, ora risolto. Si prega di leggere "Input non attendibile nei flussi di lavoro GitHub" per maggiori dettagli.

La morale della storia: Non effettuare mai il checkout e creare PR da fonti non attendibili senza prima esaminare il PR. Il termine "Non attendibile" qui, a meno che non sia sottoposto ad un'autenticazione draconiana della provenienza, potrebbe significare qualsiasi account sviluppatore potenzialmente compromesso.

Distribuzione di malware involontaria qui!

Distribuzione continua è il culmine dell'automazione, ma quel culmine potrebbe essere frustrato dalla mancanza di adeguati controlli di approvazione sul pipeline flusso.

I rischi di una distribuzione completamente automatizzata dall'origine commit ai sistemi di produzione includono la possibilità che codice dannoso venga distribuito negli ambienti di produzione senza essere rilevato, nonché la possibilità che errori nel processo di distribuzione causino interruzioni o interruzioni.

Per mitigare questi rischi, si consiglia spesso alle organizzazioni di implementare una “interruzione definitiva” nel processo di distribuzione, che richiede approvazione umana prima che le versioni vengano distribuite negli ambienti finali.

Stanno chiudendo le porte

La rabbia della palude: Quelle gioiose password predefinite in CI/CD gli strumenti vengono cancellati. Accedendo al /var/lib/jenkins/secrets/initialAdminPassword ormai è una strada morta. Molti strumenti ora forniscono 2FA, che Covid ha reso popolare, e anche la scimmia codificatrice più pigra lo sta usando!

M3M3N70: Stiamo combattendo la 2FA, ma non è così facile. È difficile fare spear-phishing a quei ragazzi, come "Scatter Swine" ha fatto con Twilio. Con le chiavi WebAuthn è molto più difficile. Almeno possiamo provarci rubare i cookie per aggirare l'MFA, ma è necessario entrare nella scatola dello sviluppatore.

L'autenticazione a più fattori è un buon passo nella giusta direzione per limitare il rischio di fuga di segreti di autenticazione. La maggior parte dei moderni strumenti DevOps supportano l'MFA. E chiavi di autenticazione sotto WebAuthn / U2F (vedi Progetto FIDO2) sono forse l'opzione migliore per l'MFA in DevOps, se gestite correttamente.

La rabbia della palude: I ragazzi di DevOps si stanno svegliando. Hanno la dannata cosa del “minimo privilegio” nel sangue. E non sono più scimmie in codice. Ora veniamo colti in flagrante dai revisori.

Infatti,  pipelineora sono un po' più robusti rispetto a un paio di anni fa, con azioni e script deboli rimossi e con ulteriori passaggi di test di sicurezza che hanno persino rilevato i nostri dropper nascosti in modalità invisibile commitmessaggi e pacchetti che abbiamo dirottato.

Domanda per il lettore: il processo di creazione del software dai sorgenti e di implementazione in produzione è un'attività rischiosa? Riesci a vedere il tuo DevOps nella fase di vecchi bei tempi per i cattivi?

Raccomandazioni finali

Da dove cominciare CI/CD pipelineS?

La prima raccomandazione è semplice: con attenzione recensioni pipelines (sono critico risorse) per questioni di sicurezza. Le revisioni sono costose ma necessarie e dovrebbero essere eseguite correttamente. I revisori dovrebbero essere consapevoli di cosa guardare. Ogni passaggio deve essere controllato per eventuali difetti.

Forse una combinazione di revisori esperti armati di scanner automatizzati di codici dannosi potrebbe aiutare.

La seconda raccomandazione è quella di formare gli sviluppatori che scrivono pipelines e mantenerli in sicurezza. Cose da considerare:

• Come gestire correttamente l'autenticazione con servizi interni e cloud, evitando il fastidio di gestire credenziali a lungo termine.
• Come limitare pipelines all'insieme esatto di risorse a cui ha bisogno di accedere. Il principio del privilegio minimo torna a splendere.
• Come scrivere i passaggi da effettuare pipelineÈ riproducibile come il blocco della versione ed evita le vulnerabilità dell'iniezione di comandi.
• Come approvare le distribuzioni dal punto di vista della sicurezza (sono altre!): quale sicurezza standards dovrebbero essere abbinati e come aggiungere controlli/gate corrispondenti nel pipelines.

Una terza raccomandazione è quella di configurare il CI/CD sistema con la dovuta attenzione. Autenticazione forte, nessuna password predefinita o impostazioni non sicure, privilegi minimi... Prenditi cura delle vulnerabilità nei plugin e nelle estensioni installate. Questo potrebbe essere il focus dei post successivi, continuate a seguirci.

La quarta raccomandazione è quella di sfruttare il CI/CD pipelines per l'automazione della sicurezza. Analisi del codice sorgente (SAST), analisi della composizione della sorgente (SCA), la scansione delle perdite di segreti, gli strumenti anti-malware, gli scanner di sicurezza dei container o i rilevatori di runtime automatici (DAST e malware) possono essere eseguiti di routine su pipeline. E la tua organizzazione può far rispettare standards sulla copertura della scansione di sicurezza in CI/CD.

Ricorda che questi strumenti non rimuovono ancora la revisione degli esperti dall'equazione, altrimenti potresti avere un falso senso di sicurezza.

Se sei esperto dei top ten di OWASP, un bel progetto recente è il OWASP Top 10 CI/CD Rischio per la sicurezza.

Nota di non responsabilità

(1) Gli esempi in questo post utilizzano GitHub come SCM, AWS come fornitore cloud e GitHub Actions o Jenkins come CI/CD strumento. Non sono più deboli/sicuri delle loro alternative. Nessuna cattiva intenzione di stampa! Questi strumenti sono potenti e devono essere usati in modo appropriato.

(2) M3M3N70 and La rabbia della palude sono personaggi di fantasia. Qualsiasi somiglianza con persone o gruppi, viventi o morti, è semplicemente casuale... o no?

Per saperne di più

• Haymore, A. et al. “10 storie vere su come abbiamo compromesso CI/CD pipelineS". Gruppo NCC, gennaio 2022.
• configure-aws-credentials Azione GitHub and Configurazione di OpenID Connect in Amazon Web Services per dettagli su come eseguire i comandi AWS per la distribuzione nei flussi di lavoro GitHub.
• Lobacevski J. "Mantenere sicure le azioni e i flussi di lavoro GitHub Parte 1: prevenire le richieste PWN". GitLab Security Lab, dicembre 2020.
• Lobacevski J. "Mantenere sicure le azioni e i flussi di lavoro GitHub Parte 2: input non attendibili". GitLab Security Lab, gennaio 2021.
• OWASP. “I primi 10 dell'OWASP CI/CD Rischi per la sicurezza””. Luglio 2022.
• Saltzer J. & Schroeder M. “La protezione delle informazioni nei sistemi informatici”. Aprile 1975. I principi di sicurezza si sono evoluti con la tecnologia, ma 47 anni dopo la maggior parte delle idee di S&S rimangono in vigore.
• NCSC del Regno Unito. “Proteggi la creazione e la distribuzione pipeline".. Centro nazionale per la sicurezza informatica del Regno Unito, febbraio 2019.