Microsoft ist, wie alle Unternehmen von Hackerangriffen ausgesetzt. Dabei kommt es auch immer wieder zu Vorfällen und einer der größten Vorfälle in 2023 ist der des chinesischen Hackerangriffs Storm 0558.
Storm 0558 – Was war und ist passiert?
- Juli 2023
Chinesische Häcker nutzten einen Microsoft-Konto-Verbraucherschlüssel (MSA / z.B. hotmail Konto) um Token für den Zugriff auf OWA und Outlook.com zu fälschen.
Wie kam es zum Verlust des Schlüssels?
- Absturz des Consumer Signing Systems im April 2021 führte zu einem Snapshot mit dem leider nicht geschwärzten Schlüssel. Dies soll nun behoben sein, dass Schlüssel geschwärzt werden in Snapshots.
- Der CrashDump enthielt aber kein Schlüsselmaterial, dies war nicht korrekt und der Scan war fehlerhalft, der dies erkennen und das Verschieben in die Debuggung-Umgebung (mit Internetverbindung) verhindern sollte. Das Problem will Microsoft behoben haben.
- Nach April 2021 konnten Häcker erfolgreich das Konto eines Microsoft Corp Ingenieurs kompromittieren. Leider sind hier Informationen schon gelöscht, durch automatische Aufbewahrungspolicies.
Warum der Zugriff auf Unternehmensmails?
- Seit September 2019 gibt es einen gemeinsamen Endpunkt für die Veröffentlichung von Schlüsselmetadaten (Unternehmen und Consumer Konten).
- Hilfs-API um Signaturen kryptografisch zu validieren, aktualisierte diese Bibliotheken jedoch nicht, um die Validierung des Anwendungsbereichs automatisch durchzuführen (dieses Problem wurde behoben)
- EntwicklerInnen von Exchange dachten, dass die Validierung durchgeführt wurde, war es aber nicht. Also akzeptierte Exchange auch noch die alten April 2021 Schlüssel, statt die von 2022.
Kommentar
Ich werde selber auch immer von chinesischen Häckern angegriffen. Dies wird im Defender for Cloud Apps und in unserem SOC SIEM immer wieder sichtbar. Für uns und mich sind Angriffe aus China, die häufigsten und die größte Bedrohungslage.
Diese Erkenntnis liegt auch bei Microsoft vor, jedoch hätte es nicht alles schiefgehen müssen. Dazu komme leider auch, dass gerade die Behörden, wie BSI, BaFin und auch LDSBs nicht schnell und teilweise bis heute nicht reagiert haben. Microsoft hat auch erst jetzt konkret kommuniziert, was seit April 2021 bis heute passiert ist, dies ist zu spät.
Maßnahmen zur Abwehr
[folgt]
Quelle:
Malware distributor Storm-0324 facilitates ransomware access | Microsoft Security Blog
Übersetzung
“Am 11. Juli 2023 veröffentlichte Microsoft einen Blogbeitrag, in dem beschrieben wird, wie der in China ansässige Bedrohungsakteur Storm-0558 einen erworbenen Microsoft-Konto-Verbraucherschlüssel (MSA) verwendet hat, um Token für den Zugriff auf OWA und Outlook.com zu fälschen. Nachdem festgestellt wurde, dass der Bedrohungsakteur den Verbraucherschlüssel erworben hatte, führte Microsoft eine umfassende technische Untersuchung des Erwerbs des Microsoft-Konto-Verbrauchersignaturschlüssels durch, einschließlich der Frage, wie dieser für den Zugriff auf Unternehmens-E-Mails verwendet wurde. Unsere technische Untersuchung ist abgeschlossen. Im Rahmen unserer Verpflichtung zu Transparenz und Vertrauen veröffentlichen wir die Ergebnisse unserer Untersuchung.
Erwerb des Schlüssels
Microsoft unterhält eine stark isolierte und eingeschränkte Produktionsumgebung. Zu den Kontrollen für den Zugriff von Microsoft-Mitarbeitern auf die Produktionsinfrastruktur gehören Hintergrundüberprüfungen, spezielle Konten, Workstations mit sicherem Zugriff und Multi-Faktor-Authentifizierung mit Hardware-Token-Geräten. Die Kontrollen in dieser Umgebung verhindern auch die Nutzung von E-Mail, Konferenzen, Web-Recherche und anderen Tools für die Zusammenarbeit, die zu häufigen Vektoren für die Kompromittierung von Konten führen können, wie z. B. Malware-Infektionen oder Phishing, sowie die Einschränkung des Zugriffs auf Systeme und Daten mithilfe von Just-in-Time- und Just-Enough-Access-Richtlinien.
Unsere Unternehmensumgebung, die ebenfalls eine sichere Authentifizierung und sichere Geräte erfordert, ermöglicht E-Mail, Konferenzen, Web-Recherchen und andere Tools für die Zusammenarbeit. Diese Tools sind zwar wichtig, aber sie machen die Benutzer auch anfällig für Spear-Phishing, Token-Stealing-Malware und andere Vektoren zur Kompromittierung von Konten. Aus diesem Grund – und als Teil unserer Zero-Trust- und “assume breach”-Mentalität – sollte Schlüsselmaterial unsere Produktionsumgebung nicht verlassen.
Unsere Untersuchung ergab, dass ein Absturz des Consumer Signing Systems im April 2021 zu einem Snapshot des abgestürzten Prozesses (“Crash Dump”) führte. Die Crash Dumps, in denen sensible Informationen geschwärzt werden, sollten den Signierschlüssel nicht enthalten. In diesem Fall konnte der Schlüssel aufgrund einer Wettlaufsituation im Crash-Dump enthalten sein (dieses Problem wurde behoben). Das Vorhandensein des Schlüsselmaterials im Crash Dump wurde von unseren Systemen nicht erkannt (dieses Problem wurde behoben).
Wir stellten fest, dass dieser Crash Dump, von dem wir zu diesem Zeitpunkt annahmen, dass er kein Schlüsselmaterial enthielt, anschließend aus dem isolierten Produktionsnetzwerk in unsere Debugging-Umgebung im mit dem Internet verbundenen Unternehmensnetzwerk verschoben wurde. Dies steht im Einklang mit unseren Standard-Debugging-Prozessen. Unsere Methoden zum Scannen von Anmeldeinformationen haben das Vorhandensein des Schlüssels nicht erkannt (dieses Problem wurde behoben).
Nach April 2021, als der Schlüssel im Crash Dump in die Unternehmensumgebung gelangte, konnte der Storm-0558-Akteur erfolgreich das Unternehmenskonto eines Microsoft-Ingenieurs kompromittieren. Dieses Konto hatte Zugriff auf die Debugging-Umgebung mit dem Crash Dump, der fälschlicherweise den Schlüssel enthielt. Aufgrund von Richtlinien zur Aufbewahrung von Protokollen verfügen wir nicht über Protokolle mit spezifischen Beweisen für diese Exfiltration durch diesen Akteur, aber dies war der wahrscheinlichste Mechanismus, durch den der Akteur den Schlüssel erworben hat.
Warum ein Verbraucherschlüssel auf Unternehmensmails zugreifen konnte
Um der wachsenden Kundennachfrage nach Unterstützung von Anwendungen gerecht zu werden, die sowohl mit Verbraucher- als auch mit Unternehmensanwendungen arbeiten, hat Microsoft im September 2018 einen gemeinsamen Endpunkt für die Veröffentlichung von Schlüsselmetadaten eingeführt. Als Teil dieses konvergierten Angebots hat Microsoft die Dokumentation aktualisiert, um die Anforderungen für die Validierung des Schlüsselumfangs zu klären – welcher Schlüssel für Unternehmenskonten und welcher für Verbraucherkonten zu verwenden ist.
Als Teil einer bereits bestehenden Bibliothek mit Dokumentation und Hilfs-APIs stellte Microsoft eine API zur Verfügung, um die Signaturen kryptografisch zu validieren, aktualisierte diese Bibliotheken jedoch nicht, um die Validierung des Anwendungsbereichs automatisch durchzuführen (dieses Problem wurde behoben). Die Mailsysteme wurden aktualisiert, um den gemeinsamen Metadaten-Endpunkt im Jahr 2022 zu verwenden. Die Entwickler im Mailsystem gingen fälschlicherweise davon aus, dass die Bibliotheken eine vollständige Validierung durchführen, und fügten die erforderliche Validierung des Ausstellers und des Geltungsbereichs nicht hinzu. Daher akzeptierte das Mailsystem eine Anfrage für Unternehmens-E-Mails mit einem Sicherheits-Token, das mit dem Verbraucherschlüssel signiert war (dieses Problem wurde mit den aktualisierten Bibliotheken behoben).
Überprüfung nach dem Vorfall
Microsoft härtet seine Systeme kontinuierlich im Rahmen seiner Defense-in-Depth-Strategie. Die Investitionen, die im Zusammenhang mit der MSA-Schlüsselverwaltung getätigt wurden, werden im Blog https://aka.ms/storm-0558 behandelt. Die in diesem Blog beschriebenen Punkte sind eine Teilmenge dieser Gesamtinvestitionen. Der Übersichtlichkeit halber fassen wir hier die Verbesserungen zusammen, die sich auf diese Ergebnisse beziehen:
- Identifizierte und behobene Race Condition, die es ermöglichte, dass der Signierschlüssel in Crash Dumps vorhanden war
- Verbesserte Prävention, Erkennung und Reaktion auf fälschlicherweise in Crash Dumps enthaltenes Schlüsselmaterial
- Verbessertes Scannen von Anmeldeinformationen, um das Vorhandensein von Signierschlüsseln in der Debugging-Umgebung besser zu erkennen
- Verbesserte Bibliotheken zur Automatisierung der Validierung des Schlüsselbereichs in Authentifizierungsbibliotheken und klarere Dokumentation dazu”