Einmal Kernel-Zugriff bitte – BYOVD und verwundbare Treiber

Einleitung

BYOVD-Angriffe (Bring Your Own Vulnerable Driver) haben sich in den letzten Jahren zu einer ernstzunehmenden Bedrohung entwickelt. Angreifer nutzen dabei legitime, aber verwundbare Kernel-Treiber, um privilegierte Operationen auf Zielsystemen auszuführen. Hierbei spielt es keine Rolle, welche Treiber auf dem System regulär verwendet werden, sondern lediglich, welche Treiber unterstützt werden, also welche Treiber Angreifer im Nachhinein noch installieren können. Ein aktueller Blog-Artikel von Check Point Research zeigt, dass verschiedene Versionen des Truesight-Treibers aktiv in freier Wildbahn für solche Angriffe eingesetzt werden.

Dieser Artikel zeigt die technischen Hintergründe von BYOVD-Angriffen: Warum Legacy-Treiber ein strukturelles Sicherheitsproblem darstellen, wie Microsofts Schutzmaßnahmen umgangen werden können und wie simpel die praktische Ausnutzung am Beispiel des Truesight-Treibers tatsächlich ist.

Warum alte Treiber so problematisch sind

Legacy vs. moderne Signaturen

Microsoft hat die Anforderungen an Kernel-Treiber-Signaturen im Laufe der Jahre verschärft. Ein entscheidender Wendepunkt war Windows 10 Version 1607: Ab dieser Version implementierte Microsoft eine neue Policy, die das Laden jeglicher neuer Kernel-Mode-Treiber verhindert, die nicht über das Microsoft Developer Portal (also direkt von Microsoft selbst) signiert wurden.

Diese Verschärfung sollte die Qualität und Sicherheit von Treibern erhöhen. Allerdings gibt es eine bedeutende Ausnahme: Treiber, die vor dem 29. Juli 2015 signiert wurden, dürfen weiterhin geladen werden. Das eigentliche strukturelle Problem: Treiber-Schwachstellen werden zwar gepatcht, aber Windows erlaubt weiterhin das Laden älterer, signierter Versionen. Dadurch können bekannte und bereits behobene Bugs gezielt reaktiviert werden.

Details zu dieser Policy finden sich in der offiziellen Microsoft-Dokumentation zur Kernel-Mode-Code-Signing-Policy.

Microsofts Gegenmaßnahmen und ihre Limitierungen

Die Windows Treiber-Blockliste

Microsoft ist sich des Problems bewusst und unterhält eine Blockliste für bekannte verwundbare Treiber. Diese Blockliste identifiziert problematische Treiber anhand verschiedener Merkmale:

• Authentihash: Der kryptografische Hash des signierten Teils der Datei
• Version und Name: Spezifische Versionsnummern und Dateinamen
• Signer-Informationen: Identifikation über den TBS (To Be Signed) Hash des Zertifikats

Diese mehrschichtige Identifikationsstrategie soll sicherstellen, dass verwundbare Treiber zuverlässig erkannt und blockiert werden.

Die Grenzen der Blockliste

Trotz dieser Bemühungen gibt es erhebliche Limitierungen:

• Versionsdiversität: Ein einzelner Treiber existiert oft in dutzenden verschiedenen Versionen. Nicht alle diese Versionen befinden sich notwendigerweise auf der Blockliste. Angreifer können ältere oder weniger verbreitete Versionen verwenden, die noch nicht erfasst wurden. Ein Treiber kann beispielsweise in den Versionen 3.0.2 bis 3.4.7 eine Sicherheitslücke aufweisen. Theoretisch sollten daher alle Versionen in diesem Bereich blockiert werden, häufig landen jedoch nur ausgewählte Versionen auf der Blockliste, etwa 3.4.7.
• Blockliste nur auf neueren Systemen aktiv: Die Treiber-Blockliste selbst ist erst ab Windows 11 (2022 Update) standardmäßig aktiviert. Ältere Windows-Versionen, insbesondere Windows Server-Installationen, verfügen nicht automatisch über diesen Schutz. Angesichts der langen Support-Lebenszyklen von Server-Systemen und der Tatsache, dass einige Organisationen noch Windows 10 oder ältere Versionen einsetzen, bleibt ein erheblicher Teil der installierten Basis ungeschützt gegen bekannte verwundbare Treiber.

