Storm-0558

Wussten Sie, dass mutmaßlich chinesische Akteure einen "MSA-Signing-Key" von Microsoft erlangt haben und sich damit ein Access-Token für beliebige Benutzer selbst ausstellen konnten, mit denen dann der Zugriff auf Exchange Online Postfächer von durchaus sensiblen Postfächern möglich war? Doch von von vorne.

Lesen Sie dazu auch meine Nachbereitung auf Storm 0588 Nachbereitung

Die "Lücke wurde von Microsoft anfangs sehr neutral beschrieben und einige Tage lang haben auch Fachmedien die Tragweite nicht erkannt. Heute würde ich sagen, dass die Lücke sehr kritische war. Microsoft hat Sie nach einigen Tagen gestopft aber es muss sehr grundlegende Fehler in der Sicherheitsstruktur gegeben haben. Ich befürchte, dass wir aber auch in Zukunft immer wieder vergleichbare Lücken sehen werden, weil Menschen einfach Fehler machen.

Betroffen?

Vermutlich sind sie nicht betroffen und wenn, dann sollte Sie Microsoft schon angeschrieben haben. Microsoft schreibt dazu selbst:

Beginning May 15, 2023, Storm-0558 used forged authentication tokens to access user email from approximately 25 organizations, including government agencies and related consumer accounts in the public cloud. No other environment was impacted.
Quelle: https://www.microsoft.com/en-us/security/blog/2023/07/14/analysis-of-storm-0558-techniques-for-unauthorized-email-access/

Anscheinend haben sich die Angreifer gezielt auf wenige interessante Tenants und Postfächer beschränkt. Sie hätten aber mit den Rechten aber auch jedes Postfach eines beliebigen Tenants lesen und sich eventuell sogar zu anderen Apps verbinden können. Allerdings vermute ich, das Microsoft durchaus Zugriff auf Protokolle haben kann, um alle Tenants auf genau diese verdächtigen Zugriffe zu untersuchen.

Aktuell können Sie nur darauf vertrauen, dass Microsoft die Lücke geschlossen, die Nachschlüssel ungültig gemacht und alle betroffenen Tenants informiert hat.

Authentifizierung verkackt?

Bis auf wenige Ausnahmen erfolgen alle Zugriff auf Dienste und Daten in der Microsoft Cloud authentifiziert. Es gibt Ausnahmen, z.B. die Teilnahme in einem Teams Meeting als Gast oder der Download von Bildern, CSS- HTML JavaScript etc. wo eine Authentifizierung nur überflüssigen zusätzlichen Aufwand bedeuten würden. Statische anonym erreichbare Inhalte werden meist über ein Content Delivery Netzwerk (CDN) beigesteuert aber die essentiellen Daten und Informationen dürfen nur nach erfolgreicher Legitimation.

Auf verschiedenen anderen Seite der MSXFAQ habe ich dazu schon beschrieben. das OAUTH2 in der Cloud das Maß aller Dinge ist und eine Anmeldung per Kerberos, NTLM oder gar BasicAuth am Dienst schon lange nicht mehr möglich ist. Der eigentliche Service, d.h. z.B. Exchange, OneDrive o.ä. erwartet vom Client ein Zugriffstoken, welches die Identität, die Berechtigungen und die App enthält und von einer vertrauenswürdigen Stelle ausgestellt wurde. All das ist "kryptografisch" abgesichert.

Das klingt alles erst einmal perfekt aber Microsoft hat anscheinend bei der Prüfung dieser Tokens geschludert und auch Tokens vertraut, die von einer fremden Stelle ausgestellt wurden. Das ist quasi so, als wenn Sie mit einer DB-Fahrkarte nun auch bei Flixtrain nutzen könnten oder mit der Kino-Karte ins Freibad gehen.

Wie kam es raus?

Anscheinend ist der Fremdzugriff einem Kunden aufgefallen, der alle Zugriffe protokolliert und ausgewertet hat. Damit ist schon klar, dass es sich wahrscheinlich um einen sensiblen Bereich oder Nutzerkreis gehandelt hat, den ich glaube nicht, dass eine durchschnittliche Firma alle "Mail Read"-Zugriffe protokolliert. Exchange Online hat in dem Fall wohl jeden Zugriff eines Client mit dem Zeitstempel, Mailelement, Client, Netzwerk und vor allem der AppID protokoliert. Über die AppID kann ich wunderbar erkennen, mit welchem Client die Anwender die Daten nutzen und hier wird eine sensible Institution. Bei mir sind erst einmal nur "bekannte" Apps sichtbar

Leider erlaubt das einfache Azure Portal nicht die Gruppierung nach der AppID. Hier müssten Sie diese Logs entweder in Azure Sentinel überführen oder im Portal als CSV-Datei exportieren oder per Graph z.B.: mit MGGraph SignIn Logs exportieren und die Application-IDs kontrollieren.

Als Folge von Storm-0558 hat Microsoft die Haltezeit der Logs erweitert und das vorher kostenpflichtige Auditing der Exchange Aktivitäten in die Standard Lizenz aufgenommen.

Aber ein Auditlog auf Exchange Item-Level mit entsprechende Reporting habe ich bislang zumindest in Deutschland bei noch keinem Kunden in Aktion gesehen

In dem Fall muss es aber die Institution gemacht haben und ist auf die Unregelmäßigkeiten aufmerksam geworden.

Microsoft Gegenmaßnahmen

Der Exchange Online Kunde konnte sich diese Zugriffe natürlich nicht erklären und hat vermutlich über ein entsprechend eskaliertes Ticket um Aufklärung nachgefragt. Im Dokument heißt es dann so schön:

