Nachlese zum Storm-0558 Cloud-Hack: Microsoft tappt noch im Dunkeln

[English]Eine mutmaßlich in China angesiedelte Hackergruppe, von Microsoft als Storm-0558 bezeichnet, war der Zugriff auf E-Mail-Konten von etwa 25 Organisationen in der Microsoft Cloud zu erhalten. In einer Nachlese hat Microsoft Ende letzter Woche noch einen "umfangreichen" Text mit einigen wenigen Informationen nachgeliefert, was passiert ist. Kurzfazit: Microsoft ist es wohl gelungen, den (durch Zufall von Kunden entdeckten und gemeldeten) Angriff nach Wochen zu unterbinden. Aber es ist weiterhin unklar, wie die Angreifer an einem missbrauchten Microsoft-Konto (MSA)-Kundenschlüssel gelangten, und (inzwischen korrigierte) Bugs im Azure Code haben wohl den Missbrauch des MSA-Keys ermöglicht.


Anzeige

Rückblick: Hack von Outlook-Cloud-Konten

Mitte Juni 2023 wurde Microsoft von Kunden aus dem US-Außenministerium darüber informiert, dass seit Mitte Mai 2023 unbefugte Dritte Zugriff aus bestimmte E-Mail-Konten von Mitarbeitern hatten. Das Ganze war eine zufällig Entdeckung des Kunden, dem in der Überwachung ungewöhnliche Zugriffe auf Postfächer aufgefallen waren. Die Untersuchung Microsofts ergab dann, dass es einer (mutmaßlichen chinesischen)  Hackergruppe mit dem Namen Storm-0558 gelungen war, in die betreffenden Postfächer einzudringen.

Microsoft hatte zum 11. Juli 2023 den ersten Beitrag Microsoft mitigates China-based threat actor Storm-0558 targeting of customer email veröffentlicht, in dem der Hack eingestanden wurde. Dort hieß es, dass man einen Angriff eines in China ansässigen Bedrohungsakteurs (Storm-0558) auf Kunden-E-Mails entschärft habe. Die Gruppe Storm-0558 zielt laut Microsoft in erster Linie auf Regierungsbehörden in Westeuropa ab und konzentriert sich auf Spionage, Datendiebstahl und Zugriff auf Anmeldeinformationen.

Ich hatte das Ganze im Blog-Beitrag China-Hacker (Storm-0558) in Microsofts Cloud, Outlook Online-Konten gehackt aufgegriffen und erläutert, dass das Ganze brisanter war, als die Darstellung in Microsofts weichgespültem Beitrag erahnen lässt. So steht fest, dass die Angreifer gefälschte Authentifizierungstokens verwendeten, um auf die E-Mails von Benutzern zuzugreifen. Die benötigten Azure AD Authentifizierungstokens konnten sie über einen internen Microsoft-Kontosignaturschlüssel (MSA) für Consumer generieren.

Das Kürzel MSA steht für Microsoft Account. Der Begriff wird für den von Microsoft betriebenen Single-Sign-on-Dienst im Internet benutzt. MSA wird auf Microsoft-Servern in der Cloud verwaltet und die Anmeldung am Microsoft Konto kann dann für viele Webseiten und Dienste verwendet werden. Der obige letzte Satz besagt im Grunde: Die Anmeldung an einem "privaten", für Konsumenten vorgesehenen Microsoft Konto ermöglichten Authentifizierungstokens zu erstellen, mit denen auch auf Microsoft Azure AD (neuerdings als Microsoft EntraID bezeichnet) zugegriffen werden konnte.

Microsoft schrieb zwar, dass man die Verwendung der Authentifizierungstokens schnell unterbunden und später auch den MSA-Key widerrufen habe. Aber die Angreifer hatten viele Wochen Zugriff auf die Postfächer von rund 25 Organisationen. Es stellte sich natürlich sofort die Frage: Wie sind die Angreifer von Storm-0558 an diesen privaten Microsoft-Kontosignaturschlüssel (MSA) gelangt? Und wieso lässt sich dieser MSA-Key für Consumer verwenden, um Azure AD-Tokens zu fälschen? Microsoft vermied in seinem Beitrag das Eingeständnis, dass es sich um Bugs und einen ausgenutzten 0-day handelt.

Microsofts zweiter Bericht – vieles bleibt unklar

Vorigen Freitag, den 14. Juli 2023, hat Microsoft dann einen zweiten Bericht Analysis of Storm-0558 techniques for unauthorized email access zu diesem Vorfall veröffentlicht. Dort wurde der Vorgang nochmals bestätigt und es heißt, dass die betroffenen Kunden direkt benachrichtigt wurden. Zudem seien die Zugriffe der Storm-0558-Gruppe unterbunden und die Infrastruktur gehärtet worden.

