Nicht aufzuhalten: Auf der Suche nach einer Command-Injection-Schwachstelle in Kubernetes
Redaktion und weitere Kommentare von Tricia Howard
Zusammenfassung
Tomer Peled, ein Sicherheitsforscher von Akamai, hat vor kurzem eine gravierende Schwachstelle in Kubernetes entdeckt, der die CVE-Nummer CVE-2023-3676 mit einem CVSS-Score von 8,8 zugewiesen wurde.
Diese Entdeckung führte zur Identifizierung von zwei weiteren Schwachstellen, die auf die gleiche Ursache zurückzuführen sind: unsicherer Funktionsaufruf und unzureichende Bereinigung von Nutzereingaben.
Die Schwachstelle ermöglicht die Remoteausführung von Code mit SYSTEM-Berechtigungen auf allen Windows-Endgeräten innerhalb eines Kubernetes-Clusters. Zur Ausnutzung dieser Schwachstelle muss der Angreifer eine schädliche YAML-Datei auf dem Cluster anwenden.
Diese Schwachstelle kann auf Standardinstallationen von Kubernetes ausgenutzt werden und wurde sowohl bei On-Premise-Bereitstellungen als auch beim Azure Kubernetes Service getestet.
Wir bieten eine Proof-of-Concept- YAML-Datei sowie eine OPA-Regel zur Blockierung dieser Schwachstelle.
Einführung
YAML (Akronym für YAML Ain‘t Markup Language) ist eine maschinenlesbare Sprache zur Datenserialisierung, die Ähnlichkeiten zu JSON aufweist und hauptsächlich in Konfigurationsdateien verwendet wird. Als solche spielt sie eine große Rolle bei Kubernetes, dem neuen und vielseitigen Container-Orchestrierungssystem, das Unternehmen bei der Automatisierung der Bereitstellung, Skalierung und Verwaltung von containerisierten Anwendungen unterstützt. 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.
YAML-Dateien in Kubernetes wurden in den letzten Jahren intensiv erforscht. Da Kubernetes bei der Clusterkonfiguration auf YAML setzt, ist eine vertiefende Befassung mit diesem Thema besonders interessant.
Wie wurden YAML und Kubernetes bereits ausgenutzt?
2022 wurde CVE-2022-1471 im Konstruktor von SnakeYAML gefunden, einem bekannten Parser für YAML-Dateien. Die Schwachstelle ermöglichte die Erstellung unsicherer Objekte, was eine Ausführung von Code auf anfälligen Anwendungen zur Folge haben kann, welche diese verwenden. Ein weiteres Beispiel, das die möglichen Auswirkungen von YAML-Dateien illustriert, ist die CVE-Empfehlung zu CVE-2021-25749, die vom Kubernetes-Sicherheitsteam erstellt wurde. Diese Schwachstelle ermöglicht Angreifern, die Verifizierung von Root-Berechtigungen, indem der Name in der YAML-Datei falsch geschrieben wird.
Im Rahmen unserer Recherchen zu Kubernetes sind wir auf CVE-2017-1002101 und CVE-2021-25741gestoßen. Diese Schwachstellen haben gezeigt, wie Angreifer Race-Bedingungen und Symlinks in Verbindung mit der subPath Untereigenschaft in einer YAML-Datei nutzen können, um Zugriff auf privilegierte Daten außerhalb des Containers zu erhalten.
Diese früheren Schwachstellen haben uns dazu veranlasst, die Richtung der Pfadverarbeitung in der Codebasis von Kubernetes zu verfolgen, was schließlich zur Entdeckung der Schwachstelle führte, die unser heutiges Thema bildet.
In diesem Blogbeitrag zeigen wir, wie ein Angreifer mit „apply“-Berechtigungen – den Berechtigungen, die für die Interaktion mit der Kubernetes-API erforderlich sind – Code injizieren kann, der auf Windows-Remotegeräten mit SYSTEM-Berechtigungen ausgeführt wird.
Schwachstellendetails
Wenn ein Pod erstellt wird, hat der Nutzer die Möglichkeit, ein freigegebenes Verzeichnis zwischen Pod und Host zu erstellen. Diese Funktion – auch als „volumes“ bezeichnet – ist nützlich, wenn Websites über einen Container in einem Pod bereitgestellt werden. Beispielsweise kann es wünschenswert sein, die Websitedateien über ein mit dem Host geteiltes Verzeichnis freizugeben. Auf diese Weise lässt sich das Standortlayout wie gewünscht ändern, ohne dass jedes Mal das Image neu kompiliert werden muss, welches die Website enthält.
Die Aktivierung von volumes erfolgt durch Aufnahme des Parameters „volume“ in die YAML-Datei des Pods. Die Speicherorte zum Einhängen des volume sind in mountPath (dem Speicherort im Container) und in hostPath (dem Speicherort auf dem Host) aufgeführt.
Der wichtigste Vorteil ist,dass das/die freigegebene Verzeichnis/Datei mithilfe der Untereigenschaft „subPath“ an einem ausgewählten Speicherort eingehängt werden kann. Alle relevanten Eigenschaften für volumes sind in Abbildung 1 dargestellt.
Abb. 1: YAML-volume-Konfiguration
Das Parsen der YAML-Datei erfolgt durch kubelet – einen zentralen Service in Kubernetes, der für die Ausführung der containerisierten Anwendungen auf einem Knoten verantwortlich ist. Als Teil des Patches für CVE-2021-25741 validiert kubelet jeden Parameter in der YAML-Datei und stellt außerdem sicher, dass in Folge der Verwendung des subPath-Parameters keine Symlinks durch Aufruf der integrierten Funktion „isLinkPath“ erstellt werden. Die Funktion ist in Abbildung 2 dargestellt.
Abb. 2: subPath-Funktion zum Prüfen von symlink-Pfaden
Die Funktion verwendet den durch den Nutzer in der YAML-Datei bereitgestellten subPath als Parameter. Dieser Pfad wird dann verwendet, um einen PowerShell-Befehl zu erstellen, mit dem der Pfadtyp bestimmt werden soll (d. h. ob es sich um einen Symlink handelt oder nicht). Der formatierte PowerShell-Befehl wird dann sofort durch den Funktionsaufruf „exec.Command“ aufgerufen.
Das Vorhandensein von „exec.Command“ in Verbindung mit nicht bereinigtem, durch den Nutzer bereitgestellten Input ist ein deutlicher Hinweis auf eine mögliche Befehlsinjektion.
PowerShell ermöglicht Nutzern die Beurteilung von Werten in Zeichenfolgen, bevor sie verwendet werden. Dies ist möglich durch Hinzufügen von $(<experssion_to_be_evaluated>) zu Ihrer Zeichenfolge, zum Beispiel (Abbildung 3).
PS> echo “the value of 1+1 is $(1+1)
Output:
the value of 1+1 is 2
Abb. 3: Beispiel für die Auswertung von Ausdrücken in Zeichenfolgen durch PowerShell
Dies ist ein recht einfaches Beispiel, tatsächlich können jedoch beliebige PowerShell-Befehle zwischen den Klammern eingefügt und ausgewertet werden, wie z. B. $(Start-Process cmd), $(Invoke-Expression exp) sowie weitere PowerShell-Verfahren.
Ein Angreifer kann diese subPath-Auswertung missbrauchen, um auf den anfälligen Code zuzugreifen und beliebige Befehle mit SYSTEM-Berechtigungen (eigener Kontext von kubelet) über Remote-Knotenauszuführen und so die Kontrolle über alle Windows-Knoten im Cluster zu erlangen. Abbildung 4 zeigt einen schädlichen subPath-Wert.
Abb. 4: YAML-Datei mit Befehlsinjektion innerhalb des subPath-Parameters
Proof-of-Concept zur Demonstration von CVE-2023-3676
Beim Proof of Concept handelt es sich um eine einfache YAML-Datei , die die Auswertung des PowerShell-Befehls enthält. Sie finden diese Datei sowie ein Video , das den Terminal veranschaulicht, der gestartet wird, in unserem GitHub-Repository.
Diese CVE führte zur Erkennung und Behebung von weiteren Command-Injection-Schwachstellen. Diese wurden zusammenfassend mit den Nummern CVE-2023-3955 und CVE-2023-3893 versehen.
Patch-Analyse
Das Kubernetes-Team entschied sich für das Patchen dieser Schwachstellenklasse durch Weitergabe von Parametern aus Umgebungsvariablen anstelle von Nutzereingaben (Abbildung 5). Bei einer Weitergabe von Werten auf diese Weise werden die Parameter als Zeichenfolgen behandelt und daher von PowerShell nicht als Ausdrücke ausgewertet.
Abb. 5: Gepatchte Funktion für CVE-2023-3676
Besteht für mich ein Risiko?
Wie bereits erwähnt, sind alle Kubernetes-Versionen vor 1.28 anfällig für diese CVE. Es gibt mehrere Methoden, mit denen ermittelt werden kann, ob einer der Knoten in Ihrem Cluster ein Windows-Knoten ist. Eine Methode ist die Ausführung des Befehls in Abbildung 6.
kubectl get nodes -o wide --show-labels | grep “os=windows” Ausgabe: akswin000000 Ready agent 4d17h v1.26.6 agentpool=win,beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=windows… akswin000001 Ready agent 4d17h v1.26.6 agentpool=win,beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=windows… |
Abb. 6: Ein kubectl-Befehl, mit dem ermittelt wird, ob einer der Knoten in Ihrem Cluster ein Windows-Knoten ist
Abwehr
Patching ist die zuverlässigste Methode für Sie, um sich vor dieser Schwachstelle zu schützen. In Fällen, in denen das Patching nicht möglich ist, haben wir eine Reihe von Möglichkeiten zum Schutz vor dieser Schwachstelle vorgestellt. Sie können die Lösung auswählen, die am besten zu Ihrer Umgebung passt.
Frühere Lösungen
Für CVE-2023-3676 können Kubernetes-Administratoren die Verwendung von Volume.Subpathdeaktivieren. Dadurch wird sichergestellt, dass Ihr Cluster vor dieser Schwachstelle geschützt ist, aber es wird ein Mechanismus deaktiviert, der manchmal für Cluster in der Produktion wichtig ist.
OPA
Open Policy Agent (OPA) ist ein Open-Source-Agent, mit dem Nutzer Daten über an Knoten ein- und ausgehenden Traffic erhalten und richtlinienbasierte Aktionen bei empfangenen Daten ausführen können. OPA verwendet Rego als Sprache für seine Engine, mit der Administratoren Regeln erstellen können, um die Implementierung bestimmter YAML-Dateien zu verhindern. Abbildung 7 zeigt eine Regel, die die Erstellung von Pods mit einem schädlichen subPath blockiert.
package kubernetes.admission
deny[msg] {
input.request.kind.kind == "Pod"
path := input.request.object.spec.containers.volumeMounts.subPath
not startswith(path, "$(")
msg := sprintf("malicious path: %v was found", [path])
}
Abb. 7: Eine Regel, die die Erstellung von Pods mit einem schädlichen subPath blockiert
RBAC
Die rollenbasierte Zugriffskontrolle (Role-Based Access Control – RBAC) ist eine Methode, mit der Nutzervorgänge nach Nutzern segmentiert werden. Beispielsweise kann jeder Nutzer Pods nur im eigenen Namespace erstellen oder nur Informationen für zulässige Namespaces anzeigen. Dies kann dazu beitragen, die Anzahl der Nutzer zu begrenzen, die Aktionen auf einem Cluster ausführen können, und die Aufmerksamkeit auf die Nutzer zu lenken, die über solche Berechtigungen verfügen, die sich missbrauchen lassen.
Fazit
Für CVE-2023-3676 sind nur geringe Berechtigungen erforderlich, weswegen es Angreifern leicht gemacht wird: Sie benötigen lediglich Zugriff auf einen Knoten und apply -Berechtigungen. Wie in diesem Blogbeitrag erläutert, führt die erfolgreiche Ausnutzung dieser Schwachstelle zur Ausführung von Remotecode auf jedem Windows-Knoten auf dem Computer mit SYSTEM-Berechtigungen.
Einfache Ausnutzung von Schwachstellen mit massiven Folgen bedeutet in der Regel, dass die Wahrscheinlichkeit eines solchen Angriffs (und ähnlicher Angriffe) auf Unternehmen höher ist. Der einzige einschränkende Faktor bei dieser Schwachstelle ist ihr Umfang – sie ist auf Windows-Knoten beschränkt, die aktuell nicht sehr weit verbreitet sind.
Es ist wichtig, dass Administratoren ihre Kubernetes-Cluster auf die neueste verfügbare Version patchen, um die Ausnutzung dieser Schwachstellen zu verhindern. Wenn das Patching nicht sofort verfügbar ist, empfehlen wir Ihnen, eine der oben beschriebenen Methoden zu verwenden, um sich vor dieser Schwachstelle zu schützen.
Wir möchten dem Kubernetes-Team für die schnelle Reaktion und die reibungslose Kommunikation danken.
Chronik der Veröffentlichung
13.07.2023: Schwachstelle wird dem Kubernetes-Team mitgeteilt.
19.07.2023: CVEs werden vom Kubernetes-Team zugewiesen.
23.08.2023: Kubernetes veröffentlicht die Problembehebungen für diese CVEs.
13.09.2023: Blogbeitrag wird veröffentlicht