On June 16, 2023, Microsoft was notified by a customer of anomalous Exchange Online data access.
Quelle https://learn.microsoft.com/en-us/exchange/policy-and-compliance/mailbox-audit-logging/mailbox-audit-logging?view=exchserver-2019

Und etwas weiter dann:

Microsoft analysts began investigating the possibility that the actor was forging authentication tokens using an acquired Azure AD enterprise signing key. In-depth analysis of the Exchange Online activity discovered that in fact the actor was forging Azure AD tokens using an acquired Microsoft account (MSA) consumer signing key. This was made possible by a validation error in Microsoft code.

Damit bestätigt Microsoft öffentliche, dass die Überprüfung des Tokens auf Exchange Online einfach fehlerhaft war und Microsoft einem MSA-Token, welche eigentlich nur "Privatanwender" in Rahmen eines "Microsoft Kontos( Vormals Passport oder LiveID) vertraut. Es geht aber noch weiter

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. All MSA keys active prior to the incident – including the actor-acquired MSA signing key – have been invalidated

Irgendwie muss der Angreifer auch noch einen "inaktiven" aber dennoch gültigen Schlüssel zum Signieren selbst erstellter Token "gefunden" haben. Im Bog-Eintrag beschreibt Microsoft dann weiter, was die Angreifer denn so alles mit den erlangten Zugriffsrechten angestellt haben und welche Infrastruktur sie für den Zugriff genutzt haben. Wie sinnvoll hier eine Auflistung der genutzten IP-Adressen ist, lasse ich aber mal dahingestellt. Es werden wohl kaum den Angreifern zuzuordnende Server sein, sondern eher ein paar der überall verfügbare gekaperten unsicheren Wordpress-Server, Proxy-Server o.ä. die bevorzugt über "SoftEther" (https://www.softether.org/) als VPN-Server missbraucht wurden.

Natürlich hat Microsoft von sich aus Gegenmaßnahmen ergriffen. Es dürfte auch so schon peinlich genug sein, so einen Lücke zugeben zu müssen. Laut Blog haben Sie dann.

  • 26. Jun: OWA hat die Tokens nicht mehr akzeptiert
  • 27. Jun: Microsoft hat die Nutzung von MSA-Tokens dieses Ausstellers generell blockiert
  • 29. Jun: Microsoft hat wohl alle MSA Signing Tokens ersetzt und die früheren ungültig gemacht
  • 03. Jul: Microsoft hat nun bei allen betroffenen Kunden die Schlüssel geblockt

Damit sollte diese Lücke nun geschlossen sein und da sich die Angreifer nur auf ausgewählte Kunden konzentriert hatten, dürfe es hoffentlich nicht andere Kunden betroffen haben.

Einschätzung

Wenn ich ehrlich bin, dann habe ich nicht bis ins Detail nun nachvollzogen, was Microsoft hier genau gemacht hat. Tokens sind natürlich einige Stunden gültig aber dass es dann Zwischen der ersten Meldung am 16. Jun und den ersten Gegenmaßnahmen so lange gedauert hat und selbst die Umsetzung sich über mehrere Tage hingezogen hat, finde ich befremdlich. Niemand sollte mit Steinen werfen, denn Code hat immer Fehler aber dass die Qualitätssicherung beim Code zur Verifizierung von Access Tokens diese Lücke nicht gefunden hat, sollte nicht kleingeredet werden.

Microsoft hat auf dem BLOG-Artikel sehr ausführlich die Zusammenhänge und die Analysen hinsichtlich Storm-0558, die genutzten IP-Adressen und Produkte genannt. Sie gehen aber nicht auf ihre interne Verarbeitung genauer ein und ob diese Lücke nun ein Auslöser ist, auch andere Code-Teile zu prüfen. Die Überprüfung von Tokens kommt ja nicht nur in der Cloud vor, sondern auch sie können sich mit AzureAD-Tokens und MSA-Tokens auch bei anderen Diensten anmelden. Wurden auch alle anderen Dienste gewarnt und einbezogen, die einem AzureAD-Token vertrauen?

Ich hätte mir auch gewünscht, dass es z.B. ein Skript gibt, welche die Auswertung der Signin-Logs im eigenen Tenant vereinfacht. Eine Kurzform habe ich hier beschrieben.

Connect-MgGraph -Scopes AuditLog.Read.All,Directory.Read.All
Get-MgAuditLogSignIn -all | group appdisplayname -NoElement | ft -autosize 

Count Name
----- ----
    2 Azure Portal
    1 Dataverse
    1 Microsoft Docs
    6 Microsoft Graph Command Line Tools
    1 Office 365 Exchange Online
    4 Office 365 SharePoint Online
    4 Office Online Core SSO
    2 Office Online Loki SSO
   11 Office365 Shell WCSS-Client
    1 Powell-GraphApi
    1 SharePoint Online Web Client Extensibility
   10 Windows Sign In

So bekommen Sie alle genutzten Apps anhand des Displaynamens und die Häufigkeit heraus. Leider habe ich keine Gegenprobe mit einem Tenant, der so betroffen war um die "unbekannten" Apps zu zeigen.

Angeblich hätte Microsoft alle betroffenen Kunden informiert und alle Maßnahmen getroffen, dass diese Lücke überall geschlossen ist. Wer es positiv sehen will, kann daraus nun einen Vorteil für die Cloud konstruieren, dass der Betreiber die Lücke professionell analysiert, gefunden und gestopft hat, ohne dass Sie als On-Premises Administrator ein Update installiere mussten. Insofern war dies schon bequemer als der Hafnium Exploit Anfang 2021.

Weitere Links