Wat is user mode en kernel mode?

Om te begrijpen waarom een BYOVD zo effectief is, en hoe het werkt, moeten we eerst kijken naar hoe Windows met rechten omgaat.

Binnen Windows wordt er gebruik gemaakt van zogenaamde protection rings. Dit zijn beveiligingsniveaus die bepalen wat code wel en niet mag doen op hardwareniveau. In theorie zijn er vier ringen, genummerd van 0 tot en met 3, waarbij ring 0 de meeste rechten heeft en ring 3 de minste. Ring 0 wordt hierin gebruikt voor kernel mode, en ring 3 voor user mode.

User mode (ring 3) is de wereld waarin alle programma's draaien voor dagelijks gebruik. Denk hierbij aan bijvoorbeeld de browser, Office, en delen van het antivirus. Programma's in user mode hebben beperkte rechten en kunnen dus niet zomaar bij het geheugen van andere processen, ze kunnen niet direct met hardware praten en niet het besturingssysteem aanpassen.

Kernel mode (ring 0) is het hart van het besturingssysteem. Hier draait Windows zelf, samen met drivers die het besturingssysteem nodig heeft om met hardware en andere systeemcomponenten te communiceren. Code in kernel mode heeft geen beperkingen. Het kan bij al het geheugen, alle processen, alle hardware en alle bestanden.

De scheiding tussen deze ringen is bewust ontworpen, om te voorkomen dat elk programma zomaar in de kernel kan. Door user mode en kernel mode strikt van elkaar te scheiden zorgt Windows ervoor dat een fout in een normaal programma niet het hele systeem laat crashen. Crasht de browser? Vervelend, maar het systeem blijft gewoon doordraaien. Als er iets in de kernel crasht, verschijnt de welbekende Blue Screen of Death.

Drivers: de brug tussen user mode en kernel mode

Niet alle software kan zijn werk doen vanuit user mode. Een grafische kaart aansturen, communiceren met een netwerkkaart of een USB-apparaat herkennen: dit soort taken vereist directe toegang tot hardware, en dit kan enkel vanuit de kernel.

Om dit probleem op te lossen bestaan drivers. Een driver is in feite een stuk software dat in kernel mode draait en werkt als een soort brug tussen het besturingssysteem en de hardware. Wanneer je bijvoorbeeld een document wilt printen, vraagt Windows niet rechtstreeks aan de printer wat er moet gebeuren. Dat verzoek gaat via de printerdriver, die in de kernel draait en daadwerkelijk met de printer kan communiceren.

Om vanuit user mode te communiceren met een driver wordt er gebruik gemaakt van een mechanisme dat IOCTL heet (Input Output Control). Een IOCTL is in feite een soort opdrachtcode die een opdracht naar een driver kan sturen. De driver ontvangt het verzoek, en voert de bijbehorende functie uit in de kernel.

Tussen het programma in user mode en de driver in kernel mode zit nog een tussenlaag: de I/O Manager. De I/O Manager is een onderdeel van Windows dat alle communicatie met drivers regelt. Wanneer een programma een opdracht naar een driver stuurt, gaat dat verzoek niet rechtstreeks. Het programma roept eerst een functie aan in de Windows API, die vervolgens de I/O Manager activeert.

Vervolgens pakt de I/O Manager het verzoek op en verpakt dit in een IRP (Input Output Request Packet), en stuurt deze naar de juiste driver. In de IRP zit alles wat de driver nodig heeft om de opdracht correct uit te voeren, waaronder de IOCTL-code en andere gegevens. De driver leest de IRP, kijkt naar de opdracht en voert deze uit.

Driver signing en DSE uitgelegd

Een driver heeft dus volledige toegang tot de kernel. Het zou een enorm risico zijn als iedereen zomaar een driver kon schrijven en laden op een Windows-systeem. Om deze reden heeft Microsoft een mechanisme ingebouwd dat bepaalt welke drivers wel en niet geladen mogen worden.

Dit mechanisme heet driver signing. Voordat een driver op een Windows-systeem mag draaien, moet hij voorzien zijn van een digitale handtekening van een vertrouwde leverancier. Deze handtekening bewijst dat de driver afkomstig is van een betrouwbare partij en dat de code sinds het ondertekenen niet is aangepast.

