Erste Details zur Ursache des CrowdStrike-CSAgent.sys-Absturzes

 (twitter.com/patrickwardle)
1 Punkte von GN⁺ 2024-07-22 | 1 Kommentare | Auf WhatsApp teilen
  • Die weltweiten Windows-Abstürze wurden in der ersten Analyse auf einen Ablauf zurückgeführt, in dem CrowdStrikes CSAgent.sys auf eine falsche Speicheradresse verwies
  • Die problematische Anweisung war mov r9d, [r8], und in R8 befand sich eine nicht gemappte Adresse, die per Index aus einem Pointer-Array geholt worden war
  • Dateien wie C-00000291-...xxx.sys wirkten nicht wie Kernel-Treiber, sondern wie obfuskierte Daten, die von CSAgent.sys gelesen werden; CrowdStrike bestätigte später, dass es sich um Konfigurationsdateien namens Channel Files handelt
  • CrowdStrike erklärte, dass C-00000291- einen Logikfehler auslöste, der zum OS-Absturz führte, und widersprach der Vermutung, ein Null-Byte in der Channel File sei die Ursache
  • Diese Auslieferung wurde nicht als Versionsupdate, sondern als Content-Update behandelt, wodurch in manchen Fällen die Staging-Kontrollen einzelner Clients umgangen wurden; der Crash-Report wurde zum entscheidenden Hinweis für die Ursachenanalyse

Absturzablauf von CSAgent.sys

  • Die erste Analyse war eine statische Analyse auf Basis von Reverse Engineering von CrowdStrikes CSAgent.sys und einem einzelnen Crash-Dump
    • Ohne Windows-System oder VM wurden die Unterlagen geteilt und um weitere Untersuchung gebeten
    • CSAgent.sys wurde anhand einer bei VirusTotal hochgeladenen Datei analysiert: VirusTotal-Sample
  • Der Absturzpunkt war die Anweisung mov r9d, [r8]
    • R8 war eine nicht gemappte Adresse
    • Dieser Wert war eine Adresse, die mit dem Index RDX (0x14 * 0x8) aus dem in RAX liegenden Pointer-Array geholt wurde
  • Andere .sys-Dateien wie C-00000291-...32.sys wirkten nicht wie echte Treiber, sondern eher wie obfuskierte Daten
    • Es gab Anzeichen dafür, dass CSAgent.sys auf diese Dateien verwies oder sie las
    • Da das Löschen der Dateien den Absturz behob, wurde vermutet, dass ihr Inhalt den Absturz von CSAgent.sys beeinflusst haben könnte
    • Mit Debugging ließe sich das leichter verifizieren, wurde ergänzt
  • Die geteilte .zip enthielt mehrere Versionen von CSAgent.sys, IDBs und mehrere C-....sys-Dateien
    • Eine der neuesten Dateien schien laut Beschreibung ein „fix“ zu enthalten
    • Freigegebener Link: Google-Drive-ZIP

Channel Files und bestätigte Angaben von CrowdStrike

  • Kevin Beaumont schrieb, dass die problematischen .sys-Dateien Channel-Update-Dateien seien und dass ein fehlerhaftes Format den übergeordneten CS-Treiber zum Absturz gebracht habe
  • Die technische Erklärung von CrowdStrike bestätigte die Richtung der ersten Analyse
    • Die C-...sys-Dateien seien keine Kernel-Treiber, sondern Konfigurationsdateien namens Channel Files
    • C-00000291- habe einen Logikfehler ausgelöst, der in der Folge über CSAgent.sys zum OS-Absturz führte
    • Link: Technische Erklärung von CrowdStrike
  • Manche vermuteten eine leere 0x0-Channel-File als Ursache, doch CrowdStrike bestritt, dass das Problem mit einem Null-Byte in der Channel File zusammenhing
    • Malware Utkonos wies auf eine Prüfung hin, wonach die Datei mit 0xaaaaaaaa beginnen müsse: zugehöriger Beitrag
  • Das Channel-Update wurde offenbar unter Umgehung der Staging-Kontrollen einiger Clients ausgerollt
    • Einige IT-Verantwortliche hatten in den CrowdStrike-Richtlinien eingestellt, die neueste Version zu ignorieren; da dieses Update jedoch kein Versionsupdate, sondern ein Content-Update war, wurde diese Kontrolle umgangen
    • Zugehöriger Beitrag: ResetEra-Thread
  • Auch in CrowdStrike-Patenten taucht der Begriff channel files mehrfach auf
    • Als Beispiele wurden US11822515B2 und US11645397B2 genannt
    • Der Suchbegriff lautet channel file assignee:(Crowdstrike, Inc.)

