Vorwurf: Microsoft patcht Azure (Synapse Pwnalytics-Schwachstelle) zu langsam und gefährdet die Cloud-Sicherheit

[English]Man hört ja gelegentlich "wir migrieren in die Cloud, zu Microsoft Azure, Office 365 etc., da stellt Microsoft sicher, dass gepatcht wird und Schwachstellen zeitnah geschlossen werden". Cloud-Nutzer sind aber auf Gedeih und Verderb auf den Goodwill und die Fähigkeiten Microsofts angewiesen. Und in Bezug auf zeitnahes Patchen von Schwachstellen sieht es mitunter düster aus, wie ein aktueller Fall zur Synapse Pwnalytics-Schwachstelle zeigt, den ich hier mal aufbereite.

Dass es mit dem Berichten von Schwachstellen oft hängt und Leute bei Bug-Bounty-Prämien oft hinten herunter fallen, ist bei Sicherheitsexperten bekannt. Folgender Tweet legt nahe, dass Firmen Bug-Bounty-Programme als Maulkorb missbrauchen, um Sicherheitslücken nicht öffentlich werden zu lassen, diese aber auch nicht schließen.

Dort wurde ein Sicherheitsforscher genötigt, seinen Github-Post über eine Schwachstelle wieder zu löschen, weil alle Bug Bounty-Einsendungen vertraulich sind, bis eine Freigabe erfolgt. Aber auch bei Microsoft läuft nicht alles rund – wie ich aus diversen Mails weiß, bei denen ich auf cc gesetzt wurde, wenn Leute Schwachstellen berichteten.

Der Azure Synapse Pwnalytics-Fall

Zum Juni 2022-Patchday am 14.6.2022 hat Microsoft auch Schwachstellen in Microsoft Azure geschlossen. Sicherheitsforscher Tzah Pahima hat das Ganze kurz auf Twitter aufgegriffen in mehreren Tweets aufgegriffen.

Er war in der Lage, auf die Passwörter von Tausenden von Unternehmen auf Azure zugreifen und Code auf ihren VMs ausführen. Dazu gehört auch der Zugriff auf Microsofts eigene Anmeldedaten.

Tenable kritisiert Vorgehen Microsofts

Sicherheitsanbieter Tenable hat den Fall nochmals aufgegriffen und kritisiert die zähe Behebung zweier schwerwiegender Sicherheitsschwachstellen in Microsofts Cloud-Umgebung (Microsoft Azure Synapse Pwnalytics). Denn seit dem 10. März hat Tenable Research versucht, mit Microsoft zusammenzuarbeiten, um zwei schwerwiegende Schwachstellen in der Infrastruktur von Azure Synapse Analytics zu beheben.

Was ist Synapse Analytics?

Synapse Analytics ist eine Plattform, die für maschinelles Lernen, Datenaggregation und andere Rechenanwendungen verwendet wird. Der Dienst ist derzeit in Microsofts Azure Bug Bounty-Programm unter den „High-Impact"-Szenarien aufgeführt. Microsoft erklärt, dass Produkte und Szenarien, die unter dieser Überschrift aufgeführt sind, "die höchsten potenziellen Auswirkungen auf die Sicherheit der Kunden haben".

Microsoft Azure Synapse Pwnalytics-Schwachstellen

Tenable Research hat zwei schwerwiegende Schwachstellen in der Infrastruktur entdeckt, auf der dieser Dienst läuft. Diese Schwachstellen ermöglichen es einem Benutzer, die Rechte des Root-Benutzers innerhalb der zugrundeliegenden virtuellen Apache Spark-Maschinen zu erweitern oder die Hosts-Datei aller Knoten in einem Apache Spark-Pool zu „vergiften".

Die Schlüssel, Geheimnisse und Dienste, auf die über diese Schwachstellen zugegriffen werden kann, ermöglichen bekanntermaßen weitere seitliche Bewegungen und die Kompromittierung von Microsoft-eigenen Infrastrukturen. Dies kann potenziell zur Kompromittierung von Daten anderer Kunden führen, wie in jüngster Zeit in mehreren anderen Fällen zu beobachten war, beispielsweise ChaosDB von Wiz und SynLapse von Orca. Microsoft hat jedoch behauptet, dass ein mandantenübergreifender Zugriff über diese Angriffsvektoren nicht möglich ist.

