Metodologia Pentesting CI/CD

Tip

Impara & pratica AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Impara & pratica GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Impara & pratica Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Sostieni HackTricks

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:

  • Github
  • Gitlab
  • Bitbucket
  • Gitea
  • Gitblit
  • Cloud providers (offrono le proprie platforms 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.

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 platforms VCS consentono di creare pipelines, per questa sezione analizzeremo solo i potenziali attacchi al controllo del source code.

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:

  • 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.
  • 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)

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.

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:

{{#ref}} docker-build-context-abuse.md {{#endref}}

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.

Per avere successo in un attacco PPE, un malicious actor 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).
  • 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.
  • 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.

Exploitation Benefits

Conoscendo le 3 varianti per avvelenare una pipeline, vediamo cosa potrebbe ottenere un attacker dopo un’exploit riuscito:

  • 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.

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:

  • 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.

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.

More relevant info

Tools & CIS Benchmark

  • 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. 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

Controlla questo articolo interessante sui top 10 rischi CI/CD secondo Cider: https://www.cidersecurity.io/top-10-cicd-security-risks/

Labs

Automatic Tools

  • Checkov: Checkov è uno strumento di static code analysis per infrastructure-as-code.

References

Tip

Impara & pratica AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Impara & pratica GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Impara & pratica Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Sostieni HackTricks