Translated ['', 'src/pentesting-ci-cd/pentesting-ci-cd-methodology.md']

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}}