Atlantis Security
Last updated
Last updated
Lerne & übe AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Lerne & übe GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Atlantis hilft dir im Grunde, Terraform von Pull Requests von deinem Git-Server auszuführen.
Gehe zur Atlantis-Release-Seite in https://github.com/runatlantis/atlantis/releases und lade die passende Version herunter.
Erstelle ein persönliches Token (mit Repo-Zugriff) deines GitHub-Benutzers.
Führe ./atlantis testdrive aus und es wird ein Demo-Repo erstellt, das du verwenden kannst, um mit Atlantis zu kommunizieren.
Du kannst die Webseite unter 127.0.0.1:4141 aufrufen.
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 verwenden möglicherweise persönliche Konten.
In jedem Fall wird aus der Perspektive eines Angreifers das Atlantis-Konto eines der sehr interessanten Ziele sein.
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, die 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.
Atlantis führt Terraform aus, indem es einfach die terraform plan und apply Befehle 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 bereitstellst für deinen spezifischen Anbieter an Atlantis:
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")
Viele Benutzer setzen Umgebungsvariablen, z.B. AWS_ACCESS_KEY, wo Atlantis läuft.
Andere erstellen die notwendigen 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.
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).
Die Konfiguration für atlantis server kann über Befehlszeilen-Flags, Umgebungsvariablen, eine Konfigurationsdatei oder eine Mischung aus dreien angegeben werden.
Du kannst die Liste der unterstützten Flags für den Atlantis-Server hier finden.
Werte werden in dieser Reihenfolge ausgewählt:
Flags
Umgebungsvariablen
Konfigurationsdatei
Beachte, dass du in der Konfiguration interessante Werte wie Tokens und Passwörter finden könntest.
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, jede Repo zu spezifizieren. Dies ist die Prioritätsreihenfolge:
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.
Wahrscheinlich erforderlich, um durch Flags wie allowed_overrides oder allow_custom_workflows erlaubt zu werden.
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 wird unterstützt).
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 zusammenführbar (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, ermöglichen.
Conftest Richtlinienprüfung
Atlantis unterstützt das Ausführen 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 konfigurieren können, in den Dokumenten.
In den Dokumenten finden Sie die Optionen, die Sie verwenden können, um Atlantis auszuführen:
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:
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:
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:
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.
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:
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 Branch-Schutzumgehungen
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 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:
Folgen Sie den Vorschlägen aus der vorherigen Technik, um diesen Angriff auf eine diskretere Weise durchzuführen.
Wenn atlantis plan oder atlantis apply ausgeführt wird, wird Terraform im Hintergrund ausgeführt. Sie können Befehle an Terraform von Atlantis über Kommentare wie folgt übergeben:
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
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.
Wenn das Server-seitige Konfigurations Flag allowed_overrides konfiguriert ist, um apply_requirements zu verwenden, ist es möglich, dass ein Repo die Plan-/Anwendungs-Schutzmaßnahmen ändert, um sie zu umgehen.
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:
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 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 bestehen würde, auf Ihren eigenen Repos zu planen/anwenden.
Um dies zu verhindern, erlauben Sie nur Bitbucket-IP-Adressen (siehe ausgehende IPv4-Adressen).
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)
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.
--allow-fork-prsWenn 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-allowlistAtlantis 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.
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:
Anbieter in das Atlantis-Image einbacken oder hosten und den Ausgang im Produktionsumfeld verweigern.
Das Anbieter-Registry-Protokoll intern implementieren und öffentlichen Ausgang verweigern, sodass Sie kontrollieren, wer Schreibzugriff auf das Registry hat.
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. die Anforderung eines "Daumen hoch" auf dem PR, bevor Sie den plan fortsetzen. Conftest könnte hier nützlich sein.
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 unterstützt das Senden eines grundlegenden Authentifizierungs-Headers in allen Webhook-Ereignissen. Dies erfordert die Verwendung einer HTTPS-URL für Ihren Webhook-Standort.
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.
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.
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
