Interview: Der kleingeredete Storm-0558 Hack der Microsoft Cloud

Bei Microsoft gab es im Mai 2023 einen Zugriff auf die Cloud (Exchange Online) durch die mutmaßlich staatsnahe chinesische Hackergruppe Storm-0558. Offiziell bekannt ist, dass dabei E-Mail-Konten von 25 Organisationen gehackt wurden. Ich hatte die Entwicklung und die bisher bekannt gewordenen Fakten, Versäumnisse und Fehler Microsofts im Blog in diversen Beiträgen nachgezeichnet. Nun gibt es bei Kontrafunk ein Interview mit mir zu diesem Vorfall, wo der kleingeredete Vorfall nochmals beleuchtet und einige Einschätzungen gegeben werden.


Anzeige

Der Storm-0558 Cybervorfall

Microsoft hat sich einen sogenannten MSA-Key klauen lassen, eine Art Generalschlüssel für die Azure Cloud. Laut einer Veröffentlichung von Microsoft im Juli 2023 wurde ein Angriff auf Kunden seines Exchange Online-Diensts, der in der Microsoft Azure Cloud bereitgestellt wird, festgestellt. Der Vorfall wird von Microsoft kein geredet, es seien nur wenige Kunden betroffen. Sicherheitsforscher haben aber herausgefunden, dass prinzipiell die gesamte Microsoft Cloud kompromittiert wurde.

MSA-Schlüssel öffnet die Microsoft Cloud

Betroffen waren laut Microsoft weitgehend nur E-Mail-Konten (privat und beruflich) von etwas 25 Organisationen – ein Großteil waren wohl im und für das US-Außenministerium tätig. Der Zugriff war für die Angreifer möglich, weil diese an einen privaten sogenannten (MSA)-Kundenschlüssel herangekommen sind. Diese Schlüssel benutzt Microsoft intern für private Microsoft-Konten (outlook.com-Mails, etc.), um bei der Anmeldung ein sogenanntes Sicherheitstoken zu generieren.

Mit diesem Sicherheitstoken, welches von Apps, einem E-Mail-Programm oder einer App verwendet wird, kann sich die Anwendung an allen Diensten dieses Kontos (OneDrive, Office, outlook.com, Skype etc.) automatisch anmelden. Die Angreifer waren damit in der Lage, sich mittels des MSA-Keys selbst Sicherheitstokens auszustellen. Sie konnten also ohne Zugangsdaten auf die gewünschten E-Mail-Konten zugreifen. Microsoft beschuldigt die mutmaßlich staatsnahe chinesische Hackergruppe Storm-0558 für den Angriff verantwortlich zu sein.

Ziemlich wenig an Informationen

Auffällig war, dass Microsoft in einer ersten Meldung nur minimale Informationen zum Sachverhalt in einem sehr langen Text veröffentlichte (siehe auch China-Hacker (Storm-0558) in Microsofts Cloud, Outlook Online-Konten gehackt). Dort stellte sich Microsoft positiv dar, der Angriff wurde sofort durch Sperren des MSA-Schlüssels unterbunden, es waren nur 25 Organisationen betroffen, die wurden alle benachrichtigt. Tenor: "Gehen Sie weiter, es ist nichts passiert."

Erst im Laufe der Zeit kamen neue Eingeständnisse Microsofts hinzu (siehe Nachlese zum Storm-0558 Cloud-Hack: Microsoft tappt noch im Dunkeln) und Informationen von Dritten (siehe GAU: Geklauter AAD-Schlüssel ermöglichte (Storm-0558) weitreichenden Zugang zu Microsoft Cloud-Diensten). Entdeckt wurde der Hack im Juni 2023, öffentlich wurde es Anfang Juli 2023. Die Angreifer waren aber seit Mai 2023 unerkannt im System. Es geht im konkreten Fall wohl um die Ausforschung von Mitarbeitern des US-Außenministeriums oder anderer staatlicher Stellen.

Wie wurde das Leck entdeckt

Der Angriff wurde nicht durch Microsoft entdeckt  sondern durch einen aufmerksamen Mitarbeiter der IT im US-Außenministerium, dem ungewöhnliche Zugriffe aus einer App auf die E-Mail-Konten aufgefallen waren. Dieser meldet dies an Microsoft sowie die US Cybersecurity-Behörde CISA. Dabei wurde ein besonderes Problem sichtbar: Den meisten Kunden der Microsoft Cloud hätte ein Angriff gar nicht auffallen können, da für die Beobachtung der Zugriffe eine besondere Software erforderlich ist, die Microsoft aber nur zahlenden Kunden bereitstellte.

Das US-Außenministerium hatte bei Beschaffung der Software gehörig Druck auf Microsoft gemacht, so dass man diese Überwachungsfunktionen (Purview Audit (Premium) Protokollierung) kostenfrei bekam. Auf Grund dieses Vorfalls wird diese Funktionalität inzwischen allen Kunden kostenfrei bereitgestellt (siehe Nach CISA-Bericht zum Storm-0558-Hack stellt Microsoft Kunden erweitertes Cloud-Logging bereit).

Potentiell ist die gesamt Microsoft Cloud betroffen

Brisant erschien mir bereits bei der ersten Veröffentlichung Microsofts, dass die Angreifer einen MSA-Schlüssel für Consumer in die Finger bekamen, aber mit diesem Schlüssel Sicherheitstokens für beliebige Azure Konten – auch Business-Konten – fälschen konnten. Microsoft hat dann in Verlautbarungen eingestanden, dass Fehler in den Azure-Routinen zur Ausstellung/Überprüfung dieser Sicherheitstokens den Zugriff auf Consumer- und Business-Konten ermöglichte. Die Fehler sollen nun behoben sein.


Anzeige

Sicherheitsforscher des Unternehmens Wiz haben sich die Details, die bisher öffentlich wurden, dann nochmals genauer angesehen und kamen zum Schluss, dass der Sicherheits-GAU viel größer als durch Microsoft eingestanden war (siehe GAU: Geklauter AAD-Schlüssel ermöglichte (Storm-0558) weitreichenden Zugang zu Microsoft Cloud-Diensten). Mit dem MSA-Schlüssel für Consumer konnten die Angreifer Sicherheitstokens zum Zugriff auf jedes beliege Azure-Konto fälschen – potentiell war also jedes Azure-Konto und jede Azure-App von diesem Vorfall betroffen.