Het uiteindelijke mechanisme dat deze check afdwingt heet DSE (Driver Signature Enforcement). DSE controleert bij het laden van elke driver of de handtekening geldig is. Als de handtekening niet klopt of ontbreekt, weigert Windows de driver te laden.

Echter zit er een fundamentele zwakte in dit model. Een handtekening zegt iets over wie de driver heeft gemaakt, maar niet of deze goed is geschreven. De leverancier kan een driver publiceren die een serieuze kwetsbaarheid bevat. Windows controleert enkel of de handtekening klopt, niet of de driver veilige code bevat.

Dit is precies de opening waar BYOVD-aanvallen gebruik van maken.

Hoe legitieme drivers misbruikt kunnen worden

Om het concreet te maken, pakken we er een echt voorbeeld bij: een driver die wij bij Cyber Cloud zelf ook regelmatig in de praktijk gebruiken tijdens onze pentesten.

De driver in kwestie is wsftpmr.sys, onderdeel van Topaz Antifraud — software die door Braziliaanse en Spaanse banken gebruikt wordt om bankfraude tegen te gaan. In 2023 ontdekte Northwave een kwetsbaarheid (CVE-2023-52271) in deze driver. De driver is netjes ondertekend door Microsoft en heeft daardoor geen last van DSE.

De kwetsbaarheid zit in hoe de driver omgaat met verzoeken vanuit user mode. Een goed geschreven driver controleert bij elk verzoek of de aanvrager wel de juiste rechten heeft. Deze driver doet dat niet. De driver maakt een device aan dat door elke gebruiker op het systeem benaderd kan worden: \\.\Warsaw_PM. Vervolgens accepteert de driver een IOCTL met code 0x22201C die het mogelijk maakt om willekeurige kernelfuncties aan te roepen, waaronder ZwTerminateProcess. Het gevolg is dat elke gebruiker op het systeem via de driver processen kan stoppen die normaal beschermd zijn — zelfs Protected Process Light (PPL) processen, zoals Microsoft Defender.

Figuur 3 – Exploitketen voor wsftpmr.sys: van user mode naar kernel process termination

Voor ons als pentesters bij Cyber Cloud betekent dit dat we de driver simpelweg kunnen inladen op een systeem. Vervolgens is het mogelijk om de kwetsbaarheid in de driver te misbruiken om dingen te doen vanuit user mode die normaal niet mogelijk zouden zijn — zoals het uitschakelen van antivirussoftware.

Figuur 4 – Links: IOCTL 0x22201C verstuurd om Microsoft Defender (PID 21960) te stoppen. Rechts: de Threat service is gestopt.

Het uitschakelen van beveiligingssoftware is overigens niet de enige toepassing van BYOVD. Er bestaan ook kwetsbare drivers met zogenaamde write primitives, die het mogelijk maken om willekeurig in het kernelgeheugen te schrijven. Daarmee kan een aanvaller bijvoorbeeld DSE uitschakelen om vervolgens zelf willekeurige, niet-ondertekende drivers in te laden. Iedere kwetsbare driver biedt zijn eigen mogelijkheden, en aanvallers kiezen de driver die past bij wat ze willen bereiken.

Hoe bescherm je je organisatie?

Verdedigen tegen BYOVD is fundamenteel lastig, omdat de aanval misbruik maakt van de legitieme functionaliteit van Windows zelf. Er is geen enkele maatregel die het probleem volledig oplost, maar door verschillende lagen te combineren wordt het voor een aanvaller een stuk lastiger.

• • Beperk lokale beheerdersrechten op werkstations en servers — een kwetsbare driver kan alleen ingeladen worden met adminrechten.
• • Voer regelmatig pentesten uit om te ontdekken waar privilege escalation binnen de omgeving mogelijk is.
• • Activeer Microsoft's Vulnerable Driver Blocklist, al is die niet volledig en wordt slechts een aantal keer per jaar bijgewerkt.
• • Detecteer op service creation events met een EDR, of zelf via tools zoals Sysmon en Windows Event Forwarding gekoppeld aan een SIEM.

Onze klanten