Mehr Informationen, inklusive der Blockliste selbst werden hier von Microsoft bereitgestellt.

EDR-Software als zusätzlicher Schutz

Ein weiterer Schutz besteht durch den Einsatz von Endpoint Detection and Response Software (EDRs). Die Hersteller pflegen eigene Erkennungssignaturen für anfällige Treiber, die von Angreifergruppen aktiv eingesetzt werden. Das zeigt sich bei der Analyse des Truesight-Treibers auf VirusTotal:

Die Ergebnisse des Scans können hier nachgelesen werden.

Auch hier gibt es Grenzen: CVE-2013-3900 ermöglicht Signatur-Umgehung

Statische Malware-Signaturen, die auf Hash-Werten basieren, können durch die Ausnutzung von CVE-2013-3900 umgangen werden. Die Schwachstelle erlaubt es, einzelne Bytes zu verändern, ohne dabei die digitale Signatur (Authentihash) zu invalidieren. Der allgemeine Datei-Hash ändert sich dadurch, was erkennungsbasierte Schutzmaßnahmen umgeht. Dieses Verhalten wurde im oben genannten Check Point Beitrag im Detail beleuchtet, wobei über 2500 verschiedene Varianten des Truesight-Treibers identifiziert wurden.

Verändert man ein einzelnes Byte des Treibers, geht die Erkennungsrate deutlich nach unten:

Obwohl CVE-2013-3900 bereits vor langer Zeit von Microsoft behoben wurde, besteht ein grundlegendes Problem: Da der Fix potenziell dazu führen kann, dass auch legitime, unveränderte Treiber nicht mehr korrekt geladen werden, ist er nicht standardmäßig aktiviert. Stattdessen muss er manuell über die Registry eingeschaltet werden:

Weitere Details finden sich auf der offiziellen Microsoft Seite. Die technische Funktionsweise wird im folgenden Abschnitt detailliert demonstriert.

Treiber-Exploitation Demystified

Weniger kompliziert als gedacht

Der Begriff “Kernel-Exploit” klingt nach komplexen Buffer-Overflows, ausgeklügelten ROP-Chains und tiefgreifendem Verständnis von Kernel-Internals. Die Realität von BYOVD-Angriffen ist jedoch oft deutlich simpler: Viele “Kernel-Treiber-Exploits” sind eigentlich triviale Funktionen, die der Treiber bereitstellt und die man als Angreifer einfach selbst nutzen kann.

Anatomie eines verwundbaren Treibers

Schauen wir uns den Truesight-Treiber als konkretes Beispiel an. Windows-Kernel-Treiber folgen einer standardisierten Struktur:

• DriverEntry: Der Einstiegspunkt des Treibers, wird beim Laden aufgerufen
• IOCTL-Handler: Eine Dispatch-Funktion, die eingehende I/O-Control-Anfragen verarbeitet

IOCTLs (Input/Output Control Codes) sind die Schnittstelle zwischen Userland-Programmen und Kernel-Treibern. Ein Userland-Prozess kann über die DeviceIoControl-API mit einem Treiber kommunizieren und dabei verschiedene Control-Codes senden, um spezifische Operationen auszulösen. Für das Laden des Treibers und die anschließende Interaktion sind lokale Administratorrechte notwendig.

Eine gefährliche Funktion

Bei der Analyse des Truesight-Treibers mit Binary Ninja stößt man auf eine besonders interessante Funktion:

Diese Funktion ermöglicht das Beenden beliebiger Prozesse über die Funktion ZwTerminateProcess(). Eine hochprivilegierte Operation, die normalerweise selbst für administrative Accounts bei geschützten Prozessen (Protected Process Light; PPL) blockiert wird. Protected Process Light ist ein Windows-Schutzmechanismus, der sicherheitsrelevante Prozesse gegenüber Zugriffen absichert, selbst wenn diese mit hohen Rechten erfolgen. EDR-Produkte setzen PPL ein, um ihre Schutzkomponenten zuverlässig vor Deaktivierung durch Angreifer zu schützen.

Der Call-Graph zeigt, wie diese Funktion aufgerufen wird:

