Atlantis Security
Informazioni di Base
Atlantis ti aiuta fondamentalmente ad eseguire terraform dalle Pull Requests dal tuo server git.
Laboratorio Locale
Vai alla pagina dei rilasci di atlantis su https://github.com/runatlantis/atlantis/releases e scarica quella che fa al caso tuo.
Crea un token personale (con accesso al repository) del tuo utente github
Esegui
./atlantis testdrive
e creerà un repo demo che puoi usare per interagire con atlantisPuoi accedere alla pagina web su 127.0.0.1:4141
Accesso ad Atlantis
Credenziali del Server Git
Atlantis supporta diversi host git come Github, Gitlab, Bitbucket e Azure DevOps. Tuttavia, per accedere ai repository su queste piattaforme e eseguire azioni, è necessario concedere loro un certo accesso privilegiato (almeno permessi di scrittura). La documentazione incoraggia a creare un utente specifico per Atlantis su queste piattaforme, ma alcune persone potrebbero utilizzare account personali.
In ogni caso, dal punto di vista di un attaccante, l'account di Atlantis sarà molto interessante da compromettere.
Webhook
Atlantis utilizza facoltativamente Segreti del Webhook per convalidare che i webhook ricevuti dal tuo host Git siano legittimi.
Un modo per confermare ciò sarebbe consentire le richieste solo dai IP del tuo host Git, ma un modo più semplice è utilizzare un Segreto del Webhook.
Nota che a meno che tu non stia utilizzando un server github o bitbucket privato, dovrai esporre i punti finali del webhook su Internet.
Atlantis sta per esporre i webhooks in modo che il server git possa inviargli informazioni. Dal punto di vista di un attaccante sarebbe interessante sapere se è possibile inviargli messaggi.
Credenziali del Provider
Atlantis esegue Terraform semplicemente eseguendo i comandi terraform plan
e apply
sul server dove è ospitato Atlantis. Proprio come quando esegui Terraform in locale, Atlantis ha bisogno di credenziali per il tuo provider specifico.
Spetta a te come fornire le credenziali per il tuo provider specifico ad Atlantis:
Il Chart di Atlantis Helm e il Modulo AWS Fargate hanno i loro meccanismi per le credenziali del provider. Leggi le loro documentazioni.
Se stai eseguendo Atlantis in un cloud, molti cloud hanno modi per dare accesso all'API cloud alle applicazioni in esecuzione su di essi, ad esempio:
Ruoli EC2 di AWS (Cerca "Ruolo EC2")
Molti utenti impostano variabili d'ambiente, ad es.
AWS_ACCESS_KEY
, dove Atlantis è in esecuzione.Altri creano i file di configurazione necessari, ad es.
~/.aws/credentials
, dove Atlantis è in esecuzione.Usa il Provider Vault di HashiCorp per ottenere le credenziali del provider.
Il contenitore dove Atlantis è in esecuzione con molta probabilità conterrà credenziali privilegiate per i provider (AWS, GCP, Github...) che Atlantis sta gestendo tramite Terraform.
Pagina Web
Per impostazione predefinita Atlantis eseguirà una pagina web sulla porta 4141 in localhost. Questa pagina ti consente semplicemente di abilitare/disabilitare l'applicazione di atlantis e controllare lo stato del piano dei repository e sbloccarli (non consente di modificare le cose, quindi non è così utile).
Probabilmente non la troverai esposta su Internet, ma sembra che per impostazione predefinita non siano necessarie credenziali per accedervi (e se lo sono atlantis
:atlantis
sono le credenziali predefinite).
Configurazione del Server
La configurazione del server atlantis
può essere specificata tramite flag della riga di comando, variabili d'ambiente, un file di configurazione o una combinazione dei tre.
Puoi trovare qui l'elenco dei flag supportati dal server Atlantis
I valori sono scelti in questo ordine:
Flag
Variabili d'ambiente
File di configurazione
Nota che nella configurazione potresti trovare valori interessanti come token e password.
Configurazione dei Repository
Alcune configurazioni influenzano come i repository sono gestiti. Tuttavia, è possibile che ogni repository richieda impostazioni diverse, quindi ci sono modi per specificare ciascun repository. Questo è l'ordine di priorità:
File
/atlantis.yml
del repository. Questo file può essere utilizzato per specificare come atlantis dovrebbe trattare il repository. Tuttavia, per impostazione predefinita alcune chiavi non possono essere specificate qui senza alcuni flag che lo consentano.Probabilmente richiesto di essere consentito da flag come
allowed_overrides
oallow_custom_workflows
Configurazione Lato Server: Puoi passarla con il flag
--repo-config
ed è un yaml che configura nuove impostazioni per ciascun repository (supporta regex)Valori predefiniti
Protezioni PR
Atlantis consente di indicare se si desidera che il PR venga approvato
da qualcun altro (anche se non è impostato nella protezione del branch) e/o sia mergiabile
(protezioni del branch superate) prima di eseguire l'apply. Da un punto di vista della sicurezza, è consigliabile impostare entrambe le opzioni.
Nel caso in cui allowed_overrides
sia True, queste impostazioni possono essere sovrascritte su ciascun progetto tramite il file /atlantis.yml
.
Script
La configurazione del repository può specificare script da eseguire prima (pre workflow hooks) e dopo (post workflow hooks) l'esecuzione di un workflow.
Non esiste alcuna opzione per consentire di specificare questi script nel file /atlantis.yml
del repository.
Workflow
Nella configurazione del repository (configurazione lato server) è possibile specificare un nuovo flusso di lavoro predefinito, o creare nuovi flussi di lavoro personalizzati. È inoltre possibile specificare quali repository possono accedere a quelli nuovi generati. Successivamente, è possibile consentire al file atlantis.yaml di ciascun repository di specificare il flusso di lavoro da utilizzare.
Se il flag configurazione lato server allow_custom_workflows
è impostato su True, i flussi di lavoro possono essere specificati nel file atlantis.yaml
di ciascun repository. Potrebbe essere necessario che allowed_overrides
specifichi anche workflow
per sovrascrivere il flusso di lavoro che verrà utilizzato.
Questo darà fondamentalmente RCE nel server Atlantis a qualsiasi utente che può accedere a quel repository.
Controllo delle policy Conftest
Atlantis supporta l'esecuzione delle policy server-side conftest contro l'output del piano. I casi d'uso comuni per l'utilizzo di questo passaggio includono:
Negare l'uso di un elenco di moduli
Assegnare attributi di una risorsa al momento della creazione
Catturare eliminazioni non intenzionali di risorse
Prevenire rischi per la sicurezza (ad esempio, esporre porte sicure al pubblico)
Puoi verificare come configurarlo nella documentazione.
Comandi di Atlantis
Nella documentazione puoi trovare le opzioni che puoi utilizzare per eseguire Atlantis:
Attacchi
Se durante l'exploitation trovi questo errore: Error: Error acquiring the state lock
Puoi risolverlo eseguendo:
Pianificazione RCE di Atlantis - Modifica della configurazione in una nuova PR
Se hai accesso in scrittura su un repository, sarai in grado di creare un nuovo branch su di esso e generare una PR. Se puoi eseguire atlantis plan
(o forse viene eseguito automaticamente) sarai in grado di eseguire RCE all'interno del server di 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ù stealth
Puoi eseguire questo attacco in modo ancora più stealth, seguendo questi suggerimenti:
Invece di aggiungere direttamente la shell rev nel file terraform, puoi caricare una risorsa esterna che contiene la shell rev:
Puoi trovare il codice rev shell in https://github.com/carlospolop/terraform_external_module_rev_shell/tree/main/modules
Nella risorsa esterna, utilizza la funzionalità ref per nascondere il codice rev shell di terraform in un branch all'interno del repository, qualcosa del genere:
git@github.com:carlospolop/terraform_external_module_rev_shell//modules?ref=b401d2b
Invece di creare una PR su master per attivare Atlantis, crea 2 branch (test1 e test2) e crea una PR da uno all'altro. Quando hai completato l'attacco, basta rimuovere la PR e i branch.
Atlantis plan Secrets Dump
Puoi scaricare i segreti utilizzati da terraform eseguendo atlantis plan
(terraform plan
) inserendo qualcosa del genere nel file terraform:
Atlantis applica RCE - Modifica della configurazione in una nuova PR
Se hai accesso in scrittura su un repository, sarai in grado di creare un nuovo branch su di esso e generare una PR. Se puoi eseguire atlantis apply
sarai in grado di eseguire RCE all'interno del server Atlantis.
Tuttavia, di solito dovrai aggirare alcune protezioni:
Fusibile: Se questa protezione è impostata in Atlantis, puoi eseguire
atlantis apply
solo se la PR è fusibile (il che significa che la protezione del branch deve essere aggirata).Controlla potenziali aggiramenti delle protezioni del branch
Approvato: 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 aggirare questa protezione
Eseguendo terraform apply
su un file Terraform malintenzionato con local-exec.
Devi solo assicurarti che qualche payload come quelli seguenti finisca nel file main.tf
:
Segui i suggerimenti della tecnica precedente per eseguire questo attacco in modo più furtivo.
Iniezione di Parametri Terraform
Quando si esegue atlantis plan
o atlantis apply
terraform viene eseguito sotto-needs, è possibile passare comandi a terraform da atlantis commentando qualcosa del genere:
Qualcosa che puoi passare sono le variabili di ambiente che potrebbero essere utili per aggirare alcune protezioni. Controlla le variabili di ambiente di Terraform in https://www.terraform.io/cli/config/environment-variables
Flusso Personalizzato
Eseguire comandi di build personalizzati maligni specificati in un file atlantis.yaml
. Atlantis utilizza il file atlantis.yaml
dal ramo della richiesta di pull, non da master
.
Questa possibilità è stata menzionata in una sezione precedente:
Se il flag di configurazione lato server allow_custom_workflows è impostato su True, i flussi di lavoro possono essere specificati nel file atlantis.yaml
di ciascun repository. Potrebbe anche essere necessario che allowed_overrides
specifichi anche workflow
per sovrascrivere il flusso di lavoro che verrà utilizzato.
Questo darà fondamentalmente RCE nel server Atlantis a qualsiasi utente che può accedere a quel repository.
Ignorare le protezioni del piano/apply
Se il flag configurazione lato server allowed_overrides
ha apply_requirements
configurato, è possibile per un repository modificare le protezioni del piano/apply per ignorarle.
Dirottamento PR
Se qualcuno invia commenti atlantis plan/apply
sui tuoi pull request validi, farà eseguire terraform quando non lo desideri.
Inoltre, se non hai configurato nella protezione del branch di chiedere di riesaminare ogni PR quando viene effettuato un nuovo commit, qualcuno potrebbe scrivere configurazioni maligne (controlla scenari precedenti) nel file di configurazione di terraform, eseguire atlantis plan/apply
e ottenere RCE.
Questa è l'impostazione nelle protezioni del branch di Github:
Segreto del Webhook
Se riesci a rubare il segreto del webhook utilizzato o se non viene utilizzato alcun segreto del webhook, potresti chiamare il webhook di Atlantis e invocare comandi di atlantis direttamente.
Bitbucket
Bitbucket Cloud non supporta i segreti del webhook. Ciò potrebbe consentire agli attaccanti di spoofare le richieste da Bitbucket. Assicurati di consentire solo gli IP di Bitbucket.
Ciò significa che un attaccante potrebbe inviare richieste false ad Atlantis che sembrano provenire da Bitbucket.
Se stai specificando
--repo-allowlist
allora potrebbero inviare solo richieste false relative a quei repository, quindi il danno maggiore che potrebbero fare sarebbe pianificare/applicare sui tuoi stessi repository.Per prevenire ciò, permetti solo gli indirizzi IP di Bitbucket (vedi Indirizzi IP IPv4 in uscita).
Post-Esploitation
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 credenziali di accesso al vcs/atlantis-data/atlantis.db
Contiene credenziali di accesso al vcs con più informazioni/atlantis-data/repos/<org_name>
/
<repo_name>/<pr_num>/<workspace>/<path_to_dir>/.terraform/terraform.tfstate
File di stato di TerraformEsempio: /atlantis-data/repos/ghOrg_/_myRepo/20/default/env/prod/.terraform/terraform.tfstate
/proc/1/environ
Variabili di ambiente/proc/[2-20]/cmdline
Linea di comando diatlantis server
(potrebbe contenere dati sensibili)
Mitigazioni
Non Utilizzare Su Repository Pubblici
Poiché chiunque può commentare su pull request pubblici, anche con tutte le mitigazioni di sicurezza disponibili, è comunque pericoloso eseguire Atlantis su repository pubblici senza una corretta configurazione delle impostazioni di sicurezza.
Non Utilizzare --allow-fork-prs
--allow-fork-prs
Se stai eseguendo su un repository pubblico (cosa non consigliata, vedi sopra) non dovresti impostare --allow-fork-prs
(impostato su false di default) perché chiunque può aprire una pull request dal proprio fork al tuo repository.
--repo-allowlist
--repo-allowlist
Atlantis richiede di specificare un elenco di repository che accetterà i webhook tramite il flag --repo-allowlist
. Ad esempio:
Repository specifici:
--repo-allowlist=github.com/runatlantis/atlantis,github.com/runatlantis/atlantis-tests
Tua intera organizzazione:
--repo-allowlist=github.com/runatlantis/*
Ogni repository nella tua installazione 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 segreto del webhook.
Questo flag garantisce che la tua installazione di Atlantis non venga utilizzata con repository che non controlli. Consulta atlantis server --help
per ulteriori dettagli.
Proteggere la Pianificazione di Terraform
Se gli attaccanti che inviano pull request con codice Terraform maligno sono nel tuo modello di minaccia, devi essere consapevole che le approvazioni di terraform apply
non sono sufficienti. È possibile eseguire codice maligno in una terraform plan
utilizzando il data source external
o specificando un provider maligno. Questo codice potrebbe quindi esfiltrare le tue credenziali.
Per prevenire ciò, potresti:
Integrare i provider nell'immagine di Atlantis o nell'host e negare l'uscita in produzione.
Implementare il protocollo del registro dei provider internamente e negare l'uscita pubblica, in modo da controllare chi ha accesso in scrittura al registro.
Modificare il configurazione del repository lato server's
plan
per convalidare l'uso di provider o data source non consentiti o PR da utenti non consentiti. Potresti anche aggiungere una convalida aggiuntiva in questo punto, ad esempio richiedendo un "ok" sulla PR prima di consentire alplan
di continuare. Conftest potrebbe essere utile in questo caso.
Segreti del Webhook
Atlantis dovrebbe essere eseguito con i segreti del Webhook impostati tramite le variabili d'ambiente $ATLANTIS_GH_WEBHOOK_SECRET
/$ATLANTIS_GITLAB_WEBHOOK_SECRET
. Anche con il flag --repo-allowlist
impostato, senza un segreto del webhook, gli attaccanti potrebbero inviare richieste ad Atlantis fingendo di provenire da un repository che è nella lista consentita. I segreti del webhook garantiscono che le richieste del webhook provengano effettivamente dal tuo fornitore VCS (GitHub o GitLab).
Se stai utilizzando Azure DevOps, anziché i segreti del webhook aggiungi un nome utente e una password di base.
Autenticazione di Base di Azure DevOps
Azure DevOps supporta l'invio di un'intestazione di autenticazione di base in tutti gli eventi del webhook. Ciò richiede l'utilizzo di un URL HTTPS per la posizione del tuo webhook.
SSL/HTTPS
Se stai utilizzando segreti del webhook ma il traffico è su HTTP, i segreti del webhook potrebbero essere rubati. Abilita SSL/HTTPS utilizzando i flag --ssl-cert-file
e --ssl-key-file
.
Abilita l'Autenticazione sul Server Web di Atlantis
È molto consigliabile abilitare l'autenticazione nel servizio web. Abilita BasicAuth utilizzando --web-basic-auth=true
e configura un nome utente e una password utilizzando i flag --web-username=yourUsername
e --web-password=yourPassword
.
Puoi anche passare queste come variabili d'ambiente ATLANTIS_WEB_BASIC_AUTH=true
ATLANTIS_WEB_USERNAME=yourUsername
e ATLANTIS_WEB_PASSWORD=yourPassword
.
Riferimenti
Last updated