Das Wiz Research Team hat kürzlich eine Lieferketten-Schwachstelle in der IBM Cloud entdeckt, die nach eigenen Angaben erstmals die Infrastruktur eines Cloud-Anbieters betrifft.
Mit dramatischem Flair nannten sie die Schwachstelle Hell’s Keychain.
Die Sicherheitsprobleme wurden IBM Cloud Ende August gemeldet und Anfang September behoben. Bevor die Schwachstelle behoben wurde, konnte ein Angreifer mit Kenntnis der Schwachstelle bösartigen Code ausführen und von jedem IBM-Cloud-Kunden gespeicherte Daten verändern, der PostgreSQL verwendete.
Ein Rezept für den Zugriff: verbotene Verbindung und Schlüsselbund-Geheimnisse
Die Wiz-Forscher – Ronen Shustin, Shir Tamari, Nir Ohfeld und Sagi Tzadik – schrieben in einem Blogbeitrag: „Unserer Erfahrung nach umfasst das Rezept für einen Angriff auf die Lieferkette eines Cloud-Service-Providers (CSP) zwei Zutaten: die verbotene Verbindung steht für den Netzwerkzugriff – genauer gesagt ist sie die Verbindung zwischen einer Produktionsumgebung und ihrer Build-Umgebung.“
Der Schlüsselbund, so erklärten sie, „symbolisiert die Sammlung eines oder mehrerer verstreuter Geheimnisse, die der Angreifer in der Zielumgebung findet. Obwohl beide Komponenten für sich genommen unhygienisch sind, bilden sie in Kombination eine tödliche Verbindung.“
Im Fall von Hell’s Keychain waren die drei Schlüsselbund-Geheimnisse ein Kubernetes-Service-Account-Token, ein Passwort für eine private Container-Registry und Zugangsdaten für einen CI/CD-Server. Die verbotene Verbindung verknüpfte eine persönliche PostgreSQL-Instanz mit der Build-Umgebung von IBM Cloud Databases.
Auch lesenswert:
- Leitfaden zur Sicherheit von Software-Lieferketten für Entwickler
- Wie Hacker die Software-Lieferkette kompromittieren
SQL-Injection und das Auslesen von Container-Registries
Die Forscher entdeckten zunächst eine SQL-Injection-Schwachstelle, über die sie beliebige Befehle auf der zugrunde liegenden virtuellen Maschine ausführen konnten, auf der ihre Datenbankinstanz gehostet wurde. Diese nutzten sie, um die interne Umgebung zu kartieren und nach neuen Angriffsflächen zu suchen.
Ihre Aktionen lösten eine Warnung beim Sicherheitsteam von IBM Cloud aus, das ihnen schließlich die Erlaubnis gab, ihre Forschung fortzusetzen.
Bei der Untersuchung der Umgebung fanden sie ein Kubernetes-API-Token, mit dem sie auf die Kubernetes-API zugriffen und eine Liste weiterer Pods mit PostgreSQL-Instanzen einsehen konnten. Anschließend nutzten sie das Auslesen von Container-Registries, um vier Zugangsdaten zu finden, mit denen sich auf mehrere Container-Registries zugreifen ließ.
„Unsere Abfrage der IAM-API von IBM Cloud ergab, dass es sich um einen API-Schlüssel handelte, der auf die Container-Registry-Images von IBM Cloud zugreifen konnte und offenbar über Lese- und Schreibberechtigungen verfügte! Anschließend verwendeten wir die ibmcloud-cli, um uns mit diesem Schlüssel bei der spezifischen Container-Registry anzumelden“, schrieben sie.
Es stellte sich zwar heraus, dass die Beschreibung des Schlüssels unzutreffend war – sie konnten nicht in die Container-Registry schreiben –, doch sie stuften ihre Erkenntnisse weiterhin als gravierend ein. „Hätte ein böswilliger Akteur diese Zugangsdaten erlangt, hätte er Hunderte von Images der verwalteten Datenbankdienste von IBM Cloud abrufen und untersuchen können“, schrieben sie.
Auch lesenswert: So verhindern Sie SQL-Injection-Angriffe
Netzwerkzugriff auf die Build-Server von IBM Cloud
Die Forscher untersuchten die Container-Images, auf die sie Zugriff hatten, und fanden mehrere sensible Geheimnisse in übersehenen Dateien, darunter FTP-Zugangsdaten und Zugangsdaten für interne Artefakt-Repositories der internen Dienste von IBM Cloud.
Anschließend untersuchten sie die historischen Befehle, mit denen das Image des Containers erstellt worden war, um herauszufinden, welche Artefakte beteiligt waren. „Als wir versuchten, von der Maschine, auf der die PostgreSQL-Instanz gehostet wurde, auf diese Server zuzugreifen, waren wir schockiert, als wir feststellten, dass wir Netzwerkzugriff auf interne Build-Server von IBM Cloud hatten! Anschließend authentifizierten wir uns mit den Zugangsdaten für das Artefakt-Repository bei ihnen und legten dadurch erfolgreich die verbotene Verbindung offen“, schrieben sie.
Schließlich testeten sie ihre Berechtigungen, indem sie Dateien in den Repositories erstellten, die beim Build-Prozess des PostgreSQL-Images verwendet wurden. „Damit war bewiesen, dass wir beliebige Dateien in den Paketen überschreiben konnten, die auf jeder PostgreSQL-Instanz installiert worden wären – und damit war der Weg für den Lieferkettenangriff etabliert“, schrieben sie.
Lehren aus dem Vorfall
Die Wiz-Forscher erklärten, Hell’s Keychain „veranschaulicht, wie verstreute Zugangsdaten im Klartext in Ihrer Umgebung ein enormes Risiko für Ihr Unternehmen darstellen können, indem sie dessen Integrität und Mandantentrennung beeinträchtigen. Darüber hinaus unterstreicht die Schwachstelle die Notwendigkeit strenger Netzwerk-Kontrollen und zeigt, dass der Pod-Zugriff auf die Kubernetes-API eine häufige Fehlkonfiguration ist, die zu einer uneingeschränkten Offenlegung und zum Auslesen von Container-Registries führen kann.“
Nach Ansicht der Forscher lassen sich aus ihren Erkenntnissen drei zentrale Lehren ziehen:
- Überwachen Sie Ihre Umgebung kontinuierlich auf verstreute Geheimnisse
- Stellen Sie sicher, dass Ihre Produktionsumgebung strengen Netzwerk-Kontrollen unterliegt
- Konfigurieren Sie Ihre Container-Registry so, dass böswillige Akteure sie nicht auslesen können
„IBM Cloud hat die von uns entdeckten Schwachstellen und Sicherheitsprobleme umgehend untersucht und behoben“, schrieben sie. „Die Zusammenarbeit mit dem Sicherheitsteam von IBM Cloud hat uns sehr gefallen. Es nahm die Probleme äußerst ernst und behob sie schnell und professionell.“
Weiterführende Literatur: