Es gibt verschiedene Arten von Kernel-Treibern. Die ersten, die einem in den Sinn kommen, sind Gerätetreiber, die eine Softwareschnittstelle zu Hardwaregeräten wie Plug-and-Play-Schnittstellen oder Filtertreibern bereitstellen. Diese Low-Level-Systemkomponenten unterliegen einem strengen Entwicklungsprozess, der auch eine Überprüfung der Sicherheit beinhaltet. Es gibt jedoch zusätzliche „Software“-Treiber, die für die Ausführung in Ring 0 entwickelt wurden und spezifische, nicht hardwarebezogene Funktionen wie Software-Debugging und -Diagnose, Systemanalyse usw. bieten. Wie Sie diesem Artikel entnehmen können, können diese die Angriffsfläche von Systemen deutlich vergrößern.

In neueren Windows-Versionen ist das direkte Laden eines bösartigen, unsignierten Treibers nicht mehr möglich (es sei denn, die Überprüfung der Treibersignatur wird während des Bootens explizit deaktiviert). Damit gehören Kernel-Rootkits der Vergangenheit an, es gibt jedoch immer noch Möglichkeiten, bösartigen Code in den Kernel zu laden. Während tatsächlich existierende Schwachstellen und Exploits, die dies erreichen, viel Aufmerksamkeit auf sich ziehen, gibt es einen viel einfacheren Weg: den Missbrauch legitimer, signierter Treiber. Es gibt viele Treiber von verschiedenen Hardware- und Softwareanbietern, die Funktionen bieten, um mit minimalem Aufwand vollständig auf den Kernel zuzugreifen.

Sicherheitslücken in signierten Treibern werden hauptsächlich von Spiele-Cheat-Entwicklern ausgenutzt, um Anti-Cheat-Mechanismen zu umgehen, aber es wurde auch beobachtet, dass sie von mehreren APT-Gruppen und von gängiger Malware verwendet werden.

Dieser Artikel behandelt die Arten von Schwachstellen, die häufig in Kerneltreibern auftreten und bietet mehrere Fallstudien zu Malware, die solche anfälligen Treiber verwendet. Außerdem analysiert er Beispiele für anfällige Treiber, die wir während unserer Forschung entdeckt haben und skizziert wirksame Abwehrtechniken gegen diese Art von Ausbeutung. Obwohl dieses Problem nicht neu ist und in der Vergangenheit, hauptsächlich in den Jahren 2018 und 2019, relevante Forschungen zu diesem Thema vorgelegt wurden ([1], [2], [3]), ist es zum jetzigen Zeitpunkt immer noch ein Problem.

Häufige Arten von Treiber-Schwachstellen

Obwohl jede Schwachstelle anders ist, sind in nicht verwandten Kerneltreibern immer wieder ähnliche Arten von Schwachstellen aufzufinden. Die Ursache können teilweise durch (alten) Treibercode verursacht sein, der erstellt wurde, als der Zugriff auf den Kernel-Modus nicht auf signierte Treiber beschränkt war und Entwickler noch nicht an Sicherheit dachten (Malware konnte einfach unsignierte Rootkit-Treiber laden). In den folgenden Abschnitten werden, die an den häufigsten beobachteten Schwachstellen in Treibern einer Vielzahl von Hardware- und Softwareherstellern beschrieben, einige davon sind bekannt.

MSR read/write

Modellspezifische Register (MSRs) [PDF-Link] wurden 1993 in Pentium 80586-CPUs eingeführt. MSRs kann man sich als „globale Variablen“ einer CPU (oder eines bestimmten Kerns) vorstellen. Einige enthalten verschiedene Informationen über den Prozessor oder spezifischen CPU-Kern – wie Temperatur, Leistung, etc. Darüber hinaus gibt es auch viele MSRs, die für den Betrieb eines Systems kritische Daten enthalten, wie zum Beispiel IA32_LSTAR (0xC0000082) für SYSCALL oder IA32_SYSENTER_EIP (0x00000176) für SYSENTER, die beide Zeiger zu einer Adresse im Kernel enthalten an den die CPU springt, wenn eine SYSCALL - oder SYSENTER -Anweisung ausgeführt wird. Auf neueren Windows x64-Plattformen wie Windows 10 oder 11 wird SYSCALL sowohl für AMD- als auch für Intel-CPUs verwendet, wobei IA32_LSTAR auf die KiSystemCall64-Funktion in ntoskrnl.exe verweisen sollte. Der Übergangsmechanismus zum Windows-Kernel bei der Ausführung von SYSCALL ist in Abbildung 1 dargestellt.

Abbildung 1. Handhabung von SYSCALL in x64-Windows

MSRs werden durch eine Nummer indiziert und durch die privilegierten RDMSR- und WRMSR-Befehle aufgerufen, die nur im Kernel-Modus ausgeführt werden können. Viele kommerzielle Treiber implementieren Funktionen für User-Mode-Anwendungen, um auf diese Anweisungen über einen IOCTL-Mechanismus zuzugreifen. Dies ist normalerweise dazu gedacht, einige bestimmte unschuldige MSRs (wie CPU-Spannung, Temperatur, …) zu lesen oder schreiben zu können, aber Entwickler fügen manchmal keine zusätzlichen Prüfungen hinzu, um den Zugriff auf kritische MSRs einzuschränken, wie das Beispiel in Abbildung 2 zeigt. Dies gibt potenziellen Angreifern die Möglichkeit, zum Beispiel die SYSCALL/SYSENTER-Einstiegspunkt-MSRs zu patchen, bei denen es sich um Zeiger auf eine Funktion handelt, die jeden Systemaufruf aus dem Benutzermodus verarbeitet.

Abbildung 2. Anfälliger MSR-IOCTL-Handler im Treiber AMDPowerProfiler.sys

Das Überschreiben des Systemaufrufzeigers war auf älteren CPUs und Systemen trivial und sehr leistungsfähig, bevor Maßnahmen wie Supervisor Mode Execution Prevention (SMEP) eingeführt wurden. Auf solchen Systemen reichte es aus, einfach den Zeiger auf die Adresse eines beliebigen ausführbaren Puffers im User-Mode zu ändern, der bösartigen Code enthielt, und dann sofort einen Systemaufrufbefehl auf demselben CPU-Kern auszuführen, um Codeausführung auf Kernel-Ebene zu erreichen. Dies ist bei neueren Systemen aufgrund moderner Techniken zur Verhinderung von Codeausführung nicht mehr der Fall. Abgesehen davon ist es durch den geschickten Einsatz verschiedener Techniken immer noch möglich, die meisten dieser Eindämmungsmaßnahmen zu umgehen und eine Codeausführung auf Kernel-Ebene unter Windows 10 oder sogar dem brandneuen Windows 11 zu erreichen (Stand Dezember 2021).

Alle Eindämmungsmaßnahmen in den folgenden Abschnitten sind auf den meisten modernen Computern vorhanden und müssen umgangen werden, um eine erfolgreiche Kernel-Modus-Ausnutzung zu erreichen.

SMEP

SMEP ist ein 2011 in Intel-Prozessoren eingeführter Schutzmechanismus, der auf der Ivy-Bridge-Architektur basiert und seit Windows 8.0 standardmäßig aktiviert ist. Es verhindert die Ausführung von Code in User-Mode-Seiten von Ring 0 und wird implementiert, indem einem Flag-Bit auf jeder virtuellen Speicherseite in der Seitentabelle ein Benutzermodus- oder Kernel-Mode-Wert zugewiesen wird. Wenn ein System versucht, Code in einer User-Mode-Seite aus dem Kernel-Space auszuführen, wird ein 0x000000FC-Fehler (ATTEMPTED_EXECUTE_OF_NOEXECUTE_MEMORY) ausgelöst und ein BSOD verursacht. SMEP kann während der Ausführung dynamisch ein- und ausgeschaltet werden, wobei sein Status im CR4-Register für jeden CPU-Kern einzeln gespeichert wird (siehe Abbildung 3).

Abbildung 3.CR4 -Registerflags einer CPU (Bildnachweis: Wikipedia)

SMEP verhindert die naive Ausnutzung eines MSR R/W IOCTL, um den LSTAR MSR so zu ändern, dass er direkt auf bösartigen Code im User-Mode verweist. Da der Angreifer jedoch die Kontrolle über den Stack hat, der bei Systemaufrufen an den Kernel-Modus übergeben wird, kann er eine Technik namens ROP chain (ROP-Kette) verwenden, um den Stack zu manipulieren. Durch das Platzieren einer Kette von Rücksendeadressen auf dem Stack kann der Angreifer veranlassen, einen sorgfältig ausgewählten Befehlssatz im Kernel-Modus auszuführen, indem er den LSTAR MSR über eine angreifbare IOCTL ändert. Wenn der Stack entsprechend vorbereitet ist, führt die Ausführung des Systemaufrufbefehls zur Ausführung des ersten „Gadgets“ in der ROP-Kette. Danach „kehrt“ der Code zum nächsten Gadget in der Kette zurück, der mit dem Rest auf dem Stack bereitgestellt wurde.

Die Funktionalität einer solchen ROP-Kette wird durch die Verfügbarkeit geeigneter Code-Stücke, sogenannte Gadgets, die in den Modulen des Kernels verfügbar sind, eingeschränkt. Da ein Angreifer Kernel-Module aus dem Dateisystem lesen kann und weiß, an welchen Adressen die Module geladen werden, können die Gadgets leicht nachgeschlagen werden und wenn diese Gadgets existieren, kann dann eine funktionierende ROP-Kette aufgebaut werden.

Um den Übergang zum Kernel richtig zu initialisieren, muss die ROP-Kette das GS-Register unter Verwendung des SWAPGS -Befehls austauschen. Unter 64-Bit-Windows enthält das GS-Register die Adresse des Thread Environment Block (TEB) im User-Mode und die Adresse der Kernel Processor Control Region (KPCR) im Kernel-Mode. Daher ist es entscheidend, dass sich diese beiden Adressen ändern, bevor irgendwelche Operationen im Kernel ausgeführt werden. Es überrascht nicht, dass die Anweisung SWAPGS auch die erste Anweisung in der KiSystemCall64-Funktion des Windows-Kernels ist.

Der nächste Schritt besteht darin, den ursprünglichen Wert des LSTAR MSR unter Verwendung des WRMSR-Befehls wiederherzustellen, um zu vermeiden, dass die ROP-Kette bei der nächsten Ausführung des SYSCALL-Befehls ausgeführt wird.

An diesem Punkt wird der bösartige Code im Kernel ordnungsgemäß ausgeführt und der Angreifer kann jede gewünschte Nutzlast ausführen. Dies können zusätzliche ROP-Gadgets sein, um beispielsweise den SMEP- oder SMAP-Schutz durch Überschreiben von CR4 zu deaktivieren, oder sogar direkte Aufrufe einer exportierten ntoskrnl-API-Funktion.

Der Angreifer kann CR4 mit einem MOV CR4-Gadget überschreiben, um SMEP und auch SMAP zu deaktivieren, was im nächsten Abschnitt behandelt wird. Sie können dann direkt mit der Ausführung einer Nutzlast im Benutzermodus fortfahren. Die einzige Schwierigkeit bei diesem Ansatz besteht darin, einen gültigen CR4-Wert im Voraus zu berechnen. Obwohl die meisten CR4-Werte im Benutzermodus durch Ausführen des CPUID-Befehls erraten werden können, können einige Inkonsistenzen zwischen verschiedenen Windows-Versionen auftreten.

Um sicher in den Benutzermodus zurückzukehren, muss der Angreifer, sobald die ROP-Kette ausgeführt wurde, den SWAPGS-Befehl erneut ausführen und dann den SYSRET-Befehl.

Ältere Exploits, die SMEP umgehen, werden in [4], (2015) beschrieben.

SMAP

Supervisor Mode Access Prevention (SMAP) ist eine neuere Schutzmethode, die eingeführt wurde, um SMEP zu ergänzen und den Zugriff vom Kernel auf User-Mode-Seiten weiter einzuschränken – sie verbietet sowohl Lese- als auch Schreibvorgänge. Sein Status wird wie bei SMEP als Bit im Register CR4 gespeichert (siehe Abbildung 3).

SMAP sollte die zuvor beschriebene ROP-Ketten-Technik nutzlos machen, da der Stapel, der die ROP-Kette enthält, tatsächlich eine User-Mode-Seite ist. Ein System mit aktivem SMAP zeigt Bluescreen, sobald es versucht, auf den Stack zuzugreifen, nachdem es über den Systemaufruf zum Kernel übergegangen ist.

SMAP kann auch vorübergehend deaktiviert werden, indem das AC-Flag im EFLAGS-CPU-Register gesetzt wird. Diese Funktion ist auch die Achillesferse dieser Schutzmethode in Bezug auf die MSR-Ausnutzung – es stellte sich heraus, dass das AC-Flag aus dem User-Mode direkt vor dem Übergang in den Kernel-Mode mithilfe der Anweisungen POPF und PUSHF gesetzt werden kann. Dies wird durch den SFMASK MSR verursacht, der steuert, welche EFLAGS-Registerbits gelöscht werden, wenn der SYSCALL-Befehl ausgeführt wird. Selbst auf den neuesten Windows 11-Rechnern hat die Maske das AC-Flag-Bit nicht gesetzt, was bedeutet, dass sie beim Übergang zum Kernel nicht gelöscht wird und SMAP vom Benutzer deaktiviert werden kann.

Da die SFMASK von einem anderen MSR gesteuert wird (0xC0000084), selbst wenn Microsoft SFMASK so geändert hat, dass das AC-Flag implizit gelöscht wird, könnte der Angreifer diese MSR theoretisch trotzdem vor der Ausnutzung patchen.

Es ist erwähnenswert, dass SMAP erst seit kurzem standardmäßig in Windows 10 x64 mit neuerer Hardware aktiviert ist.

KVA shadowing

KVA-Shadowing wurde als Software-Schutzmaßnahme für die Ende 2017 entdeckte Meltdown-CPU-Sicherheitslücke eingeführt.

Die Grundidee dieser Schutzmaßnahme besteht darin, dass der virtuelle Adressraum in zwei Teile aufgeteilt wird – User-Mode und Kernel-Mode. Der Adressraum im User-Mode hat nur Zugriff auf sehr eingeschränkte Teile des ntoskrnl-Moduls, insbesondere auf einen einzelnen Codeabschnitt Namens .KVASCODE, der für Low-Level-Operationen wie das Betreten und Verlassen des Kernels bei der Verarbeitung eines Systemaufrufs verantwortlich ist. Dies wird gehandhabt, indem „Shadow“-Äquivalente der verantwortlichen Funktionen implementiert werden, wie KiSystemCall64Shadow, das wie das ursprüngliche KiSystemCall64 funktioniert, aber Unterschiede enthält, die für die Handhabung von KVA-Shadowing und das richtige Umschalten des Adressraumkontexts verantwortlich sind (siehe Abbildung 4). Der Rest des Kernels ist vollständig getrennt und auf seinen eigenen Adressraum gemappt und kann nicht einmal direkt von der CPU aus dem User-Mode-Adressraum zugegriffen werden, bis der Kontext entsprechend umgeschaltet wird.

Abbildung 4. Vergleich der Versionen KiSystemCall64 undKiSystemCall64Shadow des System Call Handlers – kleine Unterschiede sind am Anfang der Funktion zu erkennen

Während KVA-Shadowing als Fix für die Meltdown-Schwachstelle entwickelt wurde, verursacht sie möglicherweise auch Probleme für andere Arten von Schwachstellen, einschließlich der MSR-Schwachstelle.

Es gibt im Allgemeinen zwei Ansätze, um den Schutz vor Ausnutzung zu deaktivieren – eine besteht darin, sie als Einstellung in der Registrierung zu deaktivieren. Dies erfordert Administratorzugriff und anschließend einen Neustart, damit die Änderungen wirksam werden.

Alternativ versucht ein Angreifer beim Erstellen einer ROP-Kette für die MSR-Ausnutzung, Gadgets ausschließlich im .KVASCODE-Abschnitt des ntoskrnl -Moduls zu finden, denn da dieser Abschnitt den Systemaufrufübergang behandelt, ist es möglich, eine funktionierende ROP-Kette aufzubauen.

Eine ähnliche Risikominderung wurde auch in Linux-Systemen eingeführt, wo sie als Kernel Page Table Isolation (KPTI) bezeichnet wird.

Physischen Speicher lesen und schreiben

Ein gemeinsames Merkmal von vielen Low-Level-Kernel-Treibern scheint es zu sein, dass sie in der Lage sind, physischen Speicher direkt zu lesen und zu schreiben. Dies wird erreicht, indem ein bestimmter Bereich des physischen Speichers einem virtuellen Speicherpuffer zugeordnet wird, der gelesen oder geschrieben und sogar an eine Anwendung im User-Mode übergeben werden kann. Es gibt mehrere Möglichkeiten, dies zu erreichen. Die gebräuchlichste ist die Möglichkeit, den Abschnitt \Device\PhysicalMemory dem virtuellen Speicher zuzuordnen, wie in Abbildung 5 gezeigt.

Abbildung 5. Sicherheitsanfälligkeit in der physischen Speicherzuordnung im Passmark DirectIO64.sys-Treiber

Ein potenzieller Nachteil für die Angreifer besteht darin, dass sie zuerst die virtuelle Adresse in eine physische übersetzen müssen. Treiber, die physische Speicher-E/A implementieren, bieten manchmal auch eine IOCTL für die Übersetzung einer physischen Adresse in eine virtuelle an. Aber selbst wenn der Treiber keine solche Adresskonvertierung hat, gibt es immer noch viele Möglichkeiten, diese Funktion zu nutzen.

Der einfachste Anwendungsfall besteht darin, einfach den gesamten physischen Speicher zu durchsuchen und nach bestimmten Artefakten zu suchen, die kritische Datenstrukturen darstellen, die der Angreifer finden möchte. Der Angreifer könnte beispielsweise versuchen, nach der EPROCESS -Struktur des bösartigen Prozesses zu suchen und ihn auf SYSTEM -Berechtigungen zu erhöhen, indem er ein Token von einem privilegierteren Prozess stiehlt oder dessen Rechte ändert. Einige dieser Strategien werden hier und hier  demonstriert.

Da physische Speicherzuordnungen jegliche Schutzfunktionen für den virtuellen Speicher außer Acht lassen, ist es auch möglich, auf ausführbare Speicherseiten zu schreiben. Dies gibt dem Angreifer die Möglichkeit, bestimmte Kernel-Module und Code-Blöcke nachzuschlagen, diese sorgfältig zu modifizieren und, falls gepatchter Code über eine System-API oder eine IOCTL eines Treibers ausgeführt werden kann, eine bösartige Codeausführung auf Kernel-Ebene zu erreichen.

Lesen/Schreiben des virtuellen Speichers

IOCTLs für den Zugriff auf den virtuellen Speicher sind in diesen Treibern nicht so häufig zu finden wie diejenigen auf dem physischen Speicher, aber sie haben sehr ähnliche Auswirkungen. Diese zu verwenden ist noch einfacher, da keine Adressübersetzung erforderlich ist und auf alle im Benutzermodus gefundenen virtuellen Kernel-Adressen direkt zugegriffen werden kann. Ein potenzieller Nachteil besteht darin, dass der Zugriff durch den Speicherschutz der Zieladresse eingeschränkt ist, sodass es nicht möglich ist, Nur-Lese-Speicherseiten zu schreiben, ohne den Schutz zuvor zu ändern.

Daher wird diese Sicherheitsanfälligkeit häufig verwendet, um verschiedene Kernel-Datenstrukturen zu manipulieren, um beispielsweise einen bösartigen Prozess auf SYSTEM-Rechte zu erhöhen, indem Token von solchen Kernel-Strukturen gestohlen werden.

Diese Sicherheitsanfälligkeit tritt am häufigsten über eine IOCTL mit einer einfachen Zeiger-Dereferenzierung im Kernel-Mode auf, daher kann es schwierig sein, diese Sicherheitsanfälligkeit mit heuristischen Methoden zu erkennen.

Fallstudien

Wenn Malware-Akteure bösartigen Code im Windows-Kernel auf x64-Systemen auf denen auch die Überprüfung von Treiber-Signaturen (DSE) aktiviert ist, scheint das Verwenden eines anfälligen signierten Kernel-Treibers eine praktikable Möglichkeit zu sein. Diese Technik ist als Bring Your Own Vulnerable Driver (BYOVD) bekannt und wurde sowohl bei hochkarätigen APT-Akteuren als auch bei gängiger Malware in freier Wildbahn beobachtet.

In den folgenden Abschnitten stellen wir einige Beispiele vor.

Slingshot APT

Slingshot ist eine Cyberspionage-Plattform, die 2018 von Kaspersky aufgedeckt wurde [5] und vermutlich seit mindestens 2012 aktiv ist. Die Akteure hinter dieser Malware haben sich entschieden, ihr Hauptmodul namens Cahnadr als Kernel-Modus-Treiber zu implementieren. Auf älteren x86-Systemen würde der Treiber direkt vom User-Mode-Modul geladen werden. Auf neueren Systemen mit aktivem DSE beschlossen sie, einen angepassten Treiber-Loader zu implementieren, der die folgenden signierten Kerneltreiber mit MSR-Schwachstellen nutzt: Goad, SpeedFan (CVE-2007-5633), Sandra (CVE-2010-1592) und ElbyCDIO (CVE-2009-0824). Die Ausnutzung zielte auf Systeme vor Windows 8 ab, daher war der Exploit eine einfache Modifikation des LSTAR MSR, um auf eine bösartige Nutzlast in einem Puffer im User-Mode hinzuweisen.

Beachten Sie, dass die Kaspersky-Forscher davon ausgingen, dass diese Bedrohungsakteure von 2012 bis 2018 aktiv waren, was bedeutet, dass diese Exploits ziemlich alt und bekannt waren. Dies war aber kein Grund für die Angreifer, sie nicht mehr zu verwenden, denn die Zertifikate dieser anfälligen Treiber wurden nie widerrufen.

InvisiMole

Im Jahr 2018 entdeckten ESET-Forscher einen hochentwickelten APT-Akteur, den sie InvisiMole nannten [6]. Die Gruppe wird seitdem von ESET beobachtet und im Jahr 2020 wurde ein umfangreiches Whitepaper (PDF) über die Gruppe und ihr Toolset veröffentlicht. In diesem Whitepaper berichteten unsere Kollegen, dass InvisiMole die BYOVD-Technik verwendet und die MSR-Sicherheitslücke im speedfan.sys-Treiber (CVE-2007-5633) ausnutzt, um einen bösartigen unsignierten Treiber zu laden. Obwohl diese Kampagne auf ältere x86-Systeme abzielte und die Ausnutzung eines bösartigen Treibers aus heutiger Sicht trivial war, da es noch keine Schutzmaßnahmen gab, war es dennoch ein interessanter Fall. Er zeigte, dass die Gruppe hinter dieser Malware technisch sehr fähig ist.

Später während dieser Untersuchung wurde jedoch eine neuere Variante der InvisiMole-Malware entdeckt, die die BYOVD-Technik verwendet. Diese Variante ist der einzige Fall, in dem wir bisher eine MSR-Ausnutzung auf Windows 10 x64-Systemen durch einen böswilligen Akteur in der freien Wildbahn beobachten konnten. Sie verwendet fortschrittliche Techniken, um Schutzmaßnahmen wie SMEP und sogar SMAP zu umgehen. Allerdings wird die Ausnutzung durch KVA-Shadowing eingedämmt, um das sich die Malware-Entwickler nicht gekümmert haben. Zufälligerweise wurde die Ausnutzung von MSR verwendet, um einen bösartigen Treiber bereitzustellen, der versuchte, unsere Sicherheitsprodukte zu deaktivieren. Obwohl die gesamte Kompromittierungskette umfangreicher ist, konzentrieren wir uns auf einen bestimmten Teil der Malware, der die BYOVD-Technik und die MSR-Ausnutzung verwendet, die im HauptUser-Mode-Modul stattfindet.

User-Mode-Modul

Die Autoren von InvisiMole scheinen ein ausgeklügeltes Framework zur Ausnutzung von ROP-Ketten  entwickelt zu haben, das sie für die MSR-Exploits verwenden – obwohl das Code-Sample viele Debug-Meldungen im Code enthält, konnten wir sie nicht mit bekannten Projekten in Verbindung bringen. Dies lässt uns glauben, dass das Framework ein Originalwerk dieser Malware-Autoren ist und dass beträchtliche Ressourcen für die Entwicklung aufgewendet wurden. Das Framework ist eine umfangreiche C++-Codebasis mit verschiedenen Klassen.

Anscheinend wussten die Autoren von InvisiMole nicht von der Möglichkeit, das AC-Flag mit den Anweisungen PUSHF und POPF zu setzen, wie im Abschnitt SMAP beschrieben, und wählten stattdessen ein sehr komplexes ROP-Gadget aus der Kernelfunktion MiDbgCopyMemory, das mit der privilegierten STAC-Anweisung beginnt, die dem Setzen des AC-Flags gewidmet ist (siehe Abbildung 6). Darüber hinaus verwendet InvisiMole den IRETQ-Befehl nach jedem Gadget, das das RFLAGS-Register explizit mit dem gesetzten AC-Flag setzt, was den Exploit noch weiter stabilisiert.

Abbildung 6. ROP-Gadget, das von InvisiMole verwendet wird, um die SMAP-Abwehr zu deaktivieren

Das anfängliche Gadget springt direkt zum STAC-Befehl, der SMAP sofort deaktiviert, indem er das AC-Flag setzt. Da dieses Gadget mitten in der MiDbgCopyMemory-Funktion auftaucht, bereitet die Malware den Stack sorgfältig vor und registriert sich, um die Funktion sicher zu verlassen. Sobald die MiDbgCopyMemory-Funktion zurückkehrt, fährt die ROP-Kette mit dem SWAPGS-Gadget [7] fort, um richtig in den Kernel-Modus zu wechseln, gefolgt von dem WRMSR-Gadget, um den LSTAR MSR auf seinen ursprünglichen Wert zurückzusetzen. An diesem Punkt fährt InvisiMole mit der Ausführung der Nutzlast fort, die eine exportierte Kernelfunktion oder der Einstiegspunkt eines geladenen bösartigen Treibers sein kann.

