Thought Leadership
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).
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.
„Es gibt nichts Aufregenderes, als herauszufinden, dass das Ziel einen Webdienst zur Verfügung stellt. Vor allem, wenn er lokal und auf einem hohen, scheinbar zufälligen Port liegt“, erklärt Tsarimi.
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/
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.
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.
www.orca.security
