Technische Details zur kritischen Schwachstelle in Azure Synapse

Der aktuelle Blog von Orca Security beschreibt die technischen Details von SynLapse, als Fortsetzung des vorherigen Blogs. Orca hat mit der Veröffentlichung bis jetzt gewartet, um Synapse-Kunden Zeit zu geben, ihre lokalen Versionen zu patchen und ihre Nutzung von Azure Synapse zu überdenken. MSRC hat mehrere Verbesserungen vorgenommen und arbeitet weiter an einer umfassenden Tenant-Isolation.

Tzah Pahima, Forscher bei Orca Security, wird die Entdeckung von SynLapse zugeschrieben – einer kritischen Sicherheitslücke in Microsoft Azure Synapse Analytics, die auch Azure Data Factory betraf. Sie ermöglichte es Angreifern, die Mandantentrennung zu umgehen und gleichzeitig folgende Fähigkeiten zu erlangen:

• Zugangsdaten für andere Azure-Synapse-Kundenkonten zu erlangen.
• Kontrolle über deren Azure-Synapse-Arbeitsbereiche.
• Code auf gezielten Kundenrechnern innerhalb des Azure Synapse Analytics-Dienstes auszuführen.
• Weitergabe von Kundenzugangsdaten an Datenquellen außerhalb von Azure.

Ein Angreifer, der nur den Namen eines Azure Synapse-Arbeitsbereichs kennt, könnte auf folgende Weise die in Synapse eingegebenen Zugangsdaten eines Opfers ausspähen: https://vimeo.com/26made/review/697795723/39bc9d9948

Was ist Azure Synapse Analytics?

Azure Synapse Analytics importiert und verarbeitet Daten aus vielen Kundendatenquellen (z. B. CosmosDB, Azure Data Lake und externen Quellen wie Amazon S3).

Jede Synapse-Instanz wird als Workspace bezeichnet. Um Daten aus einer externen Datenquelle zu importieren und zu verarbeiten, gibt ein Kunde Zugangsdaten und relevante Daten ein und stellt dann über eine Integration Runtime eine Verbindung zu dieser Quelle her – eine Maschine, die eine Verbindung zu vielen verschiedenen Datenquellen herstellt.

Integration Runtimes können entweder selbst (On-Premises) oder in der Azure Cloud gehostet werden (über die Azure Data Factory Integration Runtime). In der Cloud gehostete Azure IRs können auch mit einem Managed Virtual Network (VNet) konfiguriert werden, um private Endpunkte für externe Verbindungen zu verwenden, was zusätzliche Isolationsebenen bieten kann.

Wie kritisch war SynLapse?

SynLapse ermöglichte es Angreifern, über einen internen Azure-API-Server, der die Integration Runtimes verwaltet, auf Synapse-Ressourcen zuzugreifen, die anderen Kunden gehören. Da das Orca-Team den Namen eines Arbeitsbereichs kannte, war es in der Lage, Folgendes durchzuführen:

• Autorisierung innerhalb anderer Kundenkonten zu erlangen, während des Agierens als Synapse Workspace. Je nach Konfiguration hätte das Team auf noch mehr Ressourcen innerhalb eines Kundenkontos zugreifen können.
• Auslesen von Zugangsdaten, die Kunden in ihrem Synapse-Arbeitsbereich gespeichert haben.
• Kommunikation mit den Integration Runtimes anderer Kunden. Das Orca-Team konnte dies nutzen, um Remote-Code (RCE) auf den Integration Runtimes eines beliebigen Kunden auszuführen.
• Kontrolle über den Azure-Batch-Pool, der alle gemeinsam genutzten Integration Runtimes verwaltet. Orca war in der Lage, Code auf jeder Instanz auszuführen.

Zukünftige Entschärfung

Nach Gesprächen mit Microsoft ist Orca Security nun der Ansicht, dass Azure Synapse Analytics sicher ist und eine ausreichende Tenant-Isolation bietet. Aus diesem Grund hat Orca die Warnmeldungen zu Synapse aus der Orca Cloud Security-Plattform entfernt. Microsoft arbeitet weiterhin an zusätzlicher Isolation und Härtung.

www.orca.security/de/