Kritische Schwachstelle zur Ausführung beliebigen Codes in Kubernetes entdeckt

Am 3. Dezember 2018 wurde eine schwerwiegende Schwachstelle offengelegt, die in der Kubernetes-Community für Aufsehen sorgte: Es war die erste kritische CVE im Kubernetes-Projekt (gemessen am CVSS-v3-Score).

Gepatchte Versionen wurden veröffentlicht und für Endnutzer und Cloud-Anbieter bereitgestellt. Aktualisieren Sie auf eine Version mit Fehlerbehebung, falls Sie das noch nicht getan haben. Wir empfehlen folgende gepatchte Releases: v1.10.11, v1.11.5, v1.12.3 und v1.13.0-rc.1. Falls ein Upgrade nicht möglich ist, wurden im erwähnten GitHub-Issue von Jordan Liggitt aus dem Kubernetes-Projekt weitere Workarounds und Maßnahmen zur Risikominderung vorgeschlagen.

Die kritische Schwachstelle mit der Kennung CVE-2018-1002105 wurde von Darren Shepherd von Rancher entdeckt. Sie ermöglicht es Angreifern, aus der Ferne auf Backend-Dienste im Kubernetes-Cluster zuzugreifen und beliebige Befehle auf ihnen auszuführen. Dadurch können Angreifer möglicherweise ihre Berechtigungen ausweiten.

Der Angriff wird durch eine Schwachstelle im kubelet-API-Dienst ermöglicht, einer von vielen Komponenten des Kubernetes-Projekts.

Der kubelet-API-Dienst ist ein von Kubernetes bereitgestelltes Gateway, über das sich Backend-Dienste, auch aggregierte API-Server genannt, registrieren können. Anfragen an diese Server, beispielsweise API-Aufrufe an /apis/<apiGroup>/<apiVersion>, werden daher über den kubelet-API-Dienst an das Ziel des aggregierten API-Servers innerhalb des Kubernetes-Clusters weitergeleitet.

Ein Beispiel für einen aggregierten API-Server ist ein Integritätsprüfungsdienst für Load Balancer, der interne Backend-Server nach ihrem Status abfragt. Ein weiteres Beispiel ist der integrierte Metrikdienst von Kubernetes.

Die Schwachstelle

Um die Schwachstelle auszunutzen, muss ein Nutzer Zugriff auf den kubelet-API-Dienst haben, der als kube-apiserver bezeichnet wird. Dadurch können Angreifer ihre Berechtigungen ausweiten und weitere Zugriffskontrollen erlangen.

Die Schwachstelle entsteht durch die Art und Weise, wie der kube-apiserver Anfragen an die internen Backend-Server im Cluster weiterleitet. Dadurch wird ein direkter Tunnel zwischen den Backend-Servern und dem Nutzer geöffnet. Genauer gesagt geschieht dies bei der Verarbeitung von Anfragen zur Verbindungsaktualisierung, die für die WebSocket-Kommunikation relevant sind. Die so entstehende offene TCP-Verbindung zwischen Client und Backend-Server kann anschließend für beliebige Anfragen direkt an diesen Server genutzt werden.

Normalerweise wird dieser kubelet-API-Dienst für alle außerhalb des Clusters blockiert. Standardmäßig ist der Zugriff auf diese API jedoch für anonyme Nutzer aktiviert, um Diensterkennung und Integritätsprüfungen zu ermöglichen.

Ein weiterer Angriffsvektor besteht darin, dass ein für Nutzer zugänglicher Dienst mit dem kubelet-API-Dienst so interagieren kann, dass ein Angreifer aus der Ferne die Kontrolle über diese Interaktion übernimmt. So entsteht ein Weg, die Verbindung zum kubelet zu manipulieren und die Schwachstelle auf ähnliche Weise auszunutzen.

Interessanterweise ist dies nicht der erste Vorfall im Zusammenhang mit kube-apiserver. Eine im März veröffentlichte Analyse zeigte, wie ein öffentlich zugänglicher kube-apiserver zu Malware für das Mining von Kryptowährungen in einem Kubernetes-Cluster führte. Auch Teslas Cloud-Infrastruktur wurde Opfer eines ähnlichen Angriffs auf Kryptowährungen, der durch eine unsichere Kubernetes-Administrationskonsole ermöglicht wurde. Dennoch ist diese aktuelle Schwachstelle die schwerwiegendste, die dem Product Security Team von Kubernetes bislang gemeldet wurde.

Das Sicherheitsteam von Snyk hat die Schwachstelle am 5. Dezember 2018 in unsere Datenbank aufgenommen.

Die wichtigsten Erkenntnisse:

• Unsichere Standardeinstellungen – Sowohl authentifizierte als auch nicht authentifizierte Nutzer dürfen die Kubernetes-API abfragen.

• Unzureichende Protokollierung – Böswillige oder verdächtige Aktivitäten erfolgten über eine bestehende API-Verbindung. Deshalb wurden die tatsächlichen Aktivitäten nicht in den Kubernetes-Protokollen erfasst, sondern nur der ursprüngliche API-Aufruf.

So schützen Sie sich

Im Juni haben wir unsere entwicklerfreundliche Docker-Image-Scanning-Lösung vorgestellt. Damit können Sie erkennen, ob Ihre Images eine der in diesem Beitrag genannten Schwachstellen oder weitere Sicherheitslücken enthalten. Außerdem gibt Snyk Empfehlungen zur Behebung und schlägt Basis-Images mit weniger Schwachstellen vor, mit denen Sie auch diese spezifische Schwachstelle eindämmen können.

Falls Sie es noch nicht ausprobiert haben, können Sie Ihre Projekte mit Dockerfiles testen. Wir beginnen dann mit dem Scannen und Überwachen dieser Projekte auf anfällige Pakete, die im Betriebssystem-Basis-Image installiert sind.