Technische Unterstützung
Dokumentation
Anmeldung
Kontakt
Kritische Kubernetes-Schwachstellen: Informiert bleiben
Wajahat Raja
27. September 2023. TuxCare-Expertenteam
In der sich ständig verändernden Landschaft der Cybersicherheit ist Wachsamkeit von entscheidender Bedeutung, insbesondere wenn es um komplizierte und häufig verwendete Systeme wie Kubernetes geht. Ein Trio von wurde gerade ein Trio hochgradiger Sicherheitslücken entdeckt, die eine erhebliche Bedrohung für Kubernetes-Umgebungen darstellen. Während diese Kubernetes-Schwachstellen Kubernetes-Schwachstellen in erster Linie Windows-Endpunkte innerhalb eines Kubernetes-Clusters betreffen, gehen ihre potenziellen Auswirkungen über Windows-Systeme hinaus und unterstreichen die Bedeutung von robuster plattformübergreifender Sicherheits Maßnahmen in der Linux-zentrierten Welt.
Das CVE-Trio: CVE-2023-3676, CVE-2023-3893, und CVE-2023-3955
Die Die CVSS-Punktzahl für diese drei Schwachstellen, CVE-2023-3676, CVE-2023-3893 und CVE-2023-3955, beträgt 8,8. Sie haben die Möglichkeit, Remotecode mit erhöhten Rechten innerhalb eines Kubernetes-Clusters auszuführen. Wichtig ist, dass diese Schwachstellen alle Kubernetes-Systeme mit Windows-Knoten betreffen.
Akamai hat diese Sicherheitsrisiken verantwortungsbewusst offengelegt Kubernetes-Sicherheitsrisiken auf 13. Juli 2023und löste damit eine schnelle Reaktion der Kubernetes-Community aus. Am 23. August 2023 wurden Korrekturen veröffentlicht, die die Bedeutung der Zusammenarbeit im Bereich der Open-Source-Software unterstreichen.
Auspacken der Kubernetes-Schwachstellen
Die Schwachstellen stehen im Zusammenhang mit der Manipulation von YAML-Dateien, einer in Kubernetes weit verbreiteten Konfigurationssprache zur Verwaltung der Container-Laufzeitsicherheit in Anwendungen. Die Möglichkeit, diese Schwachstellen auszunutzen, ergibt sich aus der direkten Verbindung von YAML-Dateien und der Kubernetes-Engine.
Bemerkenswert, YAML-Parsing-Schwachstellen haben bereits rote Fahnen in Kubernetes Sicherheitsupdates. CVE-2022-1471 beispielsweise deckte eine Schwachstelle in der Remotecodeausführung im SnakeYaml-Parser auf, die den Kubernetes-Java-Client betraf. CVE-2021-25749 ermöglichte auch die Aufnahme von falsch geschriebenen Benutzernamen in YAML-Dateien, was zur Ausführung von Arbeitslasten mit root führte.
Die Unterpfad-Untereigenschaftssaga
Die Schwachstellen, über die wir heute sprechen, gehen auf frühere Probleme mit der Subproperty "subPath" in YAML-Dateien zurück. Mit der Eigenschaft "volume" ermöglicht Kubernetes das Einbinden eines Verzeichnisses vom Hostsystem in einen Container, eine Fähigkeit, die im Kubernetes-Ökosystem häufig genutzt wird. Diese Funktion hat zahlreiche Untereigenschaften, von denen "subPath" eine ist. Wenn "subPath" in einer YAML-Datei angegeben wird, wird sie von kubelet, einem wichtigen Kubernetes-Dienst, verarbeitet.
PowerShell-Feinheiten
Die Wurzel dieser Fehler liegt darin, wie Kubernetes die Zeichenkette "subPath" behandelt. Während der Verarbeitung bestimmt Kubelet, ob es sich um einen Symlink handelt. Dieser Schutz wird jedoch über einen PowerShell-Befehl implementiert, der durch den Funktionsaufruf "exec.Command" aufgerufen wird. Dies öffnet Angreifern Tür und Tor, um PowerShell-Code an den "subPath"-String anzuhängen, der dann ausgeführt wird.
Die Fähigkeit von PowerShell, Werte in Zeichenketten vor der Verwendung zu bewerten, ermöglicht es Angreifern, auf einfache Weise bösartige Befehle einzuführen. So kann ein Angreifer beispielsweise eine YAML-Datei mit einem "subPath" bereitstellen, der "$(Start-Process cmd)" enthält. Während der Pfadvalidierung sendet kubelet diesen Befehl an die PowerShell, wo er mit den Rechten des kubelet-Dienstes, insbesondere der SYSTEM-Ebene, ausgeführt wird.
Ausweitung des Anwendungsbereichs von CVE-2023-3676
Die Sicherheitslücke, die dieser Debatte zugrunde liegt, CVE-2023-3676wurde in Kubernetes 1.28 behoben. Die Kubernetes-Schwachstellenbewertungführte jedoch zur Offenlegung von zwei weiteren Schwachstellen durch Befehlsinjektion: CVE-2023-3955 und CVE-2023-3893. Diese Schwachstellen betreffen zwar hauptsächlich Kubernetes unter Windows in seiner
Standardkonfiguration betreffen, ist es wichtig, daran zu denken, dass Angreifer immer noch Anwendungsprivilegien auf einem Knoten erlangen müssen.
Kubernetes Exploit-Prävention
Um diese Schwachstellen zu beseitigen, sind proaktive Maßnahmen erforderlich. Die DevSecOps für Kubernetes hat sich dafür entschieden, diese Art von Schwachstellen zu beheben, indem es von Parametern, die auf Benutzereingaben basieren, zu Umgebungsvariablen wechselt. Durch diese Änderung wird sichergestellt, dass Parameter nur als Zeichenketten verarbeitet werden, sodass sie nicht als PowerShell-Ausdrücke ausgewertet werden können.
Im Zusammenhang mit Kubernetes-Patch-VerwaltungWenn eine sofortige Aktualisierung auf die gepatchte Version nicht möglich ist, haben Administratoren verschiedene Möglichkeiten. Sie können die Verwendung von "Volume.Subpath" unterbinden, was jedoch Auswirkungen auf eine regelmäßig verwendete Funktion hat. Eine weitere Option ist die Verwendung des Open Policy Agent (OPA), eines Open-Source-Agenten, der richtlinienbasierte Aktivitäten durchführen kann. Administratoren können in der OPA-eigenen Rego-Sprache Regeln schreiben, um die Ausführung bestimmter YAML-Dateien zu verhindern. Container-Image-Scanning kann auch zur Identifizierung von Schwachstellen verwendet werden.
Darüber hinaus sollte eine rollenbasierte Zugriffskontrolle (RBAC) eingesetzt werden, um die Anzahl der Benutzer zu begrenzen, die berechtigt sind, Operationen innerhalb eines Kubernetes-Clusters durchzuführen. Diese umfassende Strategie verbessert die Sicherheit und reduziert gleichzeitig potenzielle Angriffswege.
Schlussfolgerung
Wachsamkeit und proaktive Sicherheitsmaßnahmen sind in der Kubernetes-Welt von entscheidender Bedeutung. Während CVEs in Kubernetes (CVE-2023-3676, CVE-2023-3893 und CVE-2023-3955) hauptsächlich Windows-Endpunkte innerhalb eines Kubernetes-Clusters betreffen, sind die Auswirkungen weitreichend. Da Kubernetes-Cluster miteinander verbunden sind, kann die Kompromittierung eines einzelnen Knotens, selbst wenn er unter Windows läuft, Auswirkungen auf die gesamte Konfiguration und Sicherheit des Clusters haben.
Je mehr wir uns in der komplexen Welt von Kubernetes und ihren Schwachstellen zurechtfinden, desto klarer wird, dass Kubernetes-Best-Practices unerlässlich sind, unabhängig von den beteiligten Plattformen. Es reicht nicht aus, einen Knoten in einer sich ständig verändernden digitalen Landschaft zu verteidigen, sondern es ist auch notwendig, die Kubernetes-Cluster-Sicherheit.
Zu den Quellen für diesen Beitrag gehören Artikel in den Hacker-Nachrichten und CSO.