Treiberlader

Die Technik zum Laden von Treibern ist komplex – InvisiMole installiert zuerst einen „Treiberlader“ – ein weiteres Kernel-Treibermodul, das verwendet wird, um die als Argument übergebene bösartige Nutzlast (noch einen anderen Treiber) zu laden. Um den Treiberlader zu initialisieren, führt InvisiMole mehrere separate MSR-Exploits aus Dabei trägt jede Instanz eine dedizierte ROP-Kette mit einer einzigen API-Aufruf-Nutzlast. Die Malware beginnt mit der Ausführung von ExAllocatePoolWithTag, um einen ausführbaren Kernel-Speicherpuffer für den Loader zuzuweisen, gefolgt von der Vorbereitung des Images im Benutzermodus, um seine zukünftige Adresse im Kernel widerzuspiegeln – Abschnitte werden an ihre virtuellen Offsets verschoben; Importe werden gelöst und Verlagerungen behoben. Sobald das Image fertig ist, wird es mit memcpy aus dem ntoskrnl-Modul aus dem Benutzermodus in den zugewiesenen Kernel-Puffer kopiert.

Um die Codeausführung an den Loader zu übertragen, sobald er in den Kernel kopiert wurde, nutzen die Autoren von InvisiMole auch die MSR-Schwachstelle und entwickelten mehrere dedizierte PE-Exporte im Loader (Beispiel siehe Abbildung 7), die Übergänge vom User-Mode-Systemaufrufen verarbeiten sollen. Es funktioniert sehr ähnlich wie die ROP-Chain-Gadgets – GS-Register tauschen, User-Mode- und Kernel-Mode-Stacks austauschen, alle Register auf dem Stack speichern, den ursprünglichen LSTAR MSR-Wert wiederherstellen und dann die eigentliche Funktion aufrufen. Nach Beendigung wird dieser Vorgang umgekehrt.

Abbildung 7. Exportierte Funktion im Treiberlademodul, die durch Ändern von LSTAR MSR . aufgerufen wird

Wenn der Loader im Kernel richtig initialisiert ist, wird ein Export namens _Start64 ausgeführt, indem LSTAR MSR auf die Exportadresse im Kernel geändert wird. Nach der Verarbeitung des Übergangs zum Kernel registriert _Start64 eine verzögerte Routine, die für das Laden des Payload-Treibers verantwortlich ist, und kehrt in den User-Mode zurück. Die zurückgestellte Loader-Routine versucht, den Payload-Treiber auf „richtige“ Weise zu initialisieren – indem sie Registrierungsschlüssel und Kernel-Treiberobjekte erstellt, alle notwendigen Schritte ausführt, um den Treiber im System zu registrieren, als ob das Betriebssystem den Treiber selbst laden würde, und schließlich IoCreateDriver aufruft. Der korrekte Initialisierungsansatz wurde gewählt, damit der geladene Nutzlasttreiber E/A-Anforderungspakete verarbeiten und mit einem User-Mode-Modul unter Verwendung von IOCTLs kommunizieren kann.

Nutzlasttreiber

Der Payload-Treiber bietet IOCTL-Funktionalität zum Deaktivieren verschiedener Benachrichtigungs-Callbacks (siehe Abbildung 8), die hauptsächlich darauf abzielen, Sicherheitslösungen von Drittanbietern zu deaktivieren, und die Möglichkeit, eine Datei im Dateisystem zu schützen. Die spezifischen Befehle werden vom User-Mode-Modul übergeben. Interessanterweise versucht das User-Mode-Modul, verschiedene Teile des ESET-Schutzes im Kernel zu deaktivieren.

Abbildung 8. IOCTL-Handler im InvisiMole-Nutzlasttreiber

RobbinHood

Eine BYOVD-Technik in gängiger Malware zu sehen, die darauf abzielt, so viele Menschen wie möglich zu erreichen, ist selten, aber die RobbinHood-Ransomware-Familie zeigt, dass sie sich dennoch als nützlich erweisen kann [8].

Diese Ransomware nutzt einen anfälligen GIGABYTE-Motherboard-Treiber GDRV.SYS (CVE-2018-19320; siehe Abbildung 9 und Abbildung 10), um DSE zu deaktivieren und dann ihren eigenen bösartigen Treiber zu installieren.

Abbildung 9. Ausnutzung des GIODrv-Treibers im RobbinHood-Beispiel

Wie DSE deaktiviert wird, hängt von der Windows-Version ab – unter Windows 7 und älter wird eine nt!g_CiEnabled-Variable direkt im ntoskrnl-Modul geändert. Auf neueren Windows 8- bis Windows 11-Systemen wird stattdessen die Variable ci!g_CiOptions im Modul ci.dll geändert. Das Auffinden dieser Variable ist etwas komplizierter und es sieht so aus, als hätten die Autoren eine Methode übernommen, die in einem Open-Source-Projekt namens DSEFix gefunden wurde, das auf GitHub verfügbar ist. Darüber hinaus sind die Variablen in ci.dll seit Windows 8.1 durch PathcGuard geschützt und eine Manipulation des Moduls führt schließlich zum BSOD des Systems, selbst wenn die Variable wieder auf einen ursprünglichen Wert geändert wird.

Der bösartige Treiber wird dann verwendet, um eine lange Liste von Prozessen zu beenden und ihre Dateien zu löschen, wobei der Schwerpunkt hauptsächlich auf Endpoint Protection-Software und anderen Dienstprogrammen liegt. Da die Beendigung im Kernel-Mode erfolgt, werden die meisten von Sicherheitssoftware verwendeten Selbstschutzmechanismen umgangen, und die Technik ist wahrscheinlicher erfolgreicher als der Versuch, den Schutz aus dem User-Mode zu deaktivieren.

Abbildung 10. WriteVirtualMemory-IOCTL-Handler in GIODrv

LoJax

Im Jahr 2018 entdeckten ESET-Forscher das allererste UEFI-Rootkit, das in freier Wildbahn verwendet wurde. Um Zugriff auf die UEFI-Module der Opfer zu haben, verwendet die Malware ein leistungsstarkes Dienstprogramm namens RWEverything.

