From 56478bd905a40f15cce568745745dc395620389e Mon Sep 17 00:00:00 2001 From: Translator Date: Mon, 27 Apr 2026 23:29:13 +0000 Subject: [PATCH] Translated ['', 'src/pentesting-ci-cd/pentesting-ci-cd-methodology.md'] --- .../pentesting-ci-cd-methodology.md | 105 +++++++++++------- 1 file changed, 63 insertions(+), 42 deletions(-) diff --git a/src/pentesting-ci-cd/pentesting-ci-cd-methodology.md b/src/pentesting-ci-cd/pentesting-ci-cd-methodology.md index f8c32e8e1..4f4bfc2de 100644 --- a/src/pentesting-ci-cd/pentesting-ci-cd-methodology.md +++ b/src/pentesting-ci-cd/pentesting-ci-cd-methodology.md @@ -6,51 +6,51 @@ ## VCS -VCS sta per **sistema di controllo versione**, questo sistema permette agli sviluppatori di **gestire il codice sorgente**. Il più comune è **git** e di solito troverai le aziende che lo usano in una delle seguenti **piattaforme**: +VCS sta per **Version Control System**, questi sistemi permettono agli sviluppatori di **gestire il proprio codice sorgente**. Il più comune è **git** e di solito troverai aziende che lo usano in una delle seguenti **platforms**: - Github - Gitlab - Bitbucket - Gitea - Gitblit -- Cloud providers (offrono le proprie piattaforme VCS) +- Cloud providers (offrono le proprie platforms VCS) ## CI/CD Pipelines -CI/CD pipelines permettono agli sviluppatori di **automatizzare l'esecuzione del codice** per diversi scopi, inclusi build, test e deployment delle applicazioni. Questi workflow automatizzati sono **attivati da azioni specifiche**, come push di codice, pull request o task schedulati. Sono utili per snellire il processo dallo sviluppo alla produzione. +Le pipeline CI/CD consentono agli sviluppatori di **automatizzare l'esecuzione del codice** per vari scopi, tra cui building, testing e deploy delle applicazioni. Questi workflow automatizzati vengono **attivati da azioni specifiche**, come push di codice, pull request o task pianificati. Sono utili per semplificare 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] -> Anche se alcune piattaforme VCS permettono di creare pipeline per questa sezione analizzeremo solo potenziali attacchi al controllo del codice sorgente. +> Anche se alcune platforms VCS permettono di creare pipeline, per questa sezione analizzeremo solo i possibili attacchi al controllo del codice sorgente. -Le piattaforme che contengono il codice sorgente del tuo progetto contengono informazioni sensibili e le persone devono essere molto attente ai permessi concessi all'interno di questa piattaforma. Questi sono alcuni problemi comuni attraverso le piattaforme VCS che un attacker potrebbe abusare: +Le platforms che contengono il codice sorgente del tuo progetto contengono informazioni sensibili e bisogna fare molta attenzione ai permessi concessi all'interno di questa platform. Questi sono alcuni problemi comuni tra le platforms VCS che un attacker potrebbe abusare: -- **Leaks**: If your code contains leaks in the commits and the attacker can access the repo (because it's public or because he has access), he could discover the leaks. -- **Access**: Se un attacker può **accedere a un account all'interno della 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 un SSO valido (quindi un attacker potrebbe usare il suo account github per entrare, per esempio). -- **Credentials**: Username+Pwd, personal tokens, ssh keys, Oauth tokens, cookies... esistono 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 alcun secret, l'attacker potrebbe abusare del webhook della piattaforma di terze parti -- Se il secret è nell'URL, accade la stessa cosa e l'attacker ottiene anche il secret -- **Code compromise:** Se un actor maligno ha qualche tipo di accesso in scrittura sui repo, potrebbe provare a **iniettare codice malevolo**. Per avere successo potrebbe aver bisogno di **bypassare le protezioni dei branch**. Queste azioni possono essere compiute con diversi obiettivi: +- **Leaks**: se il tuo codice contiene leaks nei commit e l'attacker può accedere al repo (perché è pubblico o perché ha accesso), potrebbe scoprire i leaks. +- **Access**: se un attacker può **accedere a un account dentro la platform VCS** potrebbe ottenere **più visibilità e permessi**. +- **Register**: alcune platforms consentiranno semplicemente agli utenti esterni di creare un account. +- **SSO**: alcune platforms non consentiranno agli utenti di registrarsi, ma permetteranno a chiunque di accedere con un SSO valido (quindi un attacker potrebbe usare il suo account github per entrare, per esempio). +- **Credentials**: Username+Pwd, personal tokens, ssh keys, Oauth tokens, cookies... ci sono diversi tipi di token che un user potrebbe rubare per accedere in qualche modo a un repo. +- **Webhooks**: le platforms VCS consentono di generare webhooks. Se non sono **protetti** con secret non visibili, un **attacker potrebbe abusarne**. +- Se non è presente alcun secret, l'attacker potrebbe abusare del webhook della platform di terze parti +- Se il secret è nell'URL, succede la stessa cosa e l'attacker ha anche il secret +- **Code compromise:** se un malicious actor ha qualche tipo di accesso in **write** ai repos, potrebbe provare a **iniettare codice malevolo**. Per avere successo potrebbe dover **bypass branch protections**. Queste azioni possono essere eseguite con diversi obiettivi in mid: - Compromettere il main branch per **compromettere la production**. -- Compromettere il main (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** (vedi sezione successiva) +- Compromettere il main (o altri branches) per **compromettere le macchine degli sviluppatori** (dato che di solito eseguono test, terraform o altre cose dentro il repo sulle loro macchine). +- **Compromettere la pipeline** (controlla la sezione successiva) ## Pipelines Pentesting Methodology -Il modo più comune per definire una pipeline è tramite un **file di configurazione CI ospitato nel repository** che la pipeline builda. 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 consistente, per esempio — Jenkinsfile (Jenkins), .gitlab-ci.yml (GitLab), .circleci/config.yml (CircleCI), e i file YAML di GitHub Actions situati sotto .github/workflows. Quando viene triggerata, la job della pipeline **pulls the code** dalla source selezionata (es. commit / branch), e **esegue i comandi specificati nel CI configuration file** su quel codice. +Il modo più comune per definire una pipeline è usare un **CI configuration file hosted in the repository** che la pipeline builda. Questo file descrive l'ordine dei job eseguiti, le condizioni che influenzano il flusso e le impostazioni dell'ambiente di build.\ +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 di GitHub Actions situati sotto .github/workflows. Quando viene attivato, il job della pipeline **scarica il codice** dalla source selezionata (ad 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**. +Pertanto, l'obiettivo finale dell'attacker è in qualche modo **compromettere quei file di configurazione** o i **comandi che eseguono**. > [!TIP] -> Alcuni hosted builders permettono ai contributor di scegliere il contesto di build Docker e il percorso del Dockerfile. Se il contesto è controllato dall'attacker, puoi impostarlo al di fuori del repo (es., "..") per ingerire file dell'host durante la build ed esfiltrare secret. Vedi: +> Alcuni hosted builders consentono ai contributors di scegliere il Docker build context e il path del Dockerfile. Se il context è controllato dall'attacker, puoi impostarlo fuori dal repo (ad es. "..") per ingerire file dell'host durante la build ed exfiltrare secrets. Vedi: > >{{#ref}} >docker-build-context-abuse.md @@ -58,48 +58,67 @@ Quindi l'obiettivo finale dell'attacker è in qualche modo **compromettere quei ### PPE - Poisoned Pipeline Execution -La Poisoned Pipeline Execution (PPE) sfrutta i permessi in un repository SCM per manipolare una CI pipeline ed eseguire comandi dannosi. Utenti con i permessi necessari possono modificare i file di configurazione CI o altri file usati dalla job di pipeline per includere comandi malevoli. Questo "avvelena" la CI pipeline, portando all'esecuzione di tali comandi malevoli. +Il percorso Poisoned Pipeline Execution (PPE) sfrutta i permessi in un repository SCM per manipolare una CI pipeline ed eseguire comandi dannosi. Gli utenti con i permessi necessari possono modificare i CI configuration file o altri file usati dal job della pipeline per includere comandi malevoli. Questo "avvelena" la CI pipeline, portando all'esecuzione di questi comandi malevoli. -Perché un actor maligno abbia successo eseguendo un attacco PPE deve essere in grado di: +Per avere successo in un attacco PPE, un malicious actor deve poter: -- Avere **accesso in scrittura alla piattaforma VCS**, poiché di solito le pipeline sono triggerate quando viene effettuato 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 "accesso in scrittura"**. -- 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 aver bisogno di essere in grado di **bypassare le protezioni dei branch**. +- Avere **write access alla platform VCS**, poiché di solito le pipeline vengono attivate quando viene eseguito un push o una pull request. (Controlla la VCS pentesting methodology per un riepilogo dei modi per ottenere accesso). +- Nota che a volte una **external PR conta come "write access"**. +- Anche con i permessi di write, 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 **bypass branch protections**. Ci sono 3 varianti di PPE: -- **D-PPE**: Un attacco **Direct PPE** avviene quando l'actor **modifica il CI config** file che verrà eseguito. -- **I-DDE**: Un attacco **Indirect PPE** avviene quando l'actor **modifica** un **file** su cui il CI config che verrà eseguito **si appoggia** (come un makefile o una configurazione terraform). -- **Public PPE or 3PE**: In alcuni casi le pipeline possono essere **triggerate da utenti che non hanno accesso in scrittura nel repo** (e che potrebbero non far parte nemmeno dell'organizzazione) perché possono inviare una PR. -- **3PE Command Injection**: Di solito, CI/CD pipelines impostano **variabili d'ambiente** con **informazioni sulla PR**. Se quel valore può essere controllato da un attacker (come il titolo della PR) e viene **usato** in un **punto pericoloso** (come eseguire comandi sh), un attacker può **iniettare comandi lì dentro**. +- **D-PPE**: un attacco **Direct PPE** si verifica quando l'attacker **modifica il file CI config** che verrà eseguito. +- **I-DDE**: un attacco **Indirect PPE** si verifica quando l'attacker **modifica** un **file** su cui il CI config file che verrà eseguito **si basa** (come un make file o una terraform config). +- **Public PPE or 3PE**: in alcuni casi le pipeline possono essere **attivate da utenti che non hanno write access nel repo** (e che potrebbero non far nemmeno parte dell'org) perché possono inviare una PR. +- **3PE Command Injection**: di solito le pipeline CI/CD **imposteranno environment variables** con **informazioni sulla PR**. Se quel valore può essere controllato da un attacker (come il titolo della PR) ed è **usato** in un **posto pericoloso** (come eseguire **sh commands**), un attacker potrebbe **iniettare comandi** lì. ### Exploitation Benefits -Conoscendo le 3 varianti per avvelenare una pipeline, vediamo cosa un attacker potrebbe ottenere dopo una sfruttamento riuscito: +Sapendo le 3 varianti per avvelenare una pipeline, vediamo cosa potrebbe ottenere un attacker dopo un'exploit riuscita: -- **Secrets**: Come menzionato in precedenza, le pipeline richiedono **privilegi** per i loro job (recuperare il codice, buildarlo, deployarlo...) e questi privilegi sono di solito **conservati in secrets**. Questi secret sono generalmente accessibili tramite **env variables o file all'interno del sistema**. Pertanto un attacker cercherà sempre di esfiltrare quanti più secret possibile. -- A seconda della piattaforma di pipeline l'attacker **potrebbe dover specificare i secret nella config**. Questo significa che se l'attacker non può modificare la pipeline CI configuration (**I-PPE** per esempio), potrebbe **esfiltrare solo i secret che quella pipeline possiede**. -- **Computation**: Il codice viene eseguito da qualche parte; a seconda di dove viene eseguito un attacker potrebbe essere in grado di pivotare ulteriormente. -- **On-Premises**: Se le pipeline sono eseguite on-premises, un attacker potrebbe trovarsi in una **rete interna con accesso a ulteriori risorse**. -- **Cloud**: L'attacker potrebbe accedere **ad altre macchine nel cloud** ma anche **esfiltrare** token di ruoli IAM/service accounts per ottenere **ulteriore accesso all'interno del cloud**. -- **Platforms machine**: A volte i job vengono eseguiti nelle **macchine della piattaforma pipelines**, che di solito sono in un cloud senza accessi aggiuntivi. -- **Select it:** A volte la **piattaforma pipeline ha configurato diverse macchine** e se puoi **modificare il CI configuration file** puoi **indicare dove vuoi far girare il codice malevolo**. In questa situazione, un attacker probabilmente eseguirà una reverse shell su ogni macchina possibile per tentare un ulteriore sfruttamento. -- **Compromise production**: Se sei all'interno della pipeline e la versione finale è buildata e deployata da essa, potresti **compromettere il codice che finirà in esecuzione in produzione**. +- **Secrets**: come detto in precedenza, le pipeline richiedono **privileges** per i loro job (recuperare il codice, buildarlo, deployarlo...) e questi privileges di solito sono **concessi in secrets**. Questi secrets sono di solito accessibili tramite **env variables o file all'interno del sistema**. Pertanto un attacker cercherà sempre di exfiltrare quanti più secrets possibile. +- A seconda della platform della pipeline, l'attacker **potrebbe dover specificare i secrets nel config**. Questo significa che se l'attacker non può modificare il CI configuration pipeline (**I-PPE** per esempio), potrebbe **solo exfiltrare i secrets che quella pipeline ha**. +- **Computation**: il codice viene eseguito da qualche parte, a seconda di dove viene eseguito un attacker potrebbe riuscire a pivotare ulteriormente. +- **On-Premises**: se le pipeline vengono eseguite on premises, un attacker potrebbe finire in una **internal network con accesso a più risorse**. +- **Cloud**: l'attacker potrebbe accedere ad **altre macchine nel cloud** ma potrebbe anche **exfiltrare** IAM roles/service accounts **tokens** da esse per ottenere **ulteriore accesso dentro il cloud**. +- **Platforms machine**: a volte i job verranno eseguiti all'interno delle **platform machines delle pipelines**, che di solito si trovano dentro un cloud con **nessun altro accesso**. +- **Select it:** a volte la **platform delle pipelines avrà configurato più 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 possibile macchina per provare a sfruttarla ulteriormente. +- **Compromise production**: se sei dentro la pipeline e la versione finale viene buildata e deployata da lì, potresti **compromettere il codice che finirà in esecuzione in production**. + +### Dependency & Registry Supply-Chain Abuse + +Compromettere una CI/CD pipeline o rubare credenziali da essa può permettere a un attacker di passare da **pipeline execution** a **ecosystem-wide code execution** backdoorando dipendenze o tooling di release: + +- **Install-time code execution via package hooks**: pubblica una versione del package che aggiunge hook `preinstall`, `postinstall`, `prepare` o simili, così il payload viene eseguito automaticamente sulle workstation degli sviluppatori e sui CI runners durante l'installazione delle dipendenze. +- **Secondary execution paths**: anche se i target installano con `--ignore-scripts`, un package malevolo può comunque registrare un **common CLI name** nel campo `bin`, così il wrapper controllato dall'attacker viene symlinked dentro `PATH` ed esegue più tardi quando il command viene usato. +- **Runtime bootstrapping**: un piccolo installer può scaricare un secondo runtime o toolchain durante l'installazione (per esempio Bun o un interpreter impacchettato) e poi lanciare il main payload con esso, evitando requisiti di dipendenze locali. +- **Credential harvesting from build environments**: una volta che il codice gira dentro CI, controlla environment variables, `~/.npmrc`, `~/.git-credentials`, SSH keys, cloud CLI configs e tooling locale come `gh auth token`. Su GitHub Actions, cerca anche secrets e artifacts specifici del runner. +- **Workflow injection with stolen GitHub tokens**: un token con permessi **`repo` + `workflow`** è sufficiente per creare un branch, commettere un file malevolo dentro `.github/workflows/`, attivarlo, raccogliere artifacts/logs prodotti e poi eliminare il branch temporaneo/il workflow run per ridurre le tracce. +- **Wormable registry propagation**: i token npm rubati dovrebbero essere validati per i permessi di **publish** e per capire se bypassano 2FA. Se lo fanno, enumera i packages scrivibili, scarica i loro tarball, inserisci un loader come `setup.mjs`, imposta `preinstall` per eseguirlo, incrementa la patch version e ripubblica. Questo trasforma una compromissione CI in auto-esecuzione a valle in altri ambienti. + +#### Practical checks during an assessment + +- Revisiona l'automazione di release per hook del package-manager aggiunti a `package.json`, voci `bin` inattese o bump di versione che modificano solo l'artifact di release. +- Controlla se CI memorizza credenziali di registry a lunga durata in file in plaintext come `~/.npmrc` invece di usare OIDC a breve durata o trusted publishing. +- Verifica se i token GitHub disponibili in CI possono scrivere workflow files o creare branch/tag. +- Se si sospetta un package compromesso, ispeziona il tarball pubblicato e non solo il Git repository, perché il loader/runtime malevolo potrebbe esistere solo nell'artifact pubblicato. +- Cerca esecuzioni inattese del package-manager dentro CI come `npm install` invece di `npm ci`, download/esecuzione inattesi di Bun o nuovi workflow artifacts generati da branch transienti. ## More relevant info ### Tools & CIS Benchmark -- [**Chain-bench**](https://github.com/aquasecurity/chain-bench) è uno strumento open-source per auditare la tua software supply chain stack per compliance di sicurezza basata su un nuovo [**CIS Software Supply Chain benchmark**](https://github.com/aquasecurity/chain-bench/blob/main/docs/CIS-Software-Supply-Chain-Security-Guide-v1.0.pdf). L'audit si concentra sull'intero processo SDLC, dove può rivelare rischi dal codice fino al deploy. +- [**Chain-bench**](https://github.com/aquasecurity/chain-bench) è uno strumento open-source per auditare il tuo software supply chain stack per la conformità di sicurezza basata su un nuovo [**CIS Software Supply Chain benchmark**](https://github.com/aquasecurity/chain-bench/blob/main/docs/CIS-Software-Supply-Chain-Security-Guide-v1.0.pdf). L'audit si concentra sull'intero processo SDLC, dove può rivelare rischi dal code time al deploy time. ### Top 10 CI/CD Security Risk -Consulta questo interessante articolo sui top 10 rischi CI/CD secondo Cider: [**https://www.cidersecurity.io/top-10-cicd-security-risks/**](https://www.cidersecurity.io/top-10-cicd-security-risks/) +Controlla questo articolo interessante sui top 10 CI/CD risks secondo Cider: [**https://www.cidersecurity.io/top-10-cicd-security-risks/**](https://www.cidersecurity.io/top-10-cicd-security-risks/) ### Labs -- Su ogni piattaforma che puoi eseguire localmente troverai come avviarla localmente così puoi configurarla come vuoi per testarla +- Su ogni platform che puoi eseguire localmente troverai come avviarla localmente così puoi configurarla come vuoi per testarla - Gitea + Jenkins lab: [https://github.com/cider-security-research/cicd-goat](https://github.com/cider-security-research/cicd-goat) ### Automatic Tools @@ -109,6 +128,8 @@ Consulta questo interessante articolo sui top 10 rischi CI/CD secondo Cider: [** ## References - [https://www.cidersecurity.io/blog/research/ppe-poisoned-pipeline-execution/?utm_source=github\&utm_medium=github_page\&utm_campaign=ci%2fcd%20goat_060422](https://www.cidersecurity.io/blog/research/ppe-poisoned-pipeline-execution/?utm_source=github&utm_medium=github_page&utm_campaign=ci%2fcd%20goat_060422) +- [The npm Threat Landscape: Attack Surface and Mitigations](https://unit42.paloaltonetworks.com/monitoring-npm-supply-chain-attacks/) +- [Checkmarx Security Update: April 22, 2026](https://checkmarx.com/blog/checkmarx-security-update-april-22/?p=108469) {{#include ../banners/hacktricks-training.md}}