Sicherheitslücke ermöglicht Angreifern das Einbrechen von Kubernetes-Clustern

Cyber Security News

Die Sicherheitslücke wird ausgelöst, wenn ein Cloud-Container ein bösartiges Image aus einer Registry zieht.

Eine Schwachstelle in einer der Go-Bibliotheken, auf denen Kubernetes basiert, könnte zu Denial-of-Service (DoS) für die Container-Engines CRI-O und Podman führen.

Der Fehler (CVE-2021-20291) betrifft die Go-Bibliothek namens “containers/storage”. Laut Aviv Sasson, dem Sicherheitsforscher bei Palo Alto’s Unit 42 Team, der den Fehler gefunden hat, kann er ausgelöst werden, indem ein bösartiges Image in einer Registry platziert wird; die DoS-Bedingung wird erzeugt, wenn dieses Image von einem ahnungslosen Benutzer aus der Registry gezogen wird.

“Durch diese Schwachstelle könnten böswillige Akteure jede containerisierte Infrastruktur gefährden, die auf diesen anfälligen Container-Engines aufbaut, einschließlich Kubernetes und OpenShift”, sagte Sasson in einem Posting am Mittwoch.

CRI-O und Podman sind Container-Images, ähnlich wie Docker, die verwendet werden, um Aktionen auszuführen und Container in der Cloud zu verwalten. Die Container/Speicher-Bibliothek wird von CRI-O und Podman verwendet, um die Speicherung und den Download von Container-Images zu verwalten.

Wenn die Schwachstelle ausgelöst wird, kann CRI-O keine neuen Images ziehen, keine neuen Container starten (selbst wenn sie bereits gezogen wurden), keine lokalen Image-Listen abrufen oder Container beenden, so der Forscher.

Podman kann unterdessen keine neuen Images ziehen, keine laufenden Pods abrufen, keine neuen Container starten (selbst wenn sie bereits gezogen wurden), keine Execs in Containern ausführen, keine existierenden Images abrufen oder existierende Container killen, sagte er.

Die Auswirkungen könnten ziemlich weitreichend sein: “Ab Kubernetes v1.20 ist Docker veraltet und die einzigen unterstützten Container-Engines sind CRI-O und Containerd”, erklärte Sasson. “Das führt zu einer Situation, in der viele Cluster CRI-O verwenden und angreifbar sind. In einem Angriffsszenario könnte ein Angreifer ein bösartiges Image auf mehrere verschiedene Nodes ziehen, was alle zum Absturz bringt und den Cluster kaputt macht, ohne dass es eine andere Möglichkeit gibt, das Problem zu beheben, als die Nodes neu zu starten.”

Weaponizing Container Pulls

Wenn eine Container-Engine ein Image aus einer Registry zieht, lädt sie zuerst dessen Manifest herunter, das die Anweisungen enthält, wie das Image zu erstellen ist. Ein Teil davon ist eine Liste von Schichten, aus denen das Container-Dateisystem besteht, das die Container-Engine liest und dann jede Schicht herunterlädt und dekomprimiert.

“Ein Angreifer könnte eine bösartige Schicht in die Registry hochladen, die darauf abzielt, die Schwachstelle auszunutzen, und dann ein Image hochladen, das zahlreiche Schichten verwendet, einschließlich der bösartigen Schicht, und damit ein bösartiges Image erstellen”, erklärte Sasson. “Wenn das Opfer dann das Image aus der Registry abruft, lädt es dabei die bösartige Schicht herunter und die Schwachstelle wird ausgenutzt.”

Sobald die Container-Engine beginnt, die bösartige Schicht herunterzuladen, ist das Endergebnis ein Deadlock.

“[This] ist eine Situation, in der eine Sperre erworben und nie freigegeben wird”, erklärt Sasson. “Dies führt zu einem DoS, da andere Threads und Prozesse ihre Ausführung stoppen und ewig auf die Freigabe der Sperre warten.”

Er listete die Schritte auf, die passieren, wenn die Sicherheitslücke ausgelöst wird: Routine 1 – Lädt die bösartige Schicht aus einer Registrierung herunter. Routine 1 – Erwirbt eine Sperre. Routine 2 – Dekomprimiert die heruntergeladene Schicht mit dem xz-Binary und schreibt die Ausgabe nach stdout. Routine 3 – Wartet darauf, dass xz beendet wird und dass alle Daten in stdout gelesen werden. Wenn die Bedingungen erfüllt sind, fährt sie fort und schließt einen Kanal namens chdone. Routine 1 – Verwendet die Ausgabe von xz als Eingabe und versucht, die Daten zu entpacken. Da die Datei kein tar-Archiv ist, scheitert untar mit “invalid tar header” und beendet das Lesen der restlichen Daten aus dem stdout von xz nicht. Da die Daten nie gelesen werden, ist Routine 3 jetzt blockiert und wird chdone nie schließen. Routine 1 – Wartet darauf, dass Routine 3 chdone schließt und ist ebenfalls blockiert.

Sobald Routine 1 in eine Sackgasse geraten ist, kann die Container-Engine keine neuen Anfragen ausführen, da sie dazu die Sperre auf Schritt 2 erwerben muss, die niemals freigegeben wird.

Patches für den Fehler wurden in Version 1.28.1 von containers/storage; CRI-O Version v1.20.2; und Podman Version 3.1.0 veröffentlicht. Admins sollten so bald wie möglich aktualisieren.

Container-Sicherheit im Rampenlicht

Die Sicherheit von Cloud-Containern steht weiterhin im Fokus der Anwender – und der Cyberangreifer. So wurde Anfang April eine organisierte, sich selbst verbreitende Kryptomining-Kampagne aufgedeckt, die auf falsch konfigurierte, offene Docker Daemon API-Ports abzielte. Im Zusammenhang mit dieser Kampagne wurden täglich Tausende von Versuchen beobachtet, Container zu kompromittieren.

Ebenfalls im April wurde festgestellt, dass Microsofts Cloud-Container-Technologie Azure Functions eine Schwachstelle beherbergt, die es Angreifern erlaubt, direkt in Dateien zu schreiben, so die Forscher. Es handelt sich dabei um eine Schwachstelle zur Ausweitung von Privilegien, die es einem Benutzer letztendlich ermöglichen könnte, aus dem Container zu entkommen.

Und, in einem anschaulichen Beispiel, warum Cloud-Infrastruktur braucht starke Sicherheit, eine einfache Docker-Container-Honeypot wurde für vier verschiedene kriminelle Kampagnen in der Spanne von 24 Stunden verwendet, in einem aktuellen Labortest.

Haben Sie sich jemals gefragt, was in Untergrund-Cybercrime-Foren vor sich geht? Finden Sie es am 21. April um 14 Uhr ET während einer KOSTENLOSEN Threatpost-Veranstaltung mit dem Titel “Underground Markets: A Tour of the Dark Economy”. Experten von Digital Shadows (Austin Merritt), Malwarebytes (Adam Kujawa) und Sift (Kevin Lee) nehmen Sie mit auf eine geführte Tour durch das Dark Web, einschließlich der Frage, was zum Verkauf steht, wie viel es kostet, wie Hacker zusammenarbeiten und welche neuesten Tools für Hacker verfügbar sind. Registrieren Sie sich hier für die LIVE-Veranstaltung am Mittwoch, 21. April.

[Blocked Image: https://media.threatpost.com/wp-content/uploads/sites/103/2020/09/25104849/cloud-hack.jpg]

Einige Teile dieses Artikels stammen aus:
threatpost.com