2nd report from Microsoft on Storm-0558 Cloud-Hack

Microsoft überwacht "die Situation" und will weitere Schritte zum Schutz der Kunden unternehmen. Es ist ein umfangreicher Bericht mit sehr viel Text, der den Leser quasi mit sehr vielen Nebensächlichkeiten erschlägt. Interessanter sind aber folgende Informationen, die sich im Text finden.

Unklar, wie Hacker an den MSA-Key kamen

Im ersten und zweiten Artikel bestätigt Microsoft, dass die Gruppe Storm-0558 einen sogenannten MSA-Consumer Signing Key (Signierschlüssel) verwendete, um Authentifizierungstoken für Azure AD Enterprise und MSA Consumer für den Zugriff auf OWA und Outlook.com zu fälschen. Hierzu heißt es im Text:


Anzeige

Storm-0558 acquired an inactive MSA consumer signing key and used it to forge authentication tokens for Azure AD enterprise and MSA consumer to access OWA and Outlook.com.

[…]

The method by which the actor acquired the key is a matter of ongoing investigation.

In den herausgezogenen Sätze gesteht Microsoft, dass man noch keine Ahnung hat, wie die Angreifer auf den intern bei Microsoft vorhanden MSA-Signierschlüssel zugreifen und diesen stehlen konnten. Im Text schreibt Microsoft: "Die Methode, mit der der Akteur den Schlüssel erworben hat, ist Gegenstand laufender Ermittlungen."

Der Schlüssel sei "inaktiv", sprich "nicht in Verwendung" gewesen, heißt es weiter. Die einzige Maßnahme, die Microsoft ergreifen konnte, war die Tokens zu sperren und alle  MSA-Schlüssel, die vor dem Vorfall aktiv waren (dazu gehört auch der von Storm-558 verwendete MSA-Signierschlüssel) für ungültig zu erklären.

Bug in der Validierung

In obigem Text wird noch ein weiteres Problem offensichtlich. Wieso lassen sich mit einem inaktiven MSA-Signierschlüssel für Consumer Authentifizierungstoken für MSA Consumer und zusätzlich auch für Azure AD Enterprise generieren, um denn den Zugriff auf OWA und Outlook.com zu erhalten? Von Microsoft heißt es im Originaltext nur:

Though the key was intended only for MSA accounts, a validation issue allowed this key to be trusted for signing Azure AD tokens.

Zu Deutsch: Obwohl der Schlüssel nur für MSA-Konten gedacht war, konnte er aufgrund eines Validierungsproblems zum Signieren von Azure AD-Tokens verwendet werden. Oder im Klartext: Ein Bug im Validierungscode hat dazu geführt, dass die eigentlich ungültigen Authentifizierungstoken akzeptiert wurden. Das Problem sei zwar korrigiert worden, schreibt Microsoft. Aber der Vorgang wirft ein besonderes Schlaglicht auf die Angelegenheit.

Im Bericht von Microsoft liest sich das so, als ob das Unternehmen alles unternommen habe, den Angriff zu stoppen (stimmt zwar, aber als Storm-558 gemerkt hat, dass die Tokens gesperrt wurden, haben die in meinen Augen erkannt, dass der Vektor verbrannt ist und die Aktivitäten zurückgefahren). Da die Wege, wie die Angreifer an den MSA-Key kamen, unbekannt sind, wäre es theoretisch möglich, dass die Gruppe den Ansatz erneut nutzt.

Dazu merkt Microsoft aber an, dass die internen Maßnahmen zur Härtung und Isolierung die Mechanismen zum Zugriff per unauthorisiertem Authentifizierungstoken gewirkt hätte. Seit Microsoft den vom Akteur erworbenen MSA-Signierschlüssel für ungültig erklärt hat, wurden keine schlüsselbezogenen Aktivitäten des Akteurs mehr beobachtet. Außerdem habe man gesehen, dass Storm-0558 zu anderen Techniken übergegangen ist, was laut Microsoft darauf hindeutet, dass der Akteur nicht in der Lage ist, Signierschlüssel zu verwenden oder darauf zuzugreifen.

Viele Worte aber wenig Klartext

Im Bericht erläutert Microsoft umfangreich, was der Angreifer alles mit den gekaperten Konten anstellen und an Daten abziehen konnten und was man nach der Entdeckung zur Härtung unternommen habe. Was aber in den Microsoft-Berichten tunlichst vermieden wird, ist von einer 0-day-Schwachstelle im Code zur Validierung der Tokens zu schreiben.

Sicherheitsforscher Kevin Beaumont schrieb bereits anlässlich des ersten Berichts von Microsoft, dass es für ihn so aussieht, als ob Redmond ein grober Fehler unterlaufen sei. In der nachfolgenden Diskussion auf Mastodon zwischen Beaumont und Dan Goodin (betreut bei ArsTechnica Sicherheitsthemen) geht es darum, dass Microsoft ziemlich um den heißen Brei herum schleicht, sobald es um die Rolle beim eigenen Cloud-Dienst geht.

