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 cloud (offrono le proprie piattaforme VCS)
Pipelines
Le pipeline consentono agli sviluppatori di automatizzare l'esecuzione del codice (per scopi di costruzione, test, distribuzione...) dopo che si verificano determinate azioni: Un push, una PR, cron... Sono estremamente utili per automatizzare tutti i passaggi dallo sviluppo alla produzione.
Tuttavia, questi sistemi devono essere eseguiti da qualche parte e di solito con credenziali privilegiate per distribuire codice.
VCS Pentesting Methodology
Anche se alcune piattaforme VCS consentono di creare pipeline, in questa sezione analizzeremo solo i potenziali attacchi al controllo del codice sorgente.
Le piattaforme che contengono il codice sorgente del tuo progetto contengono informazioni sensibili e le persone devono prestare molta attenzione ai permessi concessi all'interno di questa piattaforma. Questi sono alcuni problemi comuni tra le piattaforme VCS che un attaccante potrebbe sfruttare:
Leaks: Se il tuo codice contiene leak nei commit e l'attaccante può accedere al repo (perché è pubblico o perché ha accesso), potrebbe scoprire i leak.
Accesso: Se un attaccante può accedere a un account all'interno della piattaforma VCS, potrebbe guadagnare maggiore visibilità e permessi.
Registrazione: Alcune piattaforme consentiranno solo agli utenti esterni di creare un account.
SSO: Alcune piattaforme non consentiranno agli utenti di registrarsi, ma permetteranno a chiunque di accedere con un SSO valido (quindi un attaccante potrebbe usare il proprio account github per entrare, 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 repo.
Webhook: Le piattaforme VCS consentono di generare webhook. Se non sono protetti con segreti non visibili, un attaccante potrebbe abusarne.
Se non c'è alcun segreto in atto, l'attaccante potrebbe abusare del webhook della piattaforma di terze parti.
Se il segreto è nell'URL, succede la stessa cosa e l'attaccante ha anche il segreto.
Compromissione del codice: Se un attore malintenzionato ha qualche tipo di accesso in scrittura sui repo, potrebbe cercare di iniettare codice malevolo. Per avere successo, potrebbe dover bypassare le protezioni dei branch. Queste azioni possono essere eseguite con diversi obiettivi in mente:
Compromettere il branch principale per compromettere la produzione.
Compromettere il principale (o altri branch) per compromettere le macchine degli sviluppatori (poiché di solito eseguono test, terraform o altre cose all'interno del repo sulle loro macchine).
Compromettere la pipeline (controlla la sezione successiva).
Pipelines Pentesting Methodology
Il modo più comune per definire una pipeline è utilizzare un file di configurazione CI ospitato nel repository che la pipeline costruisce. Questo file descrive l'ordine dei lavori eseguiti, le condizioni che influenzano il flusso e le impostazioni dell'ambiente di costruzione. Questi file di solito hanno un nome e un formato coerenti, ad esempio — Jenkinsfile (Jenkins), .gitlab-ci.yml (GitLab), .circleci/config.yml (CircleCI) e i file YAML delle GitHub Actions situati sotto .github/workflows. Quando attivata, la job della pipeline estrae il codice dalla sorgente selezionata (ad es. commit / branch) e esegue i comandi specificati nel file di configurazione CI contro 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 Poisoned Pipeline Execution (PPE) sfrutta i permessi in un repository SCM per manipolare una pipeline CI ed eseguire comandi dannosi. Gli utenti con i permessi necessari possono modificare i file di configurazione CI o altri file utilizzati dal job della pipeline per includere comandi malevoli. Questo "avvelena" la pipeline CI, portando all'esecuzione di questi comandi malevoli.
Affinché un attore malintenzionato abbia 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. (Controlla la metodologia di pentesting VCS per un riepilogo dei modi per ottenere accesso).
Nota che a volte una PR esterna conta come "accesso in scrittura".
Anche se ha permessi 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 dover essere in grado di bypassare le protezioni dei branch.
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 utenti che non hanno accesso in scrittura nel repo (e che potrebbero nemmeno far parte dell'organizzazione) perché possono inviare una PR.
3PE Command Injection: Di solito, le pipeline CI/CD imposteranno variabili di ambiente con informazioni sulla PR. Se quel valore può essere controllato da un attaccante (come il titolo della PR) ed è utilizzato in un luogo pericoloso (come l'esecuzione di comandi sh), un attaccante potrebbe iniettare comandi lì.
Exploitation Benefits
Conoscendo le 3 varianti per avvelenare una pipeline, vediamo cosa un attaccante potrebbe ottenere dopo un'esploitazione riuscita:
Segreti: Come menzionato in precedenza, le pipeline richiedono privilegi per i loro lavori (recuperare il codice, costruirlo, distribuirlo...) e questi privilegi sono solitamente concessi in segreti. Questi segreti sono di solito accessibili tramite variabili di ambiente o file all'interno del sistema. Pertanto, un attaccante cercherà sempre di esfiltrare quanti più segreti possibile.
A seconda della piattaforma della pipeline, l'attaccante potrebbe dover specificare i segreti nella configurazione. Questo significa che se l'attaccante non può modificare la pipeline di configurazione CI (I-PPE per esempio), potrebbe solo esfiltrare i segreti che quella pipeline ha.
Computazione: Il codice viene eseguito da qualche parte, a seconda di dove viene eseguito, un attaccante potrebbe essere in grado di pivotare ulteriormente.
On-Premises: Se le pipeline vengono eseguite in sede, un attaccante potrebbe finire in una rete interna con accesso a più risorse.
Cloud: L'attaccante potrebbe accedere a altre macchine nel cloud ma potrebbe anche esfiltrare i token IAM roles/service accounts da esso per ottenere ulteriore accesso all'interno del cloud.
Macchine della piattaforma: A volte i lavori verranno eseguiti all'interno delle macchine della piattaforma delle pipeline, che di solito si trovano all'interno di un cloud con nessun altro accesso.
Selezionalo: A volte la piattaforma delle pipeline avrà configurato diverse macchine e se puoi modificare il file di configurazione CI puoi indicare dove vuoi eseguire il codice malevolo. In questa situazione, un attaccante probabilmente eseguirà una reverse shell su ogni possibile macchina per cercare di sfruttarla ulteriormente.
Compromettere la produzione: Se sei all'interno della pipeline e la versione finale viene costruita e distribuita da essa, potresti compromettere il codice che andrà a finire in produzione.
More relevant info
Tools & CIS Benchmark
Chain-bench è uno strumento open-source per l'audit della tua catena di fornitura software per la conformità alla sicurezza basato su un nuovo CIS Software Supply Chain benchmark. L'audit si concentra sull'intero processo SDLC, dove può rivelare rischi dal tempo di codice fino al tempo di distribuzione.
Top 10 CI/CD Security Risk
Controlla questo interessante articolo sui 10 principali rischi CI/CD secondo Cider: https://www.cidersecurity.io/top-10-cicd-security-risks/
Labs
Su ogni piattaforma che puoi eseguire localmente troverai come lanciarla localmente in modo da poterla configurare come desideri per testarla.
Gitea + Jenkins lab: https://github.com/cider-security-research/cicd-goat
Automatic Tools
Checkov: Checkov è uno strumento di analisi statica del codice per l'infrastruttura come codice.
References
Last updated
