Breaking boundaries investigating vulnerable drivers and mitigating risks

### Overview In this talk, researcher Jan Vojtěšek from Check Point Research explores the landscape of vulnerable Windows kernel drivers, shifting the research focus from isolated logic bugs to what genuinely constitutes a security boundary violation: enabling non-privileged users to escalate privileges to system level. As Microsoft continues to harden the kernel boundary from user mode, attackers increasingly rely on driver exploitation to execute rootkits, deploy minifilters, escalate privileges, and bypass Driver Signature Enforcement. While repositories like LOLDrivers aggregate known vulnerable drivers for defenders, they also present an attack surface for threat actors.

### Key Topics - **Defining Vulnerable Boundaries**: A bug in a driver is only a practical vulnerability if it crosses a security boundary. Many previously discovered drivers using physical memory mapping required administrative privileges to interact with, meaning they did not cross a true security boundary. The primary target for exploitation is non-privileged user-to-system access. - **Analysis of LOLDrivers**: Evaluating 224 known vulnerable 64-bit signed drivers from the LOLDrivers project revealed that approximately 90% were directly accessible to non-privileged users due to permissive Discretionary Access Control Lists (DACLs). - **Common Driver Design Flaws**: Non-privileged access stems from three recurring patterns: 1. Creating a device via `IoCreateDevice`, which does not accept a custom DACL and defaults to open permissions. 2. Calling `IoCreateDeviceSecure` with weak, overly permissive SDDL strings. 3. Calling `IoCreateDeviceSecure` with a strong DACL but omitting the `FILE_DEVICE_SECURE_OPEN` flag in device characteristics, allowing non-privileged callers to access the device via its namespace. - **Mass Hunting Methodology**: Check Point Research constructed Yara rules targeting 64-bit signed drivers with missing or weak DACLs, combined with high-risk kernel primitives (e.g., `ZwOpenProcess`, `ZwOpenThread`, `ZwOpenProcessToken`). Running this across VirusTotal Retrohunt for a one-year window (June 2023–June 2024) initially flagged ~22,500 drivers. Signature filtering with tools like `SignTool` and `SignCheck`, deduplication via import hashes (`imphash`) and PE version metadata, and removal of INF-configured DACLs reduced this set to nearly 2,000 at-risk drivers.

### Technical Details To demonstrate the methodology, Vojtěšek highlighted a newly discovered vulnerability in an anti-rootkit component used by Doctor Web products (Dr.Web Security Space, Katana, and CureIt), tracked with a high-severity score (8.8) under a BDU identifier. The signed kernel driver (`DWShield`) used `IoCreateDevice` without an access list, leaving it accessible to unprivileged users, but implemented custom application-level protections that the researchers systematically bypassed: - **Autogenerated Device and Symbolic Link Names**: The 16-character hexadecimal symbolic link was brute-forced via the `QueryDosDeviceA` API. - **Digital Signature Checks on Calling Processes**: Standard code injection was blocked, but Katana and CureIt were vulnerable to DLL sideloading. To compromise Dr.Web Security Space, researchers bypassed a proprietary filter driver (`Spider G3E`) that enforces a module cache. By sideloading a valid Microsoft-signed DLL from a custom location and replacing it via an NTFS file move operation rather than a copy, the metadata-only change bypassed cache change detection, allowing local privilege escalation, arbitrary kernel read/write, and arbitrary process termination.

### Takeaways & Mitigation Developers must secure drivers at creation time by avoiding `IoCreateDevice` for sensitive functionality, applying strict DACLs using `IoCreateDeviceSecure` (or registry/INF settings), and always setting `FILE_DEVICE_SECURE_OPEN`. Relying on custom application checks (signature checks, IOCTL obfuscation, auto-generated names) consistently proves fragile. Furthermore, current ecosystem remediations—such as the Microsoft Vulnerable Driver Blocklist—suffer from slow updates (1–2 times per year) and limited coverage (~half of LOLDrivers), while Windows continues to load drivers signed by expired or revoked certificates due to boot-time CRL verification constraints. Consequently, threat actors will continue leveraging Bring Your Own Vulnerable Driver (BYOVD) workflows unless structural defenses evolve.