Die Schwachstellen in der Cloud

Der obige Sachverhalt und die obige Diskussion wirft einen Schatten auf die Frage "wie sicher ist die (Microsoft) Cloud?". Es wird ja häufig argumentiert, dass durch die Migration in die Cloud die Sicherheit automatisch erhöht wird – weil sich der Cloud-Anbieter um die Absicherung kümmere. Am Ende des Tages haben sich die Cloud-Nutzer aber nur eine "Black Box" gekauft, und können nur hoffen, dass darin nicht allzu viele Fehler und Schwachstellen enthalten sind.

Während bei On-Premises-Lösungen Updates verteilt und so ggf. Schwachstellen nicht nur behoben, sondern auch öffentlich bekannt werden, bleibt die in der Cloud verwendete Software oft eine "black box". Der Außenstehende erfährt nicht, ob und wann Schwachstellen in der Cloud-Lösung gepatcht wurden. Von Microsoft gibt es – laut Kevin Beaumont – keine CVE-Kennung für gefundene Schwachstellen in der Cloud. Nur wenn ein Sicherheitsvorfall öffentlich wird, sieht sich der Cloud-Anbieter genötigt, ein paar Informationen offen zu legen.

In diesem Kontext ist mir am Wochenende auch obiger Tweet vom crowstrike-Blog untergekommen, die im Beitrag Adversaries Can "Log In with Microsoft" through the nOAuth Azure Active Directory Vulnerability ein weiteres Problem offen legen. Angreifer könnten sich über die nOAuth-Schwachstelle bei Microsofts Azure Active Directory in der Cloud anmelden, heißt es. Der Beitrag geht auf einen von Descope am 20. Juni 2023 veröffentlichten Beitrag zurück, in dem  beschrieben wird, wie eine Kombination aus einer Schwachstelle in Azure Active Directory und schlecht integrierten Anwendungen von Drittanbietern ("nOAuth" genannt) – eine vollständigen Übernahme von Cloud-Konten möglich werde. nOAuth sei die jüngste in einer Vielzahl von Schwachstellen und architektonischen Schwächen in Microsoft-Software und -Systemen wie Active Directory, die ausgenutzt werden können und Unternehmen in Gefahr bringen, heißt es.

Ergänzung: Frank Carius hat in diesem Artikel noch einige Informationen und Gedanken zum Thema zusammen getragen.

Ä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

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
PowerHell: Achtung, ungefixte Schwachstellen in der PowerShell-Galerie – Teil 3

Azure AD Hack? Seltsame Azure AD IP 20.119.0.42:443 "safe-hse.com" am 13. Juni 2023
Microsoft benennt AzureAD in Microsoft EntraID um


Cookies blockieren entzieht uns die Finanzierung: Cookie-Einstellungen

Dieser Beitrag wurde unter Azure, Cloud, Outlook.com, Sicherheit abgelegt und mit , , , verschlagwortet. Setze ein Lesezeichen auf den Permalink.