Der RWEverything-Treiber wurde kürzlich von Microsoft direkt in Windows 10 und 11 deaktiviert, indem die im Abschnitt Virtualisierungsbasierte Sicherheit beschriebene HVCI-Speicherintegritätsfunktion verwendet wurde.

Entdeckte Schwachstellen

Bei unserer Forschungsarbeit haben wir uns entschieden, nicht nur bestehende Schwachstellen zu katalogisieren, sondern auch nach neuen zu suchen. Wir haben YARA-Regeln eingerichtet, um nach Kernel-Treibern mit bestimmten Funktionen und Indikatoren für potenzielle Schwachstellen zu suchen. Außerdem haben wir ein proof-of-concept exploitation framework erstellt, um die neu gefundenen Treiber zu testen und zu bestätigen, dass sie anfällig sind.

Wir haben Hunderte von verschiedenen Kernel-Treibern durchgesehen, die unseren Kriterien entsprachen, und abgesehen von den bereits entdeckten Treibern haben wir auch drei Treiber gefunden, die zuvor nicht als angreifbar galten und die teilweise mehrere voneinander unabhängige Fehler enthielten. Sogar nachdem sich mehrere unabhängige Forschungsgruppen mit diesem Thema befasst haben, konnten wir immer noch neue Schwachstellen, auch von namhaften Herstellern, finden.  Das zeigt, dass die Windows-Treibersicherheit immer noch ein Problem ist.

Während wir nach allen Arten von Schwachstellen suchten, die in den vorherigen Abschnitten beschrieben wurden, erwies sich das Auffinden von Schwachstellen mit MSR-Zugriff als am einfachsten, da sie am häufigsten aufgrund der Verwendung spezieller privilegierter Anweisungen (RDMSR/WRMSR) auftraten, die diese Funktionalität verraten. Interessanterweise stellte sich in vielen Fällen heraus, dass diese Treiberklasse auch andere Arten von Schwachstellen wie beliebige Lese- und Schreibfunktionen des physischen oder virtuellen Speichers enthielt.

AMD μProf (CVE-2021-26334)

Wir haben eine MSR-Sicherheitslücke im Kerneltreiber AMDPowerProfiler.sys identifiziert, der Teil der Performance-Analyse-Software AMD μProf ist.

Das Besondere an diesem Treiber ist, dass der Treiber nach der Installation des zugrunde liegenden Softwarepakets bei jedem Systemstart ausgeführt wird. Der ungefilterte MSR-IOCTL-Zugriff in Kombination mit dem Fehlen von FILE_DEVICE_SECURE_OPEN-Flags (siehe Abbildung 11) und der On-Boot-Präsenz bietet dem Angreifer eine gute Möglichkeit, den Treiber auch als unprivilegierter Benutzer auszunutzen – dies ist ein Vorteil gegenüber dem BYOVD-Ansatz, wenn der Angreifer den Treiber selbst laden muss.

Abbildung 11. Erstellung eines AMD uProf-Kerneltreibergeräts ohne das Flag FILE_DEVICE_SECURE_OPEN, das Nicht-Administratorzugriff ermöglicht

Andererseits ist die Software ein Nischendienstprogramm für Entwickler und kein Paket, das auf eine große Anzahl von Systemen verteilt wird. Wir haben keine andere Schwachstelle im Treiber identifiziert.

Das anfällige IOCTL ist IOCTL_ACCESS_MSR (0x222030).

AMD hat die Sicherheitsanfälligkeit (CVE-2021-26334) bestätigt und in der Patch-Tuesday-Version vom November 2021 einen Fix veröffentlicht.

Passmark-Software

Passmark ist ein Unternehmen, das verschiedene Computer-Benchmark- und Diagnosetools anbietet. Um eine solche Funktionalität im User-Mode zu erreichen, muss auf viele Low-Level-Systemfunktionen über einen Kernelmodus-Treiber zugegriffen werden.

Die Kerneltreiber DirectIo32.sys und DirectIo64.sys von Passmark sind ein gemeinsames Framework, das von mehreren Anwendungen des Anbieters geteilt und verteilt wird – nämlich BurnInTest, PerformanceTest und OSForensics.

Der Treiber enthält direkten, ungefilterten MSR-R/W-Zugriff (CVE-2020-15480), eine Fähigkeit, physischen Speicher (CVE-2020-15481) sowohl zum Lesen als auch zum Schreiben zuzuordnen, und der IOCTL-Handler enthält außerdem einen Pufferüberlauf (CVE-2020-15479) aufgrund des blinden Kopierens eines IOCTL-Eingabepuffers beliebiger Größe in eine lokale Variable auf dem Stack ohne Größenprüfung.

Passmark hat diese Schwachstellen bestätigt und veröffentlichte kurz darauf eine gepatchte Version.

CVE-2020-15479

Wenn der Treiber eine IOCTL-Anforderung von einem User-Mode-Programm empfängt, kopiert er zuerst den angeforderten Eingabepuffer in einen lokalen Puffer auf dem Stack. Die Größe des memmove basiert nur auf der Größe des Eingabepuffers (siehe Abbildung 12) und berücksichtigt nicht die Kapazität des Stapelpuffers. Dies kann zu einem Pufferüberlauf führen, wenn ein ausreichend großer IOCTL-Puffer bereitgestellt wird. Es gibt mehrere ungeprüfte memmove-Aufrufe in der IOCTL-Handlerfunktion und mehrere IOCTLs können verwendet werden, um den Pufferüberlauf zu nutzen.

Abbildung 12. Pufferüberläufe in den anfälligen Passmark-Treibern

CVE-2020-15480

Dieser Treiber bietet RDMSR- und WRMSR-Funktionalität, die über eine IOCTL bereitgestellt wird, die es einem nicht privilegierten User-Mode-Programm ermöglicht, beliebige CPU-MSRs ohne zusätzliche Prüfungen zu lesen und zu schreiben. Die anfälligen IOCTLs sind IOCTL_READ_MSR (0x80112060) und IOCTL_WRITE_MSR (0x80112088).

CVE-2020-15481

Die physische Speicherzuordnungsfunktionalität wird über einen einzigen Steuercode bereitgestellt – IOCTL_MAP_PHYSICAL_MEMORY (0x80112044). Die Implementierung gliedert sich in zwei Teile: Die primäre Version erfolgt über die ZwMapViewOfSection-API; Wenn diese Methode aus irgendeinem Grund fehlschlägt, implementiert die Funktion über die Kernel-APIs MmMapIoSpace und MmMapLockedPages auch einen sekundären Ansatz als Backup. Beide sind in Abbildung 13 dargestellt.

Abbildung 13. IOCTL-Implementierung des physischen Speichers in den Treibern von Passmark