Tenable meldete diese Probleme am 10. März 2022 an Microsoft. Microsoft hat bereits am 30. April 2022 damit begonnen, einen Fix für das Problem der Privilegienerweiterung bereitzustellen. Tenable geht derzeit davon aus, dass das Problem in allen Regionen erfolgreich behoben wurde. Die Endanwender müssen nichts unternehmen, um sicherzustellen, dass ihre Umgebungen nicht mehr betroffen sind. Der Hosts-File-Poisoning-Angriff ist zum Zeitpunkt der Erstellung dieses Artikels noch nicht gepatcht. Aufgrund der Art dieser Schwachstellen und des Offenlegungsprozesses hat Tenable hierfür noch keine CVE-Referenznummern.

Zähe Bearbeitung durch Microsoft

Während des Offenlegungsprozesses schienen Vertreter von Microsoft zunächst zuzustimmen, dass es sich um kritische Probleme handelt. Microsoft entwickelte und implementierte einen Patch für die Privilegieneskalation ohne weitere Informationen von Tenable Research. In den letzten Tagen des Offenlegungsprozesses versuchte das Microsoft Security Response Center (MSRC), den Schweregrad des Problems der Privilegienerweiterung herunterzuspielen und stufte es als "Best Practice Recommendation" und nicht als Sicherheitsproblem ein.

Trotz eindeutiger gegenteiliger Beweise lehnte das MSRC ein Kopfgeld oder eine Anerkennung für diese Entdeckung ab. Nachdem Microsoft von Tenable informiert wurde, Informationen über die Schwachstellen zu veröffentlichen, revidierten Vertreter von Microsoft die vorherige Entscheidung und stuften diese Probleme als sicherheitsrelevant ein. Dies zeigt einen klaren Mangel an Kommunikation zwischen den beteiligten Teams bei Microsoft.

Diese Schwachstellen und die Interaktion der Tenable-Forscher mit Microsoft zeigen, wie schwierig es ist, sicherheitsrelevante Probleme in Cloud-Umgebungen anzugehen. Der gesamte Prozess entzieht sich weitgehend der Kontrolle des Kunden. Die Kunden sind bei der Behebung der gemeldeten Probleme vollständig auf die Cloud-Anbieter angewiesen. Die gute Nachricht ist jedoch, dass ein Problem, sobald es behoben ist, auch behoben ist. Die Kunden müssen in der Regel nichts unternehmen, da alles hinter den Kulissen abläuft. Die schlechte Nachricht ist jedoch, dass die Cloud-Anbieter nur selten darauf hinweisen, dass eine sicherheitsrelevante Schwachstelle überhaupt vorhanden war.

Ausführlichere Informationen über die Interaktionen mit Microsoft und die technischen Details dieser Schwachstellen finden Sie in diesem Beitrag auf dem Tenable TechBlog. In einem persönlichen Statement äußert sich auch Tenables CEO Amit Yoran zu den Vorgängen der vergangenen Woche und über die grundsätzliche Problematik von Schwachstellen in Cloud-Umgebungen der großen Anbieter.

Weitere Informationen

• TRA-2022-19: Microsoft Azure Synapse Analytics Hosts File Poisoning
• TRA-2022-20: Microsoft Azure Synapse Analytics Privilege Escalation

Nicht der einzige Bock in Azure

Bereits im März 2022 haben Sicherheitsforscher von Orca Security eine kritische Azure Automation-Schwachstelle (AutoWarp) in weniger als zwei Stunden identifiziert. AutoWarp ist eine kritische Schwachstelle im Azure-Automatisierungsdienst, die unbefugten Zugriff auf andere Azure-Kundenkonten ermöglicht, die diesen Dienst nutzen. Je nach den vom Kunden zugewiesenen Berechtigungen könnte dieser Angriff die vollständige Kontrolle über Ressourcen und Daten des Zielkontos bedeuten.

Microsoft Azure Automation

