![[H]ard|Forum](/styles/hardforum/xenforo/logo_dark.png){kind=logo}
erek
[H]F Junkie
- Joined
- Dec 19, 2005
- Messages
- 10,894
"The WHQL process does not certify that the driver in question is bug-free: as Eclypsium has documented, the plethora of unpatched signed drivers out there is jaw-dropping. On the bright side, HVCI and VBS stop all these kind of attacks as they will detect any tampering at the register level like, for instance, mangling the CR4 control register . And from the latest Windows 10 20H1, VMWare started offering Virtualization Based Security support: we can then predict that the attack surface will soon become slimmer due the fact that VBS will stop any attempt of disabling SMEP by detecting any real-time changes to the 20th CR4 bit.
Preamble - Why are drivers still a valuable target?
Kernels are, no euphemism intended, complex piece of software and the Windows OS is no exception. Being one of the toughest to scrutinize due to its lack of source code and undocumented APIs, it is now being more documented thanks to the immense effort from the research community. Regrettably, during recent times, it has also increased in complexity and its mitigation way improved. So why attacking drivers? Besides the ones shipped by Microsoft, third-party drivers are the only and more accessible means for third parties to get code execution into ring 0. Starting from Windows 1607 Anniversary Update, only signed drivers through WHQL certification process are now allowed to be loaded and, as a consequence of that, crafting and shipping your own bug door is not possibile straightforward anymore. More information on the whole driver signing process can be found here.
In this post I would like to cover the “low-hanging fruits”; those hidden and still undiscovered vulnerabilities in signed and trusted production drivers which are, too often than not, widely deployed on consumers and enterprise endpoints.
An exploitable kernel driver vulnerability can lead an unprivileged user to SYSTEM, just because the vulnerable driver is locally available to anyone. (Well, sometimes the vulnerable driver or kernel component can be owned even remotely - EternalBlue anyone?
My goal here is to illustrate a general approach on performing the initial bug analysis through IDA and WinDbg, run a simple fuzzing test and then construct the exploit bottom-up.
The exploit I build is based on this vulnerability discovered by Lucas Dominikow from CoreSecurity which impacts the MSI Ambient Link driver. Even though I managed to build a reliable, yet no so elegant, exploit for Windows 7 SP1, our focus we’ll be on Windows 10 only.
These are the two Windows 10 builds I have tested, for both 1709 and 2004 version"
https://github.com/uf0o/CVE-2020-17382
Preamble - Why are drivers still a valuable target?
Kernels are, no euphemism intended, complex piece of software and the Windows OS is no exception. Being one of the toughest to scrutinize due to its lack of source code and undocumented APIs, it is now being more documented thanks to the immense effort from the research community. Regrettably, during recent times, it has also increased in complexity and its mitigation way improved. So why attacking drivers? Besides the ones shipped by Microsoft, third-party drivers are the only and more accessible means for third parties to get code execution into ring 0. Starting from Windows 1607 Anniversary Update, only signed drivers through WHQL certification process are now allowed to be loaded and, as a consequence of that, crafting and shipping your own bug door is not possibile straightforward anymore. More information on the whole driver signing process can be found here.
In this post I would like to cover the “low-hanging fruits”; those hidden and still undiscovered vulnerabilities in signed and trusted production drivers which are, too often than not, widely deployed on consumers and enterprise endpoints.
An exploitable kernel driver vulnerability can lead an unprivileged user to SYSTEM, just because the vulnerable driver is locally available to anyone. (Well, sometimes the vulnerable driver or kernel component can be owned even remotely - EternalBlue anyone?
My goal here is to illustrate a general approach on performing the initial bug analysis through IDA and WinDbg, run a simple fuzzing test and then construct the exploit bottom-up.
The exploit I build is based on this vulnerability discovered by Lucas Dominikow from CoreSecurity which impacts the MSI Ambient Link driver. Even though I managed to build a reliable, yet no so elegant, exploit for Windows 7 SP1, our focus we’ll be on Windows 10 only.
These are the two Windows 10 builds I have tested, for both 1709 and 2004 version"
https://github.com/uf0o/CVE-2020-17382