[English]Der Hack von Microsofts Azure-Cloud durch die mutmaßlich chinesische Gruppe Storm-0558 von Mai bis Juni 2023 war durch einen gestohlenen privaten MSA-Schlüssel und Bugs möglich. Damals waren Konten bei Exchange Online und Outlook.com von 25 Organisationen gehackt worden. Unklar war, woher die Angreifer in den Besitz eines privaten MSA-Schlüssel gelangen konnten. Jetzt hat Microsoft bekannt gegeben, dass der MSA-Schlüssel aus einem sogenannten Windows Crash Dump stammte, der auf einem PC von Microsoft erzeugt und dann über ein kompromittiertes System abgezogen wurde.
Anzeige
Rückblick: Storm-0558 Cloud-Hack
Im Juli 2023 wurde bekannt, dass es einer von Microsoft Storm-0558 genannten chinesischen Hackergruppe gelungen war, Zugang zu den in der Microsoft Cloud (Exchange Online, outlook.com) gespeicherten E-Mail-Konten von etwa 25 Organisationen zu erhalten. Dazu gehören auch Regierungsbehörden (US-Außenministerium), sowie zu entsprechenden Privatkonten von Personen, die wahrscheinlich mit diesen Organisationen in Verbindung stehen.
Die Angreifer waren im Besitz eines privaten (MSA)-Kundenschlüssels für Microsoft-Konten, und konnten diesen MSA-Key benutzen, um gefakte Sicherheitstoken (für OWA) zu generieren. Diese Sicherheitstokens ließen sich auf Grund eines Verifizierungsbugs sowohl für Zugriffe auf private Microsoft-Konten (z.B. outlook.com) als auch für Zugriffe auf Azure AD-Konten und wohl auch Azure-Apps missbrauchen.
Microsoft hatte das offiziell eingestanden, spielte aber den Vorfall herunter – ich hatte im Blog-Beitrag China-Hacker (Storm-0558) in Microsofts Cloud, Outlook Online-Konten gehackt erstmals darüber berichtet. Das Ganze entwickelte sich dann zu einem veritablen Sicherheits-GAU, denn die Angreifer tummelten sich beispielsweise seit Mai 2023 unerkannt in den Systemen. Erst als ein Kunde ungewöhnliche Aktivitäten bemerkte, flog der Hack auf. Sicherheitsforscher von Wiz gaben an, dass eigentlich die gesamte Microsoft Cloud-Infrastruktur als potentiell kompromittiert angesehen werden müsste. Die gesamte Entwicklung ist in zahlreichen Blog-Beiträgen nachgezeichnet worden, die am Artikelende verlinkt sind. Unklar war aber, wie die die Angreifer an den privaten MSA-Kundenschlüssel gelangen konnten.
Microsoft nennt die Umstände des Schlüssel-Diebstahls
Nach vielen Wochen der Analyse glaubt Microsoft nun zu wissen, wie die chinesische Hackergruppe Storm-0558 an den privaten MSA-Kundenschlüssel gelangen konnte. Redmond hat das Ganze am 6. September 2023 im Beitrag Results of Major Technical Investigations for Storm-0558 Key Acquisition offen gelegt.
Anzeige
- Es heißt zwar, dass Microsoft eine stark isolierte und eingeschränkte Produktionsumgebung unterhält, wo der Zugang auch kontrolliert wird. Dort wird die Verwendung von E-Mail, Konferenzen, Web-Recherche und anderen Tools blockiert.
- Aber außerhalb der eingeschränkten Produktionsumgebung werden natürlich PCs eingesetzt, auf denen E-Mail, Konferenzen, Web-Recherchen und andere Kollaborations-Tools zulässig und im Einsatz sind. Diese System sind dann auch anfällig für Angriffe (per Spear-Pishing etc.).
Und dann hat sogzusagen Mc Murphy zugeschlagen, d.h. wenn etwas schief geht, dann auch richtig. Microsofts Untersuchung führt zum Ergebnis, dass es im April 2021 zu einem Absturz des Signiersystems für Verbraucher kam. Dabei wurde ein Schnappschuss des abgestürzten Prozesses ("Crash Dump") erzeugt. Normalerweise sollten solche Crash-Dumps keine sensiblen Informationen enthalten bzw. diese sollten unkenntlich gemacht werden. Im Klartext: In diesem Crash Dump hätte niemals ein MSA-Signaturschlüssel enthalten sein dürfen.
Im aktuellen Fall trat jedoch einen sogenannte Race-Condition auf, so dass der private MSA-Kundenschlüssel im Crash-Dump enthalten war (dieses Problem wurde laut Microsoft inzwischen behoben). Der private MSA-Kundenschlüssel im Crash Dump wurde von Microsofts Sicherheitssystemen nicht erkannt (dieses Problem wurde ebenfalls behoben). An dieser Stelle werden also weitere "Bugs" eingestanden, die erst nach dem Vorfall beseitigt wurden.
Weil kein Kontrollsystem anschlug, wurde der Crash-Dump dann aus dem isolierten Produktionsnetzwerk in die Debugging-Umgebung bei Microsoft verschoben. Dort sind die Rechner aber über das Unternehmensnetzwerk mit dem Internet verbunden. Als der private Schlüssel nach dem April 2023 in der Unternehmensumgebung auf einem System lagerte, konnten die chinesischen Hacker der Storm-0558-Gruppe das Unternehmenskonto eines Microsoft-Ingenieurs kompromittieren. Dieses Konto hatte Zugriff auf die Debugging-Umgebung mit dem Crash Dump, in dem der private MSA-Kundenschlüssel ungewollt enthalten war.
Microsoft besitzt zwar (aus regulatorischen Gründen, die die Richtlinien zur Aufbewahrung von Protokollen umfassen) keine Protokolle mit spezifischen Beweisen für die Exfiltration durch diesen Akteur. Redmond geht aber davon aus, dass dies der wahrscheinlichste Mechanismus war, über den der Akteur den Schlüssel erworben hat.
Verdammt viele Zufälle, oder Insider-Job und Schlamperei?
Lassen wir doch mal die Erklärungen Microsofts etwas wirken. An dieser Stelle hat Microsoft zwar eine Vermutung geäußert, wie es wahrscheinlich gewesen sein könnte. Das lässt sich zwar nicht von der Hand weisen, aber ein harter Beweis fehlt. Was mich jetzt als außenstehenden Beobachter stutzig macht, ist diese Kette von unglaublichen Zufällen.
- Die chinesischen Angreifer konnten genau das Unternehmenskonto eines Microsoft-Ingenieurs kompromittieren, der zufällig Zugriff auf die Debug-Umgebung hatte.
- Und dann war auch noch der unwahrscheinliche Fall gegeben, dass dort zufälligerweise ein Crash-Dump des Vorfalls aus der Produktivumgebung lagerte.
- Und zufälligerweise enthielt dieser Crash-Dump auch noch diesen MSA-Schlüssel, der dort eigentlich nicht enthalten sein sollte, aber auf Grund einer Race-Condition doch vorlag.
Müßig zu erwähnen, dass die chinesischen Angreifer auch noch wussten, wo sie welche Dateien finden können, den Dump abziehen konnten, dann analysierten und in der wüsten Folge von Hex-zahlen den privaten MSA-Schlüssel isolieren konnten. Wenn man den Kommissar Kienzle im Tatort befragt, käme sofort die Antwort "So viele Zufälle gibt es nicht".
Und es gibt noch ein feines Detail, welches ich im Beitrag Sicherheitsrisiko Microsoft? Feuer von der US-Politik nach Microsofts Azure Cloud-GAU und Forderung zum Microsoft Exit – Teil 1 offen gelegt hatte. Der bei obigem Hack verwendet MSA-Schlüssel wurde von Microsoft im Jahr 2016 erstellt und ist im Jahr 2021 abgelaufen. Es ist unglaublich und unerklärlich, dass dieser abgelaufene MSA-Key zur Generierung von Sicherheitstokens verwendet werden konnte. Und es ist auch nicht erklärbar, dass Microsoft über einen einzigen "Generalschlüssel" verfügt, mit dem Tokens für Zugriffe auf die Azure-Cloud und deren Dienste erzeugt werden können. Hier möge jeder Leser und jede Leserin eigene Schlüsse ziehen.
Warum der MSA-Schlüssel verwendbar war
Microsoft hat sich im oben verlinkten Artikel auch dazu geäußert, warum es überhaupt möglich war, mit einem privaten MSA-Konsumentenschlüssel Sicherheitstokens für Unternehmenskonten in Exchange Online und OWA zu erzeugen. Im September 2018 hat Microsoft einen gemeinsamen Endpunkt zur Veröffentlichung von Schlüsselmetadaten eingeführt. Das war das Ergebnis einer wachsenden Kundennachfrage nach Unterstützung von Anwendungen, die sowohl mit Verbraucher- als auch mit Unternehmensanwendungen arbeiten. Auch hier schlug Genosse Zufall zu:
- Microsoft stellte seinerzeit, als Teil einer bereits bestehenden Bibliothek mit Dokumentation und Hilfs-APIs, eine API zur Verfügung, um die Signaturen kryptografisch zu validieren.
- Allerdings wurden die Bibliotheken, die die Validierung des Anwendungsbereichs automatisch durchzuführen sollten, nicht aktualisiert – dieses Problem ist behoben.
- Die Mailsysteme, um den gemeinsamen Metadaten-Endpunkt im Jahr 2022 zu verwenden, wurden zwar aktualisiert. 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.
In Konsequenz 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 inzwischen ebenfalls behoben). Auch hier kristallisiert sich heraus, dass eine Kette von Versäumnissen dazu führte, dass der Verlust eines privaten MSA-Kundenschlüssels zu diesen Auswirkungen führte.
Abschließende 2 Cents
Die jetzt von Microsoft veröffentlichten Informationen sind zwar lobenswert. Aber auch hier möge jeder Leser und jede Leserin eigene Schlüsse ziehen, wie es um die Zuverlässigkeit Microsofts bestellt sein muss. Persönlich vergesse ich immer, dass es sich bei Microsoft um ein Großunternehmen mit sehr vielen Angestellten handelt – und in Großunternehmen geht schief, was schief gehen kann.
Der Nimbus, dass Microsoft eine Firma mit geballter Kompetenz ist, die wissen, was sie tun, ist mit diesem Vorfall und den öffentlich gewordenen Informationen auf jeden Fall pulverisiert worden. Und wenn ich dann sehe, wie Microsoft seine Kunden gängelt, wird es Zeit, das Unternehmen an die Kandare zu nehmen, in verschiedene Teile zu zerschlagen und harten Regularien zu unterziehen. Andernfalls wird Microsoft die gesamte IT-Welt mit den angebotenen Produkten in den Abgrund ziehen.
Ä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-0548: US-Senatoren unter den Opfern; Prüfpflicht für europäische Verantwortliche
Nachgehakt: Storm-0558 Cloud-Hack und Microsofts Schweigen
Mehr als 60.000 E-Mails des US-Außenministeriums beim Microsofts Storm-0558 Cloud-Hack abgegriffen
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
Anzeige
Naja wie sie selbst sagen: zu viele Zufälle… ist halt ein Erklärungsversuch um nicht zugeben zu müssen das der NSA Masterkey abhanden gekommen ist. Diese Gerüchte über solch einen Key existieren ja schon weit vor dem Abhandenkommen und Gerüchte haben meistens einen Funken Wahrheit ;-P Bisher konnte das erfolgreich vertuscht werden, jetzt wird die Luft langsam dünn.
Eine Räuberpistole wie so oft bei MS. Offen zuzugeben, dass man sich einfach reingehackt hat, wäre auch schlecht für die Aktionäre gewesen. So dachte man sich wohl dieses Märchen von Onkel Bill aus.
Ja M$ stellt eine globale Bedrohung für die ganze Wirtschaft dar. Da M$ auch im Gesundheitswesen zum Einsatz kommen, gefährdet M$ damit auch Menschenleben. M$ gehört schon längst zerschlagen und juristisch eingenordet. Aber wer gut schmiert, fährt auch besser.
Bei aller fehlenden Sympathie zu diesem Saftladen, NEIN
Gesundheitswesen ist nicht gleich Menschenleben,
Alles im Gesundheitswesen was mit abrechnugn versicherung etcpp zu tun hat ist irrelevant fürs Menschenleben.
Und alle Systeme welche was mit einem Menschenleben zu tun haben, gehören nicht ans Internet, die müssen so abgeschirmt sein das sie auch mit einem Windows XP SP0 100% sicher sind.
"Alles im Gesundheitswesen was mit abrechnugn versicherung etcpp zu tun hat ist irrelevant fürs Menschenleben."
Das denke ich nicht, Tim.
Ich werde mich dazu jetzt nicht näher auslassen, weil zu viele private Details, aber ich bin Schlaf-Apnoeiker. Aber wenn wegen Abrechnungsfehlern mein Gerät eingezogen würde, dass dafür sorgt, dass ich nachts nicht aufhöre zu atmen, dann wäre da durchaus ein Menschenleben in Gefahr. Wie bei jedem anderen Apnoe-Patienten auch.
Dein Gerät gehört nicht ans Internet, damit kann es nicht eingezogen werden.
Und wen ein herlassen vor deiner Tür steht und nach dem gerät verlangt sag ihm das hat ein anderer schon abgeholt.
Ich würde niemals ein lebenswichtiges gerät herausgeben, egal wer es zurück verlangt.
Mag sein, dass solche Systeme nicht ans Internet gehören aber erstens gibt es keine einheitlichen Regelungen (dazu zählt dieser Zertifizierungsmist des BSI nämlich NICHT) für eingesetzte Software und zweitens sind ebendiese Hersteller mit ihrem Onlinezwang auch daran schuld. Der Softwarehersteller verkauft dir die Software und als Basis gibt es Windows + Adminrechte. Das muss so sein, weil die Software nur so einwandfrei funktioniert. Die Aktivierung der Software hat man sich von Microsoft abgeschaut. Spätestens alle 6 Monate muss die Software zum Hersteller telefonieren sonst ist die Installation unbrauchbar. Dazu kommt die Software selbst. Die erzeugten Daten werden für die Statistik mit Excel und Word erzeugt. Außerdem werden die Daten Datenschutzkonform lokal gespeichert, nicht davon betroffen sind aber die Kalibrierungsdaten. Und die liegen ganz komfortabel in der Cloud des Softwareherstellers. Und auch hier kocht jedes Softwareunternehmen sein eigenes Süppchen. Ich arbeite für eine Universitätsklinik und sehe das als betroffener Admin jeden Tag.
Es braucht bundesweite einheitliche Vorgaben. Damit meine ich nicht diesen BSI Mist. Erst wenn die Hersteller ihren Mist so anbieten dürfen, dass die Angriffsfläche minimiert ist, sollte deren Software überhaupt im Gesundheitswesen erlaubt sein. Aber solange die Softwarehersteller den Kliniken die Regeln für den Einsatz der Geräte und der Software vorgeben können, so lange wird es auch weiterhin Inteenetfähige medizinische Geräte geben.
Zufälle sind immer eine gute Erklärung, kann man dann doch so tun, als sei keine Fahrlässigkeit im Spiel.
Warum der angebliche Problembär, also der Crash-Dump nach 2 Jahren immer noch auf der Maschine rumliegt, wollen sie aber wohl nicht erklären. Das ist halt so.
Und warum ein "Signiersystem für Verbraucher" einen solchen Key überhaupt hält, lässt sich auch nur mit "wir machen nicht Standard" erklären. Klingt irgendwie nach dem Microsoft-Vertragssystem, wo man mit seinen Microsoft-Admin-Credentials Verträge "unterschreibt".
Eine Lösung, bei der unsere Chefetage aus dem Kopfschütteln gar nicht mehr rauskam.
Wer sagt denn, dass der Crashdump 2 Jahre da rum lag? Kann ja auch sein, dass der Crashdump schon vor 2 Jahren von 558 erbeutet wurde und sie so lange ausgewertet haben, bis sie den Key gefunden und verstanden haben was man damit anstellen kann.
Mir macht vor allem Sorgen, dass 558 den Key tatsächlich von einem PC in MS Büros erbeutet werden konnte. Hier hat MS den Hack ihrer eigenen internen Office-Infrastruktur zugegeben. Wenn schon die nicht ihren Laden abdichten können, wie soll es dann irgendjemand da draußen mit seiner Umgebung können?
"Wer sagt denn, dass der Crashdump 2 Jahre da rum lag?"
Na Microsoft. Die Timeline geht April 21 –》April 23.
"Und wenn ich dann sehe, wie Microsoft seine Kunden gängelt, wird es Zeit, das Unternehmen an die Kandare zu nehmen, in verschiedene Teile zu zerschlagen und harten Regularien zu unterziehen."
Hm…. die Forderung Google oder Microsoft zu zerschlagen und in verschiedene Teile aufzuteilen hört man ja immer wieder. Ist für mich etwas plakativ.
Weil, wie soll den so eine Zerschlagung in der Praxis aussehen und was hätte sie in dem Konkreten Fall hier gebracht. Eine Zerschlagung muss sinnvoll erfolgen. Was könnte man also in der Praxis abspalten…. den Xbox Bereich, den BING Bereich. Aber schon eine Abspaltung vom Office Bereich wird schwierig.
Office 365 hat im Enterprise Umfeld Berührungspunkte mit Azur. Windows ebenfalls. Also wird es schon mal schwierig, Office, das Betriebssystem und Azur voneinander zu trennen. Auch den Home Bereich vom Enterprise Bereich zu trennen geht nicht, weil beide Bereich auf die gleichen Produkte zurückgreifen.
Also an welcher Stelle hätte denn so eine Aufspaltung in dem konkreten Angriffsfall geholfen, außer dass Spielstände auf der Xbox den Angreifern nicht in die Hände gefallen wären.
Office wird doch gerade abgetrennt, so dass man das selbst hosten können soll.
Siehe hier im Blog "Änderungen bei Microsoft 365 und Office 365 wegen EU-Wettbewerbsbedenken".
Da eben die Entbündelung eine Kernanforderung an Unternehmen im Wettbewerbsrecht darstellt, ist natürlich auch eine "Entbündelung" der Unternehmen möglich. Immer.
Es wird nur Teams von Office losgelöst, sonst nichts.
Den Hausmeister und den Pförtner könnte man outsourcen. Ach, haben sie schon?
Ich glaube ehr, dass das Problem bei Office in der Zukunft noch schlimmer wird. Der Desktop Client von Outlook wurde ja gerade abgekündigt (wird eine WebAPP) und damit wird es ein lokales Office (LTSC) wohl bald nicht mehr geben.
Microsoft drückt massiv in Richtung Cloud, damit der Anwender entmündigt wird. Ziel ist ganz klar, dass der Kunde die grundlegenden Prozesse nicht mehr kennt und damit vollständig von Microsoft abhängig wird. Man siehe nur Python Support für Office, aber Berechnung nur in der Cloud.
Auch das Ende des OnPrem Exchange ist aus meiner Sicht nur eine Frage der Zeit. Client-Anwendungen werden dem Cloudzwang wohl früher zu Opfer fallen als Server, auch weil derzeit nicht alle Unternehmen genug Bandbreite haben, um alles permanent mit der Cloud zu synchronisieren.
Das Microsoft im Interesse der Kunden arbeitet glaube ich schon lange nicht mehr. Die Ganze Entwicklung schwebt in Ihrer eigenen Blase und hat den Kontakt zum Kunden vollständig verloren. Umgesetzt wird was gut für Microsoft ist.
Solange die EU da nicht reguliert und für Grundfunktionen ein Recht auf Wahl des Rechenzentrums einräumt (Microsoft Cloud, anderer Hoster oder lokal) wird sich da auch nichts ändern. Es kommt der Tag der kollabiert das Ganze. Leider wird keiner lachen, denn die Auswirkungen werden wir dann wohl alle zu spüren bekommen.
Exakt an diesen Stellen muss entbündelt werden und es ist gar KEIN Problem wenn man dann einfach offene sauber dokumentierte Standards und APIs verwendet! Dann kann dein Azure sogar mit Libre Office perfekt zusammenarbeiten…
Bei "Zerschlagungen", die es in der Vergangenheit ja schon gegeben hat, geht es darum, ein als marktbeherrschend eingestuftes Unternehmen in mehrere miteinander konkurrierende aufzuteilen und so den Wettbewerb wiederherzustellen.
Ob eine Aufteilung in dem konkreten Fall geholfen hätte, werden wir nie wissen. Die Annahme ist jedenfalls, dass, wenn ein Wechsel zu einem anderen Anbieter möglich ist, Kunden den in einem solchen Fall verstärkt vornehmen werden und die Anbieter daher eine höhere Motivation haben, das Auftreten solcher Fälle zu verhindern. Eine, wie ich finde, durchaus plausible Annahme.
natürlich wissen sie, was sie tun, sonst wären sie nicht da, wo sie nun stehen. Monopilist für lokale als auch cloudbasierte Officelösungen.
Technisches oder menschliches Versagen ist normal, ob da MS, Alphabet oder Meta draufsteht.
Der Punkt ist: wenn man seine Daten auslagert, muss man damit rechnen.
Zusammengefasst weiß MS also weiterhin nicht wie der Schlüssel seinen Weg ins freie gefunden hat.
Das einzige was MS hier aufführt ist ein möglicher Weg wie der Schlüssels über ein sehr theoretisches Szenario abgegriffen worden sein kann. Eine Verkettung von vielen unglücklichen Zufällen die sehr unwahrscheinlich ist. Genau so theoretisch könnte der Schlüssel in einer Textdatei auf einem Desktop gelegen haben oder er wurde aus der Zwischenablage abgegriffen.
Es wurden in letzter Zeit auch "hochrangige" MA dort freigestellt und die haben ein starkes Motiv, das Wissen, die Möglichkeit und es könnte in Zukunft noch viel mehr dort erfolgen, falls die es überhaupt merken sollten, das was MS da nun so behauptet könnte aber auch ganz anders "abgelaufen" sein!
Die Erklärung ist so krude und kaputt das
– sie tatsächlich stimm weil wohl kaum niemand so was sich als Erklärung aus den Fingern saugt
oder
– es alles noch viel schlimmer ist und das noch die geschönte Variante ist.
Gruß
Hacker gehen so krude und kaputt vor, da musst du dich dran gewöhnen. Die "normalen" "offensichtlichen" Wege sind ja hoffentlich schon abgedichtet. Hol dir mal eine Firma ins Haus, die dir einen internen Pen-Test machen. Die knacken dir auch dein ach so sicheres Betriebssystem wo jeder in den Quellcode reinschauen kann, versprochen.
Wahre Worte!
"Der Nimbus, dass Microsoft eine Firma mit geballter Kompetenz ist, die wissen, was sie tun, ist mit diesem Vorfall und den öffentlich gewordenen Informationen auf jeden Fall pulverisiert worden" – wirklich pulverisiert? MS hat eine Weile geschwiegen, was alle machen, die zu feige sind, Fehler einzugestehen. Dann, wenn sich das Umfeld beruhigt, kommt man mit den dämlichsten Erklärungen um dann später behaupten zu können, "es wurde alles großartig und sorgfältig beleuchtet" ("major technical investigation").
Solange der US-Senator, der sich angeschickt hat, MS mit Untersuchungen und, wenn sich der Verdacht der "negligence" bestätigt, empfindlichen Strafen zu belegen, nicht am Ball bleibt, fährt der Zug ab und niemand, wirklich niemand wird MS hops nehmen. Dann wäre nichts pulverisiert worden, sondern MS gegenüber nur bewiesen worden, dass die sich alles erlauben dürfen.
Die wenigen, die wirklich durchblicken, wie unfassbar nachlässig da gearbeitet wird, fallen doch gar nicht ins Gewicht.
"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."
Erste Regel für professionelle Programmierung:
"Traue niemals Daten die von Draußen kommen"
Für mich klingt das alles nach Ammenmärchen.
Nach "plausible Rückwärts-Erklärung" wie es die NSA für Gerichtsprozesse macht, da in den USA illegal erlangte Indizien nicht vor gericht zugelassen sind (in Deutschland kann der Richter solche zulassen).
Es entsteht der Eindruck: Es muss eine möglichst komplexe Story erzählt werden, sonst könnte die Bevölkerung verunsichert werden.
tja mit jeder weiteren erklärung sollten die entscheider für cloud und ms mehr und mehr dahinter kommen, dass es vielleicht an der zeit wäre, das system zu wechseln. wenn es der hersteller schon nicht sicher bekommt ob der zig lücken, die darin vorhanden sind, wie soll es dann der kunde sicher bekommen, der vielleicht weit aus weniger einblick in die produkte hat als der hersteller.
achja wie immer trefflich zusammengefasst und sehr unterhaltsam –> https://blog.fefe.de/?ts=9a075ef7
Ja, ganz trefflich. Jedoch schreibt auch fefe nichts über den eigentlichen Knaller: Microsoft schreibt kein Wort dazu, warum es möglich war, dass ein vor Jahren abgelaufener Signaturschlüssel noch neue Konten erstellen konnte. Also "race condition" passt hier sicherlich nicht ;-)
Mußt dann halt noch ein Antivirenabo und eine MDM mit kaufen :-)
Ich halte Crash Berichte übrigens für ein massives Datenschutzproblem.
Sie sind absolut sinnvoll zur Fehleranalyse, aber:
Spiele senden z.T. auch 100 MB große Crash Dump Files an die Entwickler, ohne dass der Nutzer weiß, was da alles an Daten mit gesendet wird?
Alle geöffneten Programme? Klar! Alle geöffneten Websites, Nutzernamen, aktiven Logins? Zertifikate? Hardwarekonfiguration und damit diverse Hardwareschwachstellen sowieso.
Wer hat Zugriff auf die Daten, wie lange werden sie auf Servern gespeichert? Was können Hacker aus diesen Daten an Informationen extrahieren?
"◾Allerdings wurden die Bibliotheken, die die Validierung des Anwendungsbereichs automatisch durchzuführen sollten, nicht aktualisiert […]"
Auch das ist GAAANZ typisch (nicht nur) für Microsoft: diese Frickler aktualisieren die (Produktions-)Systeme, auf denen sie ihre eigene Software bauen, NICHT (siehe das mit Windows gelieferte OpenSSH oder das in MEHREREN "Produkten" missbrauchte OpenSSL) bzw. erst nach MEHRFACHEN Hinweisen auf solche Schlampereien (siehe das mit Windows gelieferte cURL).
EINMAL mit Profis arbeiten!
Wenn's etwas länger her sein darf: schon vor 10 (in Worten: ZEHN) Jahren konnte (oder wollte) Microsoft NICHT erklären, wer eine Hintertür in das Installationsabbild von Windows Embedded POSReady 2009 eingebaut hatte (siehe https://seclists.org/bugtraq/2013/Aug/145 alias https://seclists.org/fulldisclosure/2013/Aug/225)
Kann man eigentlich die von Microsoft in Windows eingebauten Fremdbiliotheken selbst ohne Microsoft aktualisieren?
Dann könnte man wenigstens selbst die Schlafmützigkeit von Microsoft ausbügeln.
"Diese Sicherheitstokens ließen sich auf Grund eines Verifizierungsbugs sowohl für Zugriffe auf private Microsoft-Konten (z.B. outlook.com) als auch für Zugriffe auf Azure AD-Konten und wohl auch Azure-Apps missbrauchen."
Das ist in dieser Form falsch bzw. SEHR unglücklich formuliert: der "Bug" erlaubte über mit dem für Konten von PRIVAT-Kunden vorgesehenen MSA-Schlüssel signierte Sicherheitsokens den Zugriff auf Konten von FIRMEN-Kunden.
Anders ausgedrückt: die mit dem (wie auch immer geleckten) MSA-Schlüssel signierten Sicherheitstokens erlaubten BESTIMMUNGSGEMÄSS den Zugriff auf Konten von PRIVAT-Kunden (u.a. Outlook.com); wegen der fehlerhaften Prüfung war auch Zugriff auf die Konten von FIRMEN-Kunden möglich.
UND: Microsoft hat bisher KEINERLEI Anstalten unternommen, betroffene PRIVAT-Kunden zu informieren — obwohl sie dazu in der EU per DSGVO/GDPR gesetzlich verpflichtet sind!
Der Zugriff war nicht bestimmungsgemäß, denn der MSA-Schlüssel war zu dem Zeitpunkt schon lange abgelaufen. Der MSA-Schlüssel hätte also gar nicht mehr funktionieren dürfen.
Hätte es nicht einen Bug im Microsoft-Universum gegeben, durch den der abgelaufene MSA-Schlüssel akzeptiert wurde, wäre durch den Leak des Schlüssels nichts passiert. Wahrscheinlich hätte dann niemand den Leak mitbekommen.
@Günther Born: Vielen Dank für Ihre tolle Arbeit. Können Sie in Ihrer Berichterstattung zu diesem Thema hier ggf. die Schreibweise der Gruppierung Storm-0558 vereinheitlichen? In diesen Artikel wird die Bezeichnung Storm-0588 anstelle Storm-0558 verwendet und ich denke "Storm-0558" ist die korrekte Bezeichnung
Ist jetzt durchkorrigiert – auch in den anderen Artikeln. Danke.