Microsoft Azure Automation ermöglicht es Unternehmen, Automatisierungscode auf verwaltete Weise auszuführen. Sie können Aufträge planen, Input und Output bereitstellen und vieles mehr. Der Automatisierungscode eines jeden Unternehmens wird in einer Sandbox ausgeführt, isoliert vom Code anderer Kunden, der auf derselben virtuellen Maschine ausgeführt wird.

Nachforschungen von Orca Security ergaben, dass mehrere große Unternehmen den Dienst nutzten und auf ihn hätten zugreifen können. Die AutoWarp-Schwachstelle hätte Schäden in Milliardenhöhe verursachen können. Orca hat die kritische Schwachstelle in Azure Automation direkt an Microsoft gemeldet, sie ist nun behoben, und alle betroffenen Kunden wurden benachrichtigt. „Wir möchten uns bei Yanir Tsarimi von Orca Security bedanken, der diese Sicherheitslücke gemeldet und mit dem Microsoft Security Response Center (MSRC) im Rahmen der Coordinated Vulnerability Disclosure (CVD) zusammengearbeitet hat, um die Sicherheit der Microsoft-Kunden zu gewährleisten", erklärt das Microsoft Security Response Center (MSRC). Vor der Behebung der Schwachstelle waren Unternehmen für AutoWarp anfällig, wenn sie den Azure-Automatisierungsdienst verwendet haben und die Funktion „Managed Identity" in ihrem Automatisierungskonto aktiviert ist (was standardmäßig der Fall ist).

Durch Zufall auf Schwachstelle gestoßen

Die Schwachstelle kam auf folgende Weise ans Tageslicht: Yanir Tsarimi, Cloud Security Researcher, bei Orca Security scrollte durch die Liste der Azure-Services auf der Suche nach seinem nächsten zu untersuchenden Service. Als er „Automation Accounts" unter der Kategorie „Management & Governance" sah, war er überrascht. Er dachte, es handele sich um einen Dienst, der es ermöglicht, Azure-Konten durch Automatisierung zu steuern. Nachdem er sein erstes Automatisierungskonto erstellt hatte, stellte er fest, dass Azure Automation ein standardmäßiger Dienst für Automatisierungsskripte ist. Benutzer können damit ihr Python- oder PowerShell-Skript zur Ausführung auf Azure hochladen.

Das Einrichten einer Reverse Shell mit Python war kein Problem. Als Tsarimi jedoch einige der üblichen Befehle wie „tasklist" ausführte, erhielt er eine Fehlermeldung, dass sie nicht gefunden wurden. Offenbar ist die Umgebungsvariable „PathExt", die dafür verantwortlich ist, welche Dateierweiterungen das Betriebssystem versuchen soll auszuführen, auf einen seltsamen Wert gesetzt. Normalerweise enthält sie die Dateierweiterung „.exe", aber nicht in diesem Fall. Nur „.CPL" war vorhanden, die Dateierweiterung für Elemente der Windows-Systemsteuerung. Selbst als er versuchte, mit „tasklist.exe" die laufenden Prozesse aufzulisten, erhielt er eine Meldung, die er noch nie gesehen hatte. Es sah so aus, als ob etwas nicht stimmen könnte.

Die ersten beiden Dinge, die Tsarimi auffielen, als er sich das Laufwerk C:\ ansah, waren die Verzeichnisse „Orchestrator" und „temp". Das Orchestrator-Verzeichnis enthielt eine Menge DLLs und EXEs. Er sah Dateinamen mit „sandbox" und verstand intuitiv, dass dieses Verzeichnis die Sandbox enthielt, in der er arbeitete. Das Temp-Verzeichnis enthielt ein weiteres Verzeichnis namens „diags" und eine „trace.log"-Datei.

Ein Blick in den Code von Azure Automation

Nachdem er die Dateien aus dem Orchestrator heruntergeladen hatte, startete er ILSpy (.NET Decompiler) und suchte nach dem Code für diesen „Asset Retrieval Web Service". Er sah sich die Methode zur Einrichtung der HTTP-Routen an, und ihm fiel auf, dass „/oauth2/token" und „/metadata/identity/oauth2/token" „MSIController" zugeordnet waren. MSI steht für „Managed Service Identity", was er interessant fand.

