Problematische Git-Synchronisierung: Untersuchung von Command-Injection-Schwachstellen in Kubernetes
Zusammenfassung
Akamai-Forscher Tomer Peled hat einen Designfehler im Kubernetes-Nebenprojekt git-sync aufgedeckt, der Command Injection ermöglicht. Die Ergebnisse seiner Untersuchungen werden auf der DEF CON 2024 präsentiert.
Dieser Designfehler kann entweder zu Datenextraktion für beliebige Dateien im Pod (inklusive Servicekonto-Tokens) oder zur Befehlsausführung mit git_sync-Nutzerberechtigungen führen.
Um den Fehler auszunutzen, muss ein Angreifer lediglich eine YAML-Datei auf dem Cluster anwenden, ein Vorgang der lediglich eine geringe Berechtigungsstufe erfordert.
Diese Schwachstelle kann bei Standardinstallationen von Kubernetes auf allen Plattformen ausgenutzt werden (einschließlich Amazon Elastic Kubernetes Service (EKS), Azure Kubernetes Service (AKS) und Google Kubernetes Engine (GKE) sowie Linode).
In diesem Blogbeitrag stellen wir Ihnen eine PoC-YAML-Datei sowie Demos zur Verfügung, die die potenziellen Auswirkungen zeigen.
Da diesem Designfehler keine CVE zugewiesen wurde, gibt es keinen Patch dafür, und er kann nach wie vor ausgenutzt werden.
Das Kubernetes-Team hat uns dazu angeregt, diese Forschungsergebnisse zu teilen, um das Bewusstsein für diese Angriffsvektoren zu schärfen.
Einführung
Command-Injection-Schwachstellen sind für Kubernetes nichts neues. Allein im Jahr 2023 wurden sieben solcher Schwachstellen entdeckt, darunter mehrere, die wir selbst gefunden habenerforderlich. Bedenken bezüglich der Bereinigung von Eingaben haben uns dazu bewegt, uns etwas gründlicher mit zusätzlichen Angriffsvektoren zu befassen: Ist dieser Angriffsvektor spezifisch für das Hauptprojekt von Kubernetes oder ist er weiter verbreitet? Im Zusammenhang mit Kubernetes gibt es mehrere Nebenprojekte, in denen sich Schwachstellen verbergen können, einschließlich git-sync.
Das git-sync-Projekt ist dazu gedacht, einen Pod und ein git-Repository zu verbinden, um Änderungen automatisch mit dem jeweiligen Standort/Server zu synchronisieren, anstatt diese manuell über eine CI/CD-Lösung vorzunehmen. Nutzer können diese Funktion beispielsweise verwenden, um ihren nginx-Pod mit einem Repository zu verknüpfen, das die Dateien enthält, die sie über einen nginx-Pod offenlegen möchten.
In diesem Blogbeitrag werden wir die Details des Designfehlers, die Probleme im Kubernetes-Quellcode, die zu diesem Fehler geführt haben, und einige Abwehrmaßnahmen erläutern. Wir werden auch die Reaktion von Kubernetes auf unsere Erkenntnisse erörtern.
Informationen zum Angriffsvektor
Ein Blick auf die git-sync-Anwendungsseite zeigt, dass diese viele mögliche Konfigurationsparameter unterstützt, sodass Nutzer git-sync gemäß ihren Anforderungen anpassen können. Dies ermöglicht eine potenziell große Angriffsfläche, die von Angreifern ausgenutzt werden kann (Abbildung 1).
Abb. 1: Einige git-sync-Parameter
Das Kubernetes-Framework verwendet YAML-Dateien für praktisch alles – von der CNI-Konfiguration (Container Network Interface) über die Pod-Verwaltung bis hin zur diskreten Abwicklung. Eine Schwachstelle in YAML kann daher verheerende Folgen haben. In diesem Fall kann ein Pod erstellt werden, um git-sync für die Verbindung mit einem Remote-Repository (oder einem Angreifer) zu verwenden.
Abbildung 2 zeigt ein Beispiel für eine Konfigurations-YAML-Datei, die einen Pod mit git-sync bereitstellt.
Abb. 2: YAML-Konfigurationsdatei, die einen POD über git-sync bereitstellt
Die beiden Parameter, die am ehesten als potenzielle Angriffsvektoren in Frage kommen, waren GITSYNC_GIT und GITSYNC_PASSWORD.
Laut der offiziellen git-sync-Dokumentationist GITSYNC_PASSWORD_FILE „die Datei, aus der das Passwort oder das persönliche Zugriffstoken (siehe GitHub-Dokumentation), das für die git-Authentifizierung verwendet werden soll (siehe --username) gelesen wird.“Dies deutet auf die Möglichkeit einer Datenextraktion des „Zugriffstokens“ oder anderer Dateien auf dem Pod hin.
GITSYNC_GIT ist (ebenfalls laut offizieller Dokumentation)„der auszuführende git-Befehl (abhängig von der PATH-Suche, hauptsächlich für Testzwecke).“ Der Standardwert ist „git“, was bedeutet, dass eine Binärdatei ausgewählt werden kann, die anstelle von git ausgeführt und für die Codeausführung auf dem Cluster verwendet wird.
Vorgeschlagene Angriffskette
Unter Berücksichtigung der oben aufgeführten Informationen möchten wir unsere Theorien überprüfen. Wir gehen davon aus, dass es einige Angriffsvektoren gibt, die Angreifer ausnutzen können.
Unauffällige Codeausführung
Ein Angreifer mit geringen Berechtigungen (Berechtigungen zum Erstellen) auf dem Cluster oder Namespace kann eine schädliche YAML-Datei anwenden, die einen Pfad zu ihrer Binärdatei enthält, wodurch sie unter dem git-sync-Namen ausgeführt wird.
Die Binärdatei muss sich im Pod befinden, was auf verschiedene Arten möglich ist, z. B. über Kubernetes-Probes, Kubernetes-Volumesoder LOLBins, die im git-sync-Pod vorhanden sind (Abbildung 3).
Abb. 3: Beispiel für eine YAML-Datei mit LOLBins
Nach Anwenden der YAML-Datei übernimmt git-sync aus Sicht des Blue Teams die Kommunikation mit einem Remote-Server, weswegen die externe Kommunikation als vertrauenswürdig eingestuft wird. So können Angreifer neben der Befehlsausführung auch noch Sicherheitsmaßnahmen umgehen.
Abbildung 4 zeigt einen PoC für einen potenziellen Angriff, mit dem unter dem git-sync-Nutzer ein XMrig-Kryptominer gestartet wird.
Abb. 4: PoC des potenziellen XMRig-Kryptominers
Wenn ein Netzwerkadministrator jetzt vorhandene Pods und deren Kommunikation außerhalb des Unternehmensnetzwerks prüft, wird er höchstwahrscheinlich sehen, wie der git-sync-Nutzer mit einem externen Server kommuniziert.
Datenextraktion
Ein Angreifer mit Berechtigungen zum Bearbeiten kann eine git-sync-Bereitstellung bearbeiten, um den Parameter GITSYNC_PASSWORD_FILE zu ändern oder hinzuzufügen und auf eine beliebige Datei auf dem Pod zu verweisen. Dies führt dazu, dass git-sync die Datei als Authentifizierungsmethode bei der nächsten Verbindung mit dem git-Repository sendet.
Wenn der Angreifer auch den Speicherort des git-Repositorys ändert und einen Pseudo-Repository-Server einrichtet, sendet die nächste Bereitstellung des git-sync-Prozesses im Pod die Datei in den Parameter GITSYNC_PASSWORD_FILE vom Pod zu deren Computer. Es sind keine Einschränkungen für die Dateipfade oder Berechtigungen für GITSYNC_PASSWORD_FILEerforderlich.
Es fällt nicht schwer, sich eine Hochrisikoextraktion vorzustellen. Bedenken Sie Folgendes: Angreifer können diese Technik nutzen, um das Zugriffstoken des Pods abzurufen, wodurch sie unter dem Deckmantel des git-sync-Pods mit dem Cluster interagieren können (Abbildung 5).
Abb. 5: PoC eines potenziellen GITSYNC_PASSWORD_FILE-Angriffs
Veröffentlichung und Reaktion von Kubernetes
Wir haben unsere Erkenntnisse dem Kubernetes-Team erstmals im Dezember 2023 mitgeteilt. Nach einigen Gesprächen mit dem Kubernetes-Team wurde entschieden, dass das Bearbeiten von YAMLs als Vorgang mit hohen Berechtigungen gilt, sodass unsere Erkenntnisse keine Sicherheitsschwelle überschreiten. Aus unserer Sicht sind laterale Netzwerkbewegungen mit dieser Technik immer noch möglich, auch wenn für Bearbeitungsvorgänge an einem Pod besondere Berechtigungen erforderlich sind. Es gab auch Bedenken bezüglich des Verlusts von Integrität: Angreifer könnten Informationen stehlen, indem sie sich als legitime git-sync-Nutzer ausgeben.
Bezüglich GITSYNC_GIThat das Kubernetes-Team eingeräumt, dass für Aktionen dieser Art nur eine geringe Berechtigungsstufe erforderlich ist, war jedoch der Ansicht, dass Vorgänge mit geringen Berechtigungen nicht zu schädlichem Verhalten führen würden. Wir sind jedoch überzeugt, dass der von uns beschriebene Designfehler Angreifern ermöglicht, unter einer vorgetäuschten Identität Befehle auszuführen, und dass derartiges schädliches Verhalten bereits durch geringe Berechtigungen auf dem Cluster ermöglicht wird. Dieser Angriffsfluss ist besonders für Unternehmen gefährlich, die in ihrem Cluster eine vorab autorisierte git-sync-Kommunikation verwenden.
In beiden Fällen hat uns Kubernetes dazu angeregt, diese wichtigen Forschungsergebnisse online zu teilen, da dies „Administratoren daran erinnert, sorgfältig über die Oberfläche nachzudenken, die sie für Nutzer zugänglich machen“.
Abhilfemaßnahmen
Die in diesem Blogbeitrag beschriebenen Angriffstechniken werden vom Kubernetes-Team nicht als Schwachstellen angesehen. Daher wird es keinen Patch für sie geben. Um die Angriffsfläche zu reduzieren, empfehlen wir daher einige mögliche Abhilfemaßnahmen.
Erstens sollten Sie die Kommunikation, die das Unternehmen verlässt, strengstens überwachen – insbesondere Kommunikation von Kubernetes-Pods. Seien Sie besonders bei git-sync-Pods vorsichtig, wenn eine solche Granularität möglich ist.
Zweitens empfehlen wir, git-sync-Pods zu prüfen, um zu sehen, welchen Befehl sie ausführen. Dies ist mit folgendem Befehl möglich:
kubectl describe pod <git-sync-pod>
Wenn Sie diesen Befehl zum Beispiel auf dem in Abbildung 4 dargestellten Kryptominer ausführen, sehen Sie das –git-Argument, das bei Erkennung ein Warnsignal ausgelöst hätte, insbesondere wenn der Wert des Arguments nicht „git“ ist (Abbildung 6).
Abb. 6: Ausführung dieses Auditing-Befehls auf dem Kryptominer in Abbildung 4
Diese Prüfung ist eine gute allgemeine Sicherheitspraxis. Daher empfehlen wir, diesen Befehl auf allen Pods auszuführen, nicht nur auf git-sync-Pods.
Außerdem haben wir eine OPA-Regel erstellt, die einen der von uns vorgeschlagenen Angriffsvektoren erkennen kann, bei dem Angriffe die git-Binärdatei durch eine schädliche Payload ersetzen:
package kubernetes.admission
deny[msg] {
input.request.kind.kind == "<Deployment/Pod>"
path := input.request.object.spec.env.name
contains(path, "GITSYNC_GIT")
msg := sprintf("Gitsync binary parameter detected, possible payload alteration, verify new binary ", [path])
}
Fazit
In diesem Blogbeitrag haben wir zwei Angriffsvektoren im Kubernetes-Nebenprojekt git-sync aufgezeigt. Beide Vektoren sind auf eine mangelnde Bereinigung von Eingaben zurückzuführen, was die Notwendigkeit einer robusten Abwehr in Bezug auf die Bereinigung der Nutzereingaben unterstreicht. Diese Kubernetes-Bereigungsprobleme sind nicht spezifisch für git-sync, wie wir bereits zuvor erörtert haben.
Blue-Team-Mitglieder sollten bezüglich ungewöhnlichen Verhaltens der gitsync-Nutzer in ihrem Unternehmen wachsam sein. Wir sind davon überzeugt, dass diese Angriffsvektoren erhebliche Auswirkungen auf Unternehmen haben können. Daher ist es wichtig, darauf aufmerksam zu machen und Sicherheitsadministratoren bezüglich potenzieller Gefahren zu informieren.
Die Akamai Security Intelligence Group wird Bedrohungen wie diese weiterhin untersuchen und unsere Kunden und die Sicherheits-Community darüber informieren. Wenn Sie in Echtzeit Informationen zu unserer Arbeit erhalten möchten, folgen Sie uns auf X (ehemals Twitter).
Trotz unserer unterschiedlichen Bewertungen der Ergebnisse möchten wir dem Kubernetes-Team für seine Reaktion und den Austausch danken.