Devid Espenschied PC Analyser

PC Analyzer ist ein weiteres Dienstprogramm zum Überprüfen verschiedener Details von Geräten. Der mit der Anwendung gelieferte Kerneltreiber PCADRVX64.sys enthält zwei separate Schwachstellen – ungefilterter MSR-Zugriff (CVE-2020-28921) und die Fähigkeit, von beliebigen physischen Speicheradressen zu lesen und zu schreiben (CVE-2020-28922). Beim Erstellen des Treibergeräts ist das Flag FILE_DEVICE_SECURE_OPEN nicht angegeben, sodass nicht privilegierte Benutzer ein Handle für den Treiber abrufen können.

Devid Espenschied hat die Schwachstellen bestätigt und eine aktualisierte Version veröffentlicht.

CVE-2020-28921

Wie bei früheren Treibern ist der MSR-Zugriff uneingeschränkt (siehe Abbildung 14) und der IOCTL-Code-Handler enthält FILE_ANY_ACCESS-Flags, die es sogar einem nicht privilegierten Benutzer ermöglichen, die Funktionalität zu nutzen.

Abbildung 14. MSR IOCTL-Implementierung im PC Analyzer-Treiber

CVE-2020-28922

Die Lese- und Schreibfunktionalität des physischen Speichers des Treibers wird mit separaten IOCTLs basierend auf der Größe der Lese- oder Schreibanforderung implementiert. Es bietet die folgenden Kontrollcodes, von denen keiner eine Überprüfung der von der Anfrage anvisierten Speicheradressen durchführt:

IOCTL_READ_PHYSICAL_MEMORY_BYTE (0x82002400)
IOCTL_READ_PHYSICAL_MEMORY_WORD (0x82002500)
IOCTL_READ_PHYSICAL_MEMORY_DWORD (0x82002600)
IOCTL_WRITE_PHYSICAL_MEMORY_BYTE (0x82002700)
IOCTL_WRITE_PHYSICAL_MEMORY_WORD (0x82002800)
IOCTL_WRITE_PHYSICAL_MEMORY_DWORD (0x82002900)

Schadensbegrenzungsmaßnahmen

Obwohl wir bereits einige Mechanismen der CPU und/oder des Betriebssystems erwähnt haben, können die meisten von ihnen mit einigen cleveren Techniken umgangen werden und sind nicht sehr effektiv, wenn sich der Angreifer im Voraus darauf vorbereitet. In diesem Abschnitt möchten wir einige Schadensbegrenzungsideen erwähnen, die tatsächlich wirksam sind, um den Missbrauch gefährdeter Treiber vollständig zu stoppen.

Virtualisierungsbasierte Sicherheit

Virtualisierungsbasierte Sicherheit oder VBS ist eine in Windows 10 eingeführte Funktion, die Hardwarevirtualisierung nutzt und den Kernel in eine durch einen Hypervisor kontrollierte Sandbox packt, um das Betriebssystem mit verschiedenen Schutzmaßnahmen zu schützen.

VBS bietet mehrere Schutzfunktionen, von denen die bekannteste die Hypervisor-Protected Code Integrity (HVCI) ist, die auch als eigenständige Funktion erhältlich ist. HVCI erzwingt die Codeintegrität im Kernel und lässt nur die Ausführung von signiertem Code zu. Es verwendet auch eine Blocklisting-Funktionalität, bei der ein bekannter Code, der mit einer bestimmten, gültigen Signatur signiert ist, in eine Blocklist aufgenommen werden kann und nicht ausgeführt oder geladen werden darf. Einer der Treiber, der bereits über diese Methode auf die Sperrliste gesetzt wurde, ist das Dienstprogramm RWEverything.

HVCI verhindert effektiv, dass anfällige Treiber missbraucht werden, um unsignierten Kernel-Code auszuführen oder bösartige Treiber zu laden (unabhängig von der verwendeten Ausnutzungsmethode). Es macht den Anschein, dass Malware, die anfällige Treiber für das Nachladen von bösartigem Code nutzt, eine der Hauptbeweggründe Microsofts für die Implementierung dieses Features war:

VBS bietet erhebliche Sicherheitsgewinne gegen praktische Angriffe, darunter mehrere, die wir im letzten Jahr gesehen haben. Dazu gehören von Menschen betriebene Ransomware-Angriffe wie RobbinHood und ausgeklügelte Malware-Angriffe wie Trickbot, die Kernel-Treiber und -Techniken verwenden, die durch HVCI abgewehrt werden können. Unsere Untersuchungen zeigen, dass es 60 % weniger aktive Malware-Berichte von Computern gab, die Erkennungen an Microsoft 365 Defender mit aktiviertem HVCI meldeten, im Vergleich zu Systemen ohne HVCI. Das Surface Book 3, das im Mai 2020 ausgeliefert wurde, und das Surface Laptop Go, das im Oktober 2020 ausgeliefert wurde, und Benutzer haben möglicherweise nicht bemerkt, dass sie VBS verwenden und sind daher aufgrund der Arbeit unter der Haube besser geschützt. [Betonung hinzugefügt]

Abgesehen von der Durchsetzung der Kernel-Code-Integrität sichert VBS auch wichtige MSRs und verbietet jegliche Änderungen an ihnen. Es überrascht nicht, dass dieser Schutz auch den LSTAR MSR betrifft und alle oben beschriebenen Ausnutzungsmöglichkeiten abschwächt.

Während VBS im Allgemeinen ein wirksamer Schutz gegen MSR-Ausnutzung und das Ausführen von Schadcode im Kernel ist, ist die Akzeptanz dieser neuen Funktion ziemlich begrenzt, da sie mehrere Hardwareanforderungen stellt, die nur neuere Maschinen erfüllen können. Es gibt auch einige Nachteile, wobei der bemerkenswerteste ein Leistungseinbruch ist, der je nach Arbeitsbelastung durchaus spürbar sein kann. Während einige Benchmarks die Leistungseinbußen bei bestimmten Videospielen auf bis zu 25 % schätzen, schätzt das detailliertere Benchmarking von Tom's Hardware die Leistungseinbußen, je nach den jeweiligen Benchmarks und der Hardwarekonfiguration, auf etwa 5 % (siehe Abbildung 15). Dies ist nicht zu vernachlässigen und veranlasst einige Benutzer möglicherweise dazu, diese Funktion zu deaktivieren. Es kann auch einige Kompatibilitätsprobleme mit älteren Treibern und Software geben. Mit der Veröffentlichung von Windows 11 hat Microsoft beschlossen, HVCI standardmäßig für alle kompatiblen Geräte zu aktivieren.