Eine gewisse Erfahrung in der Softwareentwicklung bei der Überprüfung des Quellcodes ist hierbei sehr hilfreich, um auch in komplizierteren Fällen „zwischen den Zeilen zu lesen".

Tsarimi begann, HTTP-Anfragen an „/oauth2/token" zu stellen, und passte seine Anfrage so an, dass sie wie eine Metadaten-Anfrage aussah. Er wollte, dass das Token von den Azure-Verwaltungs-APIs verwendet werden kann, also hat er „resource=https://managment.azure.com/" verwendet. Die Anfrage gab einfach ein JWT (JSON Web Token) zurück. Er entschlüsselte das JWT-Token und sah seine Abonnement-ID, seine Mieter-ID und die Ressourcen-ID seines Automatisierungskontos. Er fand heraus, dass jedes Automatisierungskonto eine „systemzugewiesene verwaltete Identität" hat, was im Grunde bedeutet, dass Benutzer ihren Automatisierungsskripten Rollen zuweisen können und die Identität vom Dienst verwaltet wird.

Tsarimi wollte nun testen, ob sein JWT-Token echt ist. Er hat die Azure CLI verwendet, um eine einfache Anfrage zu stellen, um alle seine VMs abzurufen („az vm list"), hat die Anfrage abgefangen und das JWT-Token ausgetauscht. Er bekam eine Fehlermeldung, dass er nicht genügend Berechtigungen habe. Nachdem er seiner verwalteten Identität eine kompatible Rolle zugewiesen hatte, funktionierte das Token und war tatsächlich mit seiner verwalteten Identität verknüpft.

Ein Token, das mit einer verwalteten Identität verknüpft ist, stellt an sich kein Problem dar, es gab jedoch zusätzliche Ports, die lokal zugänglich waren. Zufällige Ports stellten Tsarimi JWT-Tokens zur Verfügung. Er führte das Skript noch ein paar Mal aus, und verschiedene Ports gaben ihm erneut verschiedene Token. Nun war ihm klar, dass er tatsächlich auf die Identitätsendpunkte anderer Leute zugreifen konnte. Er hatte bereits bewiesen, dass diese Tokens zur Verwaltung des Azure-Kontos verwendet werden können, wenn sie mit genügend Berechtigungen ausgestattet sind, so dass der Zugriff auf Daten anderer Tenants nicht notwendig war.

Das Orca-Forschungsteam wollte verstehen, wie weit diese einfache Schwachstelle gehen kann. Die Forscher nutzten die Schedule-Funktion von Azure Automation, um Tokens von einigen hundert Ports abzugreifen und zu sehen, welche Tenants auftauchten. Sie haben das jeweilige Token nicht gespeichert und nur die Metadaten über den Tenant extrahiert (Tenant-ID und Ressourcen-ID des Automatisierungskontos). In dieser kurzen Zeitspanne, bevor das Problem gepatcht wurde, konnten sie viele verschiedene Tenants beobachten, darunter mehrere sehr bekannte Unternehmen.

Es handelte sich um einen relativ einfachen Fehler, der sich zu einer sehr interessanten Schwachstelle entwickelte. Die Ursache ließ sich bislang nicht klar bestimmen. Der Identitäts-Endpunkt könnte eine Form der Authentifizierung erfordert haben (andere Endpunkte auf diesem Server taten dies sicherlich). Vielleicht hat aber auch jemand die Tatsache übersehen, dass das interne Netzwerk des Rechners nicht wie erwartet in einer Sandbox untergebracht ist.

Microsoft hat dieses Problem behoben, indem nun der HTTP-Header „X-IDENTITY-HEADER" bei der Anforderung von Identitäten erforderlich ist. Nutzer müssen den Wert auf den geheimen Wert setzen, der in ihren Umgebungsvariablen festgelegt ist. Microsoft hat außerdem angekündigt, die gesamte Architektur zu überprüfen, um sicherzustellen, dass eine derartiger Fehler nicht erneut auftreten kann.