[English]Nächster Datenschutz- und Sicherheitsvorfall bei Microsoft: Sicherheitsforscher von Wiz sind über ein öffentliches Microsoft AI GitHub Repository auf private interne Daten im Umfang von 38 Terabyte, die auf einer Azure Cloud Store-Instanz gespeichert waren, gestoßen. Der Zugriff wurde durch ein falsch konfiguriertes SAS-Token ermöglicht, heißt es. Dieses gigantische Datenleck enthielt auch die Backups zweier Microsoft Mitarbeiter mit geheimen Schlüsseln und Zugangsdaten sowie über 30.000 interne Microsoft Teams-Nachrichten.
Anzeige
Wenn es noch eines Beweises bedurfte, dass uns bzw. auch den Microsoft Angestellten die IT-Sicherheit entgleitet, dann liegt dieser nun vor. Ich bin gerade von zwei Blog-Lesern per Kommentar und auf Twitter auf diesen Vorfall hingewiesen worden – danke dafür.
Datenleck bei Microsoft AI-Forschern
Ein Team von Wiz-Sicherheitsforschern durchforstet das Internet nach in der Cloud gehosteten Daten, die irrtümlich öffentlich einsehbar sind. Im Rahmen dieser Aktivitäten haben sie auch einen Blick auf ein öffentliches GitHub-Repository der Microsoft AI-Forschungsgruppe geworfen. Dort sollen sich Interessierte eigentlich Trainingsdaten herunterladen können. Aber über die dort angegebenen URLs für die Downloads war noch mehr möglich. Die Wiz-Sicherheitsforscher schreiben, bei der Freigabe von Open-Source-Trainingsdatensätzen habe das KI-Forschungsteam von Microsoft versehentlich die Tür zum Tresorraum offen gelassen.
Die Sicherheitsforscher haben den Vorfall im Rahmen einer verantwortlichen Offenlegung in diesem Blog-Beitrag sowie auf X in einer Serie von Tweets öffentlich gemacht. Auch von Microsoft gibt es diesen Blog-Beitrag, der zeitgleich veröffentlicht wurde.
Was ist passiert?
Über ein GitHub-Repository werden von der Microsoft AI-Forschungsgruppe interessierten Entwicklern Open-Source-Code und KI-Modelle für die Bilderkennung öffentlich zum Download bereitstellt. Interessierte konnten sich die Modelle über eine angegebene URL von einer Azure Storage-Instanz herunterladen (siehe nachfolgendes Bild).
Soweit nichts ungewöhnliches, solche öffentlichen GitHub-Repositories gibt es von Microsoft einige und die werden auch genutzt. Als die Sicherheitsforscher aber genauer hinschauten, fanden sie heraus, dass zu dieser URL ein falsch konfiguriertes SAS-Token gehörte, welches Dritten die Berechtigungen zum Zugriff auf das gesamte Speicherkonto gewährte.
In Azure ist ein SAS-Token (Shared Access Signature) eine signierte URL, die Zugriff auf Azure Storage-Daten gewährt. Die Zugriffsebene kann vom Benutzer angepasst werden; wobei die Berechtigungen von schreibgeschützt bis zur vollständigen Kontrolle reichen. Dabei kann der Umfang der Zugriffsrechte sich entweder auf eine einzelne Datei, einen Container oder ein ganzes Speicherkonto beziehen. Auch die Ablaufzeit für Zugriffe ist vollständig anpassbar, so dass der Benutzer Token mit unbegrenzter Gültigkeitsdauer erstellen kann. Diese Granularität bietet den Benutzern eine große Flexibilität, birgt aber auch das Risiko, zu viel Zugriff zu gewähren. Im freizügigsten Fall (wie beim obigen Token von Microsoft) kann das Token für immer volle Kontrollrechte für das gesamte Konto gewähren – und damit im Wesentlichen dieselbe Zugriffsstufe wie der Kontoschlüssel selbst bieten.
Anzeige
Die Wiz-Sicherheitsforscher geben an, dass das SAS-Token der URL auf den Azure Storage-Bereich nicht nur Zugriff auf die eigentlich privaten Daten ermöglicht, sondern auch noch die volle Kontrolle gewährte. Ein Angreifer hätte nicht nur alle Dateien des Azure-Speicherkonto einsehen, sondern auch vorhandene Dateien löschen und überschreiben können. Laut den Sicherheitsforschern hätte ein Angreifer bösartigen Code in alle KI-Modelle in diesem Speicherkonto hätte einschleusen können, und jeder Benutzer, der dem GitHub-Repository von Microsoft vertraut, wäre damit infiziert worden. Der perfekte Lieferkettenangriff auf das Microsoft KI-Trainingsmaterial und die gespeicherten Dateien.
Ein 38 TByte großes Datenleck
Für die Sicherheitsforscher war es aber im ersten Schritt interessanter, was man auf dem unbeabsichtigt zugänglichen Speicherbereich so finden konnte. Der Scan der Speicherinstanz dieses Kontos durch das Wiz-Team ergab, dass dadurch versehentlich 38 TB an zusätzlichen privaten Daten öffentlich einsehbar waren.
Obiger Tweet und das darin eingebettete Schema verdeutlichen den Sachverhalt, nachfolgendes Bild zeigt die Verzeichnisstruktur des Bereichs der Azure Storage-Instanz, die eigentlich privat sein sollte.
Die über das GitHub Repository erreichbaren Verzeichnisse enthielten die persönlichen Computer-Backups von zwei Microsoft-Mitarbeitern. In diesen Backups fanden sich sensible persönliche Daten, darunter Passwörter für Microsoft-Dienste, geheime Schlüssel und über 30.000 interne Microsoft Teams-Nachrichten von 359 Microsoft-Mitarbeitern.
Das war mal wieder der Jackpot mit den Kronjuwelen aus dem Microsoft Tresor – fast so etwas wie ich gerade im Beitrag Interview: Der kleingeredete Hack der Microsoft Cloud zum Storm-0558-Hack der Azure-Cloud zusammengefasst hatte.
Die Sicherheitsforscher von Wiz erläutern in ihrem Blog-Beitrag noch eine Reihe an Details und erklären die Risiken bei der Verwendung von SAS-Tokens. Die Tokens sind schnell konfiguriert, aber Konto-SAS-Tokens extrem schwer zu verwalten und zu widerrufen sind. Es gibt laut Wiz keine offizielle Möglichkeit, diese Token innerhalb von Azure zu verfolgen oder die Token-Ausgabe zu überwachen. SAS-Tokens werden auf der Client-Seite erstellt, und sind keine Azure-Objekte. Aus diesem Grund kann sogar ein scheinbar privates Speicherkonto potenziell weit offengelegt werden. Der perfekte Ansatz für Chaos und solche Vorfälle.
Interessante Zeitleiste des Vorfalls
Das SAS-Token wurde am 20. Juli 2020 erstmals auf GitHub eingestellt, wobei ein Ablaufdatum auf 5. Oktober 2021 festgelegt worden ist. Dann wurde am 6. Oktober 2021 das Ablauf-Token erneuert und mit dem Ablaufdatum 6. Oktober 2051 versehen. Keine Ahnung, ob zu diesem Datum den heutigen Protagonisten noch etwas "weh tut" oder Microsoft noch existiert.
Die Sicherheitsforscher von Wiz stießen am 22. Juni 2023 auf das Problem und meldeten dieses dem MSRC. Zu diesem Zeitpunkt stand die Azure-Speicherinstanz wohl bereits zwei Jahre für Unbefugte offen. Dann ging es sehr fix, bereits zwei Tage später, am 24. Juni 2023 wurde das SAS-Token von Microsoft für ungültig erklärt. Am 7. Juli 2023 wird das SAS-Token wird auf GitHub komplett ersetzt. Im Hintergrund laufen interne Untersuchungen Microsofts im Hinblick auf mögliche Auswirkungen, die am 16. August 2023 abgeschlossen werden. Am 18. September 2023 geben Wiz und Microsoft zeitgleich den Vorfall öffentlich bekannt.
Wie Microsoft die Dinge sieht
Microsoft hat den Sicherheitsvorfall im Beitrag Microsoft mitigated exposure of internal information in a storage account due to overly-permissive SAS token öffentlich gemacht. Dort heißt es, dass Microsoft eine Offenlegung interner Informationen in einem Speicherkonto auf Grund zu lax gewährter Zugriffsrechte mittels SAS-Tokens entschärft habe.
Man habe den Vorfall, in den ein Microsoft-Mitarbeiter verwickelt war, untersucht und behoben. Im Beitrag wird die obige Darstellung von Wiz bestätigt und auch zugegeben, dass zu den Daten, die in diesem fehl konfigurierten Speicherkonto offengelegt wurden, auch Backups der Arbeitsplatzprofile zweier ehemaliger Mitarbeiter sowie interne Microsoft Teams-Nachrichten dieser beiden Mitarbeiter mit ihren Kollegen austauschten, gehörten.
Microsoft legt Wert darauf, dass keine Kundendaten preisgegeben wurden, und es seien auch keine anderen internen Dienste durch dieses Problem gefährdet gewesen. Als Reaktion auf dieses Problem seien keine Kundenmaßnahmen erforderlich – wie hörte ich bei ähnlichen Vorfällen aus meiner Blog-Leserschaft "Man ist mit einem blauen Auge davon gekommen". Immerhin meint teilt Microsoft mit, dass man im Beitrag die gewonnenen Erkenntnisse und bewährten Verfahren teile, um Kunden zu informieren und ihnen zu helfen, ähnliche Vorfälle in Zukunft zu vermeiden. Diese Erklärungen und "gute Ratschläge Microsofts, wie man so etwas vermeidet", lassen sich im verlinkten Beitrag nachlesen.
Ähnliche Artikel:
China-Hacker (Storm-0558) in Microsofts Cloud, Outlook Online-Konten gehackt
Nachlese zum Storm-0558 Cloud-Hack: Microsoft tappt noch im Dunkeln
Nach CISA-Bericht zum Storm-0558-Hack stellt Microsoft Kunden erweitertes Cloud-Logging bereit
GAU: Geklauter AAD-Schlüssel ermöglichte (Storm-0558) weitreichenden Zugang zu Microsoft Cloud-Diensten
Microsofts Cloud-Hack: Überprüfung durch US Cyber Safety Review Board
Microsoft Cloud-Hack durch Storm-0558: US-Senatoren unter den Opfern; Prüfpflicht für europäische Verantwortliche
Nachgehakt: Storm-0558 Cloud-Hack und Microsofts Schweigen
Microsofts Storm-0558 Cloud-Hack: Schlüssel stammt aus Windows Crash Dump eines PCs
Interview: Der kleingeredete Hack der Microsoft Cloud
Sicherheitsrisiko Microsoft? Feuer von der US-Politik nach Microsofts Azure Cloud-GAU und Forderung zum Microsoft Exit – Teil 1
Sicherheitsrisiko Microsoft? Azure-Schwachstelle seit März 2023 ungepatcht, schwere Kritik von Tenable – Teil 2
Antworten von Microsoft zum Hack der Microsoft Azure-Cloud durch Storm-0558 – Teil 1
Antwort vom BfDI, Ulrich Kelber, zum Hack der Microsoft Azure-Cloud durch Storm-0558 – Teil 2
2015
"Microsoft legt Wert darauf, dass keine Kundendaten preisgegeben wurden, und es seien auch keine anderen internen Dienste durch dieses Problem gefährdet gewesen." – ja, aber….😄
Wie kamen dann eigentlich die 38 TByte zusammen? Also Microsoft mag viele Daten haben aber AI braucht ja viele verschiedene Informationen zum "Lernen" wenn da mal nicht auch Kundendaten darunter waren.
Nochmal lesen… Bei den Daten waren persönliche Backups zweier Mitarbeiter dabei. Da frage auch ich mich, was haben die da zu suchen? Das Ding hier ist echt Blödheit hoch Zehn. Ich würde das aber nicht MS insgesamt anlasten, das ist die Blödheit einzelner Mitarbeiter, es besteht aber die Befürchtung, dass es davon noch mehr gibt, wie überall.
"das ist die Blödheit einzelner Mitarbeiter, es besteht aber die Befürchtung, dass es davon noch mehr gibt, wie überall"
Auch wenn Sie sicher das Gegenteil suggerieren wollten lese ich das als "MS kann systematisch nicht vertrauenswürdig sein".
Insoweit besten Dank für ein wahres Wort!
Falsch gelesen! Mein Beitrag ist kein MS-Bashing, auch nicht das Gegenteil, sondern besagt: Sowas kann überall passieren. Letztlich mit jedem System, was irgendwie vernetzt ist und irgendwie am Internet hängt. Und selbst die Air-Gap kann überwunden werden!
Wie Hr. Born drunter schreibt, der ganze Scheiß ist einfach zu komplex geworden, das überblickt keiner mehr, und dann passiert sowas. Und dieses Problem betrifft nicht nur Microsoft, sondern JEDEN von uns, MICH, DICH, EUCH und alle ANDEREN da draußen. Das darf man nicht vergessen.
Dass es jetzt mal wieder Microsoft trifft, hängt damit zusammen, dass die einfach im Fokus der Öffentlichkeit und der Spezialisten einschließlich Hacker stehen. Wo einmal Dreck gefunden wurde, ist bestimmt noch mehr Dreck, über den man sich brüskieren kann. Und wer viel macht, macht auch viel falsch, das ist einfach so.
Es kann aber jeden von uns treffen. Macht euer Zeug so sicher wie möglich, patcht was das Zeug her gibt, verteilt eure Admin-Zugänge auf verschiedene Konten (Tiering), macht Netzwerksegemntierung mit ordentlichen FW-Regeln so dass man nicht mehr von überall nach überall verbinden kann, sondern nur noch was unbedingt sein muss, macht Admin-Workstation-Hardening, benutzt besser Admin-Sprungserver für die administrativen zugänge, vernünftiges Rechtemanagement auf Servern und Freigaben, auch in der Cloud, stellt erstmal mit einer Klassifizierung fest wo eure schützenswerten Daten liegen und wer drauf zugreifen kann (dafür gibts nicht gerade günstige Monitoring-Systeme mit KI usw), usw…. Macht es den Angreifern so schwer wie irgendwie möglich, und das wird auch euch keinen Spaß machen so zu arbeiten, aber leider muss es sein, sonst haben "DIE" euch ruckzuck im Sack.
Es gillt: ZERO TRUST!
Außerdem müsst ihr Zugriffe überwachen und protokollieren, damit im Fall eines Falles nachvollzogen werden kann, was passiert ist. Es gibt jede Menge feine kostenlose bis sauteure Monitoringlösungen für alle erdenkliche Fälle.
Ich denke ja seit längerem darüber nach, warum wir inzwischen gehäuft Vorfälle haben. Victim-Blaming hilft imho nicht wirklich weiter.
Wenn bei Microsoft ein Storage-Konto als "privat" angelegt wurde, und keine Vorgaben das Speichern persönlicher Daten verbieten (und bei MS gilt ja Cloud first), spricht für den gemeinen Nutzer (gilt auch für Microsofts KI-Forscher) nichts dagegen, dass da auch Backups in diesen "großen Speicher" abgelegt werden – zumal es in solchen Firmen auch Szenarien geben mag, dass man lokale Server-Speicherbereiche oder lokale Festplatten stark begrenzt oder verbietet.
Entweder hat Microsoft keine Vorgaben, was wie wo zu erfolgen hat. Oder: Die Szenarien sind so komplex geworden, dass sie schlicht nicht mehr beherrschbar sind.
Ich plädiere für das letztere. Was imho nicht weiter hilft: a) Victim Blaming, b) noch mehr Digitalisierung, c) Null-Fehler-Kultur (das gibt es imho nicht).
Zum Glück muss ich mir darüber keinen Kopf zerbrechen, sondern liefere nur Beschreibungen von Vorfällen und gelegentlich Denkanstöße. Handeln müssen Administratoren und IT-Verantwortliche da draußen.
Administratoren und IT-Verantwortliche? Es gibt auch noch das Thema Schulung der Mitarbeiter, Fahrlässigkeit von Mitarbeitern oder ggf. die Gefahrenabwehr bei Bereitstellungen durch vorherige Consultation des ISB.
Tokens und Schlüssel scheint das Kryptonit von Microsoft zu sein. Anders kann ich mir nicht erklären wieso, in letzter Zeit zu hauf, die Schlüssel dort "verloren" gehen.
Hi,
Afaik kann ein normaler teams user kein bulk export seiner Teams Chatverläufe machen, sondern nur Admin mit Compliance Role. Und mal ehrlich wieso macht man ein solchen Export von ca. 30.000 chatverläufen? (Und vertraut nicht auf Backups..)
Diskutieren wir hier nicht über Nebenkriegsschauplätze? Ich frage für einen Freund. Wäre es jetzt besser, wenn keine Teams Chatverläufe auf dem Storage-Konto gelegen hätten?
Der Kern- und Angelpunkt ist in meinen Augen: Das Zeug ist so komplex geworden und die Cloud verzeiht keine Fehler – müssten wir da vielleicht umdenken …
Ist zwar auch ein wenig "victim blaming", aber ist es nicht reichlich naiv, auf die Fehlerfreiheit einer anderen Partei zu vertrauen? Liegt der Fehler also nicht vielmehr darin, als User nicht hinreichend "paranoid!!!" zu sein?
i.a.W.: Sollten Daten in einer Cloud (die nicht ausdrücklich für die Öffentlichkeit bestimmt sind) nicht immer bereits vor dem Upload (mehrfach*) mit starken Verschlüsselung** verschlüsselt werden?
Heutige Lecks täten erst in vielen Jahren*** weh (unterstellt, dann bestünde überhaupt noch Interesse an viele Jahre alten Daten), wenn man das stets beachtete.
* verschiedene Anbieter und Algorythmen
** 3rd-party-tools, damit der Cloudanbieter keine Hintertür einbauen kann
*** wenn die Rechentechnik sich so weit entwickelt hat, dass heutige Algos+Schlüssellängen mit vertretbarem Aufwand zu knacken sind