Einführung
Bring Your Own Vulnerable Driver (BYOVD) ist eine immer beliebter werdende Angreifertechnik, bei der ein Bedrohungsakteur einen bekanntermaßen verwundbaren signierten Treiber neben seine Malware bringt, ihn in den Kernel lädt und ihn dann ausnutzt, um eine Aktion innerhalb des Kernels auszuführen, die er sonst nicht ausführen könnte. Nachdem sie Zugriff auf den Kernel erhalten haben, können sie Sicherheitssoftware manipulieren oder deaktivieren, ansonsten unzugängliche Anmeldeinformationen ausgeben oder das Verhalten des Betriebssystems ändern, um ihre Anwesenheit zu verbergen. Joe Desimone und ich haben auf der Black Hat USA 2018 neben anderen Bedrohungen durch den Kernel-Modus ausführlich darüber berichtet. BYOVD wird seit über einem Jahrzehnt von fortschrittlichen Bedrohungsakteuren eingesetzt und wird immer häufiger in Ransomware und handelsüblicher Malware eingesetzt.
Die Erzwingung der Treibersignierung (Driver Signing Force , DSE), die erstmals 2007 von Windows Vista x64 bereitgestellt wurde, war das erste Mal, dass Microsoft versuchte, die Macht von Administratoren einzuschränken. Mit DSE konnten Administratoren keinen Code mehr sofort in den Kernel laden. Mit der Einführung von Boot Guard, Secure Boot und Trusted Boot wuchsen die Einschränkungen für Administratoren, um die Bootkette vor Admin-Malware zu schützen, die zuvor ihre eigenen Bootloader/Bootkits installieren konnten.
Um die Macht der Administratoren weiter einzuschränken, hat Microsoft kürzlich die Sperrliste für anfällige Treiber standardmäßig bereitgestellt, beginnend mit Windows 11 22H2. Dies ist ein Schritt in die richtige Richtung, der Windows 11 standardmäßig sicherer macht. Leider kann das Bereitstellungsmodell der Blockliste nur langsam an neue Bedrohungen angepasst werden, da Updates in der Regel nur ein- bis zweimal im Jahr automatisch bereitgestellt werden. Benutzer können ihre Sperrlisten manuell aktualisieren, aber solche Eingriffe bringen uns aus dem Bereich der "standardmäßig sicheren" Zone.
Sicherheitsgrenzen
Bei der Bestimmung der zu behebenden Sicherheitsanfälligkeiten verwendet das Microsoft Security Response Center (MSRC) das Konzept einer Sicherheitsgrenze, die es wie folgt definiert :
Eine Sicherheitsgrenze stellt eine logische Trennung zwischen dem Code und den Daten von Sicherheitsdomänen mit unterschiedlichen Vertrauensebenen bereit. So ist beispielsweise die Trennung zwischen Kernel-Modus und Benutzermodus eine klassische und unkomplizierte Sicherheitsgrenze.
Basierend auf dieser Definition könnte man geneigt sein zu denken, dass Malware, die im Benutzermodus ausgeführt wird, nicht in der Lage sein sollte, den Kernelspeicher zu ändern. Die Grenze ist ja "einfach". Logischerweise sollte jeder Verstoß gegen diese Grenze mit einer Abhilfemaßnahme wie einem Patch oder einer Aktualisierung der Sperrliste beantwortet werden.
Leider wird die Situation von hier aus immer düsterer. In diesem Dokument heißt es später, dass Administrator-zu-Kernel keine Sicherheitsgrenze ist, mit der folgenden Erklärung:
Administrative Prozesse und Benutzer werden als Teil der Trusted Computing Base (TCB) für Windows betrachtet und sind daher nicht stark [sic] von der Kernelgrenze isoliert.
An diesem Punkt haben wir zwei scheinbar widersprüchliche Standpunkte. Auf der einen Seite stellt MSRC fest, dass Admin-to-Kernel eine unvertretbare Grenze ist und es sich nicht lohnt, sie zu korrigieren. Auf der anderen Seite versucht Microsoft, diese Grenze mit Mechanismen wie Driver Signing Enforcement, Secure Boot und der Vulnerability Driver Blocklist zu verteidigen. Da die Verteidigung unvollständig ist, nennt MSRC sie stattdessen "Defense-in-Depth-Sicherheitsfunktionen".
MSRC betrachtetAdmin-zu-PPL ebenfalls nicht als Sicherheitsgrenze, sondern klassifiziert sie als Tiefenverteidigungs-Sicherheitsfeature. Mehr dazu im nächsten Abschnitt.
Der Rest dieses Artikels bezieht sich separat auf MSRC und Microsoft. Während MSRC Teil von Microsoft ist, ist Microsoft eine viel größere Einheit als MSRC. Sie sollten nicht gleichgesetzt werden.
Ausnutzung von Schwachstellen
Im September 2022 reichte ich die Meldung VULN-074311 bei MSRC ein und informierte sie über zwei Zero-Day-Schwachstellen in Windows: eine Admin-to-PPL- und eine PPL-to-Kernel. Ich habe den Quellcode für beide Exploits bereitgestellt. In der Antwort wurde kurz und bündig darauf hingewiesen, dass sie die Schwachstellen verstanden und es abgelehnt haben, weitere Maßnahmen zu ergreifen, wie unten angegeben:
Die Studie beschreibt einen mehrstufigen Angriff, bei dem eine PPL-Umgehung genutzt wird, um die Ausführung von Kernel-Code zu erreichen. Beachten Sie, dass für alle vorgeschlagenen Angriffe Administratorrechte erforderlich sind und das gemeldete Problem daher nicht unsere Messlatte für eine sofortige Wartung erfüllt. Wir erwarten keine weiteren Maßnahmen und werden den Fall abschließen.
In diesem Sprachgebrauch bedeutet "Wartung" "Flicken". Ihre Antwort stimmt mit der oben genannten Richtlinie und ihrer historischen Behandlung der Grenze zwischen Admin und Kernel überein. Ihr Verhalten ist auch konsistent - es ist über 11 Monate her und sie haben immer noch keine der beiden Schwachstellen gepatcht. Ich finde es faszinierend, dass Microsoft bereit ist, Treiber zu blockieren, die den Kernelspeicher ändern können, MSRC jedoch nicht bereit ist, Schwachstellen zu nutzen, die das Gleiche tun können.
Als ich meinen Black Hat Asia 2023 Talk ankündigte, ist PPLdump tot. Lang lebe PPLdump, fünf Monate nach dem MSRC-Bericht auf Twitter meldete sich das Windows Defender-Team schnell, um mehr zu erfahren. Es scheint, dass MSRC den Fall geschlossen hat, ohne das Defender-Team, dessen Produkte auf PPL angewiesen sind, um Hunderte von Millionen von Windows-Rechnern zu schützen, über eine PPL-Umgehung zu informieren. Diese Art von Fehlkommunikation darf nicht weitergehen.
Schlüsselfertige Werkzeuge
EDRSandBlast ist ein Tool, das anfällige Treiber als Waffe einsetzt, um AV- und EDR-Software zu umgehen. Es kann den Kernel-Speicher modifizieren, um von AV & EDR installierte Hooks zu entfernen und sie vorübergehend oder dauerhaft für bösartige Aktivitäten auf dem System zu verblenden.
Wie ich in meinem Vortrag auf der Black Hat Asia erörtert habe, hat MSRC de facto gezeigt, dass es nicht bereit ist, Admin-to-PPL- und Admin-to-Kernel-Schwachstellen zu beheben, und dass es das Vorhandensein schlüsselfertiger Tools auf GitHub erfordert, um Microsoft zum Handeln zu motivieren. Dies hat mich dazu veranlasst, den Admin-to-PPL-Exploit PPLFault und die Admin-to-Kernel-Exploit-Chain GodFault als einfach zu bedienende Tools auf GitHub zu veröffentlichen. Der Kürze halber nennen wir sie im Folgenden "PPL-Schwachstelle" bzw. "Kernel-Schwachstelle".
Um die Inkonsistenz beim Blockieren bekannter verwundbarer Treiber bei gleichzeitiger Weigerung, Admin-zu-Kernel-Exploit-Ketten zu patchen, hervorzuheben, veröffentliche ich eine Version von EDRSandBlast, die PPLFault integriert, um das gleiche Ergebnis ohne anfällige Treiber zu demonstrieren. Sie können es hier sehen, wie es den Windows Defender-Treiber deaktiviert. Mein Ziel bei der Veröffentlichung ist es, MSRC zu motivieren, sowohl PPL- als auch Kernel-Schwachstellen mit größerer Dringlichkeit zu behandeln.
Milderung
Ich habe neben PPLFault und GodFault einen kleinen Kernel-Treiber namens NoFault veröffentlicht, der den PPL-Exploit bricht. Bis zur Reparatur von Windows können Anbieter von Antischadsoftware diesen Code verwenden, um die PPL-Sicherheitsanfälligkeit zu verringern. Wir haben den Schutz von NoFault in die neueste Version von Elastic Endpoint/Defend integriert – bitte aktualisieren Sie auf 8.9.0+, falls Sie dies noch nicht getan haben. Eine umfassende Lösung könnte darin bestehen, dass der Speichermanager Seiten-Hashes für alle ausführbaren Bilder erzwingt, die in PPL geladen werden, eine Funktion, die bereits für vollständig geschützte Prozesse verwendet wird .
GodFault ist nicht das erste Tool, das die Kernel-Schwachstelle ausnutzt. ANGRYORCHARD nutzte es erstmals mit der inzwischen gepatchten PPL-Schwachstelle KnownDLLs. Die PPL-Schwachstelle wurde inzwischen behoben, die Kernel-Schwachstelle jedoch nicht. Ich war in der Lage, die Kernel-Schwachstelle in GodFault leicht wiederzuverwenden - es sind nur ein paar Zeilen Code. Wenn dies nicht gepatcht wird, können zukünftige PPL-Exploits sofort mit dem Kernel verkettet werden. Beachten Sie, dass NoFault die Kernel-Exploit-Kette unterbricht, indem es die Ausführung des erforderlichen PPL-Codes verhindert, aber die Kernel-Schwachstelle selbst nicht behebt.
Diskussion
EDRSandBlast treiberlos zu machen, ist nur ein Beispiel für die Dinge, die Sie mit solchen Exploits tun können. Admin-to-Kernel-Exploits ermöglichen eine ganze Reihe von Malware-Funktionen, die normalerweise im Benutzermodus unmöglich sind, darunter:
- Deaktivieren Sie die Telemetrie im Kernelmodus, einschließlich Prozess-, Thread-, Objekt-Manager-, Dateisystem- und Registrierungsrückrufe. EDRSandBlast führt einige davon aus.
- Deaktivieren von Kernel-ETW-Protokollierungen
- Beenden und/oder Einschleusen von Malware in PPL-Anti-Malware-Prozesse
- Umgehen von LSA RunAsPPL, um Anmeldeinformationen zu sichern oder Credential Guard zu manipulieren
- Lese-/Schreibzugriff auf den Arbeitsspeicher von abgeschirmten VM-Arbeitsprozessen, die als PPL ausgeführt werden
- Führen Sie Schadsoftware mit größeren Berechtigungen als Antischadsoftware aus, sodass sie nicht gescannt oder im Benutzermodus beendet werden kann
- Implementieren von Rootkit-Verhalten wie dem Ausblenden von Prozessen, Dateien und Registrierungsschlüsseln
- Vollständiger Lese- und Schreibzugriff auf den physischen Speicher
Solche Kernel-gesteuerten Funktionen, die oft durch BYOVD aktiviert werden, werden regelmäßig von Kriminellen verwendet, um Sicherheitsprodukte zu umgehen und zu beeinträchtigen und sie in die Lage zu versetzen, Menschen und Unternehmen zu schaden. PPL- und Kernel-Schwachstellen ermöglichen dieselben Funktionen, sodass MSRC sie proaktiv beheben muss, bevor sie von Bedrohungsakteuren missbraucht werden, und nicht danach.
Ich möchte die Schwierigkeit des Problems nicht unterschätzen - den Kernel gegen Admins zu verteidigen ist schwierig und erfordert kontinuierliche Anstrengungen, wenn neue Umgehungen gefunden werden. Es wird nicht gelöst werden, sondern ein schwieriges und andauerndes Wettrüsten. Glücklicherweise hat Microsoft kürzlich eine neue Philosophie eingeführt,"die schwierigen Dinge nicht mehr zu vermeiden" (Link mit Zeitstempel). Die Behebung dieser Art von Schwachstellen ist eine "schwierige Sache", die die Windows-Sicherheit heute beeinträchtigt und gegen die Microsoft etwas tun kann, während sie sich gleichzeitig ihrer Vision einer Zukunft ohne Administratoren nähert. Sie sind ein großes, gut finanziertes Unternehmen mit klugen Leuten, die in der Lage sind, mehrere Probleme gleichzeitig anzugehen.
Fazit
Microsoft hat die Vulnerable Driver Blocklist erstellt, um Administratoren daran zu hindern, den Kernel zu manipulieren, aber sie haben nichts gegen eine Exploit-Kette von Administrator zu Kernel unternommen, die vor über 11 Monaten gemeldet wurde. Indem ich die Anforderung an anfällige Treiber von EDRSandBlast über GodFault entferne, hoffe ich zu beweisen, dass Admin-to-Kernel-Exploits genauso gefährlich sein können wie verwundbare Treiber und dass MSRC sie ernst nehmen muss. Angesichts des Ziels von Windows 11 der Standardsicherheit und der Tatsache, dass die Sperrliste für anfällige Treiber jetzt standardmäßig aktiviert ist, muss MSRC seine Politik der Gleichgültigkeit gegenüber PPL- und Kernel-Exploits überdenken.