Das lange Switch-Statement ist charakteristisch für einen IOCTL-Handler. Jeder Case-Zweig behandelt einen spezifischen IOCTL-Code und führt die entsprechende Operation aus. Beim IOCTL 0x22e044 wird ein Wrapper aufgerufen, der die Process-Termination-Funktion für eine beliebige PID ausführt. Hierbei findet keine weitere Filterung oder Authentifizierung statt.

Der “Exploit”, überraschend simpel

Das Entscheidende ist: Dies ist kein klassischer Exploit, der eine Sicherheitslücke ausnutzt. Es ist eine Feature-Funktion des Treibers, die von den Entwicklern implementiert wurde. Der Angriff läuft folgendermaßen ab:

1. Angreifer lädt den signierten Legacy-Treiber in den Kernel
2. Öffnet ein Handle zum Treiber-Device
3. Sendet den IOCTL-Code 0x22e044 mit der Prozess-ID des Zielprozesses
4. Der Treiber führt die Operation mit Kernel-Privilegien aus
5. Der Zielprozess wird beendet, selbst wenn es sich um einen durch PPL geschützten Systemprozess handelt (z. B. wie bei EDR Prozessen)

Ein vereinfachter Pseudo-Code für einen solchen Angriff könnte so aussehen:

Keine Buffer-Overflows, keine komplexen Exploits, nur das legitime Nutzen einer existierenden Treiber-Funktion mit erhöhten Privilegien.

CVE-2013-3900 in der Praxis: Technische Details

CVE-2013-3900 ist eine Schwachstelle im Windows Authenticode-Verifizierungsprozess, die es ermöglicht, bestimmte Teile einer signierten PE-Datei zu verändern, ohne dass die digitale Signatur ungültig wird. Diese Bereiche sind nicht durch die kryptographische Signatur abgedeckt und können daher modifiziert werden.

Die technischen Grenzen: – Es können maximal etwa 10 Bytes verändert werden, was potenziell zu 2^80 verschiedenen Varianten führen kann – Die Änderungen beeinflussen den regulären Hash der Datei (MD5, SHA1, …) – Wichtig: Die Authenticode-Signatur und TBS-Hashes bleiben unverändert

Dies ermöglicht es Angreifern, die üblichen Erkennungssignaturen von Antivirenprogrammen und EDR-Lösungen zu umgehen, da diese auf den regulären Datei-Hashes basieren, und nicht auf Authenticode oder TBS-Hashes.

Demonstration am Truesight-Treiber

Schauen wir uns ein konkretes Beispiel an. Zunächst verifizieren wir den originalen Treiber:

Der Treiber ist korrekt signiert und wird vom System akzeptiert. Nun verändern wir gezielt ein einzelnes Byte und prüfen die modifizierte Version:

Die Signatur ist weiterhin gültig! Ein Vergleich auf Hex-Ebene zeigt die vorgenommene Änderung:

Wie ersichtlich, wurde lediglich ein einzelnes Byte geändert. Diese minimale Modifikation hat jedoch erhebliche Auswirkungen auf die Hash-Werte:

Die SHA256-Hashes unterscheiden sich vollständig, während die Authenticode-Signatur identisch bleibt. Dies ermöglicht es, bekannte Malware-Signaturen zu umgehen, die auf File-Hashes basieren, während der Treiber vom Betriebssystem weiterhin als legitim anerkannt wird. Genau diese beiden Versionen wurden über Virus Total analysiert wie im ersten Teil des Blog Posts zu sehen ist. Daraus geht direkt der Unterschied hinsichtlich der Erkennungsrate hervor.

Fazit

BYOVD-Angriffe demonstrieren ein fundamentales Problem in der Windows-Sicherheitsarchitektur: Die Kompatibilität mit Legacy-Treibern schafft ein persistentes Sicherheitsrisiko. Trotz Microsofts Bemühungen mit Blocklisten und verschärften Signaturanforderungen bleiben effektive Gegenmaßnahmen begrenzt.

Die Kombination aus: – Legacy-Treibern mit übermäßig privilegierten Funktionen – CVE-2013-3900 zur Umgehung Hash-basierter Erkennung – Unvollständigen und nicht flächendeckend aktivierten Blocklisten

macht diese Angriffsvektoren zu einer anhaltenden Bedrohung. Verteidiger sollten daher neben der Aktivierung und Aktualisierung von Blocklisten auch auf verhaltensbasierte Erkennungsmechanismen setzen, die das Laden unbekannter oder selten genutzter Kernel-Treiber überwachen.