[English]Microsofts Maßnahmen, um das Laden von bösartigen Kernel-Treibern zu verhindern, scheinen hinten und vorne nicht zu greifen. Ich habe das Thema bereits seit Wochen auf dem Radar, weil die Treiber-Block-Liste wohl nicht wirklich funktioniert. Nun haben Sicherheitsforscher von Talos eine Kampagne offen gelegt, bei dem Open Source-Tools gefälschte Signatur-Zeitstempel verwenden, um bösartige Windows-Treiber zu laden.
Anzeige
Microsoft hat seit Windows Vista in den 64-Bit-Windows-Betriebssystemen die Vorgabe erlassen, dass Kernel-Mode-Treiber mit einem Zertifikat einer verifizierten Zertifizierungsstelle digital signiert werden müssen. Ohne ein solches Zertifikat lassen sich die Treiber nicht mehr laden. Zudem enthalten neuere Windows-Versionen auch die Möglichkeit, bösartige Treiber zu blockieren. Allerdings werden immer wieder Fälle bekannt, wo diese Mechanismen versagen. Und Microsoft hat noch einige "Ausnahmen" (Upgrade von Altsystemen auf Windows 10 V1607, Treiber mit einem Zertifikat vor dem 15. Juli 2015 signiert, Secure Boot deaktiviert) zugelassen, wo die Signatur-Prüfung nicht greift. Die Kollegen von Bleeping Computer haben die Ausnahmen in diesem Beitrag erwähnt.
Talos-Warnung zu RedDriver-Angriff
Ich bin auf Twitter über einen entsprechenden Tweet von Talos auf das Thema gestoßen, welches deren Sicherheitsforscher im Blog-Beitrag Old certificate, new signature: Open-source tools forge signature timestamps on Windows drivers aufgegriffen haben. Dort lassen sich Details zum Thema nachlesen.
In Kurzfassung: Cisco Talos ist darauf gestoßen, dass Bedrohungsakteure eine Windows-Richtlinienlücke ausnutzen, die das Signieren und Laden von nicht signierten Kernel-Modus-Treibern mit einem Signatur-Zeitstempel vor dem 15. Juli 2015 erlaubt. Die Akteure verwenden dabei mehrere Open-Source-Tools, die das Signierdatum von Kernel-Mode-Treibern ändern. Ziel ist es, ungeprüfte Treiber (mit bösartigem Inhalt) in Windows zu laden, obwohl diese Treiberdaten mit abgelaufenen Zertifikaten signiert sind.
Anzeige
Bei der Analyse solcher Fälle haben die Sicherheitsforscher von Talos mehr als ein Dutzend Code Signing-Zertifikate mit Schlüsseln und Passwörtern in einer PFX-Datei auf GitHub gefunden, die in Verbindung mit diesen Open-Source-Tools verwendet werden. Die meisten dieser auffälligen Treiber, die einen Sprachcode in ihren Metadaten enthielten, verwenden den Sprachcode Simplified Chinese. Das deutet darauf hin, dass die Akteure, die diese Tools verwenden, häufig chinesische Muttersprachler sind.
Cisco Talos hat außerdem einen Fall identifiziert, in dem eines dieser Open-Source-Tools verwendet wurde, um geknackte Treiber neu zu signieren und so die digitale Rechteverwaltung (DRM) von Windows zu umgehen. Die Sicherheitsforscher haben einen Blog-Beitrag veröffentlicht, der den realen Missbrauch dieser Lücke durch einen undokumentierten bösartigen Treiber namens RedDriver zeigt. Ein bisher undokumentierter treiberbasierter Browser-Hijacker namens RedDriver zielt auf chinesischsprachige Nutzer und Internetcafés.
Die Talos Sicherheitsforscher haben während der Recherche mit Microsoft Kontakt aufgenommen, um das Unternehmen über die Sicherheitslücke zu informieren. Microsoft hat daraufhin alle von Talos identifizierten, missbrauchten Zertifikate gesperrt und einen Hinweis ADV230001 veröffentlicht.
Microsoft ADV230001
Im Sicherheitshinweis ADV230001 vom 11. Juli 2023 geht Microsoft auf das Thema ein und schreibt, dass man kürzlich darüber informiert wurde, dass vom Microsoft Windows Hardware Developer Program (MWHDP) zertifizierte Treiber in böswilliger Weise für Post-Exploitation-Aktivitäten verwendet wurden. Bei diesen Angriffen verschaffte sich der Angreifer vor der Verwendung der Treiber administrative Rechte auf den angegriffenen Systemen.
Aus Redmond heißt es, dass man festgestellt habe, dass sich die Aktivität auf den Missbrauch mehrerer Entwicklerprogrammkonten beschränkte und keine Kompromittierung von Microsoft-Konten festgestellt wurde. Um Nutzer vor dieser Bedrohung zu schützen, wurden die Verkäuferkonten der Partner suspendiert und Blockiererkennungen für alle gemeldeten bösartigen Treiber implementiert. Hier ist von 133 Treibern die Rede.
Beim Lesen des letzten Absatzes klingelte bei mir etwas, und ich hatte mein Déjà-vu-Erlebnis. Eine kurze Suche im Blog warf den Beitrag Microsoft-Zertifikate zur Signatur von Malware missbraucht (Dez. 2022). Damals wurde von Microsoft das Dokument ADV220005 vom 13. Dezember 2022 veröffentlicht. Und ich habe keinen Hinweis darauf gefunden, dass die obige Schwachstelle (Treibersignierung vor dem 15. Juli 2015) geschlossen wurde. Da machen vermutlich die Altlasten mit Windows 10 LTSC 2015 und 2016 noch Probleme.
Microsoft empfiehlt die neuesten Windows-Updates vom Juli 2023 zu installieren und sicherzustellen, dass die installierten Antiviren- und Endgeräteerkennungsprodukte mit den neuesten Signaturen ausgestattet und aktiviert sind, um diese Angriffe zu verhindern. Denn zum 11. Juli 2023 wurden Windows-Sicherheitsupdates veröffentlicht, die den Treibern und Treibersignaturzertifikaten für die betroffenen Dateien das Vertrauen entziehen. Es gibt dazu einen eigenen Support-Beitrag Notice of additions to the Windows Driver.STL revocation list.
Darüber hinaus hat Microsoft Blocking-Erkennungen implementiert (Microsoft Defender 1.391.3822.0 und neuer), um Nutzer vor rechtmäßig signierten Treibern zu schützen, die in böser Absicht für Post-Exploit-Aktivitäten manipuliert wurden und dann verwendet werden.
Drama mit der Treiber-Block-Liste
Eigentlich sollte Windows bekannte, bösartige Treiber beim Laden blockieren, so dass diese keinen Schaden anrichten können. Zumindest hat Microsoft dies seit Jahren behauptet (siehe auch meinen Blog-Beitrag Sicherheitsfunktion ermöglicht Treiber-Blocklisten in Windows 10, 11 und Windows Server). Microsoft arbeitet dazu mit Treiber-Blocklisten und Sicherheitsfunktionen wie Windows Defender Application Control oder HVCI in Windows.
Im Oktober 2022 hatte ich im Blog-Beitrag Microsoft bestätigt: Windows patzt bei der Erkennung gefährlicher Treiber – Blocklisten nicht verteilt das Problem angesprochen, dass dieser versprochene Mechanismus nicht mehr als ein Placebo war. Denn die Verteilung der Blocklisten auf die Endpunkte (sprich die Windows-Systeme der Anwender) klappte nicht. Ich hatte dort einige diesbezügliche Hinweise von Sicherheitsforscher Will Dormann aufgegriffen, der das bestätigt.
Ich folge Will Dormann auf Twitter und in den letzten Monaten sind mir mehrfach Tweets aufgefallen, wo er darauf hinweist, dass schädliche Treiber trotz Blockliste geladen werden. Obiger Tweet vom 26. Mai 2023 ist eine Antwort auf einen Post, wo ein Tool zum Beenden geschützte Anti-Malware-Prozesse erwähnt wird. Dormann konstatiert, dass die Blockierung von Treibern nicht wirklich funktioniert. Er konnte einen schädlichen Treiber auf einem vollständig gepatchten Windows 11 22H2-System laden, obwohl diese in der von MS empfohlenen Liste der Treibersperrregeln enthalten ist. Die Microsoft-Treibersperrliste wird nur 1-2 Mal pro Jahr an die Endgeräte (Windows-Systeme) verteilt.
Ich habe mal in meinem Bookmark-Haufen gewühlt – obiger Tweet vom Mai 2023 enthält ein Äußerung von Dormann, dass ein vollständig gepatchtes Windows 11 22H2-System von den 554 x86-64-Treibern in der LOLDrivers-Liste 205 zulässt. Oder anders ausgedrückt, die Microsoft Vulnerable Driver Blocklist blockiert etwa 63% der bekannten anfälligen Treiber.
Bei mir bleibt ein schlechtes Gefühl diesbezüglich zurück, und ich würde mich nicht auf die Microsoft Treiber-Sperrliste oder weitere Schlenker a la "wir haben ein Entwicklerkonto gesperrt" verlassen.
Aber hey, dafür beglückt Windows Nutzer immer wieder mit ungefragten Updates veralteter Treiber. Ende Juni 2023 hatte Georg mich kontaktiert und schrieb: "Soeben musste ich feststellen, dass Win 10 Pro 22H2 seit 02. Juni 2023 wieder ungefragt veraltete Treiber für die integrierte Grafikkarte (Intel HD 620 [Intel Corporation – Display – 27.20.100.8729] ) und den externen USB LAN Adapter von Realtek (RTL8153(B)) [Realtek – Extension – 10.44.0.2] installiert, obwohl ich dies per Gruppenrichtlinie bereits am 30. November 2022 deaktiviert habe. Ich musste feststellen, dass vorgenannte Gruppenrichtlinie auf "default" gestellt worden ist.
Aktuelle Treiber sind v31.0.101.2125 für die Grafikkarte und vv10.59.20.0420 für den Realtek USB-LAN-Adapter).
Evtl. betrifft dies auch andere Blog-Leser." Hatte es seinerzeit nicht thematisiert, und hänge es hier einfach mal an.Und weil es auch noch in meinem "Stack" steckt: Frank hat auf administrator.de vor einiger Zeit das Thema "Inkompatible Treiber entfernen" im Beitrag Windows 10 Kernisolierung: Inkompatible Treiber entfernen aufgegriffen. Dort zeigt er, wie er bestimmte Hürden unter Windows 10 nehmen musste, um nicht mit mit der Kernisolierung zu kollidieren.
Ähnliche Artikel:
Microsoft Security Update Summary (11. Juli 2023)
Patchday: Windows 10-Updates (11. Juli 2023)
Patchday: Windows 11/Server 2022-Updates (11. Juli 2023)
Windows 7/Server 2008 R2; Server 2012 R2: Updates (11. Juli 2023)
Microsoft Office Updates (11. Juli 2023)
Office und Windows HTML RCE-Schwachstelle CVE-2023-36884 erlaubt Systemübernahme
Windows: Weiterhin Malware in Kernel-Treibern ladbar (RedDriver-Angriff)
China-Hacker (Storm-0558) in Microsofts Cloud, Outlook Online-Konten gehackt
Anzeige
Also immer wenn ich solche Beiträge lese komme ich nicht drum herum mich zu freuen, während solche Tools und Exploits auch zum bösem eingesetzt werden können, sind sie aber auch für die Benutzer extrem wertvoll um selbst kompilierte oder gepatchte Treiber zu laden, etwas was man als Eigentümer eines PC'S immer können sollte egal was MSFT, die Regierungen und Internationale Korporationen davon halten.
Leider ist es ja so das wenn man um eigenen Code in den Kernel zu laden auf Test-Signing ausweicht manche Software das erkennt und einfach mal sich erdreistet dann den dienst zu verweigern.
Die Chinesen haben dies erkannt und sich eine eigene Windows 10 G Edition von MSFT machen lassen welche einem Benutzer mit aktiviertem Secure Boot, also ohne Testsigning, erlaubt selbst signierte Treiber zu laden: https://www.geoffchappell.com/notes/windows/license/customkernelsigners.htm
Leider ist diese Windows 10 Version nur der CN Regierung vorbehalten.
IMHO sollte in Artikeln über Windows Sicherheitsmaßnahmen immer auch der Aspekt der de facto Enteignung von PC Besitzern beleuchtet werden.
Es ist nicht akzeptabel das jemand anderer als der Besitzer eines PC's bestimmen darf welchen Code der PC ausführt und unter welchen Berechtigungen.
Diese Enteignung ist aber bei Android oder iOS noch grösser.
Es gibt gar keinen einfachen Root Zugang mehr…
Und wenn man da jail crack dann laufen Banken Apps z.B. nicht mehr.
Und die Apps kann/sollte man nur aus AppStores laden, an denen die Wegelagerer 30% Schutzgeld erpressen und trotzdem böse Software anbieten lassen…
Vielleicht sollte man bei allen Computern auf Abo Modelle umsteigen? Dann wäre der Vermieter verantwortlich das die Geräte funktionieren/sicher sind, und der könnte einen ganz anderen Druck auf die Hersteller ausüben.
> Diese Enteignung ist aber bei Android oder iOS noch grösser.
Deswegen benutze ich nur Geräte auf denen sich Lineage OS installieren lässt.
Außerdem was soll das bitte, nur weil mobile Geräte nicht mehr für den Popo sind heißt es doch nicht das was bei PC's passiert auch nur ansatzweise Ok ist.
Und du hast natürlich in dem "freien System" jede Zeile Code gelesen und verstanden und erlaubt? Und bist auch sicher, dass der Code den du gelesen und verstanden hast, auch der ist, der da binär vorliegt und ausgeführt wird. Oder du hast das selbst kompliert (alles!) und bist auch sicher, dass dir der Compiler nicht wieder unkontrollierten Code eingebaut hat?
Das ist schon toll, ich bewundere dein Können!
Nein und das ist auch nicht der Punkt.
Es geht hier nicht um vertrauen sondern um Freiheit.
Egal wie viel oder wenig ich Windows vertraue ich will ans Eigentümer des PC's meinen Code auch mit Kernel Privilegien ausführen, so einfach ist es.
Und da hat einem Besitzer kein Konzern oder Regierung dazwischen zu reden, basta.
DavidXanatos – gilt das dann auch für deine Waschmaschine, KFZ, TV und anderen Geräten? Es hat schon seinen Grund das da niemand rumfummeln sollte/darf.
@Bernd
Zu den elektronischen Komponenten kann ich ggf. Schaltbilder erhalten. Selbst ohne Plan hat jedes Bauelement seine Daten aufgedruckt, über die ich in Erfahrung bringen kann, was es tut. So erwarte ich es grundsätzlich auch von einer Software.
Bei der Elektronik kann ich im Falle eines Schadens die Schaltung verstehen und reparieren. Ich könnte sogar Änderungen (Eigenbau) vornehmen, wie etwa den Motor drosseln. Die Frage die sich stellt ist natürlich, wie sinnvoll das ist und wie einfach einem soetwas gemacht werden soll. Bei Software muss einfach Sicherheit vorgehen, also bin ich der Meinung: Transparenz ja ("Bauteilbeschriftung"/offene Standards/Open Source), Eigenbau nein (Signierte Software).
Eine derartige Mündigkeit würde auch ein erhebliches Fachwissen voraussetzen. Die Produkte werden aber entwickelt für Leute, die sich um anderes kümmen wollen als um ihre Computer und eben darauf vertrauen möchten, dass die ganze Kiste funktioniert wie sie sie benötigen. Anders ausgedrückt, jedes Kind soll das Gerät sicher verwenden können – das funktioniert nichtmehr, wenn jede Art (Schad-)Code in das System geladen werden kann. Außerdem ist es selbt als Experte heute kaum noch möglich, alle Seiteneffekte zu ermitteln, die ein Eingriff in die komplexen Beziehungen der Dienste, Treiber und Protokolle mit sich bringt. Es macht also wenig Sinn, für eine Hand voll Enthusiasten das System so offen zu gestalten, dass daraus für die übrigen Benutzer ein erhebliches Risiko entsteht. Daher ist es völlig OK, wenn der Enthusiast sich ein OS sucht, das seine Bedürfnisse erfüllt, während für die Masse der Eingriff ins System erschwert bleibt. Freilich kann man darüber diskutieren, ob alles proprietäre auch Closed Source sein muss. Mehr Transparenz könnte helfen, Vertrauen zu den Plattformen zu steigern und gleichzeitig die Monopolstrategie, die sich regelmäßig sehr nachteilig für Verbraucher und Institutionen erweist, aufreißen. Ich plädiere für Transparenz und (teilweise) Offenlegung von Code (zB. einzelne Dienste); dass da durchaus auch noch etwas wie ein Betriebsgeheimnis beleiben muss, ist ganz klar.