Microsofts Analyse des CrowdStrike-Vorfalls und Empfehlungen

Windows[English]Microsoft hat die Tage eine Analyse des CrowdStrike-Vorfalls veröffentlicht, in der die Aussagen von Crowdstrike bestätigt werden. Und es gibt Empfehlungen, wie Drittanbieter von Sicherheitssoftware arbeiten soll. Die Verwendung von Kernel-Treibern, wie bei CrowdStrike geschehen, wird nicht empfohlen. Zudem heißt es, dass Microsoft die "Sicherheit von Windows" verbessern möchte.


Anzeige

Microsofts CrowdStrike-Analyse

Am 19. Juli 2024 kam es auf Grund eines fehlerhaften Signatur-Updates bei der CrowdStrike Falcon-Sicherheitssoftware zum Ausfall von 8,5 Millionen Windows-Systemen. Die verharrten meist in einer BlueScreen-Schleife und ließen sich u.U. nicht mehr booten. Betroffen waren Unternehmensrechner, da die oben genannte CrowdStrike Falcon-Software bei Privatleuten nicht im Einsatz ist.

In Folge standen Flughäfen still, Züge, Rundfunksender, Tankstellen, Läden und Banken waren betroffen. Für Administratoren der betroffenen Unternehmen hieß es: Versucht, die Windows-Rechner bis zu 15 Mal zu booten und zu hoffen, dass das fehlerhafte Update per Internet durch eine funktionsfähige Version ersetzt wird. Oder die Rechner vor Ort manuell vom fehlerhaften Update befreien und wieder arbeitsfähig machen. Ich hatte hier im Blog zeitnah – auch über die Probleme mit Bitlocker Wiederherstellungsschlüssel-Abfragen berichtet (siehe Artikellinks am Beitragsende).

Im Beitrag Windows Security best practices for integrating and managing security tools greift Microsoft diesen Vorfall auf. Darin wird die Analyse von CrowdStrike (siehe CrowdStrike: Untersuchungsbericht; Schadenssumme und Entschädigungen; Schuldzuweisungen) weitgehend bestätigt.

Kernel-Architekur und deren Absicherung

Viele Sicherheitsanbieter wie CrowdStrike und Microsoft nutzen eine Kernel-Treiber-Architektur, wofür es mehrere Gründe gibt. Kernel-Treiber ermöglichen eine systemweite Sichtbarkeit und die Fähigkeit, beim frühen Booten zu laden, um Bedrohungen wie Boot-Kits und Root-Kits zu erkennen, die vor den Anwendungen im Benutzermodus geladen werden können. Darüber hinaus bietet Microsoft eine Vielzahl von Funktionen wie Systemereignis-Callbacks für die Prozess- und Thread-Erstellung und Filtertreiber, die auf Ereignisse wie die Erstellung, Löschung oder Änderung von Dateien achten können. Kernel-Aktivitäten können auch Rückrufe für Treiber auslösen, um zu entscheiden, wann Aktivitäten wie die Erstellung von Dateien oder Prozessen blockiert werden sollen. Viele Hersteller verwenden auch Treiber, um eine Vielzahl von Netzwerkinformationen im Kernel zu sammeln, indem sie die NDIS-Treiberklasse verwenden.


Anzeige

Microsoft arbeitet mit Drittanbietern von Sicherheitsprodukten über ein Industrieforum namens Microsoft Virus Initiative (MVI) zusammen, um die Kompatibilität mit Windows-Updates zu gewährleisten, die Leistung zu verbessern und Zuverlässigkeitsprobleme zu lösen. Darüber hinaus müssen alle Treiber, die von den Microsoft Windows Hardware Quality Labs (WHQL) signiert werden, eine Reihe von Tests durchlaufen und sich einer Reihe von Qualitätsprüfungen unterziehen, u. a. der Verwendung von Fuzzern, der Durchführung statischer Code-Analysen und der Überprüfung von Laufzeittreibern.

Alle WHQL-signierten Treiber durchlaufen die Aufnahmeprüfungen und Malware-Scans von Microsoft und müssen diese bestehen, bevor sie zur Signierung freigegeben werden. Entscheidet sich ein Drittanbieter für die Verteilung seines Treibers über Windows Update (WU), durchläuft der Treiber außerdem Microsofts Flighting- und schrittweise Rollout-Prozesse, um die Qualität zu beobachten und sicherzustellen, dass der Treiber die notwendigen Qualitätskriterien für eine breite Freigabe erfüllt.

Empfehlungen für die Zukunft

In obigem Beitrag sowie im Techcommunity-Beitrag Windows resiliency: Best practices and the path forward beschreibt Microsoft, was man alles an Sicherheitsmaßnahmen in Windows implementiert hat und was man bei Drittanbieter-Treibern unternimmt, um die Sicherheit zu gewährleisten. Im Techcommunity-Beitrag heißt es aber auch:

Dieser [ CrowdStrike]Vorfall zeigt deutlich, dass Windows Veränderungen und Innovationen im Bereich der End-to-End-Resilienz Priorität einräumen muss. Diese Verbesserungen müssen Hand in Hand mit laufenden Verbesserungen der Sicherheit gehen und in enger Zusammenarbeit mit unseren vielen Partnern erfolgen, denen die Sicherheit des Windows-Ökosystems ebenfalls sehr am Herzen liegt.

