9.4 KiB
Metodologia Pentesting CI/CD
{{#include ../banners/hacktricks-training.md}}
VCS
VCS sta per Sistema di Controllo delle Versioni, questo sistema permette agli sviluppatori di gestire il loro codice sorgente. Quello più comune è git e solitamente troverai le aziende che lo utilizzano in una delle seguenti piattaforme:
- Github
- Gitlab
- Bitbucket
- Gitea
- Gitblit
- Cloud providers (they offer their own VCS platforms)
CI/CD Pipelines
Le CI/CD pipelines permettono agli sviluppatori di automatizzare l'esecuzione del codice per vari scopi, inclusi build, test e deploy delle applicazioni. Questi workflow automatizzati vengono attivati da azioni specifiche, come push di codice, pull request o task schedulati. Sono utili per snellire il processo dallo sviluppo alla produzione.
Tuttavia, questi sistemi devono essere eseguiti da qualche parte e di solito con credenziali privilegiate per deployare codice o accedere a informazioni sensibili.
VCS Pentesting Methodology
Note
Even if some VCS platforms allow to create pipelines for this section we are going to analyze only potential attacks to the control of the source code.
Le piattaforme che contengono il codice sorgente del tuo progetto contengono informazioni sensibili e bisogna fare molta attenzione con i permessi concessi all'interno di queste piattaforme. Questi sono alcuni problemi comuni nelle piattaforme VCS che un attacker potrebbe sfruttare:
- Leaks: Se il tuo codice contiene leak nei commit e l'attacker può accedere al repo (perché è pubblico o perché ha accesso), potrebbe scoprire i leak.
- Access: Se un attacker riesce ad accedere a un account sulla piattaforma VCS potrebbe ottenere maggiore visibilità e permessi.
- Register: Alcune piattaforme permettono semplicemente a utenti esterni di creare un account.
- SSO: Alcune piattaforme non permettono la registrazione, ma consentono a chiunque di accedere con una SSO valida (quindi un attacker potrebbe usare ad esempio il suo account github per entrare).
- Credentials: Username+Pwd, personal tokens, ssh keys, Oauth tokens, cookies... ci sono diversi tipi di token che un utente potrebbe rubare per accedere in qualche modo a un repo.
- Webhooks: Le piattaforme VCS permettono di generare webhooks. Se non sono protetti con secret non visibili un attacker potrebbe abusarne.
- Se non è presente nessun secret, l'attacker potrebbe abusare del webhook della piattaforma terza
- Se il secret è nella URL, succede lo stesso e l'attacker avrà anche il secret
- Code compromise: Se un attore malevolo ha in qualche modo accesso in scrittura ai repo, potrebbe provare a iniettare codice malevolo. Per avere successo potrebbe dover bypassare le branch protections. Queste azioni possono essere eseguite con diversi obiettivi:
- Compromettere il main branch per compromettere la produzione.
- Compromettere il main (o altri branch) per compromettere le macchine degli sviluppatori (dato che di solito eseguono test, terraform o altre cose dal repo sulle loro macchine).
- Compromettere la pipeline (vedi sezione successiva)
Pipelines Pentesting Methodology
Il modo più comune per definire una pipeline è usando un CI configuration file ospitato nel repository che la pipeline costruisce. Questo file descrive l'ordine dei job eseguiti, le condizioni che influenzano il flusso e le impostazioni dell'ambiente di build.
Questi file tipicamente hanno un nome e un formato coerenti, per esempio — Jenkinsfile (Jenkins), .gitlab-ci.yml (GitLab), .circleci/config.yml (CircleCI), e i file YAML di GitHub Actions sotto .github/workflows. Quando viene triggerata, la pipeline job pulls the code dalla sorgente selezionata (es. commit / branch), e esegue i comandi specificati nel CI configuration file su quel codice.
Quindi l'obiettivo finale dell'attacker è in qualche modo compromettere quei file di configurazione o i comandi che essi eseguono.
PPE - Poisoned Pipeline Execution
La Poisoned Pipeline Execution (PPE) sfrutta le autorizzazioni in un repository SCM per manipolare una pipeline CI ed eseguire comandi dannosi. Utenti con i permessi necessari possono modificare i CI configuration files o altri file usati dal job della pipeline per includere comandi malevoli. Questo "avvelena" la pipeline CI, portando all'esecuzione di tali comandi malevoli.
Perché un attore malevolo abbia successo in un attacco PPE deve essere in grado di:
- Avere write access alla piattaforma VCS, dato che di solito le pipeline sono triggerate quando viene eseguito un push o una pull request. (Vedi la VCS pentesting methodology per un riepilogo dei modi per ottenere accesso).
- Nota che a volte una PR esterna conta come "write access".
- Anche se ha permessi di scrittura, deve essere sicuro di poter modificare il CI config file o altri file su cui il config si basa.
- Per questo, potrebbe dover essere in grado di bypassare le branch protections.
Ci sono 3 varianti di PPE:
- D-PPE: Un attacco Direct PPE si verifica quando l'attore modifica il CI config file che verrà eseguito.
- I-DDE: Un attacco Indirect PPE avviene quando l'attore modifica un file su cui il CI config che verrà eseguito fa affidamento (come un make file o una config terraform).
- Public PPE or 3PE: In alcuni casi le pipeline possono essere triggerate da utenti che non hanno write access nel repo (e che potrebbero neanche far parte dell'organizzazione) perché possono inviare una PR.
- 3PE Command Injection: Di solito, le pipeline CI/CD impostano environment variables con informazioni sulla PR. Se quel valore può essere controllato da un attacker (come il titolo della PR) ed è usato in un punto pericoloso (come l'esecuzione di comandi sh), un attacker potrebbe iniettare comandi lì dentro.
Exploitation Benefits
Conoscendo le 3 varianti per avvelenare una pipeline, vediamo cosa un attacker potrebbe ottenere dopo una sfruttamento riuscito:
- Secrets: Come menzionato prima, le pipeline richiedono privilegi per i loro job (recuperare il codice, buildarlo, deployarlo...) e questi privilegi sono di solito concessi come secrets. Questi secrets sono spesso accessibili tramite env variables o file dentro il sistema. Perciò un attacker cercherà sempre di esfiltrare quanti più secrets possibile.
- A seconda della piattaforma pipeline l'attacker potrebbe dover specificare i secrets nella config. Ciò significa che se l'attacker non può modificare la CI configuration pipeline (I-PPE per esempio), potrebbe esfiltrare solo i secrets che quella pipeline possiede.
- Computation: Il codice viene eseguito da qualche parte; a seconda di dove viene eseguito un attacker potrebbe pivotare ulteriormente.
- On-Premises: Se le pipeline sono eseguite on-premises, un attacker potrebbe finire in una rete interna con accesso a più risorse.
- Cloud: L'attacker potrebbe accedere ad altre macchine in cloud ma anche potrebbe esfiltrare IAM roles/service accounts tokens da esso per ottenere ulteriore accesso nel cloud.
- Platforms machine: A volte i job vengono eseguiti sulle macchine della piattaforma pipeline, che solitamente sono in cloud con nessun accesso aggiuntivo.
- Select it: A volte la pipelines platform avrà configurato diverse macchine e se puoi modificare il CI configuration file puoi indicare dove vuoi eseguire il codice malevolo. In questa situazione, un attacker probabilmente eseguirà una reverse shell su ogni macchina possibile per provare a sfruttarla ulteriormente.
- Compromise production: Se sei nella pipeline e la versione finale viene buildata e deployata da essa, potresti compromettere il codice che finirà in esecuzione in produzione.
More relevant info
Tools & CIS Benchmark
- Chain-bench è uno strumento open-source per auditare la tua software supply chain stack per la compliance di sicurezza basata su un nuovo CIS Software Supply Chain benchmark. L'audit si concentra sull'intero processo SDLC, dove può rivelare rischi dal code time fino al deploy time.
Top 10 CI/CD Security Risk
Dai un'occhiata a questo articolo interessante sui top 10 rischi CI/CD secondo Cider: https://www.cidersecurity.io/top-10-cicd-security-risks/
Labs
- Per ogni piattaforma che puoi eseguire localmente troverai come lanciarla localmente così da poterla configurare come vuoi per testarla
- Gitea + Jenkins lab: https://github.com/cider-security-research/cicd-goat
Automatic Tools
- Checkov: Checkov è uno strumento di static code analysis per infrastructure-as-code.
References
{{#include ../banners/hacktricks-training.md}}