Böse Überrschung für Kunden der Microsoft Clouddienste: Nachdem Angreifer den Dienst kompromittierten konnten, spielte der Konzern den Vorfall herunter. Nun muss er jedoch zugeben, dass die Attacke weitaus schlimmer war – und durch zahlreiche, schwerwiegende Sicherheitsmängel sowie Versäumnisse in Microsofts Cloud-Infrastruktur ermöglicht wurden.
Vorgeschichte: Was war passiert?
Im Juli 2023 wurden zahlreiche Organisationen in der Microsoft 365 Cloud gehackt. Über ein Monat verging, bis Microsoft den Angriff überhaupt bemerkte. Auch das geschah nur, weil sich über Wochen hinweg zunehmend Kunden über unbefugte Zugriffe beschwerten. Und zwar durch einen MSA-Schlüssel, mit dem vereinfacht gesagt jeder beliebige Nutzer angemeldet werden kann, ohne dessen Kennwort zu wissen. Microsoft hielt sich damals bedeckt, vermied harte, konkrete Worte. Und betonte, es sei „nur“ Outlook Web kompromittiert worden.
Damals hielte ich das für irreführend und mit hoher Wahrscheinlichkeit falsch: Schon alleine, weil Microsofts Clouddienste überall Single-Sign-On (SSO) nutzen. Wer sich z.B. in Outlook Web anmeldet, kann auf weitere Clouddienste wie Teams, SharePoint, OneDrive und weitere zugreifen – ohne sich neu anmelden zu müssen. Und es gab weitere Gründe: So sprach Microsoft beispielsweise von „impersonate Azure AD“. Am Azure Active Directory (AAD) Verzeichnisdienst hängen alle Cloudanwendungen des Konzerns. Wer sich als fremder AAD-Benutzer ausgeben kann, der hat Zugriff auf alles, was der bei Microsoft in der Cloud liegen hat.
Wie fiel Angreifern der goldende MSA-Schlüssel in die Hände?
Am 06.09.2023 veröffentlicht der Konzern einen Beitrag mit den Ergebnissen der eigenen Untersuchung.1 Darin wurden nicht nur die Befürchtungen bestätigt. Die erste Überraschung: Der Angriff fand nicht im Mai 2023 statt, wie bislang bekannt – sondern geht bis 2021 zurück. Im April 2021 ist ein produktives Signiersystem abgestürzt und hat einen Schnappschuss (Crash dump) von diesem Prozess angelegt. Darin sollten keine Schlüsseldaten enthalten sein, waren sie aber doch – dies war der erste Fehler aus einer ganzen Reihe von Pannen, die zum GAU führten. Der nächste: Sie hatten ein Verfahren, um Schlüsseldateien zu entfernen. Auch das hat versagt und den Schlüssel nicht erkannt.
Dieser Crash dump wurde von der produktiven Umgebung in das interne Microsoft-Netz verschoben. Dort sollten sensible Daten ebenfalls gefiltert werden, ein weiteres Mal haben die Mechanismen versagt. Nach April 2021 wurde ein Microsoft-Mitarbeiter erfolgreich angegriffen, wodurch die Angreifer Zugriff auf das Unternehmensnetzwerk bekam und damit auch auf den Schnappschuss vom abgestürzten Prozess, der sensibelste Informationen enthält. Wann genau? Weiß Microsoft nicht, weil sie die Protokolle schon gelöscht haben. Um Speicher zu sparen, wissen sie nicht mal genau, ob es wirklich so wahr. Sie haben keine Beweise dafür, sondern sehen es als wahrscheinlichste Erklärung dafür, wie der Angreifer den MSA-Schlüssel bekommen hat. Zwischenstand dieser interessante: Wir sind bei drei Sicherheitsmängeln.
Warum konnte ein Privatkunden-Schlüssel Unternehmen kompromittieren?
Der geklaute MFA-Schlüssel war ursprünglich für Privatkunden gedacht. Also Office 365 Abonnenten, Menschen die Windows mit Cloudkonto nutzen usw. Die bekannten Opfer unter den Kunden sind jedoch nicht privat, sondern beispielsweise Regierungsorganisationen. Wie das passieren konnte, wird im Beitrag ebenfalls erklärt: Kunden wollten Anwendungen, die sowohl mit Privat- als auch Unternehmensanwendungen funktionieren. Daher hat Microsoft das zusammengeführt, jedoch versäumt, in den Bibliotheken eine Überprüfung durchzuführen. Die Entwickler von Exchange Online gingen davon aus, die Bibliothek kümmert sich schon um alles. Wenn jeder denkt, die anderen werden es richten, tut es am Ende keiner. Diese Mängel führten dazu, dass Exchange Online den Schlüssel für Privatkunden akzeptierte.
Interessant: Microsoft traut seinem eigenen Firmennetzwerk nicht
Im Blogeintrag betont Microsoft ihre stark isolierte und eingeschränkte Produktivumgebung. Dort seien beispielsweise E-Mails, Konferenzen und das Surfen im Web nicht möglich, um Angriffe durch Phishing/Schadsoftware zu verhindern. Die Sicherheitsmaßnahmen im Unternehmensnetzwerk sind dagegen deutlich bescheidener. Deswegen sollte Schlüssel das produktive Netz nicht verlassen, so Microsoft. Das finde ich bemerkenswert. Was würdet ihr höher einstufen: Euer Unternehmensnetz oder die Produktivumgebung? Ich sehe da klar das Unternehmensnetzwerk, es ist schließlich das Herz des Ganzen.
Dort befinden sich interne Daten, Zahlungsinformationen und bei einem Softwareunternehmen besonders wichtig: Der Quellcode! Die ganzen Office-Programme wie Outlook, Teams, Edge usw. werden dort entwickelt, eben so wie Windows und der gesamte Azure Cloud-Stack. Ist man drin, kann man Schadcode in die produktive Umgebung ausliefern. Oder noch besser: Software infizieren, die an (bei MS sehr viele) Kunden ausgeliefert wurde. Hatten wir schon mal mit SolarWinds,2 da zählte u.a. Microsoft zu den zahlreichen bekannteren Opfern. Mehrere Monate lang konnten Angreifer bereits von März bis Dezember 2020 Schadsoftware in zwei Phasen bei Microsoft erfolgreich einschleusen, ohne dass dies dem Konzern auffiel.3
Die Folgen?
Die Tagesschau fasst den Vorfall zusammen, macht aber das Ausmaß klar und zitiert Recherchen des SWR. Auch dort stellt man fest, wie Microsoft den Angriff heruntergespielt hat. Hier wird auch ein wichtiger Punkt aufgegriffen, der oft zu kurz kommt: Niemand kennt den genauen Umfang oder weiß, ob die Angreifer Hintertüren eingebaut haben – immerhin hatten sie Vollzugriff. Manuel Höferlin, innenpolitischer Sprecher der FDP-Fraktion stellt zutreffend fest, dass die beste Verschlüsselung nutzlos ist, wenn der Schlüssel schlecht geschützt in unbefugte Hände gerät. Auch setzt er sich für das Schließen von Sicherheitslücken ein, statt diese staatlich auszunutzen. Das hätte hier zwar nichts geholfen, da das Problem bei Microsoft lag und nicht durch 0-Day Schwachstellen verursacht wurde. Dennoch eine vernünftige Haltung.
Gegen Ende wird festgestellt, dass das Europäische Parlament stark von Microsoft abhängig ist: Man setzt überall auf Windows, Teams, SharePoint und Exchange. Zumindest auf die Cloud-Varianten der letzten Drei hatten Angreifer lange Zeit Zugang, mutmaßlich aus China. Das solle man nun prüfen. Viel wichtiger finde ich aber die Forderung, sich von Microsoft zu lösen und auf freie, selbst verwaltete Software zu wechseln.4 Diesen Schritt ist z.B. Indien bereits gegangen, nachdem sie sich durch Microsoft-Software zahlreiche Ransomware-Schädlinge eingefangen haben. Schon in diesem Beitrag habe ich das befürwortet: Neben verschiedenen Sicherheitsproblemen sind wir auch politisch und finanziell in Abhängigkeit und daher z.B. Preiserhöhungen recht schutzlos ausgeliefert.5
Fazit: Nächster Totalschaden unter den Augen von 3.500 Experten
Fassen wir zusammen: Eine Verkettung von fünf Schwachstellen bzw. Fehlern hat dazu geführt, dass ein Universalschlüssel noch mächtiger wurde und bis zu 2 Jahre lang in unbefugtem Besitz war. Microsoft selbst sieht das als wahrscheinlichste Erklärung, da sie nicht vollständig bewiesen ist. Dabei zeigte sich, dass der Konzern es mit dem Schutz des Firmennetzwerkes nicht so genau nimmt. Und ironischerweise sogar die eigenen Produkte als Sicherheitsrisiko betrachtet. Bereits das ist mehr als bemerkenswert, nachdem Sicherheit doch eines der zentralen Versprechen der Cloud ist. Microsoft selbst brüstet sich mit alleine über 3.500 Sicherheitsexperten nur für die Azure-Cloud.6
All diese Sicherheitsmängel wurden jedoch trotzdem über Monate und Jahre hinweg nicht erkannt. Erst als dutzende Kunden die Einbrüche meldeten, merkte Microsoft: Wir wurden gehackt. Nach derart schwerwiegenden Qualitätsmängeln ist es um so erstaunlicher, dass daran offensichtlich nichts verändert werden soll, um derartige Katastrophen zu verhindern. Lediglich die gefundenen Probleme beseitigt man.
Aber was ist mit den strukturellen Problemen? Den Prozess zu verbessern, der den Eimer kaputt gemacht hat, statt nur ein Klebeband über das Loch zu kleben? Fehlanzeige. Offensichtlich gibt es gar kein Interesse daran. Man bedenke, wie wir von diesem Cloud-Hack überhaupt erfahren haben: Kunden (darunter eine US-Behörde) haben zusätzlich zum Abo bezahlt, um Zugriff auf Protokolle zu bekommen. Diesen Zugang haben sie genutzt, die Protokolle überwacht und ihnen ist aufgefallen, dass jemand ihre Cloud-Instanz gehackt hat. Hätten die sich auf Microsofts 3.500 Spezialisten verlassen, wie es der Konzern verspricht, wüssten wir bis heute nichts davon – und die Angreifer würden auf unbestimmte Zeit weiter Daten aus der Cloud stehlen und manipulieren. Wäre ich Microsoft (Cloud) Kunde, könnte ich spätestens jetzt nicht mehr ruhig schlafen…
Quellen
- Results of Major Technical Investigations for Storm-0558 Key Acquisition
https://msrc.microsoft.com/blog/2023/09/results-of-major-technical-investigations-for-storm-0558-key-acquisition/ ↩︎ - https://www.heise.de/news/Falsche-Angaben-bei-IT-Sicherheit-US-Boersenaufsicht-klagt-gegen-Solarwinds-9351468.html ↩︎
- https://www.heise.de/news/Microsoft-Solarwinds-Hacker-sahen-Code-fuer-Azure-Exchange-und-Intune-5060022.html ↩︎
- Hacker-Angriff auf Microsoft war gravierend
https://www.tagesschau.de/investigativ/swr/microsoft-outlook-e-mails-sicherheitsluecke-hacker-100.html ↩︎ - Tschüss Microsoft: Warum Indien von Windows zu GNU/Linux wechselt – sollten wir das auch tun?
https://u-labs.de/portal/tschuss-microsoft-warum-indien-von-windows-zu-gnu-linux-wechselt/ ↩︎ - Azure Security
https://azure.microsoft.com/de-de/explore/security/ ↩︎