Bleibt abzuwarten, was am Ende des Tages passiert. Mit jeder Windows-Version wird Microsoft ja nicht müde, zu behaupten, dass es "das sicherste Windows aller Zeiten" sei. Insgesamt lässt sich aber feststellen, dass es immer wieder dicke Klopper gab und gibt. Ich erinnere daran, dass der Secure Boot in vielen Systemen nutzlos ist, weil der Secure Boot im UEFI vieler Motherboards mit einer Testsignatur versehen wurde. Die Seite binarly hat hier berichtet – einen deutschsprachigen Beitrag gibt es von Golem.

Ähnliche Artikel:
Weltweiter Ausfall von Microsoft 365 (19. Juli 2024)
Ausfall von Microsoft 365 und weltweite Störungen – wegen CrowdStrike-Update, was zum BSOD führt?
Wieso weltweit zahlreiche IT-Systeme durch zwei Fehler am 19. Juli 2024 ausfielen
CrowdStrike-Analyse: Wieso eine leere Datei zum BlueSceen führte
Nachlese des CrowdStrike-Vorfalls, der bisher größten Computerpanne aller Zeiten
CrowdStrike: Untersuchungsbericht; Schadenssumme und Entschädigungen; Schuldzuweisungen


Anzeige

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

8 Antworten zu Microsofts Analyse des CrowdStrike-Vorfalls und Empfehlungen

  1. 1ST1 sagt:

    " Mit jeder Windows-Version wird Microsoft ja nicht müde, zu behaupten, dass es "das sicherste Windows aller Zeiten" sei. "

    Es ist immer die Frage, welche "Sicherheit" gemeint ist. Sicherheit vor Hackerangriffen oder Betriebssicherheit.

    Beide sollte sehr hoch sein, aber wenn ein Hersteller von Sicherheitssoftware in seinen Kernelmodulen schlampt, ist das kein Hacker-Sicherheitsproblem, sondern ein Betriebssicherheitsproblem. Das ist etwas anderes. Klar kann Microsoft hier evtl. noch die Betriebssicherheit erhöhen, in dem es gegenüber solchen Treibern sicherheitstoleranter wird, in dem es eben deswegen nicht abstürzt, sondern sich irgendwie selbst heilt, in dem der Treiber dann einfach nicht geladen wird, aber die Verantwortung für die Betriebssicherheit des Treibers liegt in letzter Konsequenz immer bei dessen Hersteller. Von Außerhalb des Treibers kann man diesen letztlich nicht betriebssicher machen.

    • Anonymous sagt:

      Je mehr Bloat und Online und Cloud und Telemetrie und sonstige Überwachung "unter Freunden" desto unsicherer wird alles, das müsste nun auch der Letzte erkannt haben.

    • Anonymous sagt:

      sorry aber was ist das denn für ein , ich will mal vorsichtig sagen, bullshit.
      "irgenwie sich selbst heilt". und dann den treiber nicht lädt. das ist ja nur treiberbezogen jetzt. Das Betriebssystem ist Gigabytes an Code groß. Es wird niemals so eine Selbstheilungsmethode geben solange wir die aktuelle Software+Hardware Archetiktur verfolgen. Und es wird nie eine 100% Ausfallsichere und Hackersichere Software geben solange diese von Menschen programmiert wird. Weil Menschen eben Fehler machen. Oder haben Sie sich noch nie auf eigenen Daumen mit dem Hammer getroffen?

  2. Devos sagt:

    Der geschilderte Prozess gibt mir zu denken. Gewährleistet Microsoft die Prüfung eingereichter Update-Pakete, die mit dem Windows-Update ausgespielt werden oder prüft Microsoft lediglich technische Aspekte und autorisiert anschließend mit zugewiesenen Signaturen, ohne auf "Maliziösität" geprüft zu haben?

  3. HackIT0 sagt:

    Wenn es einen Bug im Windows-Telemetrieservice (… upps, keine Kundendaten mehr) geben würde dann gäbe es noch mal selben Tag ein Sicherheitupdate da. Auch der KI-Hype hat mehr Prioriät bei Microsoft als der Endkunde.

  4. Anonym sagt:

    >>> Darüber hinaus müssen alle Treiber, die von den Microsoft Windows Hardware Quality Labs (WHQL) signiert werden, <<<

    Soll kleiner glauben, dass die WHQL nicht noch genügend Raum für Schmu böte – auch wenn im Falle von (1) Microsoft das Spiel von Trend Micro durchschaute.

    Zitat: "Das Produkt wurde jetzt zurückgezogen, weil Microsoft den zentralen Kerneltreiber darin auf die Schwarze Liste getan hat. Grund: Der hat sich selber wie ein Rootkit verhalten. Der hat geguckt, ob er gerade WHQL-geprüft wird, und sich dann anders verhalten als sonst, damit der Treiber die Zulassung kriegt."

    (1) blog.fefe.de/index.html?ts=a031774b

    • Anonym sagt:

      Und wer (1) liest fällt dann völlig vom Glauben ab. Zitat: "However, some threat actors go for the "Rolls Royce" method of signing drivers, which is to buy or steal an EV certificate and then submit it for Microsoft WHQL validation as a fake company. Once they have a signed printer driver package, a threat actor can install the driver on any other networked device where they have administrative privileges."

      (1) bleepingcomputer.com/news/microsoft/windows-print-nightmare-continues-with-malicious-driver-packages/

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.

Du findest den Blog gut, hast aber Werbung geblockt? Du kannst diesen Blog auch durch eine Spende unterstützen.