[English]Die Sicherheitsexperten von Tenable sind in Microsoft Azure auf eine Schwachstelle gestoßen, die sie als kritisch einstufen. Microsoft hat aber verlauten lassen, dass man diese Schwachstelle, die mehr als zehn Azure Services betrifft, nicht patchen möchte. Das heißt, die Schwachstelle wird nicht geschlossen.
Anzeige
Schwachstelle in Azure
Das Ganze erinnert mich ein wenig an den Sachverhalt, den ich im Blog-Beitrag Sicherheitsrisiko Microsoft? Azure-Schwachstelle seit März 2023 ungepatcht, schwere Kritik von Tenable – Teil 2 aufgegriffen habe. Seinerzeit hat Microsoft die Schwachstelle nach öffentlicher Kritik gepatcht (siehe Nach Tenable Kritik: Microsoft hat Azure-Schwachstelle nun doch schneller (im August 2023) gefixt).
Nun hat das Cloud Research Team von Tenable eine neue, als kritisch eingestufte, Schwachstelle in Azure entdeckt. Laut einer Mitteilung von Tenable betrifft die Schwachstelle die nachfolgenden Azure Services.
- Azure Application Insights
- Azure DevOps
- Azure Machine Learning
- Azure Logic Apps
- Azure Container Registry
- Azure Load Testing
- Azure API Management
- Azure Data Factory
- Azure Action Group
- Azure AI Video Indexer
- Azure Chaos Studio
Azure Service Tags und Firewall
Die Sicherheitslücke betrifft Azure-Kunden, deren Firewall-Regeln auf Azure Service Tags basieren. Azure Service Tags vereinfachen die Netzwerkisolierung innerhalb von Azure, indem sie bestimmte IP-Bereiche von Azure-Diensten gruppieren. Diese Tags können verwendet werden, um Netzwerksicherheitsregeln zu definieren und diese Regeln konsistent auf mehrere Azure-Ressourcen anzuwenden. Im Wesentlichen bieten Azure Service Tags eine bequeme Möglichkeit zur Verwaltung von Zugriffskontrollen, wie Firewall-Regeln oder Konfigurationen von Netzwerksicherheitsgruppen (NSG).
Laut Tenable ermöglicht die Schwachstelle in Azure es einem Angreifer es aber, Azure Service Tags basierende Firewall-Regeln zu umgehen. Dazu muss der Angreifer einen Requests von vertrauenswürdigen Services fälschen. Die Sicherheitsforscher schreiben, ein Bedrohungsakteur könnte von der User-Firewall akzeptierte Service Tags missbrauchen, wenn keine zusätzlichen Validierungsmechanismen vorhanden sind.
Anzeige
Azure Firewall bypassing, Source: Tenable
Durch Ausnutzung dieser Schwachstelle könnte sich ein Angreifer Zugriff auf den Azure Service eines Unternehmens und andere interne und private Azure Services verschaffen. "Diese Schwachstelle ermöglicht es einem Angreifer, serverseitig gefälschte Anfragen zu kontrollieren und vertrauenswürdige Azure Services zu imitieren", erklärt Liv Matan, Senior Research Engineer bei Tenable. Tenable hat die Details dieser Schwachstelle im Blog-Beitrag These Services Shall Not Pass: Abusing Service Tags to Bypass Azure Firewall Rules (Customer Action Required) beschrieben.
Meldung im Januar 2024
Tenable hat diese Entdeckung am 24. Januar 2024 an Microsoft gemeldet und erhielt am 31. Januar 2024 die Bestätigung des Microsoft Security Response Center (MSRC), dass das Verhalten als "Elevation of Privilege" mit dem Schweregrad "Wichtig" eingestuft werde. Tenable hat auch eine Bug-Bounty-Prämie für die Meldung kassiert. Zum 2. Februar 2024 erstellt das MSRC einen umfassenden Plan zur Behebung der Schwachstelle sowie einen Zeitplan für die Umsetzung.
Microsoft will nicht patchen
Wer jetzt meint, es kommt bald ein Patch, sieht sich aber getäuscht. Die Verantwortlichen im MSRC beschließen am 26. Februar 2024, das Problem durch eine umfassende Aktualisierung der Dokumentation zu beheben und weitere Varianten der Sicherheitslücke dort zu behandeln. Welche internen Gründe und technischen Randbedingungen zu dieser Entscheidung Microsofts führten, sind mir unbekannt. Zum 3. Juni 2024 erfolgte dann eine koordinierte Offenlegung durch Tenable.
Azure-Kunden müssen handeln
Azure Kunden, deren Firewall-Regeln auf Azure Service Tags basieren, sind durch diese Schwachstelle gefährdet. Da Microsoft keinen Patch für diese Schwachstelle veröffentlichen wird, müssen diese Azure-Kunden zeitnah handeln. Tenable empfiehlt dazu:
- Analysieren Sie zunächst die Netzwerkregeln in Ihrer Azure-Umgebung für jeden zugehörigen Dienst, suchen Sie nach der Verwendung von Service-Tags, und filtern Sie die betroffenen Dienste. Gehen Sie bei den betroffenen Diensten davon aus, dass diese Ressourcen öffentlich sind.
- Um diese Ressourcen zu schützen, fügen Sie Authentifizierungs- und Autorisierungsebenen für diese hinzu.
Tenable merkt an, dass Administratoren bei der Konfiguration der Netzwerkregeln für Azure-Dienste bedenken, dass Service-Tags kein wasserdichtes Mittel sind, um den Datenverkehr zu einem privaten Dienst zu sichern. Wenn Administratoren sicherstellen, dass eine starke Netzwerkauthentifizierung beibehalten wird, können sich die Benutzer mit einer zusätzlichen und entscheidenden Sicherheitsebene schützen. In diesem Fall hätte selbst ein Angreifer, der die Schwachstelle ausnutzt, um den Zielendpunkt zu erreichen, große Schwierigkeiten, diesen Zugang auszunutzen.
Microsoft hat dazu wohl eine zentrale Dokumentation zusammengestellt, um Kunden über die Verwendung von Service Tags zu informieren. Tenable schreibt dazu: "Wir empfehlen unseren Kunden dringend, sofort zu handeln. Starke Netzwerkauthentifizierung bietet Usern eine zusätzliche und entscheidende Sicherheitsebene." Kunden sollten umgehend Maßnahmen ergreifen, und sicherzustellen, dass sie durch starke Authentifizierung und Autorisierung geschützt sind.
Weitere Informationen, einschließlich der technischen Erkenntnisse und des Proof of Concept des Teams, finden sich im Tenable Blog und im Technical Advisory. Microsoft hat dazu den Beitrag Improved Guidance for Azure Network Service Tags vom 3. Juni 2024 veröffentlicht.
BSI-Warnung vor weiterer kritischer Schwachstelle
Ergänzung: Das BSI warnt inzwischen vor einer weiteren Schwachstelle (CVS 3.1 = 10.0). Marcel W. hat mich per E-Mail auf nachfolgenden Eintrag in der Liste aktueller Sicherheitshinweise von CERT-Bund (BSI) hingewiesen.
Geschockt hat mich die Einstufung des CVSS-Score von 10.0, was ja der höchst mögliche Wert ist. Details habe ich im Blog-Beitrag CERT-Bund warnt vor Schwachstelle WID-SEC-2024-131 in Microsoft Azure veröffentlicht.
Anzeige
Ich halte Microsofts Entscheidung für nachvollziehbar. Administratoren können durch Sicherheitsmaßnahmen das Problem lösen – dann sollten auch eben die das tun.
Grundsätzlich sollten solche Dienste nicht ohne Schutz öffentlich erreichbar sein, das heißt aber nicht, dass man die Lücke nicht generell schließen sollte. Denn nicht jeder, der auf solchen Plattformen unterwegs ist, weiß, was er da gerade macht und welche Auswirkungen das haben kann.
Interessante Einstellung!
Also MS wirft kaputte Produkte auf den Markt und die Benutzer sollen diese dann selber "reparieren".
Selbst nachdenken und das System verstehen sollte doch möglich sein?
Also bei Ihnen alles schon lange bekannt und natürlcih bedacht? Selbst wenn – laut Bericht – die Dokumentation das nicht kommuniziert?
Wenn man einige Azure-Vorfälle der letzten zwei Jahre ansieht – auch bei Microsoft selbst(!) – gehe ich davon aus, dass das ganze System zu komplex ist, um von allen in allen Asptekten genau verstanden zu werden.
Da Sie uns mit Ihrem Post wohl mitteilen wollen, dass Sie selbst nachdenken und das System verstehen, können Sie ja gerne Ihre Maßnahmen hier vorstellen.
»Der Bewohner kann ja selbst einen Schrank vor die Wohnungstür stellen. Warum sollten wir eine bei Bedarf abschließbare Tür einbauen«
So kommt es mir zumindest vor. Natürlich wäre es besser, wenn Alle wissen, was sie tun. Ist aber nun mal nicht der Fall. Grade bei Anwendern von Microsoft und/oder Cloud sind es IMO doch eher Wesen, welche sich eben nicht mit der Technik beschäftigen wollen, sondern etwas schlüsselfertiges zum einfachen zusammenklicken erwarten. Eine halbwegs sichere Standardkonfiguration sollte da dann doch Standard sein.
So ist es.
Die Systeme haben ab Werk maximal zugenagelt zu sein und dann macht der Benutzer genau das auf, was er auch braucht.
Wenn man ein Haus oder Auto kauft, stehen da auch nicht alle Fenster und Türen offen und den Schlüssel bekommt man erst auf Nachfrage.
Das scheint aber leider wohl bei den Softwareherstellern noch nicht angekommen zu sein.
Die machen es genau anders herum:
Ab Werk maximal offen und man darf dann selbst zusehen, wie man die Löcher zunagelt und woher man die passenden Schlüssel bekommt.
Es gab auch mal Zeiten, da lag einer Software ein Handbuch bei, das zumindest die Grundfunktionen erläutert.
Ist auch schon seit vielen vielen Jahren nicht mehr üblich.
Nach deutschem Recht ist das sogar ein Produktmangel, der zur Forderung nach Nachbesserung berechtigt.
Kann der Anbieter nicht liefern, kann man vom Kaufvertrag zurücktreten.
Aber genau so ist es ja auch.
Da ist nichts von Haus aus offen. Der User hat sich die Freigabe für Service Tags selbst gebaut und damit die Tür aufgemacht.
Das als Schwachstelle zu bezeichnen ist aber auch sehr an den Haaren herbeigezogen.
Ein Service Tag ist eine Sammlung öffentlicher IP Adressen für den jeweiligen Service. So gibt es Service Tags für die unterschiedlichen Azure Regionen und eben auch einzelne Dienste. Das Service Tag "Logic Apps" enthält damit alle IP Adressen mit denen Logics Apps in der gesamten Azure Welt ins Internet gehen können.
Wenn ich nun hingehe und an einem meiner Dienste oder in meiner Firewall eine eingehende Freigabe mit Service Tag baue ist das nichts anderes als eine Firewall Regel die als Quelle eine große Liste öffentlicher Adressen zulässt. Und diese Freigabe muss ich selbst gebaut haben, out of the box wäre das nicht ausnutzbar.
Niemand der Azure Netzwerk verstanden hat würde sowas jemals für einen privaten Dienst tun. Die Dokumentation anzupassen ist selbstverständlich mehr als sinnvoll um auf die potenzielle falsche Verwendung hinzuweisen.