Und es gibt noch eine weitere brisante Erkenntnis, die durch US-Senator Ron Wyden öffentlich wurde (siehe auch Sicherheitsrisiko Microsoft? Feuer von der US-Politik nach Microsofts Azure Cloud-GAU und Forderung zum Microsoft Exit – Teil 1). 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 im Jahr 2023 zur Generierung von Sicherheitstokens verwendet werden konnte.

Kette an Fehlern und Versäumnissen

Geht man die Informationen durch, die in diesem Vorfall von Microsoft und Dritten öffentlich geworden ist, zeigt sich eine Kette gravierender Fehler und Versäumnisse durch Microsoft, die diesen Angriff erst ermöglichten.

  • Es ist unglaublich, dass es möglich war, mit einem MSA-Key für Consumer auch auf Business-Konten für Azure zuzugreifen. Das ist schon fahrlässig – der Fehler ist zwar korrigiert, passierte durch interne Umstellungen bei Microsoft.
  • Nicht nachvollziehbar ist auch, dass es möglich war, einen 2021 abgelaufenen MSA-Schlüssel auch noch im Jahr 2023 zu verwenden. Abgelaufene Schlüssel dürfen nach dem Ablaufdatum nicht mehr verwendbar sein – das offenbart gravierende Mängel in der Qualitätssicherung.
  • Und es ist auch nur schwer nachvollziehbar, dass Microsoft eine essentielle Funktion (Purview Audit (Premium)-Protokollierung) zur Auswertung der Zugriffe auf bestimmte Konten/Daten nur gegen Vergütung bereitstellte. Die meisten Kunden waren sozusagen "blind" – inzwischen ist das auf Druck der US-Sicherheitsbehörde CISA korrigiert – alle Kunden bekommen die Funktionen nun kostenfrei.

Weiterhin muss auch gefragt werden, wie die Angreifer überhaupt an einen geheimen MSA-Schlüssel herankommen konnten. Dieser stellt ja sozusagen die Kronjuwelen dar, die keinesfalls in fremde Hände gelangen dürfen, da dann alle Türen per Generalschlüssel offen stehen. Auch dort offenbar sich eine unglaubliche Kette an Versäumnissen und Fehlern, die ich im Blog-Beitrag Microsofts Storm-0558 Cloud-Hack: Schlüssel stammt aus Windows Crash Dump eines PCs nachgezeichnet habe. Die Kurzfassung:

  • Ein Rechner in einem speziell abgesicherten Bereich, in dem dieser MSA-Schlüssel verwaltet und die Sicherheitstokens erzeugt werden, ist 2021 abgestürzt. Bei diesem Absturz wurde ein sogenannter Speicherdump generiert, der zur Fehleranalyse verwendet werden kann.
  • Ein Speicherdump darf aber niemals vertrauliche Daten enthalten – und Microsoft hat da normalerweise auch Gegenmaßnahmen ergriffen. Aber im aktuellen Fall führte eine spezielle Bedingung dazu, dass der MSA-Schlüssel in den Daten steckte.
  • Rechner im speziell abgesicherten Bereich haben keinen Internetzugang für Mitarbeiter. Also wurde diese Dump-Datei aus dem abgesicherten Bereich in das normale Microsoft-Netzwerk kopiert, um den Absturzfehler zu untersuchen – das war 2021.
  • Irgendwann ist es den Angreifern gelungen, den Arbeitsplatz eines Microsoft-Ingenieurs mit Schadsoftware zu kompromittieren. Dadurch erhielten die Angreifer Zugriff auf die Netzwerkstruktur.
  • Und die Angreifer waren erstens in der Lage, den alten Dump aus 2021 auf einer Festplatte zu finden, dann zu erkennen, dass der quasi aus dem "Allerheiligsten" stammt und konnten dann auch noch die Daten aus dem Dump so extrahieren, dass klar war, dass bestimmte Ziffern aus vielen Bits und Bytes ein MSA-Schlüssel darstellt, der sich dann für den oben skizzierten Angriff eignet.

Ziemlich viele Zufälle und Fehler, wenn man mich fragt. Hier muss ich anmerken: Das basiert auf der Prämisse, dass Microsofts Angaben stimmen – denn auch hier gesteht Microsoft ein, dass man das alles nicht belegen könne, weil die erforderlichen Zugriffsprotokolle bis ins Jahr 2021 inzwischen gelöscht wurden. Obiger Ablauf skizziert daher nur ein Szenario, welches das von Microsoft als wahrscheinlich angegeben wurde.

Der klein geredete GAU im Interview

So mancher Benutzer und auch die Redaktion von Kontrafunk stellt sich die Frage, warum das Unternehmen mit dem Vorfall nicht offener umgeht und vor allem, ob die Cloud noch sicher ist und Microsoft diesbezüglich ein vertrauenswürdiger Partner ist. Die Frage zum Offenlegen der Details müsste Microsoft beantworten – aber die Cloud-Angebote sind eines der Herzstücke des Unternehmens und der Wachstumsmarkt schlechthin.

Wenn sich nun herausstellt, dass es bei der Azure-Cloud und Microsofts Diensten mit der Sicherheit wie bei "Hempels hinterm Sofa" zugeht und alles drunter und drüber geht, ist klar, dass durch den Vorfall das Kerngeschäft Microsofts, die Cloud, auf dem Prüfstand steht und tiefstapeln erste Unternehmenspflicht ist. Die Aufarbeitung findet in den USA inzwischen auf politischer Ebene statt, wo ein US Cyber Safety Review Board genanntes Gremium nun den Vorfall aufarbeiten soll.

Für Benutzer in Unternehmen gibt es meines Wissens keine weitere Hilfestellung Microsofts, um eine Überprüfung durchzuführen und eine Kompromittierung auszuschließen. Dazu wären die europäischen Unternehmen und Behörden/Institutionen nach DSGVO verpflichtet (siehe auch Antwort vom BfDI, Ulrich Kelber, zum Hack der Microsoft Azure-Cloud durch Storm-0558 – Teil 2).

Ich bin mir aber nicht sicher, ob jemand, der nun Purview Audit (Premium) bereitgestellt bekommt, auch wirklich im Nachhinein feststellen kann, ob unberechtigte Zugriffe stattgefunden haben. Dazu müssten die Protokolldaten noch vorhanden sein – aber dafür ist Microsoft verantwortlich – und da wird zyklisch gelöscht. Die Cloud ist für Kunden eine Black Box, wo er nur hoffen kann, dass der Anbieter seine Hausaufgaben macht und die Infrastruktur gegen solche Vorfälle absichert.