11 Antworten zu Nachlese zum Storm-0558 Cloud-Hack: Microsoft tappt noch im Dunkeln

  1. michael sagt:

    Die meisten Firmen in der M$ Cloud haben nichts zu verbergen noch schützenswerte Inhalte. Ist also unkritisch.

  2. Heiko A. sagt:

    "Der obige Sachverhalt und die obige Diskussion wirft einen Schatten auf die Frage 'wie sicher ist die (Microsoft) Cloud?'. Es wird ja häufig argumentiert, dass durch die Migration in die Cloud die Sicherheit automatisch erhöht wird – weil sich der Cloud-Anbieter um die Absicherung kümmere. […]"

    Die Cloud (a. k. a. das Rechenzentrum eines Dritten) ist nicht sicherer als eine On-Premises-Infrastruktur. Beide Infrastrukturen sind nur soweit sicher, wie es die Betreiber zulassen.

    Aus krimineller Sichtweise ist ein Rechenzentrum weitaus lukrativer. Es ist nur ein Ziel, dass man konzentriert angreifen muss, um für den Betreiber a) den größtmöglichen Schaden zu erzeugen und b) für den / die Angreifer den größtmöglichen Erfolg (sei es finanziell und / oder politisch motiviert) zu erzielen.

    Als Kunde muss man einem Rechenzentrumsbetreiber wie Microsoft "blind" vertrauen (können), wenn man sich nicht imstande fühlt, eine geeignete Alternative zu realisieren. Cloud-Lösungen haben – bedingt durch die Rahmenbedingungen – ein vielfach höheres Sicherheitsrisiko. Sie sind aus eigener Erfahrung in den meisten Fällen unwirtschaftlicher als eine On-Premises-Infrastruktur oder eine ortsnah verwaltete Hosting-Lösung, selten auch den Kundenanforderungen entsprechend.

    Und wenn nicht mal Anbieter von "IT-Sicherheitslösungen" die Sicherheit garantieren (können), wie soll es dann Microsoft oder irgendein anderer Anbieter können?

  3. 1ST1 sagt:

    Das ist in der Tat traurig. Aber bis auf das (wichtige!) Detail wie die Hacker an den Schlüssel gekommen sind, ist ja alles aufgeklärt und gefundene Lücken wurden geschlossen.

    Meine Vermutung: Der Schlüssel wurde wo anders gestohlen.

    Fazit: Das Gesamtsystem ist nur so sicher wie das schwächste Glied in der Kette.

    • Peter sagt:

      > Der Schlüssel wurde woanders gestohlen

      Tja, mag sein. Scheint auch bei Intel ein Problem gewesen zu sein.
      Aber das macht es nicht besser. Wenn der Key Intel oder Microsoft gehört und aus der Hand gegeben wird, läuft grundsätzlich etwas falsch.

    • M.D. sagt:

      | […]
      | ist ja alles aufgeklärt und gefundene Lücken wurden geschlossen.
      | […]

      Obige Aussage fällt aber deutlich in den Bereich "Vermutungen".

      | […]
      | Der Schlüssel wurde wo anders gestohlen.

      Na toll. Wie ironisch ist das denn nun wieder. Vom ständigen Microsoft-Schutzpatron im Forum ist das schon eine äußerst schlimme Vermutung. Was hat denn ein Microsoft-eigener Schlüssel in fremden Händen zu suchen und wieso war der nicht mit einem Kennwort geschützt bzw. wie sind die "Diebe" nicht nur an den Schlüssel sondern auch noch an das Kennwort gekommen? Deine vermeintliche Verteidigung ist eher eine zusätzliche Anklage.

      Ich denke, ich darf dann auch noch Vermutungen äußern?

      Ich *vermute* einfach mal, dass mehr Organisationen oder Kunden von dem Vorfall betroffen waren oder sind, als Microsoft bisher öffentlich eingestanden hat. Sie wissen doch ziemlich genau, wer überhaupt nur die Möglichkeit hatte, die unbefugten Zugriffe zu bemerken bzw. wer von den Betroffenen mit wem in Kontakt ist und Informationen zum Vorfall ausgetauscht hat. Alles andere werden sie *vermutlich* unter den Teppich kehren, falls die Betroffenen es nicht selber bemerken und öffentlich machen.

      | […] das schwächste Glied in der Kette.

      Da ist, sollten Deine Vermutungen hinsichtlich Schlüssel stimmen, Microsoft ganz vorne dabei.

      Vom Thema Datenschutz war bisher noch nicht einmal die Rede.

      Was hinsichtlich Verteidigung von Microsoft hier im Forum teilweise vorgebracht wird, hat irgendwie was von Slapstick bzw. grenzt an Wahnsinn.

    • Ralph D. Kärner sagt:

      Und das schwächste Glied in der Kette war nicht der Ort, an dem der Schlüssel gestohlen wurde, sondern der Ort, an dem die Tokens validiert wurden. Merkst Du was? Richtig: das war bei M$. Dein Beitrag kann also nach dem ersten Satz getrost enden, da gibt es nichts mehr schön zu reden.

    • Dirk sagt:

      Also meinem Eindruck nach, ist hier noch nicht einmal das "Wie" halbwegs aufgeklärt. Für mich ist des ungültigmachen von Schlüsseln nur die Bekämpfung eines Symptoms. Die Ursache liegt doch eher zum einen darin, dass eine Schlüssel Token für einen Bereich ausstellen darf, wo der Schlüssel keinerlei Berechtigung haben sollte, und on Top und das ist m.E. fast noch schlimmer, dass der zugehörige Account deaktiviert gewesen sein soll, aber mit dem Schlüssel noch Schindluder betrieben werden konnte, sprich weiter Tokens erstellt werden konnten.
      "Failure by intelligence, by design (MS Windows, by desing MSO), by overburdening, by distress, by incompatence."
      Vielleicht auch ein bisschen von allem?
      Aktuell frage ich mich, ob das Problem nur in der Cloud-Architektur liegt, oder ob das wenigstens zum Teil bewusst so angelegt ist und somit On-Premise genauso betroffen ist.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

Hinweis: Bitte beachtet die Regeln zum Kommentieren im Blog (Erstkommentare und Verlinktes landet in der Moderation, gebe ich alle paar Stunden frei, SEO-Posts/SPAM lösche ich rigoros). Kommentare abseits des Themas bitte unter Diskussion.