Atlantis Security
Last updated
Last updated
Impara e pratica AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Impara e pratica GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Atlantis aiuta fondamentalmente a eseguire terraform da Pull Requests dal tuo server git.
Vai alla pagina delle release di atlantis in https://github.com/runatlantis/atlantis/releases e scarica quella che fa per te.
Crea un token personale (con accesso ai repo) del tuo utente github
Esegui ./atlantis testdrive e verrà creato un repo demo che puoi usare per parlare con atlantis
Puoi accedere alla pagina web in 127.0.0.1:4141
Atlantis supporta diversi host git come Github, Gitlab, Bitbucket e Azure DevOps. Tuttavia, per accedere ai repo su queste piattaforme e eseguire azioni, è necessario avere alcuni accessi privilegiati concessi (almeno permessi di scrittura). La documentazione incoraggia a creare un utente su queste piattaforme specificamente per Atlantis, ma alcune persone potrebbero usare account personali.
In ogni caso, dal punto di vista di un attaccante, l'account di Atlantis sarà molto interessante da compromettere.
Atlantis utilizza opzionalmente Webhook secrets per convalidare che i webhook che riceve dal tuo host Git siano legittimi.
Un modo per confermare ciò sarebbe consentire le richieste solo dagli IP del tuo host Git, ma un modo più semplice è utilizzare un Webhook Secret.
Nota che a meno che tu non utilizzi un server github o bitbucket privato, dovrai esporre gli endpoint webhook a Internet.
Atlantis andrà a esporre webhook affinché il server git possa inviargli informazioni. Dal punto di vista di un attaccante, sarebbe interessante sapere se puoi inviargli messaggi.
Atlantis esegue Terraform semplicemente eseguendo i comandi terraform plan e apply sul server su cui è ospitato Atlantis. Proprio come quando esegui Terraform localmente, Atlantis ha bisogno di credenziali per il tuo provider specifico.
Sta a te come fornire credenziali per il tuo provider specifico ad Atlantis:
Il Helm Chart di Atlantis e il Modulo AWS Fargate hanno i propri meccanismi per le credenziali del provider. Leggi la loro documentazione.
Se stai eseguendo Atlantis in un cloud, molti cloud hanno modi per dare accesso API cloud alle applicazioni in esecuzione su di essi, ad es:
AWS EC2 Roles (Cerca "EC2 Role")
Molti utenti impostano variabili di ambiente, ad es. AWS_ACCESS_KEY, dove sta girando Atlantis.
Altri creano i file di configurazione necessari, ad es. ~/.aws/credentials, dove sta girando Atlantis.
Usa il HashiCorp Vault Provider per ottenere credenziali del provider.
Il container in cui Atlantis è in esecuzione conterrà molto probabilmente credenziali privilegiate per i provider (AWS, GCP, Github...) che Atlantis gestisce tramite Terraform.
Per impostazione predefinita, Atlantis eseguirà una pagina web sulla porta 4141 in localhost. Questa pagina consente solo di abilitare/disabilitare l'applicazione di atlantis e controllare lo stato del piano dei repo e sbloccarli (non consente di modificare le cose, quindi non è molto utile).
Probabilmente non la troverai esposta a Internet, ma sembra che per impostazione predefinita non siano necessarie credenziali per accedervi (e se lo sono, atlantis:atlantis sono le predefinite).
La configurazione per atlantis server può essere specificata tramite flag da riga di comando, variabili di ambiente, un file di configurazione o un mix dei tre.
Puoi trovare qui l'elenco dei flag supportati dal server Atlantis
I valori sono scelti in quest'ordine:
Flag
Variabili di Ambiente
File di Configurazione
Nota che nella configurazione potresti trovare valori interessanti come token e password.
Alcune configurazioni influenzano come vengono gestiti i repo. Tuttavia, è possibile che ogni repo richieda impostazioni diverse, quindi ci sono modi per specificare ciascun repo. Questo è l'ordine di priorità:
File /atlantis.yml. Questo file può essere utilizzato per specificare come atlantis dovrebbe trattare il repo. Tuttavia, per impostazione predefinita, alcune chiavi non possono essere specificate qui senza alcuni flag che lo consentano.
Probabilmente necessario essere consentito da flag come allowed_overrides o allow_custom_workflows
Configurazione Lato Server: Puoi passarla con il flag --repo-config ed è un yaml che configura nuove impostazioni per ciascun repo (supportati regex)
Valori predefiniti
Protezioni PR
Atlantis consente di indicare se desideri che il PR sia approvato da qualcun altro (anche se non è impostato nella protezione del ramo) e/o essere mergeable (protezioni del ramo superate) prima di eseguire l'applicazione. Dal punto di vista della sicurezza, impostare entrambe le opzioni è raccomandato.
Nel caso in cui allowed_overrides sia True, queste impostazioni possono essere sovrascritte su ciascun progetto dal file /atlantis.yml.
Script
La configurazione del repo può specificare script da eseguire prima (pre workflow hooks) e dopo (post workflow hooks) che un workflow viene eseguito.
Non c'è alcuna opzione per consentire di specificare questi script nel file repo /atlantis.yml.
Workflow
Nella configurazione del repo (configurazione lato server) puoi specificare un nuovo workflow predefinito, o creare nuovi workflow personalizzati. Puoi anche specificare quali repo possono accedere ai nuovi generati. Poi, puoi consentire al file atlantis.yaml di ciascun repo di specificare il workflow da utilizzare.
Se il flag server side config allow_custom_workflows è impostato su True, i workflow possono essere specificati nel file atlantis.yaml di ciascun repo. È anche potenzialmente necessario che allowed_overrides specifichi anche workflow per sovrascrivere il workflow che verrà utilizzato.
Questo darà fondamentalmente RCE nel server di Atlantis a qualsiasi utente che può accedere a quel repo.
Controllo delle Politiche Conftest
Atlantis supporta l'esecuzione di politiche conftest lato server contro l'output del piano. I casi d'uso comuni per utilizzare questo passaggio includono:
Negare l'uso di un elenco di moduli
Affermare gli attributi di una risorsa al momento della creazione
Catturare eliminazioni involontarie di risorse
Prevenire rischi per la sicurezza (ad es. esporre porte sicure al pubblico)
Puoi controllare come configurarlo in la documentazione.
Nella documentazione puoi trovare le opzioni che puoi utilizzare per eseguire Atlantis:
Se durante lo sfruttamento trovi questo errore: Error: Error acquiring the state lock
Puoi risolverlo eseguendo:
Se hai accesso in scrittura su un repository, sarai in grado di creare un nuovo branch e generare una PR. Se puoi eseguire atlantis plan (o forse viene eseguito automaticamente) sarai in grado di RCE all'interno del server Atlantis.
Puoi farlo facendo caricare ad Atlantis una fonte di dati esterna. Basta inserire un payload come il seguente nel file main.tf:
Attacco più furtivo
Puoi eseguire questo attacco anche in modo più furtivo, seguendo questi suggerimenti:
Invece di aggiungere direttamente la rev shell nel file terraform, puoi caricare una risorsa esterna che contiene la rev shell:
Puoi trovare il codice rev shell in https://github.com/carlospolop/terraform_external_module_rev_shell/tree/main/modules
Nella risorsa esterna, usa la funzione ref per nascondere il codice rev shell terraform in un branch all'interno del repo, qualcosa come: git@github.com:carlospolop/terraform_external_module_rev_shell//modules?ref=b401d2b
Invece di creare un PR per master per attivare Atlantis, crea 2 branch (test1 e test2) e crea un PR da uno all'altro. Quando hai completato l'attacco, basta rimuovere il PR e i branch.
Puoi dumpare i segreti usati da terraform eseguendo atlantis plan (terraform plan) mettendo qualcosa del genere nel file terraform:
Se hai accesso in scrittura su un repository, sarai in grado di creare un nuovo branch e generare una PR. Se puoi eseguire atlantis apply, sarai in grado di RCE all'interno del server Atlantis.
Tuttavia, di solito dovrai bypassare alcune protezioni:
Mergeable: Se questa protezione è impostata in Atlantis, puoi eseguire atlantis apply solo se la PR è mergeable (il che significa che la protezione del branch deve essere bypassata).
Controlla i potenziali bypass delle protezioni del branch
Approved: Se questa protezione è impostata in Atlantis, un altro utente deve approvare la PR prima che tu possa eseguire atlantis apply
Per impostazione predefinita, puoi abusare del token Gitbot per bypassare questa protezione
Eseguendo terraform apply su un file Terraform malevolo con local-exec.
Devi solo assicurarti che un payload come i seguenti termini nel file main.tf:
Segui le suggerimenti della tecnica precedente per eseguire questo attacco in modo più furtivo.
Quando si esegue atlantis plan o atlantis apply, terraform viene eseguito sotto, puoi passare comandi a terraform da atlantis commentando qualcosa come:
Qualcosa che puoi passare sono le variabili env che potrebbero essere utili per bypassare alcune protezioni. Controlla le variabili env di terraform in https://www.terraform.io/cli/config/environment-variables
Esecuzione di comandi di build personalizzati malevoli specificati in un file atlantis.yaml. Atlantis utilizza il file atlantis.yaml dal ramo della pull request, non da master.
Questa possibilità è stata menzionata in una sezione precedente:
Se il flag server side config allow_custom_workflows è impostato su True, i workflow possono essere specificati nel file atlantis.yaml di ciascun repo. È anche potenzialmente necessario che allowed_overrides specifichi anche workflow per sovrascrivere il workflow che verrà utilizzato.
Questo darà fondamentalmente RCE nel server di Atlantis a qualsiasi utente che può accedere a quel repo.
Se il flag server side config allowed_overrides ha configurato apply_requirements, è possibile per un repo modificare le protezioni di piano/applicazione per bypassarle.
Se qualcuno invia commenti atlantis plan/apply sulle tue pull request valide, farà sì che terraform venga eseguito quando non lo desideri.
Inoltre, se non hai configurato nella protezione del branch di chiedere di ri-valutare ogni PR quando viene inviato un nuovo commit, qualcuno potrebbe scrivere configurazioni dannose (controlla gli scenari precedenti) nella configurazione di terraform, eseguire atlantis plan/apply e ottenere RCE.
Questa è la configurazione nelle protezioni dei branch di Github:
Se riesci a rubare il webhook secret utilizzato o se non c'è alcun webhook secret in uso, potresti chiamare il webhook di Atlantis e invochare comandi atlatis direttamente.
Bitbucket Cloud non supporta i webhook secrets. Questo potrebbe consentire agli attaccanti di falsificare richieste da Bitbucket. Assicurati di consentire solo gli IP di Bitbucket.
Questo significa che un attaccante potrebbe fare richieste false ad Atlantis che sembrano provenire da Bitbucket.
Se stai specificando --repo-allowlist, allora potrebbero solo falsificare richieste relative a quei repo, quindi il danno maggiore che potrebbero causare sarebbe pianificare/applicare sui tuoi stessi repo.
Per prevenire questo, consenti solo gli indirizzi IP di Bitbucket (vedi indirizzi IPv4 in uscita).
Se sei riuscito ad accedere al server o almeno hai ottenuto un LFI, ci sono alcune cose interessanti che dovresti provare a leggere:
/home/atlantis/.git-credentials Contiene le credenziali di accesso vcs
/atlantis-data/atlantis.db Contiene le credenziali di accesso vcs con ulteriori informazioni
/atlantis-data/repos/<org_name>/<repo_name>/<pr_num>/<workspace>/<path_to_dir>/.terraform/terraform.tfstate File di stato di Terraform
Esempio: /atlantis-data/repos/ghOrg_/_myRepo/20/default/env/prod/.terraform/terraform.tfstate
/proc/1/environ Variabili d'ambiente
/proc/[2-20]/cmdline Linea di comando di atlantis server (potrebbe contenere dati sensibili)
Poiché chiunque può commentare su pull request pubbliche, anche con tutte le mitigazioni di sicurezza disponibili, è comunque pericoloso eseguire Atlantis su repo pubblici senza una corretta configurazione delle impostazioni di sicurezza.
--allow-fork-prsSe stai eseguendo su un repo pubblico (cosa non raccomandata, vedi sopra) non dovresti impostare --allow-fork-prs (di default è false) perché chiunque può aprire una pull request dal proprio fork al tuo repo.
--repo-allowlistAtlantis richiede di specificare una lista di autorizzazione di repository da cui accetterà webhook tramite il flag --repo-allowlist. Ad esempio:
Repository specifici: --repo-allowlist=github.com/runatlantis/atlantis,github.com/runatlantis/atlantis-tests
L'intera tua organizzazione: --repo-allowlist=github.com/runatlantis/*
Ogni repository nella tua installazione di GitHub Enterprise: --repo-allowlist=github.yourcompany.com/*
Tutti i repository: --repo-allowlist=*. Utile quando sei in una rete protetta ma pericoloso senza impostare anche un webhook secret.
Questo flag garantisce che la tua installazione di Atlantis non venga utilizzata con repository che non controlli. Vedi atlantis server --help per ulteriori dettagli.
Se gli attaccanti inviano pull request con codice Terraform dannoso è nel tuo modello di minaccia, allora devi essere consapevole che le approvazioni di terraform apply non sono sufficienti. È possibile eseguire codice dannoso in un terraform plan utilizzando la external data source o specificando un provider dannoso. Questo codice potrebbe quindi esfiltrare le tue credenziali.
Per prevenire questo, potresti:
Includere i provider nell'immagine di Atlantis o ospitarli e negare l'uscita in produzione.
Implementare internamente il protocollo del registro dei provider e negare l'uscita pubblica, in questo modo controlli chi ha accesso in scrittura al registro.
Modificare il passo plan della tua configurazione del repo lato server per convalidare l'uso di provider o data source non consentiti o PR da utenti non autorizzati. Potresti anche aggiungere una convalida extra a questo punto, ad esempio richiedendo un "pollice in su" sulla PR prima di consentire il proseguimento del plan. Conftest potrebbe essere utile qui.
Atlantis dovrebbe essere eseguito con i webhook secrets impostati tramite le variabili d'ambiente $ATLANTIS_GH_WEBHOOK_SECRET/$ATLANTIS_GITLAB_WEBHOOK_SECRET. Anche con il flag --repo-allowlist impostato, senza un webhook secret, gli attaccanti potrebbero fare richieste ad Atlantis spacciandosi per un repository autorizzato. I webhook secrets garantiscono che le richieste webhook provengano effettivamente dal tuo fornitore VCS (GitHub o GitLab).
Se stai usando Azure DevOps, invece dei webhook secrets, aggiungi un nome utente e una password di base.
Azure DevOps supporta l'invio di un'intestazione di autenticazione di base in tutti gli eventi webhook. Questo richiede di utilizzare un URL HTTPS per la tua posizione webhook.
Se stai usando webhook secrets ma il tuo traffico è su HTTP, allora i webhook secrets potrebbero essere rubati. Abilita SSL/HTTPS utilizzando i flag --ssl-cert-file e --ssl-key-file.
È molto consigliato abilitare l'autenticazione nel servizio web. Abilita BasicAuth utilizzando --web-basic-auth=true e imposta un nome utente e una password utilizzando i flag --web-username=yourUsername e --web-password=yourPassword.
Puoi anche passare questi come variabili d'ambiente ATLANTIS_WEB_BASIC_AUTH=true ATLANTIS_WEB_USERNAME=yourUsername e ATLANTIS_WEB_PASSWORD=yourPassword.
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