Dennis Kipker: Cloud als Cybersicherheits-Risiko

Ist Microsoft und sein Umgang mit Sicherheitslücken in seinen Produkten inzwischen das "Cyberrisiko Nummer 1"? Kann man Microsoft aufgrund seiner "Monokultur" eigentlich noch vertrauen – wie der IT-Sicherheitsrechtler Denis Kipker in obigem Tweet fragt?

Zu obigem Sachverhalt hat die Redaktion von Kontrafunk ein Interview mit mir aufgezeichnet, wo ich die bisherigen Informationen und meine Einschätzung des Vorfalls wiedergebe. Das Ganze ist hier im Blog als Podcast abrufbar (der Kontrafunk Podcast-Link umfasst die gesamte Sendung 55:34 Minuten Dauer – das Interview zum Thema "Der kleingeredete GAU: Microsofts Clouddienst-Hack" beginnt ab Minute 21:49 – oder einfach auf das "Mikrofon-Icon 2" in der Seite klicken, um den Einzelpostcast abzurufen).

PS: Es mag da ganz fix Stimmen bzgl. Kontrafunk und deren Standpunkt zu Corona etc. geben. Es geht im Interview nicht um solche politischen Standpunkte, sondern um einen ganz konkreten Vorfall und dessen technische Sichtweise sowie die Fragen, die sich daraus stellen.

Ergänzung: Gerade Luft geholt, da kommt der nächste Microsoft Datenschutz-GAU schon um die Ecke – Datenleck: Microsoft AI-Forscher verlieren 38 TByte an internen Daten über GitHub/Azure Cloud-Speicher – entdeckt von Wiz-Sicherheitsforschern – einfach nur noch zum Gruseln.

Ä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

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

Datenleck: Microsoft AI-Forscher verlieren 38 TByte an internen Daten über GitHub/Azure Cloud-Speicher


Cookies blockieren entzieht uns die Finanzierung: Cookie-Einstellungen

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