Crash-Reports und Hinweise zu macOS System Extensions

  • Crash-Reports waren ein Mittel, um den CrowdStrike-Absturz zu verstehen, und wurden auch genutzt, um andere 0-Days unter macOS aufzudecken
    • Der zugehörige Black-Hat-Vortrag trägt den Titel „The Hidden Treasure of Crash Reports?“
    • Link: Black-Hat-Vortragsseite
  • Positiv bewertet wurde, dass Apple 3rd-party-kexts abschafft und zu System Extensions im User-Mode wechselt
    • Allerdings habe es in diesem Übergang Kernel-Panics, Privilegieneskalationen und Probleme beim Unloaden von Sicherheits-Tools gegeben
  • Der Kernel-Code, der unter macOS user-mode System Extensions unterstützt, enthielt viele Bugs, und es gab Fälle, in denen in den User-Mode verlegte Sicherheits-Tools weitreichende Kernel-Panics in zentralen Apple-kexts auslösten
  • Im Zusammenhang mit einem Problem der Rechteausweitung im zentralen macOS-System-Extension-Framework wurde CVE-2019-8805 erwähnt
  • Wegen Fehlern bei der Verarbeitung von System Extensions konnten nicht privilegierter Code oder Malware das Unloaden von Sicherheits-Tools auslösen
    • Als Beispiel wurde genannt, dass sich selbst auf aktuellem macOS die als vertrauenswürdige System Extension laufende Firewall LuLu beenden lasse
    • Dieser Bug betreffe nicht nur LuLu

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2024-07-22
Meinungen auf Hacker News

  • Sobald ich las: „Es ist ein Content-Update, das einen BSOD verursacht, und Löschen behebt es“, dachte ich, ich könnte £100 darauf wetten, dass es eine Kombination aus kaputten Binärdaten und einem schlecht geschriebenen Parser ist.
    Ich beschäftige mich seit etwa den letzten zehn Jahren ziemlich ernsthaft mit Computing und überhaupt nicht mit Cybersecurity, aber meiner Ansicht nach entstehen fast alle CVEs, Crashes, Bugs, Performance-Einbrüche und Schmerzen beim Deserialisieren von Binärdaten zurück in maschinenlesbare Datenstrukturen.
    Weil menschliche Programmierer Edge Cases übersehen und imperative Sprachen das zulassen. Das umfasst Dekompressionsalgorithmen, Reader für Font-Konturen, Bild-, Video- und Audio-Parser, Game-Data-Parser, XML/HTML-Parser, OpenSSLs Parser für Zertifikate, Signaturen und Schlüssel bis hin zum Content-Parser dieses CrowdStrike-EDR.
    Unter Berücksichtigung einer zweiten Hypothese könnte ich noch £50 drauflegen.

    • Ich denke, mindestens fünf Dinge sind gleichzeitig schiefgelaufen. Schlechte Fehlerbehandlung im Kernel-Modul hat das gesamte Betriebssystem abgeschossen, die beschädigte Datei wurde weiter geparst und erzeugte eine Boot-Schleife, und die Datei wurde weder gelöscht noch als beschädigt markiert.
      Entweder hat die beschädigte Datei interne Tests bestanden oder es gab keine internen Tests, und offenbar wurden auch individuelle Einstellungen zum Zeitpunkt der Update-Anwendung ignoriert. Außerdem wurde weltweit gleichzeitig ausgerollt, sodass der Schaden nicht begrenzt wurde, und man weiß noch nicht einmal, warum die Datei überhaupt beschädigt wurde.
    • Die Top-25-Liste der häufigsten Schwachstellen für 2023 steht unter https://cwe.mitre.org/top25/archive/2023/2023_top25_list.html.
      Deserialisierung nicht vertrauenswürdiger Daten (CWE-502) lag auf Platz 15, Platz 1 war Out-of-bounds Write (CWE-787), Platz 4 Use After Free (CWE-416). Die Schwachstellen, die seit 2019 jedes Mal auf der Liste standen, sind unter https://cwe.mitre.org/top25/archive/2023/2023_stubborn_weaknesses.html zusammengestellt.
    • Statt „fast 100 %“ sieht es für mich eher nach etwa 98 % aus. Die restlichen 2 % bestehen aus Logikfehlern, Fehlkonfigurationen, schlechten Defaults und von Anfang an unsicheren Designentscheidungen.
      Zur Einordnung: Ich arbeite seit über 30 Jahren im Bereich Informationssicherheit.
    • Ich glaube nicht, dass man das imperativer Programmierung anlasten kann. Rust zum Beispiel ist imperativ, erkennt aber fehlende Fälle in einem switch ziemlich gut.
      Umgekehrt war eine Scheme-Variante, die ich vor 20 Jahren verwendet habe, funktional, prüfte aber nicht, ob alle Fälle abgedeckt waren; auch Haskells ghc hatte diese Prüfung vor einigen Jahren nicht standardmäßig aktiviert. Ich weiß nicht, ob sich das inzwischen geändert hat.
    • Ich weiß nicht, was fataler ist: dass es praktisch keine Fehler- bzw. Fehlerfallbehandlung gab, oder dass „Channel-Updates die Staging-Kontrolle der Kunden umgangen haben und an alle ausgeliefert wurden“.
      Einige IT-Verantwortliche haben bestätigt, dass sie die CS-Policy so eingestellt hatten, dass die neueste Version ignoriert wird, das hier aber umgangen wurde, weil es kein „Versionsupdate“, sondern ein „Content-Update“ war. Wenn ein Content-Update den Client kaputtmachen kann, darf es Staging-Kontrollen oder Policies nicht umgehen können.

  • Unabhängig davon, ob rootkit-basierte Endpoint-Überwachungssoftware wie CS wirklich nötig ist: Um diesen Bereich zu ethischeren Standards zu bewegen, könnten Open-Source-Alternativen ein starkes Mittel sein.
    Wenn die Kernwerkzeuge Open Source sind, ist transparent, was sie genau tun, und die Öffentlichkeit kann prüfen, ob es Backdoors oder schwere Bugs gibt. Gleichzeitig kann die Art, wie Security-Teams Malware-Signaturen bereitstellen, weiterhin ein Geschäftsmodell sein.

    • Das sehe ich nicht so. Kolide ist einer dieser Versuche, aber die tatsächliche Praxis und die Nutzung in Unternehmen sind genauso zwielichtig wie bei proprietären Produkten.
      Als Nutzer kann ich mich nicht darauf verlassen, dass ein Open-Source-Überwachungs-Rootkit besser getestet oder entwickelt ist oder meine Interessen berücksichtigt. Das Problem ist die ganze Kategorie Überwachungssoftware. Sie sollte nicht existieren. Unternehmen, die so etwas einsetzen, verstehen Sicherheit nicht, vertrauen ihren Mitarbeitern nicht und sind auch keine guten Arbeitsplätze.
    • Als Open-Source-Alternative gibt es GRR: https://github.com/google/grr
      Es läuft auf allen Client-Geräten von Google.
    • Aus Sicht eines Red Teams, das Malware zur Umgehung von EDR entwickelt, kann ich sagen: EDR-Systeme sind unverzichtbar. Die Formulierung „rootkit-basierte Endpoint-Überwachung“ ist eine ungenaue Beschreibung, die häufig aus Missverständnissen in der Gaming-Community stammt.
      Solche Tools liefern Schutz, der gegen anspruchsvolle Bedrohungen unverzichtbar ist, und sie erkennen tatsächlich etwas. Wenn ein Test Windows-Geräte enthält, wird meine Arbeit ohne EDR um 90 % leichter.
      Es gibt zwar Open-Source-EDR wie OpenEDR, aber es ist veraltet und die Telemetriequalität ist schlecht: https://github.com/ComodoSecurity/openedr. Aus diversen Proof-of-Concept-Codes auf GitHub ein produktionsreifes EDR zu bauen, ist unrealistisch und unsicher.
      Der EDR-Sensor selbst wird zum Angriffsziel. Aus Angreifersicht ist EDR meist das einzige Hindernis; macht man es Open Source, steigt das Risiko, dass bösartige Code-Beiträge die Entwicklung ausbremsen oder Schwachstellen einschleusen. Die Entwicklung von Sicherheitssensoren ist ein extrem feindliches Umfeld, in dem man nie sicher sein kann, wer auf der Gegenseite steht.
      In Wirklichkeit ist es eher das Gegenteil. Open-Source-Regeln für Malware-Heuristiken existieren, etwa die Detection Rules von Elastic Security: https://github.com/elastic/detection-rules. Elastic bietet ebenfalls EDR inklusive Kernel-Treiber an, und meiner Erfahrung nach ist es eher schwerer zu umgehen. Wenn man unter Windows ein EDR ohne Treiber baut, wird meine Arbeit leichter.
      EDR-Sensoren werden bereits von Sicherheitsforschern und Angreifern „auditiert“. Es wird ständig reverse-engineert und debuggt, um Schwächen zu finden. Wenn man ein Problem entdeckt, bei dem EDR Kernel-Mode-Shellcode einfach entgegennimmt und ausführt, würde man das selbstverständlich veröffentlichen.
    • Der Wert, den CrowdStrike liefert, liegt in der Pflege der Signaturdatenbank und in der Fähigkeit, weltweite Angriffskampagnen zu monitoren. Das erfordert erhebliche Ressourcen, die ein Open-Source-Projekt nur schwer haben kann.
      Es ist viel komplexer als ein simples Hash-Lookup-Programm.
    • Sicherheit ist eigentlich einfach kein Produkt, das man kaufen oder auslagern kann, aber genau so ist die Realität geworden.

  • Warum das bei der Testausrollung nicht aufgefallen ist, ist schwer zu verstehen. Ich frage mich, welcher Unterschied dazu geführt hat, dass das Problem erst bei der Auslieferung in die Außenwelt auftrat.
    Es ist schwer zu glauben, dass vor dem Rollout nicht getestet wurde, und Unternehmen sollten ebenfalls eine Testumgebung haben, bevor sie Drittanbieter-Komponenten ausrollen. Dass während der Entwicklung die Installation eines Pakets fehlschlägt oder Probleme verursacht, ist normal; aber niemand hält es für eine gute Idee, so etwas ohne Tests direkt in die Produktionsumgebung zu bringen. Ich verstehe nicht, warum dieser Fall anders sein sollte.

    • Vermutlich gab es zwei getrennte Pipelines: eine für Codeänderungen und eine für Datendateien.
      In Pipeline 1 wurden Software-Code-Updates wohl als kritische Änderungen behandelt, durch Nicht-Produktionsumgebungen und Canary-Tests geschickt und dann als neue „Version“ global ausgerollt.
      In Pipeline 2 wurden Content-/Channel-Updates möglicherweise anders behandelt. Über diesen Pfad werden nur Dinge wie neue Malware-Signaturen verteilt, daher ging man wohl davon aus, dass neue Dateien Datendateien in einem Standardformat sind und nicht „ausgeführt“, sondern nur gelesen werden.
      Diese Pipeline selbst wurde anfangs vermutlich getestet und als zufriedenstellend funktionierend bewertet, aber es gab wohl keinen Testschritt, der die Integrität der erzeugten Datendateien validierte oder – noch wichtiger – sicherstellte, dass sie fehlerfrei funktionieren, wenn sie an die aktuell eingesetzte Softwareversion ausgeliefert werden.
      Die Agent-Software, die täglich Channel-Dateien liest, wurde in Pipeline 1 vermutlich „gründlich“ gegen alle möglichen Datendateigrößen und simulierten Inhalte getestet. Fehlerhafte Datendateien hätten selbstverständlich mit einem Fehler abgelehnt werden müssen.
      Das genaue Szenario hier könnte gewesen sein, dass die kaputte Pipeline des zweiten Pfads eine ungewöhnlich geformte fehlerhafte Datendatei erzeugte und genau dieser Fall in der Entwicklungs-, Test- und Deployment-Pipeline der Softwareversion weder bedacht noch getestet wurde.
      Wenn das stimmt, ist die Lehre klar: Auch bei reinen „Daten“-Deployments sind Tests vor einer großflächigen Ausrollung Pflicht, egal wie standardisiert und stabil die Pipeline ist. Das erhöht Kosten und Verzögerungen, muss aber in Kauf genommen werden. Im Grunde ist es ähnlich wie der Grund, warum Menschen überhaupt für „Sicherheits“-Software bezahlen.
      Unternehmenskunden sollten genauso neue Artefakte in nichtproduktiven Bereichen ihrer IT-Umgebung testen oder eine Canary-Ausrollung vorsehen, bevor sie sie für die gesamte Produktionsflotte zulassen.
    • Nach den derzeit nur begrenzt vorliegenden Belegen wirkt es sehr unwahrscheinlich, dass dieses Deployment umfangreich getestet wurde. Plausibler ist, dass Definition-Updates locker gehandhabt wurden, um eine willkürliche SLA einzuhalten, bis es schließlich gekracht hat.
      Als das Unternehmen in Endpoint Security und Anomalieerkennung im Netzwerk einsteigen wollte, verlangten mehrere potenzielle Kunden für verschiedene CVE-Typen und Schweregrade eine SLA von 4 Stunden. Das bedeutete 24/7-On-Call-Security-Engineers sowie Erstellung und Auslieferung von Definitionen in unter 4 Stunden – und diese 4 Stunden bedeuteten, dass sie an 100 % der Zielsysteme ausgerollt werden können mussten.
      Hochwertige Definitionen für Zero-Days innerhalb von 4 Stunden zu schreiben und auszuliefern ist schon schwer; sie durch eine Testpipeline zu bringen ist noch schwerer, ganz zu schweigen davon, neue Tests zu schreiben, die tatsächlich Abdeckung bieten. In diesem Bereich galt das als „normal“, daher haben wir schnell aufgegeben. Es würde mich nicht wundern, wenn CS hier ähnlich gearbeitet hat.
    • Es ist möglich, dass die automatische Testausrollung des Definition-Updates nicht die aktuelle Version des Definition-Consumers ausgeführt hat, sondern nur eine ältere, nicht betroffene Version.
    • Ich habe schon Orte gesehen, an denen fehlgeschlagene Releases einfach als „Teil normaler Engineering-Arbeit“ behandelt wurden. Nach dem Motto: Niemand ist perfekt.
    • Dass überhaupt nicht getestet wurde, fällt schwer zu glauben. Ich frage mich, ob die Virus-Signaturen gegen die Engine getestet wurden, aber das finale Release-Artefakt, die .sys-Datei, nicht geprüft wurde und in der Packaging-Phase ein Bug hineingeraten ist.
      Das wäre immer noch miserabel, aber wenn wirklich ohne jeden Test released wurde, wäre das ein schockierendes Maß an Fahrlässigkeit.

  • Was ich nicht verstehe, ist ein deutlich weniger technischer, aber wichtigerer Punkt: Warum war der Blast Radius so groß?
    Bei viel weniger kritischen Diensten habe ich automatische Überwachung und Rollback eingesetzt und deutlich langsamer ausgerollt. Zuerst in eine Beta ohne Kundentraffic, dann – wenn es keine Probleme gab – auf einen kleinen Teil der Flotte, danach wurde der Anteil der Hosts, die das Update bekommen, langsam erhöht.
    Mit diesem Ansatz wäre das Problem sofort gestoppt worden; ich dachte, das sei gängige Praxis.

    • Das war kein Software-Update, sondern ein Signaturdatenbank-Update. So etwas muss so schnell wie möglich verteilt werden.
      Wenn man von einem neuen Virus erfährt, ist er bereits in freier Wildbahn unterwegs, daher zählt jede Minute. Man will nicht einen Tag warten und dann feststellen, dass der Server schon vor 20 Stunden kompromittiert wurde.
    • Selbst wenn es für Code-Updates ein Canary-Release-Verfahren gab, scheinen Konfigurationsupdates über einen separaten Kanal gelaufen zu sein.
      Die Erwartung war vermutlich: Man möchte keine potenziell brechenden Änderungen, aber weiterhin die neuesten Virenerkennungsregeln. Der übersehene Edge Case ist, dass eine ungetestete Konfiguration bestehenden Code kaputtmacht.
      Quelle: reine Spekulation, also bitte nicht in Nachrichtenartikeln zitieren.
    • Angesichts der Auswirkungen dieses Vorfalls hätte es eine große Staging-Umgebung für Windows-Clients geben müssen, auf die zuerst ausgerollt wird.
      Es gab viele Möglichkeiten, dieses Problem zu vermeiden oder zumindest das Eintrittsrisiko zu verringern, aber wie immer stand Profit vor Menschen.
    • Es sieht nicht so aus, als würden sie in der eigenen Organisation ihr eigenes Software-Hundefutter essen. Vielleicht halten sie ihre Software selbst intern auch nicht für besonders nützlich.
    • Die Antwort steht im Thread. Zum Vergleich: Als ich bei einem AV-Anbieter gearbeitet habe, haben wir ungefähr viermal täglich Updates an eine deutlich größere Kundenbasis gepusht, sofern die von MS gemeldeten Zahlen stimmen.

  • Es ist erstaunlich, dass die Rolle von Microsoft in dieser Angelegenheit kaum diskutiert wird. Microsoft ist nicht für den Bug verantwortlich, der den Crash direkt ausgelöst hat, hat aber ein Umfeld geschaffen, in dem die Anreize fehlen – nämlich Gewinn und Wettbewerb –, Windows widerstandsfähiger gegen solche Situationen zu machen.
    Microsoft hat im Bereich Workstation-Computing faktisch eine Monopolstellung, und weil es inzwischen eher Infrastruktur ist, besteht eine Sorgfaltspflicht, Sicherheit, Zuverlässigkeit und Funktionen des Produkts zu gewährleisten.
    Mangels Wettbewerb hat Microsoft bei der Innovation von Windows die Hände in den Schoß gelegt, und ein Teil davon hätte diesen Ausfall möglicherweise verhindern können. CrowdStrike läuft auf macOS und Linux zum Beispiel im Userspace; kann Windows keine Funktionen bereitstellen, damit CrowdStrike im Userspace laufen kann?
    Hätten Innovationen beim Application Sandboxing nicht die Notwendigkeit für das von CrowdStrike geforderte Maß an Kontrolle verringern können?
    Microsoft hält faktisch ohne Wettbewerb die Schlüssel zur weltweiten Computing-Infrastruktur in der Hand und unterliegt kaum Aufsicht. Windows machte einst mehr als 80 % des Microsoft-Umsatzes aus, ist inzwischen aber auf etwa 10 % gefallen.
    Es ist kein Problem, wenn ein Privatunternehmen dem Geld folgt, aber wenn ein Produkt für den Betrieb von Krankenhäusern, Fluggesellschaften und kritischer Infrastruktur unverzichtbar ist, kann man sich zur Steigerung der Profitabilität nicht nur auf KI-Assistenten und Werbung stürzen.
    Microsoft hat seine Sorgfaltspflicht gegenüber den Verbrauchern vernachlässigt, und CrowdStrike sehe ich als Symptom davon. Die Regierung sollte ernsthaft Wettbewerb im Markt für Desktop-Workspaces fördern – oder andernfalls Microsofts Windows-Produkte regulieren.

    • Stimmt. Es ist ein Versagen an mehreren Fronten und ein Zeichen für jahrzehntelange Systemkorruption.
      Ein Vorteil des gesunkenen Windows-Umsatzanteils ist, dass MS Windows möglicherweise nicht mehr als unantastbares Heiligtum behandelt, an dem man nichts ändern darf.

  • Ich nutze CrowdStrike nicht direkt und habe es meines Wissens auch nie auf meinen Systemen installiert. Auf dem Gerät meines letzten Arbeitgebers lief vermutlich etwas Ähnliches; bitte korrigiert mich, falls ich falschliege.
    Der CS-Treiber wird zuerst installiert und lässt sich nicht entfernen; vermutlich erkennt das ein Remote-Monitor, und da es ein signierter Treiber ist, wurde wohl erheblicher Aufwand betrieben, ihn schwer manipulierbar zu machen.
    Aber dieser Treiber lädt dann unsignierte Datendateien, die Endnutzer nach Belieben löschen können? Können Endnutzer solche Dateien auch beliebig hinzufügen und den Treiber dazu bringen, sich auf eine Weise zu verhalten, wie er es nicht sollte?
    Ich frage mich, was einen böswilligen Akteur daran hindert, mit einer bösartigen Datendatei einen weiteren großflächigen Ausfall auszulösen – oder schlimmer noch, Kernel-Rechte zu erlangen.

    • Diese Dateien können von Nutzern nicht gelöscht oder verändert werden, selbst mit Administratorrechten nicht. Wenn das möglich wäre, wäre es viel zu einfach, den Virenschutz abzuschalten.
      Es geht nur, wenn man das Dateisystem von einem anderen Betriebssystem aus mountet, was normalerweise durch BitLocker verhindert wird.

  • Haben CrowdStrike-Kunden eigentlich ein Mitspracherecht dabei, wenn solche Updates ausgerollt werden, oder akzeptieren sie einfach, dass CrowdStrike auf allen Maschinen des Unternehmens vollständige Remote Code Execution hat?
    Zumindest hoffe ich, dass Zertifizierungsstellen und Leute aus dem Kryptografie-Bereich die Möglichkeit haben, so etwas von ihren Systemen fernzuhalten.

    • Ich weiß nicht, wie man kontinuierliche Endpoint-Security an einen Drittanbieter wie CrowdStrike auslagern soll, ohne ihm Remote Code Execution und ring-0-Rechte auf allen zu schützenden Endpoints zu geben.
      Dass CrowdStrike diesen Teil automatisiert, ist ja gerade der Kern des Produkts.
    • Noch zu unseren Lebzeiten wird es passieren, dass automatische Updates für selbstfahrende Autos Millionen Menschen töten.
      Vielleicht werden wir es auch nicht erleben. Denn wir könnten zu diesen Millionen gehören.
    • Automatische Updates für „Content“, also dafür, was als Malware gilt, sind unverzichtbar und umgehen Optionen zur Update-Verzögerung: https://twitter.com/patrickwardle/status/1814367918425079934

  • Ich frage mich, ob jemand weiß, ob diese „Channel Files“ vom CS-Treiber signiert und verifiziert werden. Falls nicht, wirkt das wie ein riesiges Loch, das zu einem ring-0-Rootkit führen könnte.
    Um Channel Files zu installieren, braucht man zwar Rechte, aber sobald das möglich ist, kann man sich viel tiefer im System verstecken. Wenn ein Channel File einen Segmentierungsfehler auslösen kann, kann es vermutlich noch viel mehr tun.
    Alle Eingaben in etwas, das mit derart hohen Rechten läuft, sollten mindestens auf Integrität geprüft werden. Das ist grundlegend. Allein die Tatsache, dass man Channel Files löschen kann, deutet darauf hin, dass es nicht einmal einen Manipulationsschutzmechanismus gibt.