Abbildung 15. VBS-Benchmark-Ergebnisse von Toms Hardware

Hypervisor von Drittanbietern

Ähnlich wie bei Microsofts VBS kann eine Sicherheitslösung eines Drittanbieters mit ausreichend neuer Hardware einen eigenen benutzerdefinierten Hypervisor bereitstellen. Das Ausführen des Betriebssystems unter einem Hypervisor gibt einen detaillierten Überblick über den Zustand der Maschine und bietet die Möglichkeit, jedes Ereignis einschließlich der Ausführung eines bestimmten Befehls zu überprüfen und abzufangen. Wie bei VBS hat dies seinen Preis, nämlich Leistung und Kompatibilität.

Zertifikatssperrung

Auf modernen Windows-Systemen benötigen Treiber eine gültige Signatur basierend auf einem „akzeptablen“ Zertifikat. Daher wäre das Widerrufen des Zertifikats eines gefährdeten Treibers eine einfache Möglichkeit, diese Schwachstelle in den meisten Fällen zu entschärfen und unbrauchbar zu machen.

Leider kommt es selten zu einem Widerruf. Von den gefährdeten Treibern, die in unserer obigen Untersuchung dokumentiert wurden, wurde keinem die Signatur widerrufen. Es gibt wahrscheinlich eine Vielzahl von Gründen, warum solche Widerrufe nicht stattfinden, aber die wichtigsten sind wahrscheinlich Zeit und Kosten. Da niemand den Widerruf verlangt, ist es aus Sicht des Anbieters wenig sinnvoll, einen Widerruf zu verlangen, da dies ein kostspieliger und zeitaufwändiger Prozess ist. Darüber hinaus wird ein Signaturzertifikat auch von andere Projekte genutzt, so dass der potenzielle Widerruf aufgrund eines einzelnen Treibers die Entwicklung jedes Projekts behindern könnte.

Zudem haben wir bei unseren Recherchen festgestellt, dass Treiber mit widerrufenen Zertifikaten nicht immer blockiert werden und dass dieses Problem komplizierter ist, als es zunächst schien. Der Widerruf ist vielleicht nicht die einfachste Lösung.

Treiber-Blocklisting

Das Blockieren von Treibern ist eine Methode, die sowohl von Microsoft als auch von verschiedenen Drittanbietern von Sicherheitsprodukten übernommen wird. Einige der berüchtigtsten anfälligen Treiber werden von ESET-Sicherheitsprodukten erkannt und gelöscht, wenn sie auf einem System gefunden werden. Microsoft hat sich auch dafür entschieden, Treiber nicht nur mit seiner Sicherheitslösung zu blockieren, sondern auch direkt durch das Betriebssystem, das seine HVCI-Schadensbegrenzungsmaßnahmen verwendet, die Teil der virtualisierungsbasierten Sicherheit sind. Blocklisting ist zwar effektiv, aber keine proaktive Lösung – nur zuvor erkannte anfällige Treiber können in eine Blocklist aufgenommen werden und dies muss von jedem Anbieter manuell durchgeführt werden. Dies bedeutet, dass diese Schadensbegrenzungsmaßnahme bei bisher unbekannten Zero-Day-Treiber-Schwachstellen, die bei einem ausgeklügelten APT-Angriff verwendet werden könnten, nicht wirksam ist.

Der wohl prominenteste Blocklist-Treiber ist der Capcom-„Anti-Cheat“-Treiber Capcom.sys, der explizit eine IOCTL implementiert, die einfach den Inhalt des bereitgestellten Puffers im Kernel-Mode ausführt (siehe Abbildung 16). Um einen vom User-Mode bereitgestellten Puffer ausführen zu können, wird SMEP sogar vorübergehend deaktiviert!

Als der Treiber entdeckt wurde, geriet er in die Schlagzeilen und viele unsignierte Treiber-Loader-Tools wurden basierend auf dem Missbrauch dieser Funktion des Treibers erstellt. Folglich wurde der Treiber schließlich von vielen Anbietern von Sicherheitsprodukten, darunter Microsoft und ESET, auf die Sperrliste gesetzt.

Abbildung 16. Code-Snippet des Anti-Cheat-Treibers von Capcom

Fazit

Anfällige Treiber sind ein seit langem bekanntes Problem und werden von der Game-Cheating-Community und den Malware-Autoren gleichermaßen missbraucht, und obwohl einige Anstrengungen unternommen wurden, um den möglichen Schaden zu begrenzen, ist dies ein immer noch ein anhaltender Kampf. Es scheint, dass alle beteiligten Verantwortlichen dieses Problem lösen wollen – die Anbieter, die wir kontaktiert haben, waren während des Offenlegungsprozesses unglaublich proaktiv, um die von uns aufgedeckten Schwachstellen zu beheben. Microsoft versucht, das Betriebssystem von innen heraus zu stärken, und nicht zuletzt versuchen Sicherheits-Drittanbieter, clevere Wege zu finden, solche Treiber selbst zu erkennen und zu entschärfen.

Es scheint jedoch, dass noch ein Teil fehlt – eine gemeinsame, einheitliche Art und Weise, diese Probleme zu lösen, einschließlich einer gründlicheren Methode zur „Entschärfung“ der Treiber, sei es durch Widerrufen oder Sperren ihrer Zertifikate oder durch öffentliche, bekannte Sperrlisten, wie Sicherheitsunternehmen sie pflegen.

 

Bibliography


[1] J. Desimone and G. Landau, "BlackHat 2018: Kernel-mode Threats and Practical Defences," 9 August 2018. [Online].
[2] R. Warns and T. Harrison, "INFILTRATE 2019: Device Driver Debauchery and MSR Madness," 2 May 2019. [Online].
[3] J. Michael and M. Skhatov, "Defcon 27: Get off the Kernel if you can't Drive," 13 August 2019. [Online].
[4] N. Economou and E. Nissim, "ekoparty 2015: Windows SMEP bypass: U=S," 2015. [Online].
[5] A. Shulmin, S. Yunakovsky, V. Berdnikov and A. Dolgushev, "The Slingshot APT," 6 March 2018. [Online].
[6] Z. Hromcová and A. Cherepanov, "InvisiMole: The Hidden Part of the Story – Unearthing InvisiMole's Espionage Toolset and Strategic Cooperations," 18 June 2020. [Online].
[7] A. Ionescu, "UMPOwn: Ring 3 to Ring 0 in 3 acts," in PoC||GTFO, vol. 2, No Starch Press, 2018, p. 768.
[8] A. Brandt and M. Loman, "Living off another land: Ransomware borrows vulnerable driver to remove security software," Sophos, 7 February 2020. [Online].