54 Antworten zu Interview: Der kleingeredete Storm-0558 Hack der Microsoft Cloud

  1. Olli sagt:

    Solange das Thema nicht der Aufmacher bei ARD, ZDF, n-tv und Welt ist und es keine Brennpunkte und ZDF-Extras oder wie das heißt dazu gibt – und zwar die ganze Woche lang wie sonst auch bei wesentliches weniger wichtigen Dingen, solange wird da nix passieren. Dazu die Frage gab es Stern, Spiegel, Focus, SZ, FAZ und NZZ Artikel zum Thema – als Aufmacher?

    Schätze mal die Main-Stream-Medien haben gar nicht verstanden was das überhaupt passiert ist?

  2. Daniel sagt:

    Wenn es um die Sicherheit bei der Microsoft-Cloud und den Diensten wirklich so schlecht bestellt ist müsste die Nutzung eigentlich für alle öffentlichen Einrichtungen strikt verboten werden und auch für private Firmen dürfte bei weiterer Nutzung keine Versicherung mehr bei Schäden durch Hacker u.a. eintreten.

    Das Risiko ist jetzt klar geworden, man kann es nicht mehr ignorieren.

    • Marco3108 sagt:

      Für öffentliche Einrichtungen ist die Nutzungder MS-Cloud ja eigentlich nicht zu rechtfertigen – die DSGVO-konforme Nutzung ist nicht zu gewährleisten. Leider hält sich die Mehrheit nicht dran, gerade auf Bundes und Landesebene…

      • Wetterchen sagt:

        Das Hauptproblem ist, dass die jeweiligen Datenschützer der Bundesländer keine Eier in der Hose haben und das Schicksal der Einrichtungen Ihnen selber überlässt.
        Beispiel NRW.
        Und selbst die Datenschützer der einzelnen Einrichtungen, z.B. Unis entscheiden hier und da anders. oder eben gar nicht oder es hängt ewig im Personalrat fest.

        Was bleibt ist aber die allgemeine Erkenntnis: MS Cloud sollte man meiden so lange es geht. Aka Ende 2025. Und hoffen auf ein Wunder.

    • Pau1 sagt:

      Wenn ich mich nicht täusche hat die Datenschutz Konferenz Microsoft Produkte inkl. Cloud gebannt.
      Die angesprochenen haben nur mit den Schultern gezückt und machen einfach weiter und alle Alternativen kaputt (Limux?)

      Es ist immer wieder schön wenn man sich ein Monopol aufgebaut hat, oder sich zur Nutzung als erster greifen könnte.

  3. 1ST1 sagt:

    Wie schon an anderer Stelle erwähnt, empfehle ich dazu auch diese Nachbereitung zu lesen: https://www.msxfaq.de/cloud/security/storm_0588_nachbereitung.htm – Fazit daraus: Lessons learned, issues fixed und sogar der Datenschutz (Es gib Aufbeahrungsfristen für Logfiles) wird berücksichtigt, also final: Es wird heißer gekocht als gegessen, zurück zur Tagesordnung. Es wäre auch schön, wenn sich ein zuständiger Admin eines Großunternehmens dazu mal äußert, ich denke mal nach Freigabe des Purview Audit Premium werden die schon genau in die entsprechenden Daten reingeschaut haben und hoffentlich nichts gefunden haben.

    • Günter Born sagt:

      Danke für den Link – zum "Es wird heißer gekocht als gegessen, zurück zur Tagesordnung." – mag man so tun. Aber das Interview lief ja unter dem Aspekt "der klein geredete Vorfall" und ja, für Microsoft und diverse IT-Verantwortliche ist es genehm, wenn "es zurück zur Tagesordnung" gehen könnte. Aber die Aussage "Lessons learned, issues fixed" ist mir etwas zu flach. Denn die Fragen bleiben, wie es mit der Sicherheitskultur und Zuverlässigkeit Microsofts bestellt ist. Denn die Organisationsstruktur, die die oben skizzierten, unglaublichen Pannen ermöglichte, wurde ja m.W. nicht geändert. Die gleichen Prozesse sind weiterhin aktiv.

      Zu Purview Audit Premium wäre ich auch auf Feedback eines Admins aus einem solchen Bereich gespannt. Der Vorfall ist ja auch in diversen geschlossenen FB-Gruppen gepostet worden – da tummeln sich diese Administratoren. Bisher habe ich da noch keine Rückmeldung bekommen – gehe inzwischen davon aus, dass das im Sande verläuft.

    • Bolko sagt:

      "Lessons learned, issues fixed".

      Das weißt du doch gar nicht, sondern das sind lediglich unbelegte Behauptungen von Microsoft.
      Gibt es die alte und die neue angeblich gefixte Schlüsselvalidierung als open-source? Nein.
      Eventuell ist da eine weitere Backdoor weiterhin offen, zumindest für die NSA oder ehemalige NSA- oder Microsoft-Mitarbeiter mit Insiderwissen.

      Es ist auch nicht nachvollziehbar, ob die Anzahl der betroffenen Organisationen wirklich 25 ist oder ob nicht alle Organisationen betroffen sind.

      "Es wird heißer gekocht als gegessen"

      Eine der betroffenen Organisationen war das US-Außenministerium, das von China angezapft worden ist.
      Sowas ist keine Lappalie, sondern das könnte das Schicksal Taiwans mitentscheiden und dann gehen auch hier mangels Chips die Lichter aus.

    • Pau1 sagt:

      aao"Bei allen drei Beschreibungen der Störfällen fällt auf, dass es nie ein Einzelfehler sondern eine Verkettung mehrerer Einzelpunkte waren, die letztlich zur Katastrophe geführt haben. Einige Probleme waren schon Teil der Konstruktion aber auch der menschliche Faktor spielt in allen Fällen eine Rolle? "

      Das erinnert mich an ein Bild in Pilot Mentour.
      Er zeigt dort "Sicherheit" als mehrere Schreiben Schweizer Käse.
      Es gibt keine 100% Sicherheit, jede Scheibe hat ihre Löcher.
      Und der Trick dabei besteht darin, das man die durchlöcherten Scheiben so dreht und von verschiedenen Laibern nimmt, das niemals an einer Stelle alle Löcher in einer Reihe stehen.
      Extrem wichtig ist dabei immer das CRM.
      Das Crew Resource Management…etwas was sonst in der Industrie unbekannt ist.

      Darum ist es absolut zwingend, das alle Fehler lückenlos transparent aufgeklärt werden. So eine Geheimnistuerei wie es in der IT getrieben wird führt da zu hunderten Toten, wie es Boing mit seinem 737Max MCAS-Murks leider bewiesen hat.
      Boing konnte da einige Käsescheiben so drehen, dass die Löcher passten, aber billig waren
      Und sage niemand das das ganz etwas anders sei,da es um Menschen leben geht. Bei der Cloud inzwischen auch…

  4. Chris sagt:

    Für mich sind hier 2 Vorgänge besorgniserregend.

    – einen 2021 abgelaufenen MSA-Schlüssel auch noch im Jahr 2023 zu verwenden
    – Also wurde diese Dump-Datei aus dem abgesicherten Bereich in das normale Microsoft-Netzwerk kopiert

    Natürlich können Fehler passieren. Auch MS.
    Aber : Jeder Fehler darf alleine schon nicht passieren aber beide zusammen ?
    Da fragt man sich, wie es um die Sicherheit bei elementaren Dingen bestellt ist ?

    • R.S. sagt:

      Es sind mehrere Fehler:
      1. Der MSA-Schlüssel ist im Dump vorhanden
      2. Der Dump konnte den abgesicherten Bereich verlassen
      3. Jemand konnte sich in den Rechner des Mitarbeiters hacken
      4. der abgelaufene MSA-Schlüssel konnte verwendet werden
      5. der für Consumer-Konten gedachte MSA-Schlüssel konnte auch für Business-Konten verwendet werden
      6. Warum war der Dump von 2021 im Jahre 2023 noch auf dem Rechner des Mitarbeiters?
      Dumps gehören nach erfolgreicher Auswertung gelöscht.
      Logs löscht Microsoft regelmäßig, aber Dumps nicht?

      Keiner dieser Fehler darf passieren.

      Da wurde also mächtig geschlampt.
      Und ja, es stellt sich die berechtigte Frage, wie es bei Microsoft mit der Sicherheit sonstiger Dinge bestellt ist.

      • Bolko sagt:

        Für die Punkte 1,2,3 und 6 gibt es keine Beweise, da diese von Microsoft vorher bereits gelöscht worden waren.
        Es handelt sich lediglich um Vermutungen seitens Microsoft oder aber es ist eine Cover-Story, um den tatsächlichen anderen Vorgang zu verschleiern.

        Der Hacker könnte auch Insider-Wissen gehabt haben, vor allem, um den MSA-Key im Dump zu vermuten und zu identifizieren.

        Die Key-Validierung war eventuell nicht versehentlich so "schlecht" implementiert, sondern absichtlich, um verdeckten Zugriff für die NSA zu ermöglichen (Backdoor).
        Würde man aber diese eventuelle Wahrheit veröffentlichen, dann wäre das Vertrauen in die Microsoft-Cloud auch bei den Schlafschafen zerstört, die bisher noch nichts vom Cloud-Act oder Patriot-Act gehört hatten.

    • Pau1 sagt:

      Wieso fragt denn keiner, warum/wozu es einen Schlüssel mit diesen Eigenschaften eines Universalschlüssels überhaupt irgendwo gab und warum man diesen falsch Deklariert hat?
      Es sind schon verdammt viele Zufälle.

      Ein völliges Rätsel ist für mich, wie dieser/so ein Schlüssel in einem core dump gelangen könnte.
      Wenn man mit solchen Dingen arbeitet, weiß man, wie man dafür sorge tragen kann, das der Schlüssel niemals im Klartext vollständig im Speicher steht. Core dumps gab es schon vor Jahrzehnten, das ist nichts was MS erfunden hat.
      Wozu gibt es TPM, und HSM ?
      Ach, wie isolieren das per Netzwerk, was soll schon passen.

      (Gab es nicht neulich ein paar Server Platten aus dem inneren eines Hosters, die mit Daten bei eBay zu kaufen waren? Irgendwer hatte die Platten rausgetragen.)

  5. 1ST1 sagt:

    Hallo, Herr Born, ist die Auffasung von Frank Clarius (msxfaq) nicht genehm? Man kann ja auch versuchen, dessen Aussagen kritisch zu hinterfragen. Aber man sollte zu so einem brisanten Thema auch andere Sichtweisen zu Wort kommen lassen, sonst wird es einseitig.

    • Günter Born sagt:

      Mit genehm hat das wenig zu tun – ich hatte die Ausführungen von Frank gelesen. Es muss jeder an der Stelle selbst entscheiden, wie er gewichtet. Frank Carius stellt auf einen speziellen Fall ab, wo er konstatiert "ist nochmals gut gegangen" – kann man so tun und ist in Ordnung.

      Ich stelle die Frage: "Soll ich einem Unternehmen vertrauen, wenn ich sehe, welche unglaublichen Fehler, Versäumnisse und Schlampereien diesen Vorfall überhaupt erst so ermöglicht haben?". Und wenn ich Dennis Kipker, Professor für IT-Sicherheit, richtig interpretiere, stellt dieser ebenfalls entsprechende Fragen in Richtung Cloud-Sicherheit.

      • 1ST1 sagt:

        Eine Gewichtung ist immer wichtig, dazu muss der Leser aber auch die Bewertung der anderen Seite kennen! Der Frank Clarius bewertet das Thema – sicherlich auch mit Blick auf seine Kundenkontakte offensichtlch aus der Perspektive, wie die Unternehmen so eine M365 Umgebung betreiben und hochgradig davon abhängig sind. Dort wird man sicher analysiert haben, soweit die Logs zurück reichen. Diesen Einblick in die Denkweise der betroffenen Konzerne bekommt man ja nicht gerade oft zu lesen. Ich hätte es daher gut gefunden, wenn Sie im Artikel oder Interview auch auf diese Perspektive eingegangen wären. Dann kann man tatsächlich abwiegen, wie ernst die Lage wirklich ist oder war.

        • Daniel sagt:

          "Dort wird man sicher analysiert haben, soweit die Logs zurück reichen." Der war gut, klar wenn die kritischen Stellen schon längst gelöscht sind kann man da analysieren bis man blau anläuft man findet nix mehr. Und wenn erst eine US Behörde aufmucken muss dass man sicherheitskritische Logdateien auswerten kann ohne zu zahlen sagt auch alles. Aber lass gut sein deine positive Meinung zu Microsoft ist hier im Blog ja hinlänglich bekannt. Die können Mist bauen wie sie wollen du redest es dir schön.

          • 1ST1 sagt:

            Wir wissen nicht, wie lange MS diese Logs aufhebt, 2 Jahre sind es aber offensichtlich nicht. Aber schauen wir uns doch mal den zeitlichen Ablauf an:
            2021 wird der Key gestohlen
            Mai 2023, der erste nachgewiesene Einbruch erfolgt
            Anfang Juni 2023, der Einbruch wird initial erkannt und nach Analyse werden 25 Tenants/Privataccounts gefunden, bei denen das passiert ist.
            Anfang Juli 2023, die Sache wird öffentlich
            Juli 2023, Purview Audit Premium für jeden Enterprise-Kunden zugänglich

            Selbst wenn MS diese Logs nur 6 Monate aufheben würde, hätten die Enterprise-Kunden noch bis Oktober Zeit, um einen Einbruch aus dem Mai zu finden. Wenn man die Entdeckung des Einbruchs und Sperrung des MSA im Juni hin nimmt, dann sogar bis November für späte Einbrüche. Ich hoffe aber, dass MS wenigstens 12 Monate aufhebt, das ist bei SIEMs meistens der Default und allgemein "Best Practize".

            Ich rede nichts schön, siehe heute Morgen Eintrag zu Edge. Aber ich versuche, beide Seiten zu sehen und abzuwägen. Das macht einem dieser Blog nicht leicht!

            • Bolko sagt:

              Diese Einbrüche mittels der gefälschten Tokens könnten doch auch in den Jahren 2021 und 2022 geschehen sein, aber mangels Logs konnte man das nicht entdecken bzw man hat es entdeckt, aber die Auswirkungen der Veröffentlichung wären so gravierend, dass man da lieber lügt.

              Da wurde vielleicht das Pentagon gehackt und keiner weiß das, außer die Chinesen und die haben jetzt die Verteidigungspläne für Taiwan. China kann dann diese Pläne durchkreuzen, sich Taiwan einverleiben und Europa und die USA bekommen dann keine Chips mehr aus Taiwan.

              China würde zwar das US-Außenministerium hacken (erwiesen), aber beim Pentagon versuchen die das nicht? Wer soll das glauben?

              Ins Außenministerium kamen die problemlos rein, aber beim Pentagon nicht?

              Microsoft ist bekannt, dass das Pentagon gehackt wurde (?) und ist so offen, transparent und vertrauenswürdig, das auch öffentlich zu melden und die eigene Reputation ins Klo zu spülen?
              Tja, sorry, war doch keine Absicht, dass dank unserer massiven Fehler jetzt China über die Verteidigungspläne für Taiwan verfügt und die uns jederzeit den Zugang zu den Chips abdrehen können.
              Wir bringen da mal einen Patch raus, damit das nicht nochmal vorkommt, versprochen!

          • Bernd B. sagt:

            Ich kann mich ob der Argumentationsweise oft des Eindrucks nicht erwehren, er sei ein gemeiner Lobbyist im 'Schafspelz' des IT-Fachmanns.

    • Frank Carius sagt:

      Günter und ich haben immer mal wieder Kontakt und eigentlich sind wie gar nicht so unterschiedlich in Denkweisen und Ansichten. Gerade was Datenschutz etc angeht. Da gibt es noch viel mehr Themen zu Voratsdatenspeicherung, KFZ-Haftpflicht mit Telemetrierabatt, die "freiwillige" Datenspende bei der Nutzung von Android/Google-Dienstes oder all die "kostenfreie" Apps, die Millionenfach ohne Einschränkung (Stichwort Aufsichtsbehörden in Irland etc) genutzt werden.
      Wenn es Thematisch sinnvoll ist, dann verlinkt die MSXFAQ zu Seiten bei borncity und die Gegenrichtung gibt es auch.

      Aus meiner Sicht ist, wie gebloggt, der Storm-0558 ein GAU wie eben die AKW-Unfälle auch. Es wird immer wieder passieren aber selbst wen es kein MS gibt, und andere Lösungen genutzt werden, wird es nicht besser. es sind immer Menschen und Kostendruck.

      Bin ich ein MS Fanboy? Ich verdiene mein Geld mit Dienstleistung mit hohem Microsoft-Anteil. Das verbietet mir aber nicht kritisch zu sein. Ich kann auch den Ausführungen von Günter zu dem Thema zustimmen. Mein Artikel hat einen anderen Schwerpunkt aber ich bin weit davon entfernt, Microsoft die Absolution zu erteilen. Hafnium war auch kein Glanzlicht. Lest einfach mal die letzten größeren Produktlücken (nicht nur MS, gerne auch Citrix, F5, Atlassin etc.) Wer in der IT mit Security unterwegs ist, lernt Fälle kennen, die besser keiner wissen will.

      Informiert euch einfach auf unterschiedlichen Seiten, bildet euch eure eigene Meinung und entscheidet. während meiner Schule war IBM der big Player. In der Ausbildung hatte Novell NetWare einen dominanten Marktanteil. Heute ist IBM klein gegenüber Google, Facebook, Microsoft und Novell wohl Nische.

      Microsoft ist so groß, weil die Produkte und der Preis für die meisten sich rechnen. Auch Datenschutz und "ruhiger Schlaf" haben letztlich einen Preis.

      Die alle Blogger nehmen den Lesern nicht ab selbst zu entscheiden. Aber ich kritisiere nicht, wenn jemand etwas anderes macht.

  6. Themo sagt:

    Herr Born, ich teilte ihre Bewertung und Kritik. Microsoft hat sich mit diesem Vorfall eindeutig selbst diskreditiert. Das Ausmaß der Fehler spottet jeder Beschreibung und wirft kein gutes Licht auf die Sicherheitsarchitektur eines der wichtigsten IT-Unternehmen der Welt, auf das sich wiederum Millionen Firmen und Behörden verlassen.

    • Daniel sagt:

      Ja ich stimme da ebenfalls zu. Keine Firma mit Sinn und Verstand würde die Schlüssel der Firma und der Kunden draußen an einen Haken hängen wo jeder ran kann. Microsoft hat das im übertragenen Sinne aber getan.

      • 1ST1 sagt:

        Nein, der hing nicht draußen an der Wand, sondern wurde bei einem Einbruch gestohlen. Wo hast du denn den Ersatzschlüssel für dein Auto liegen?

        Die Verkettung der Fehler ist natürlich trotzdem tragisch. Aber so laufen Einbrüche in Netzwerke immer ab. Schonmal bei dir im eigenen Firmennetz einen Pentest machen lassen? Ich sag dir, die kommen auf Ideen, da kommst du im Leben nicht drauf! Muss man dann natürlich ändern, denn nichts ist schlimmer als bekannte offene Lücke. Und dann engagierst du das Jahr drauf eine andere Pentest-Firma und die finden mit ihrer Sichtweise wieder was anderes. Ich habe daraus gelernt, wenn dich Hacker im Visier haben, dann kommen die auch rein, es ist nur eine Frage der Zeit. Oder wie anders gesagt wird: Es gibt zwei Sorten von Firmen: Die, die schon den Hack entdeckt haben, und die, die es noch nicht wissen. In dem Sinne: Man kann nur versuchen, es denen so schwer wie möglich zu machen, übrigens auch bei Systemen mit dem OS wo jeder in den Quellcode reinzuschauen.

  7. Pau1 sagt:

    "der Zugriffe eine besondere Software erforderlich ist, die Microsoft aber nur zahlenden Kunden bereitstellte."

    Das ist m.W. nicht so gewesen.
    Es ist ja normal, das man für Software zahlt…

    Der Text hätte lauten müssen:
    "Den meisten Kunden der Microsoft Cloud hätte ein Angriff gar nicht auffallen können, da für die Beobachtung der Zugriffe eine besondere Logfiles erforderlich ist, die Microsoft aber nur zahlenden Kunden bereitstellte."
    Ich weiß das Du Günter gerne auch auf völlig ahnungslose Laien Rücksicht nimmst, die nicht wissen was ein Logfile ist, aber es hier inhaltlich völlig verzerrend, ob man für eine Softwarenutzung bezahlt, oder für die eigenen Daten

    Das Problem hier war aber, das Microsoft den Kunden Logfile-Informationen nur gegen einen wohl heftigen Aufpreis ungefiltert zur Verfügung gestellt hat. Vollkommen pervers und skrupelos dem Kunden Geld für dessen Logfile-Inhalte von derartiger Wichtigkeit abzuzocken.
    Es war ja kein Log der aktuellen Netzfrequenz, sondern wer auf die Dienste Zugriff genommen hatte.
    Mit diesen Infos war der Diebstahl wohl sehr schnell offensichtlich.
    Ein Schelm der nun glaubt das MS seine Kunden hat mit Absicht ins Messer laufen lassen, damit Zugriffr der Guten, NSA-Mafia nicht ausversehen auffallen.
    MS hat das unterstrichen, in dem sie sofort die Infos gratis geliefert hatten. Das NSA könnte unter diesen Umständen ja nicht mehr darauf bestehen, das ihre Zugriffe vor den Kunden verborgen werden.

    Das Problem mit dem Key ist nur einem der ganz wenigen Kunden aufgefallen, die sich diesen sehr sehr teuereb Luxus leisten könnten:
    Dem Außenministerium.
    Darum und nur darum sind die 25 betroffenen Kunden in dessen Umfeld gefunden worden. Microsoft könnte ja schlecht gegen die Logfiles lügen. Bei allen anderen Kunden muss man davon ausgehen, dass auch sie komprimiert sind. Nur leider leider sind die Logfiles nie erstellt oder gespeichert worden…darum muss MS das auch nicht zugeben

    • 1ST1 sagt:

      Dein letzter Absatz ist nicht schlüssig. Es werden nach Freigabe der Logs an alle Enterprise-Kunden da sicher viele Admins rein geschaut haben. Kann natürlich sein, dass die das nicht an die Glocke hängen, aber zumindestens europäische Firmen müssten das der Datenschutzbehörde melden. Und dann findet man das wahrscheinlich in einschlägigen öffentlich zugänglichen Datenbanken, spätestens dann wenn Strafen bezahlt werden müssen, kommt es raus.

      Hier vielleicht, ich weiß aber nicht ob das die besten Quellen sind:
      https://www.dsgvo-portal.de/sicherheitsvorfall-datenbank/
      https://www.enforcementtracker.com/
      Allerdings ja, dort steht wahrscheinlich nicht drin, wie "sie" eingedrungen sind.

      • Bolko sagt:

        "zumindestens europäische Firmen müssten das der Datenschutzbehörde melden."

        Gilt das wirklich für alle europäische Firmen oder nur für diejenigen, die auch in der EU sind?
        Dann wäre England zum Beispiel ausgenommen.

        Gilt das auch für Militärbereich, oder gibt es da Sonderregelungen, damit solche sicherheitskritische Vorfälle zwar gemeldet, aber nicht veröffentlicht werden?

        Mindestens eine der 25 betroffenen Organisationen liegt doch in West-Europa. Wo ist dieser Vorfall denn in der DSGVO-Liste?

      • R.S. sagt:

        Was hilft die nachträgliche Freigabe, wenn die entscheidenden Sachen gar nicht mitgeloggt wurden?
        Schau mal in die Konfiguration deines Windows-PCs (Verwaltung -> Lokale Sicherheitsrichtlinie), was da NICHT mitgeloggt wird, aber aktiviert werden kann.
        Was nicht aktiviert ist, landet erst gar nicht in den Logfiles.
        Ergo nützt eine nachträgliche Freigabe absolut gar nichts, es wurde schlicht nicht aufgezeichnet!
        Da kannst du z.B. auch das Dateisystem überwachen.
        Dann wird jede Aktion im Dateisystem (Datei lesen, Datei erstellen, Ordner erstellen, kopieren, Rechte ändern, Attribute setzen, etc. etc.) in den Logfiles aufgezeichnet.
        Ist standardmäßig deaktiviert, weil dadurch extrem große Logdateien entstehen.

        In einer Domäne lässt sich das, was geloggt werden soll, übrigens auch per GPO steuern.

        Microsoft hat sich das erweiterte Logging wahrscheinlich bezahlen lassen, weil es Rechenkapazität und Speicherplatz kostet.

        • 1ST1 sagt:

          Woher willst du wissen, was bei dem PC, an dem ich hier gerade sitze, alles nicht geloggt wird? Weißt du, was hier alles für Monitoring nebenbei mit läuft und ins Storage schiebt? (Manchmal denke ich, wir übertreiben es hier…- ist aber alles abgesegnet)

          Warum geht ihr eigentlich immer davon aus, dass hier nur gelangweilte Privatkiddies schreiben? Und nein, beim Nr. 1 Unternehmen der Times-Liste der aktuell beliebtesten 1000 Unternehmen arbeite ich nicht, aber es ist in der Liste sogar drin.

  8. rona sagt:

    @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 wieder die Bezeichnung Storm-0588 anstelle Storm-0558 verwendet und ich denke "Storm-0558" ist die korrekte Bezeichnung.

  9. Pau1 sagt:

    Ich finde schon sehr witzig, das MS seinen Kunden den Zugriff auf dessen Logfiles nur über einen vorfilterden "Premium" Dienst erlaubt, und die Kunden sich das wie kleine, dumme Kinder gefallen lassen.
    Klar muss MS dafür sorgen, das Zugriffe von NSA und Co. dem Kunden niemals auffallen können, anderenfalls würde MS eine Straftat begehen und ein Geheimgericht sie verurteilen.
    Würden die Kunden ungefiltert Logfiles bekommen, könnte dem Kunden Lücken auffallen (so wie ein root kit auch irgendwo Spuren hinterläst).
    Auch wäre für NSA & Co Universal Schlüssel extrem praktisch. Vielleicht war das just dieser hier einer davon?
    Er würde vermeiden das MS von den Aktionen überhaupt etwas erfährt. (vgl. Sina-box in Deutschland)

    Neu für mich war, das das Außenministerium die erweiterten Logzugriff kostenlos bekommen hat.
    Er muss wohl ein abschreckend hoher Preis gewesen sein.
    Ich dachte, dass die den Preis einfach aus Steuern bezahlt hätten.
    Danke für die Info.

  10. Marco3108 sagt:

    Zitat: "Ich habe daraus gelernt, wenn dich Hacker im Visier haben, dann kommen die auch rein, es ist nur eine Frage der Zeit. Oder wie anders gesagt wird: Es gibt zwei Sorten von Firmen: Die, die schon den Hack entdeckt haben, und die, die es noch nicht wissen."

    Das ist für mich DAS Totschlag-Argument gegen die MS-Cloud; wenn's uns OnPremise erwischt sind die Auswirkungen relativ klein, wenn's die MS-Cloud erwischt…

    • 1ST1 sagt:

      Mag sein, dass wenn MS, Amazon oder Google gehackt wird, die Auswirkungen global riesig sind. Aber wenn dir die Hacker deine OnPrem-Bude auseinander nehmen, dann wünschst du dir trotzdem, dass dieser Tag nie geschehen ist. Dann wächst dir "relativ klein" nämlich erstmal über den Kopf, im Bekanntenkreis hab ich das schon erlebt, und das war auch keine kleine "Klitsche", ist übrigens auch Hr. Born entgangen, obwohl es im Dunstkreis um seinen Wohnort passiert ist. Übrigens, wir haben keine Server in der MS/Amazon/Google/(anbieter einfügen)-Cloud stehen, wir betreiben unsere eigene… Ja, gut M365 nutzen wir auch, aber dort kommen keine sensitiven Sachen rein, das wird alles auf den lokalen Fileservern gespeichert.

  11. Sebastian sagt:

    Der Hack ist mir persönlich egal weil ich nie an SaaS aka "Cloud" geglaubt habe. Die Leute die an SaaS also "Cloud" glauben werden es als reinigenes Gewitter betrachten. Als ein Lichtblick betrache ich das einige Leute doch inzwischen die Mehrkosten bemerken die SaaS automatisch bedeutet. Schon meine Oma wusste das mieten auf Dauer immer teurer ist als kaufen. (Disclaimer: Oma lebt noch, also meine)

    • 1ST1 sagt:

      Die Finanzmenschen denken anders als unsereins. Und das sowohl auf Verkäufer als auch auf Käuferseite. Vor 20 Jahren hab ich mal als Techniker ein – nennen wir es mal Praktikum – in einem Vertrieb gemacht, um zu sehen ob das was für mich wäre, aber neee, den Seitenwechsel hab ich abgeblasen. Aber dabei hab ich viel über diese Leute gelernt. Mit "Mieten" hast du nämlich konstante Kosten, die du gut planen kannst, und die Sache ist sehr berechenbar, und der Verkäufer ist auch verpflichtet über einen Zeitraum immer wieder zu "liefern", sei es Support oder Service oder sowas. Bei "Kaufen" ist das nicht unbedingt so, denk da mal an unvorhergesehene Defekte und Unfälle, z.B. bei einem Auto, nachdem die Garantie abgelaufen ist, stell dir vor, du hättest dafür keine (Voll)Kasko. Und gerade bei der IT ist es so, dass dann das Geld auch noch aus einem anderen Topf kommt, kein Kauf-Topf, sondern der Betriebs-Topf. Das ist einer der Gründe, warum viele Firmen ihre IT auch von Dienstleistern betreiben lassen, Stichwort ANÜ und Co, das sind dann nämlich keine Personalkosten, sondern Betriebskosten. Da spielen dann der Wert in Euro weniger eine Rolle, Betriebskosten kann man den Aktionären besser verkaufen, als wie Personal- oder Materialkosten. Auf der Verkäuferseite ist es auch besser, monatlich gleich hohne Einnahmen zu haben, als wie im Sommer die "Saure Gurkenzeit" überstehen zu müssen und dann auf das Jahresendgeschäft zu hoffen, wo die Fachabteilungen noch Budget raushauen müssen, damit sie das kommende Jahr wieder genauso viel bekommen. Verquert, ist aber so, muss man sich damit abfinden.

      • Sebastian sagt:

        Ja die Nummer ist ehrlich gesagt ziemlich alt das du – als Manager- nix kaufen und kein Risiko eingehen musst wenn das zur Miete geht. Alte SaaS Argumente sind auch das man das steuerlich besser abrechnen kann. Nichts davon stimmt. (steuerlich natürlich nur so in DE bemerkbar.)

  12. oli sagt:

    Ich halts mit Fefe und bin heilfroh, dass wir mit unserer Firma (und ich auch privat) nicht vom MS Cloudmüll abhängig sind: https://blog.fefe.de/?ts=9a075ef7

  13. Pau1 sagt:

    Stimmt, aber wir wissen auch, das MS keinerlei (!) Hilfen bereit gestellt hat, wie andere Kunden solche Zugriffe in dem Datenwust überhaupt finden. Vermutlich reicht da ein
    findstr -i -r /C:"Storm-0558" /C:"Storm-0588" .*log
    nicht aus.
    Wichtig sind viele Logfiles und eine automatische Auswertung, damit solche "seltenen" User auffallen.
    Und das sind bei einer großen Firma viele viele TB.
    Und dann müssen die logfiles termlich gelöscht werden.

  14. Anonymous sagt:

    Microsoft researchers leak 38TB of sensitive data due to misconfigured storage on GitHub


    GB: Danke, ist schon über andere Kanäle eingeschlagen – Aufbereitung im Beitrag Datenleck: Microsoft AI-Forscher verlieren 38 TByte an internen Daten über GitHub/Azure Cloud-Speicher. Ich steig um und "mach demnächst was mit Pferden", beruhigt vielleicht das Gemüt.

  15. Singlethreaded sagt:

    Im Beitrag wird ja auch der Datenschutz in Zusammenhang mit der Microsoft Cloud und dem Sicherheitsvorfall angesprochen. Dazu gab auch vorher schon einen Eintrag im Blog:

    Antworten des Bundesdatenschutzbeauftragten, Ulrich Kelber, zum Hack der Microsoft Azure-Cloud durch Storm-0558 – Teil 2

    Daher möchte ich mal fragen, ob Günter bei den Bayern nachgefragt hat und ob es eine Rückmeldung gibt, ob Microsoft den Vorfall gemeldet hat?

  16. Martin B sagt:

    Was nur hat man an „Public Cloud" nicht verstanden, wozu die Aufregung?

  17. Andreas R. sagt:

    Zur Frage: "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 im Jahr 2023 zur Generierung von Sicherheitstokens verwendet werden konnte."

    Wer technische Kenntnisse darüber hat, wie Prozesse intern vom Betriebsystem gemanaged werden, kommt sicher schnell auf eine Idee, wie man solche CrashDumps nutzen kann.
    Ich würde versuchen, den Memory-Dump wieder in den Arbeitsspeicher zu laden und das Programm weiterlaufen zu lassen (oder evtl. neu zu starten). Das Datum der Maschine ins Jahr 2020 setzen und dann neue Zertifikate mit Ablaufdatum 2024,2025 erzeugen lassen. Damit das funktioniert, sind bestimmt diverse technische Hürden zu nehmen, aber vom Prinzip her halte ich das nicht für SO schwierig. Und dann spielt das Ablaufdatum des Schlüssels "de facto" keine Rolle, denn das System glaubt, es verarbeitet noch gültige Schlüssel.

    Wer behauptet, dass sowas nicht im Arbeitsspeicher vorliegen darf, hat mMn unzureichende Kenntnisse im Bereich System-Programmierung. Sofern man die Verarbeitung der Schlüssel nicht auf eine andere dedizierte Hardware auslagern kann, kann es immer passieren, dass Daten unverschlüsselt im RAM liegen. Man kann versuchen die Zeiten zu minimieren, wo das der Fall ist. Aber man kann es nicht grundsätzlich vermeiden. Für die Analyse eines CrashDumps ist es auch notwendig, dass ich den vollständigen Zustand des Prozesses im RAM vorliegen habe, sonst kann man den Fehler nicht analysieren. Der Kernel-Code der den Crash-Dump erzeugt, hat keinerlei Ahnung welche Art von Daten im RAM vorliegen und schreibt einfach alle Speicher-Segmente des Prozesses in den Dump.

    Der "Schwachpunkt" in diesem Fall war, dass der Dump ausserhalb der "gesicherten Zone" aufbewahrt wurde. Dass solche Dumps auch mal länger irgendwo liegen, kann ich verstehen. Denn die Analyse ist oft zeitaufwändig, erfordert technisches Know-How. Wenn es kein dringendes Problem ist, dann wird das halt abgelegt und man nimmt sich vor, das mal zu analysieren wenn man mal dafür Zeit hat. Leute die sowas können, sind auch meistens schon schon gut ausgelastet.
    Ich will jetzt MS mit dieser Aussage nicht in Schutz nehmen – aber da wird auch nur mit Wasser gekocht.

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.