Translated ['src/pentesting-ci-cd/argocd-security.md', 'src/pentesting-c

src/pentesting-ci-cd/argocd-security.md

@@ -0,0 +1,219 @@
+# Argo CD Security
+
+{{#include ../banners/hacktricks-training.md}}
+
+## Informazioni di base
+
+[Argo CD](https://argo-cd.readthedocs.io/) è una piattaforma di continuous delivery GitOps per Kubernetes. Monitora i repository Git, genera i manifest Kubernetes con strumenti come Helm, Kustomize, Jsonnet o config management plugins, e riconcilia lo stato live del cluster con lo stato desiderato memorizzato in Git.
+
+Dal punto di vista di un attacker, considera Argo CD come un **motore di deployment con credenziali Kubernetes**. Un compromesso utile di Argo CD può portare a:
+
+- Accesso a repository Git privati e credenziali del repository.
+- Accesso ai secret del cluster Kubernetes usati da Argo CD.
+- Esecuzione di codice nella generazione dei manifest in `argocd-repo-server`.
+- Deployment non autorizzato di oggetti Kubernetes tramite repository Git trusted, applicazioni Argo CD o manipolazione della cache.
+
+## Architettura e componenti interessanti
+
+Common Kubernetes objects and services:
+```bash
+kubectl get pods,svc,endpoints,ingress -A | grep -iE 'argocd|argo-cd'
+kubectl get applications,appprojects,applicationsets -A 2>/dev/null
+kubectl get secrets,configmaps -n argocd 2>/dev/null
+kubectl get networkpolicy -n argocd 2>/dev/null
+```
+Servizi interessanti:
+
+- **`argocd-server`**: API pubblica, web UI, CLI API, autenticazione e autorizzazione.
+- **`argocd-application-controller`**: confronta lo stato desiderato e quello effettivo, poi applica le risorse a Kubernetes.
+- **`argocd-repo-server`**: clona repository, mette in cache i dati Git e esegue Helm/Kustomize/Jsonnet/plugins per generare i manifest. La porta gRPC predefinita è **8081**.
+- **`argocd-redis`**: cache per dati di application, manifest e riferimenti Git. La porta Redis predefinita è **6379**.
+- **`argocd-applicationset-controller`**: genera oggetti Argo CD `Application` da generatori come Git, SCM, cluster e pull request.
+
+Da un pod compromesso o da un segmento di rete interno, verifica la raggiungibilità interna:
+```bash
+nc -vz <argocd-server> 443
+nc -vz <argocd-repo-server> 8081
+nc -vz <argocd-redis> 6379
+```
+## Attacchi Public API / UI
+
+Se hai credenziali Argo CD o un'istanza esposta, inizia dalla normale superficie API:
+```bash
+argocd login <argocd-server>
+argocd account get-user-info
+argocd account list
+argocd proj list
+argocd app list
+argocd repo list
+argocd cluster list
+argocd admin settings rbac can <subject> <action> <resource> <object>
+```
+Percorsi di attacco utili:
+
+- **Application write access**: modifica `source.repoURL`, `source.path`, valori Helm, opzioni Kustomize, impostazioni plugin o opzioni di sync così Argo CD distribuisce manifest controllati dall'attaccante.
+- **Project misconfiguration**: gli oggetti `AppProject` possono consentire `sourceRepos` ampi, `destinations` ampi, `clusterResourceWhitelist` non sicura o restrizioni deboli sui namespace.
+- **Repository credential abuse**: i segreti del repository, le credenziali GitHub App, le chiavi SSH e i token possono consentire il push su repo fidati o l'aggiunta di dipendenze malevole.
+- **Cluster credential abuse**: i segreti del cluster possono contenere bearer token o configurazione exec-provider usata da Argo CD per distribuire nei cluster di destinazione.
+- **Local admin / project tokens**: i token Argo CD a lunga durata possono essere riusati tramite l'API finché non vengono revocati o scadono.
+
+Enumera la configurazione da Kubernetes quando hai accesso di lettura al cluster:
+```bash
+kubectl get applications.argoproj.io -A -o yaml
+kubectl get appprojects.argoproj.io -A -o yaml
+kubectl get applicationsets.argoproj.io -A -o yaml
+kubectl get secrets -n argocd -o yaml | grep -nE 'repoURL|sshPrivateKey|password|bearerToken|githubApp|tlsClientCertData|tlsClientCertKey'
+kubectl get cm -n argocd argocd-cm argocd-rbac-cm argocd-cmd-params-cm -o yaml
+```
+## Abuso di Trusted Git Repository
+
+Se puoi fare push su un repository trusted da Argo CD, di solito puoi influenzare ciò che viene deployato. L'impatto dipende dai confini di `AppProject` e dai permessi del service account usato dall'application controller.
+
+Posizioni comuni dei payload:
+
+- Raw Kubernetes YAML sotto un path dell'application.
+- Template Helm chart e `values.yaml`.
+- Kustomize overlays, remote bases e generator.
+- Input di Jsonnet o config management plugin.
+- File generator di ApplicationSet che creano o aggiornano oggetti `Application`.
+
+Controlla se l'app usa automated sync, pruning, self-heal, sync windows o approvazioni manuali:
+```bash
+kubectl get applications.argoproj.io -A \
+-o custom-columns='NS:.metadata.namespace,APP:.metadata.name,PROJECT:.spec.project,AUTOSYNC:.spec.syncPolicy.automated,REPO:.spec.source.repoURL,PATH:.spec.source.path,DEST:.spec.destination.server'
+```
+## Abuso diretto di `argocd-repo-server`
+
+Non assumere che la API pubblica di Argo CD sia l'unica attack surface. I componenti interni di Argo CD comunicano con `argocd-repo-server` tramite gRPC. Se pod arbitrari possono raggiungere repo-server, richieste interne controllate dall'attacker possono bypassare i controlli normalmente applicati da `argocd-server`.
+
+Controlli pratici:
+```bash
+kubectl get svc -n argocd argocd-repo-server -o yaml
+kubectl get endpoints -n argocd argocd-repo-server -o wide
+nc -vz <argocd-repo-server> 8081
+```
+Segnali interessanti:
+
+- L'endpoint gRPC di repo-server è raggiungibile da pod non-Argo CD.
+- I NetworkPolicies mancano o consentono solo egress in allow-list senza negare ingress.
+- repo-server ha accesso a custom config management plugins, strumenti di decryption o content del repository da più tenant.
+- Redis è raggiungibile da pod non-Argo CD, consentendo l'ispezione o la manipolazione della cache se le credenziali sono disponibili o non richieste.
+
+## Unauthenticated Repo-Server RCE via Kustomize Options
+
+Nel luglio 2026, Synacktiv ha divulgato una catena di code execution non autenticata in `repo-server` di Argo CD quando un attacker può raggiungere il servizio gRPC interno. L'attacco sfrutta l'accesso diretto a `/repository.RepoServerService/GenerateManifest` e `KustomizeOptions` controllati dall'attacker.
+
+La primitive pericolosa consiste nel forzare repo-server a clonare content del repository controllato dall'attacker ed eseguire Kustomize con supporto Helm:
+```bash
+kustomize build <attacker_repo_path> --enable-helm --helm-command ./payload.sh
+```
+Input Kustomize malevolo minimo necessario per attivare l'elaborazione Helm:
+```yaml
+helmCharts:
+- name: pwn
+version: 0.0.1
+```
+Perché funziona:
+
+- `argocd-repo-server` clona il repository prima del rendering.
+- `--helm-command ./payload.sh` viene risolto in modo relativo al repository clonato.
+- L'esecuzione di codice non richiede injection di metacaratteri della shell se l'attaccante può controllare il repository renderizzato e le opzioni di build di Kustomize.
+
+Al momento della disclosure di Synacktiv del 1 luglio 2026, è stato segnalato che il problema non aveva un fix ufficiale né un CVE. Consideralo prima di tutto un problema di network-exposure: lo sfruttamento richiede raggiungibilità verso la porta gRPC interna di repo-server.
+
+## Redis Cache Poisoning to Deploy Manifests
+
+Dopo l'esecuzione di codice in `argocd-repo-server`, oppure dopo accesso diretto a Redis con credenziali valide, ispeziona le entry della cache supportate da Redis. Argo CD in genere memorizza valori JSON compressi con gzip.
+
+Prefissi di chiavi interessanti:
+```text
+mfst|...       # cached rendered manifests
+git-refs|...   # Git branch/ref to commit mappings
+app|...        # application resource/cache data
+cluster|...    # cluster cache information
+```
+L'attacco di cache poisoning descritto da Synacktiv sfrutta due elementi di stato:
+
+1. Modificare la voce di cache del manifest `mfst|...` pertinente per includere un manifest Kubernetes controllato dall'attaccante.
+2. Modificare il mapping `git-refs|...` correlato in modo che Argo CD creda che il branch sia stato spostato e poi riconcili di nuovo verso la revisione in cache.
+
+Impatto:
+
+- Con Auto Sync abilitato, Argo CD può applicare automaticamente il manifest in cache avvelenato.
+- Senza Auto Sync, il payload può comunque essere applicato quando un utente sincronizza manualmente l'applicazione.
+- L'impatto finale è limitato dalla destination dell'applicazione target e dai permessi Kubernetes disponibili ad Argo CD.
+
+## ApplicationSet Attacks
+
+ApplicationSet è particolarmente sensibile perché crea o aggiorna oggetti `Application` a partire dall'output del generator.
+
+Review:
+```bash
+kubectl get applicationsets.argoproj.io -A -o yaml
+kubectl get appprojects.argoproj.io -A -o yaml
+```
+Pattern interessanti:
+
+- I generatori git leggono file scrivibili dall'attaccante che controllano app names, paths, projects o destinations.
+- I generatori pull request per repository pubblici in cui contributor non trusted possono influenzare le generated applications.
+- I campi template che consentono broad destination clusters/namespaces.
+- AppProjects che permettono `sourceRepos: ["*"]` o broad `destinations`.
+- Generated applications che ereditano automated sync e pruning.
+
+## Post-Exploitation
+
+Da una shell del pod Argo CD, dai priorità a:
+```bash
+env
+cat /proc/1/environ 2>/dev/null | tr '\0' '\n'
+find /var/run/secrets /app/config -type f -maxdepth 4 2>/dev/null
+mount | grep -E 'secret|token|config'
+```
+Obiettivi utili:
+
+- Rubare `REDIS_PASSWORD` o materiale Redis TLS/client.
+- Estrarre credenziali del repository da secrets montati o Argo CD Kubernetes secrets.
+- Identificare le credenziali del cluster usate da Argo CD.
+- Leggere generated manifests e l'output dei plugin che possono includere secrets iniettati.
+- Verificare se custom plugins, SOPS, Helm secrets, Vault plugins o cloud CLIs espongono decryption keys e cloud credentials.
+
+## Detection & Hardening
+
+Controlli importanti:
+
+- Limita la porta **8081** di `argocd-repo-server` e la porta **6379** di Redis con NetworkPolicies in modo che solo i componenti Argo CD previsti possano raggiungerli.
+- Nelle distribuzioni Helm, verifica che le network policies vengano effettivamente create. I valori dell'Argo CD Helm chart hanno storicamente impostato la creazione delle network policy dei componenti su disabled.
+- Mantieni `argocd-server` come punto di ingresso autenticato. I servizi interni non dovrebbero essere raggiungibili da workload arbitrari.
+- Disabilita gli strumenti e i plugin di config management non usati.
+- Limita `AppProject` `sourceRepos`, `destinations`, namespace permissions e cluster-scoped resources.
+- Evita di archiviare repository credentials ampie che un utente Argo CD a basso privilegio possa far riutilizzare.
+- Monitora le richieste al repo-server, le Kustomize build options, le esecuzioni dei plugin, le scritture Redis e accessi inattesi alle chiavi `mfst|` / `git-refs|`.
+- Ruota gli utenti locali Argo CD, i project tokens, le repository credentials e le cluster credentials dopo una compromissione.
+
+Useful commands:
+```bash
+kubectl get networkpolicy -n argocd
+kubectl get networkpolicy -A | grep -i argocd
+kubectl describe networkpolicy -n argocd argocd-repo-server-network-policy 2>/dev/null
+kubectl describe networkpolicy -n argocd argocd-redis-network-policy 2>/dev/null
+```
+## Nota di Static Analysis: Typed API Requests in CodeQL
+
+Per i servizi Go che usano handler gRPC/REST, i default CodeQL remote sources possono perdere i flussi una volta che l’input grezzo è stato unmarshaled in typed request objects. Un modello utile per i servizi in stile Argo CD è:
+
+- Receiver type come `Server` o `Service`.
+- Il primo parametro è `context.Context`.
+- Il secondo parametro è un typed request object.
+
+Modella quel secondo parametro come remote source e aggiungi custom sinks per gli argomenti di `exec.Command` / `exec.CommandContext`. Questo aiuta a trovare flussi dai campi delle internal API request verso i command execution helpers.
+
+## References
+
+- [Synacktiv - Caught in the Octopus Trap: Unauthenticated RCE in Argo CD with CodeQL](https://www.synacktiv.com/en/publications/caught-in-the-octopus-trap-unauthenticated-rce-in-argo-cd-with-codeql)
+- [Argo CD docs - Security considerations](https://argo-cd.readthedocs.io/en/stable/operator-manual/security/)
+- [Argo CD docs - High Availability](https://argo-cd.readthedocs.io/en/stable/operator-manual/high_availability/)
+- [Argo CD docs - repo-server command reference](https://argo-cd.readthedocs.io/en/stable/operator-manual/server-commands/argocd-repo-server/)
+- [Argo CD - repo-server NetworkPolicy manifest](https://github.com/argoproj/argo-cd/blob/master/manifests/base/repo-server/argocd-repo-server-network-policy.yaml)
+- [Argo CD docs - metrics](https://argo-cd.readthedocs.io/en/latest/operator-manual/metrics/)
+- [Argo Helm - chart values reference](https://github.com/argoproj/argo-helm/blob/main/charts/argo-cd/README.md)
+- [Kustomize - Helm chart generator example](https://github.com/kubernetes-sigs/kustomize/blob/master/examples/chart.md)

src/pentesting-ci-cd/pentesting-ci-cd-methodology.md

@@ -6,51 +6,51 @@
 
 ## 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 usano in una delle seguenti **platforms**:
+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 platforms VCS)
+- Cloud providers (offrono le proprie piattaforme VCS)
 
 
 ## CI/CD Pipelines
 
-Le CI/CD pipelines consentono 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 pianificati. Sono utili per semplificare il processo dallo sviluppo alla produzione.
+I 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 sono **attivati da azioni specifiche**, come push di codice, pull request o task pianificati. 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**.
+Tuttavia, questi sistemi devono essere **eseguiti da qualche parte** e di solito con **credenziali privilegiate per deployare il codice o accedere a informazioni sensibili**.
 
 ## VCS Pentesting Methodology
 
 > [!NOTE]
-> Anche se alcune platforms VCS consentono di creare pipelines, per questa sezione analizzeremo solo i potenziali attacchi al controllo del source code.
+> Anche se alcune platforms VCS consentono di creare pipeline, per questa sezione analizzeremo solo i possibili attacchi al controllo del codice sorgente.
 
-Le platforms che contengono il source code del tuo progetto contengono informazioni sensibili e le persone devono essere molto attente ai permessi concessi all'interno di questa platform. Questi sono alcuni problemi comuni nelle platforms VCS che un attacker potrebbe abusare:
+Le platforms che contengono il codice sorgente del tuo progetto contengono informazioni sensibili e le persone devono essere molto attente con i permessi concessi dentro questa platform. Questi sono alcuni problemi comuni tra le platforms VCS che un attacker potrebbe abusare:
 
 - **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 **maggiore 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 proprio account github per entrare, per esempio).
-- **Credentials**: Username+Pwd, personal tokens, ssh keys, Oauth tokens, cookies... esistono 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**.
+- **Register**: Alcune platforms permetteranno semplicemente agli utenti esterni di creare un account.
+- **SSO**: Alcune platforms non permetteranno agli utenti di registrarsi, ma consentiranno a chiunque di accedere con un SSO valido (quindi un attacker potrebbe usare il suo account github per entrare, ad 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 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 third party platform
 - Se il secret è nell'URL, accade lo stesso e l'attacker ha anche il secret
-- **Code compromise:** Se un malicious actor ha qualche tipo di accesso **write** ai repos, potrebbe provare a **iniettare codice malevolo**. Per avere successo potrebbe dover **bypassare le branch protections**. Queste azioni possono essere eseguite con obiettivi diversi in mente:
-- Compromettere la main branch per **compromettere production**.
-- Compromettere la main (o altre branches) per **compromettere le macchine degli sviluppatori** (poiché di solito eseguono test, terraform o altre cose dentro il repo sulle loro macchine).
-- **Compromettere la pipeline** (vedi la prossima sezione)
+- **Code compromise:** Se un malicious actor ha qualche tipo di accesso in **write** sui repo, potrebbe provare a **iniettare codice malevolo**. Per avere successo potrebbe dover **bypassare le branch protections**. Queste azioni possono essere eseguite con obiettivi diversi in mente:
+- Compromettere la main branch per **compromettere la produzione**.
+- Compromettere la main (o altre branches) per **compromettere le macchine degli sviluppatori** (poiché di solito eseguono test, terraform o altro dentro il repo sulle loro macchine).
+- **Compromettere la pipeline** (check next section)
 
 ## Pipelines Pentesting Methodology
 
-Il modo più comune per definire una pipeline è usare un **CI configuration file hostato 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 in genere 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 situati sotto .github/workflows. Quando viene attivato, il job della pipeline **scarica il codice** dalla sorgente selezionata (ad esempio commit / branch), e **esegue i comandi specificati nel CI configuration file** su quel codice.
+Il modo più comune per definire una pipeline è usare 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 hanno tipicamente 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 situati sotto .github/workflows. Quando viene attivato, il job della pipeline **scarica il codice** dalla sorgente selezionata (ad es. commit / branch) e **esegue i comandi specificati nel file di configurazione CI** su quel codice.
 
-Pertanto, l'obiettivo finale dell'attacker è in qualche modo **compromettere quei file di configurazione** o i **comandi che eseguono**.
+Pertanto l'obiettivo finale dell'attacker è in qualche modo **compromettere quei file di configurazione** o i **comandi che eseguono**.
 
 > [!TIP]
-> Alcuni hosted builder consentono ai contributor di scegliere il Docker build context e il percorso del Dockerfile. Se il context è controllato dall'attacker, puoi impostarlo fuori dal repo (ad esempio, "..") per ingerire file dell'host durante la build ed esfiltrare secret. Vedi:
+> Alcuni builder hosted consentono ai contributor di scegliere il Docker build context e il path del Dockerfile. Se il context è controllato dall'attacker, può impostarlo fuori dal repo (ad esempio, "..") per ingestire file dell'host durante la build ed exfiltrare secrets. Vedi:
 >
 >{{#ref}}
 >docker-build-context-abuse.md
@@ -58,59 +58,60 @@ Pertanto, l'obiettivo finale dell'attacker è in qualche modo **compromettere qu
 
 ### PPE - Poisoned Pipeline Execution
 
-Il percorso Poisoned Pipeline Execution (PPE) sfrutta i permessi in un SCM repository per manipolare una CI pipeline ed eseguire comandi dannosi. Gli user con i permessi necessari possono modificare i file di configurazione CI o altri file usati dal job della pipeline per includere comandi malevoli. Questo "avvelena" la CI pipeline, portando all'esecuzione di questi 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 file di configurazione CI o altri file usati dal job della pipeline per includere comandi malevoli. Questo "avvelena" la CI pipeline, portando all'esecuzione di questi comandi malevoli.
 
-Per avere successo in un attacco PPE, un malicious actor deve essere in grado di:
+Perché un malicious actor abbia successo nell'eseguire un attacco PPE, deve essere in grado di:
 
-- Avere **write access alla platform VCS**, poiché di solito le pipelines vengono attivate quando viene eseguito un push o una pull request. (Vedi la VCS pentesting methodology per un riepilogo dei modi per ottenere accesso).
+- Avere **write access alla piattaforma 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 se ha permessi di scrittura, deve assicurarsi di poter **modificare il file di configurazione CI o altri file da cui la config dipende**.
+- Anche se ha permessi di write, deve essere sicuro di poter **modificare il file di config CI o altri file da cui dipende la config**.
 - 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'actor **modifica il file CI config** che verrà eseguito.
-- **I-DDE**: Un attacco **Indirect PPE** si verifica quando l'actor **modifica** un **file** da cui dipende il file CI config che verrà eseguito (**rely on**), come un make file o una terraform config.
-- **Public PPE or 3PE**: In alcuni casi le pipelines possono essere **attivate da user che non hanno write access nel repo** (e che potrebbero persino non far parte dell'org) perché possono inviare una PR.
-- **3PE Command Injection**: Di solito, le CI/CD pipelines **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 **sh commands**), un attacker potrebbe **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 file CI config che verrà eseguito **fa affidamento** (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 variabili d'ambiente** 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 **sh commands**), un attacker potrebbe **iniettare comandi lì dentro**.
 
 ### Exploitation Benefits
 
-Conoscendo le 3 varianti per avvelenare una pipeline, vediamo cosa potrebbe ottenere un attacker dopo un'exploit riuscito:
+Sapendo le 3 varianti per avvelenare una pipeline, vediamo cosa potrebbe ottenere un attacker dopo un'exploitazione riuscita:
 
-- **Secrets**: Come detto in precedenza, le pipelines richiedono **privilegi** per i loro job (recuperare il codice, buildarlo, deployarlo...) e questi privilegi di solito sono **concessi nei secret**. Questi secret sono solitamente accessibili tramite **env variables o file all'interno del sistema**. Pertanto un attacker cercherà sempre di esfiltrare quanti più secret possibile.
-- A seconda della platform della pipeline, l'attacker **potrebbe dover specificare i secret nella config**. Questo significa che, se l'attacker non può modificare il CI configuration pipeline (**I-PPE** per esempio), potrebbe **solo esfiltrare i secret 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 pipelines 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 **esfiltrare** token di IAM roles/service accounts **da esse** per ottenere **ulteriore accesso nel cloud**.
-- **Platforms machine**: A volte i job verranno eseguiti sulle **macchine della platform delle pipelines**, che di solito si trovano in un cloud con **nessun altro accesso**.
-- **Select it:** A volte la **platform delle pipelines avrà configurato più macchine** e, se puoi **modificare il file di configurazione CI**, 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 dentro la pipeline e la versione finale viene buildata e deployata da lì, potresti **compromettere il codice che finirà per essere eseguito in production**.
+- **Secrets**: Come detto prima, le pipeline richiedono **privilegi** per i loro job (recuperare il codice, buildarlo, deployarlo...) e questi privilegi sono solitamente **concessi in secrets**. Questi secrets sono di solito accessibili tramite **variabili d'ambiente o file dentro il sistema**. Pertanto un attacker cercherà sempre di exfiltrare quanti più secrets possibile.
+- A seconda della piattaforma della pipeline, l'attacker **potrebbe dover specificare i secrets nella config**. Questo significa che se l'attacker non può modificare la pipeline di configurazione CI (**I-PPE** ad 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 essere in grado di pivotare ulteriormente.
+- **On-Premises**: Se le pipeline vengono eseguite on premises, un attacker potrebbe finire in una **rete interna con accesso a più risorse**.
+- **Cloud**: L'attacker potrebbe accedere ad altre macchine nel cloud ma potrebbe anche **exfiltrare** token IAM roles/service accounts **da esse** per ottenere **ulteriore accesso dentro il cloud**.
+- **Platforms machine**: A volte i job verranno eseguiti dentro le **macchine della platform delle pipeline**, che di solito sono dentro un cloud con **nessun altro accesso**.
+- **Select it:** A volte la **platform 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 attacker probabilmente eseguirà una reverse shell su ogni macchina possibile 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 andrà in esecuzione in produzione**.
 
 ### Dependency & Registry Supply-Chain Abuse
 
-Compromettere una CI/CD pipeline o rubarne le credenziali può permettere a un attacker di passare da **pipeline execution** a **ecosystem-wide code execution** backdoorando dependencies o release tooling:
+Compromettere una CI/CD pipeline o rubarne le credenziali può permettere a un attacker di passare dall'**esecuzione nella pipeline** all'**esecuzione di codice su tutta l'ecosystem** inserendo backdoor nelle dependencies o negli strumenti 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 dependencies.
-- **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ì che il wrapper controllato dall'attacker venga symlinkato in `PATH` ed eseguito più tardi quando il comando 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 avviare il payload principale con esso, evitando requisiti locali di dependency.
-- **Credential harvesting from build environments**: una volta che il codice gira dentro CI, controlla le environment variables, `~/.npmrc`, `~/.git-credentials`, SSH keys, cloud CLI configs e strumenti locali come `gh auth token`. Su GitHub Actions, cerca anche secret e artifacts specifici del runner.
-- **Workflow injection with stolen GitHub tokens**: un token con permessi **`repo` + `workflow`** è sufficiente per creare un branch, fare commit di un file malevolo dentro `.github/workflows/`, attivarlo, raccogliere gli artifacts/log generati e poi eliminare il branch/workflow run temporaneo per ridurre le tracce.
-- **Wormable registry propagation**: i token npm rubati dovrebbero essere verificati per i permessi di **publish** e per capire se bypassano la 2FA. Se lo fanno, enumera i package scrivibili, scarica i loro tarball, inietta un loader come `setup.mjs`, imposta `preinstall` per eseguirlo, incrementa la patch version e ripubblica. Questo trasforma un compromesso CI in auto-esecuzione downstream in altri ambienti.
+- **Install-time code execution via package hooks**: pubblica una versione del package che aggiunge hook come `preinstall`, `postinstall`, `prepare` o simili, così il payload viene eseguito automaticamente sulle workstation degli sviluppatori e sui CI runners durante l'installazione delle dependencies.
+- **Secondary execution paths**: anche se i target installano con `--ignore-scripts`, un package malevolo può comunque registrare un **nome CLI comune** nel campo `bin` così che il wrapper controllato dall'attacker venga symlinkato in `PATH` ed eseguito più tardi quando il comando 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 con esso il main payload, evitando i requisiti delle dependencies locali.
+- **Credential harvesting from build environments**: una volta che il codice gira dentro CI, controlla variabili d'ambiente, `~/.npmrc`, `~/.git-credentials`, chiavi SSH, config dei cloud CLI e strumenti locali 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, fare commit di un file malevolo dentro `.github/workflows/`, attivarlo, raccogliere gli artifacts/log prodotti e poi eliminare il branch/workflow run temporaneo per ridurre le tracce.
+- **Wormable registry propagation**: i token npm rubati dovrebbero essere verificati per i permessi di **publish** e per capire se bypassano 2FA. Se sì, enumera i package scrivibili, scarica i loro tarball, inietta un loader come `setup.mjs`, imposta `preinstall` per eseguirlo, incrementa la patch version e ripubblica. Questo trasforma un compromesso CI in auto-esecuzione a valle in altri ambienti.
 
 #### Practical checks during an assessment
 
-- Esamina l'automazione di release per hook del package manager aggiunti a `package.json`, `bin` entries inattese o version bumps che modificano solo l'artefact di release.
-- Controlla se CI memorizza credenziali di registry a lunga durata in file in chiaro 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 branches/tags.
-- 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'artefact 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 transient branches.
+- Esamina l'automazione di release per hook del package manager aggiunti a `package.json`, entry `bin` inattese o bump di versione che modificano solo l'artefatto di release.
+- Verifica se la CI conserva credenziali di registry a lunga durata in file in chiaro come `~/.npmrc` invece di usare OIDC a breve durata o trusted publishing.
+- Verifica se i token GitHub disponibili in CI possono scrivere file di workflow o creare branch/tag.
+- Se si sospetta un package compromesso, ispeziona il tarball pubblicato e non solo il repository Git, perché il loader/runtime malevolo potrebbe esistere solo nell'artefatto pubblicato.
+- Cerca esecuzioni inattese del package manager dentro CI come `npm install` invece di `npm ci`, download/esecuzione inattesi di Bun, o nuovi artifacts di workflow generati da branch temporanei.
+- Esamina anche i motori di deploy GitOps come target CI/CD. L'enumerazione specifica di Argo CD, l'abuso del repo-server e gli attacchi di Redis cache poisoning sono trattati in [Argo CD Security](argocd-security.md).
 
 ## More relevant info
 
 ### Tools & CIS Benchmark
 
-- [**Chain-bench**](https://github.com/aquasecurity/chain-bench) è uno strumento open-source per auditare il tuo software supply chain stack per la sicurezza e la compliance 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 fino al deploy time.
+- [**Chain-bench**](https://github.com/aquasecurity/chain-bench) è uno strumento open-source per l'audit della tua software supply chain stack per la conformità alla 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
 
@@ -118,12 +119,12 @@ Controlla questo articolo interessante sui top 10 rischi CI/CD secondo Cider: [*
 
 ### Labs
 
-- Su ogni platform che puoi eseguire localmente troverai come avviarla in locale 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
 
-- [**Checkov**](https://github.com/bridgecrewio/checkov): **Checkov** è uno strumento di static code analysis per infrastructure-as-code.
+- [**Checkov**](https://github.com/bridgecrewio/checkov): **Checkov** è uno strumento di analisi statica del codice per infrastructure-as-code.
 
 ## References