Pentesting CI/CD Methodology
VCS
VCS sta per Version Control System, questi sistemi consentono agli sviluppatori di gestire il proprio codice sorgente. Il più comune è git e di solito troverai aziende che lo utilizzano in una delle seguenti piattaforme:
Github
Gitlab
Bitbucket
Gitea
Fornitori di servizi cloud (offrono le proprie piattaforme VCS)
Pipelines
Le pipeline consentono agli sviluppatori di automatizzare l'esecuzione del codice (per scopi di compilazione, test, distribuzione...) dopo determinate azioni: un push, una PR, cron... Sono estremamente utili per automatizzare tutti i passaggi dalla fase di sviluppo alla produzione.
Tuttavia, questi sistemi devono essere eseguiti da qualche parte e di solito con credenziali privilegiate per distribuire il codice.
Metodologia di pentesting VCS
Anche se alcune piattaforme VCS consentono di creare pipeline, in questa sezione analizzeremo solo potenziali attacchi al controllo del codice sorgente.
Le piattaforme che contengono il codice sorgente del tuo progetto contengono informazioni sensibili e le persone devono fare molta attenzione alle autorizzazioni concesse all'interno di questa piattaforma. Questi sono alcuni problemi comuni delle piattaforme VCS che un attaccante potrebbe sfruttare:
Fughe di informazioni: Se il tuo codice contiene fughe di informazioni nei commit e l'attaccante può accedere al repository (perché è pubblico o perché ha accesso), potrebbe scoprire le fughe di informazioni.
Accesso: Se un attaccante può accedere a un account all'interno della piattaforma VCS, potrebbe ottenere maggiore visibilità e autorizzazioni.
Registrazione: Alcune piattaforme consentono solo agli utenti esterni di creare un account.
SSO: Alcune piattaforme non consentono agli utenti di registrarsi, ma consentono a chiunque di accedere con un SSO valido (quindi un attaccante potrebbe utilizzare il suo account github per accedere, ad esempio).
Credenziali: Nome utente+Pwd, token personali, chiavi ssh, token Oauth, cookie... ci sono diversi tipi di token che un utente potrebbe rubare per accedere in qualche modo a un repository.
Webhook: Le piattaforme VCS consentono di generare webhook. Se non sono protetti con segreti non visibili, un attaccante potrebbe sfruttarli.
Se non è presente alcun segreto, l'attaccante potrebbe sfruttare il webhook della piattaforma di terze parti.
Se il segreto è nell'URL, accade lo stesso e l'attaccante ha anche il segreto.
Compromissione del codice: Se un attore malintenzionato ha qualche tipo di accesso in scrittura sui repository, potrebbe cercare di iniettare codice malevolo. Per avere successo, potrebbe dover eludere le protezioni del ramo. Queste azioni possono essere eseguite con diversi obiettivi in mente:
Compromettere il ramo principale per compromettere la produzione.
Compromettere il ramo principale (o altri rami) per compromettere le macchine degli sviluppatori (poiché di solito eseguono test, terraform o altre cose all'interno del repository sulle loro macchine).
Compromettere la pipeline (vedi la sezione successiva)
Metodologia di pentesting delle pipeline
Il modo più comune per definire una pipeline è utilizzare un file di configurazione CI ospitato nel repository su cui viene costruita la pipeline. Questo file descrive l'ordine dei lavori eseguiti, le condizioni che influenzano il flusso e le impostazioni dell'ambiente di compilazione. Questi file hanno tipicamente un nome e un formato coerenti, ad esempio — Jenkinsfile (Jenkins), .gitlab-ci.yml (GitLab), .circleci/config.yml (CircleCI) e i file YAML di GitHub Actions situati in .github/workflows. Quando viene attivato, il lavoro della pipeline preleva il codice dalla fonte selezionata (ad esempio, commit/branch) e esegue i comandi specificati nel file di configurazione CI su quel codice.
Pertanto, l'obiettivo finale dell'attaccante è in qualche modo compromettere quei file di configurazione o i comandi che eseguono.
PPE - Poisoned Pipeline Execution
Il percorso di Poisoned Pipeline Execution (PPE) sfrutta le autorizzazioni in un repository SCM per manipolare una pipeline CI ed eseguire comandi dannosi. Gli utenti con le autorizzazioni necessarie possono modificare i file di configurazione CI o altri file utilizzati dal lavoro della pipeline per includere comandi dannosi. Questo "avvelena" la pipeline CI, portando all'esecuzione di questi comandi dannosi.
Perché un attore malintenzionato possa avere successo nell'eseguire un attacco PPE, deve essere in grado di:
Avere accesso in scrittura alla piattaforma VCS, poiché di solito le pipeline vengono attivate quando viene eseguito un push o una pull request. (Consulta la metodologia di pentesting VCS per un riepilogo dei modi per ottenere l'accesso).
Nota che a volte una PR esterna conta come "accesso in scrittura".
Anche se ha le autorizzazioni di scrittura, deve essere sicuro di poter modificare il file di configurazione CI o altri file su cui si basa la configurazione.
Per questo, potrebbe essere necessario essere in grado di eludere le protezioni del ramo.
Ci sono 3 varianti di PPE:
D-PPE: Un attacco Direct PPE si verifica quando l'attore modifica il file di configurazione CI che verrà eseguito.
I-DDE: Un attacco Indirect PPE si verifica quando l'attore modifica un file su cui il file di configurazione CI che verrà eseguito si basa (come un file make o una configurazione terraform).
Public PPE o 3PE: In alcuni casi, le pipeline possono essere **attivate da
Ulteriori informazioni
Strumenti e CIS Benchmark
Chain-bench è un tool open-source per l'audit della tua catena di approvvigionamento software per la conformità alla sicurezza, basato su un nuovo CIS Software Supply Chain benchmark. L'audit si concentra sull'intero processo SDLC, rivelando i rischi dal momento della scrittura del codice fino al momento del rilascio.
Top 10 rischi di sicurezza CI/CD
Consulta questo interessante articolo sui top 10 rischi CI/CD secondo Cider: https://www.cidersecurity.io/top-10-cicd-security-risks/
Laboratori
Su ogni piattaforma che puoi eseguire localmente troverai come avviarlo in locale in modo da poterlo configurare come desideri per testarlo.
Laboratorio Gitea + Jenkins: https://github.com/cider-security-research/cicd-goat
Strumenti automatici
Checkov: Checkov è uno strumento di analisi statica del codice per l'infrastruttura come codice.
Riferimenti
Last updated
