After speaking with some pals online about Windows 10’s policy requiring drivers to be digitally signed in order to load the lot of us began digging into tools that use signed drivers – you know… to see if there was any fun to be had with drivers that don’t validate UserMode addresses that are passed to the driver.
We all had discovered quite a few that had significant vulnerabilities and could be leveraged to take advantage of a WRITE_WHAT_WHERE vulnerability, the ability to scan physical memory blocks, and even read/write to MSR (Model-Specific Registers).
I decided to tinker with one of the drivers and the Windows API routine DeviceIoControl in an attempt to acquire the following two x86/64 MSR’s: IA32_MSR_LSTAR and IA32_MSR_CSTAR.
Below is a snippet out of the driver’s dead-listing that is accompanied by an IOCTL code allowing the user to take advantage of the intrinsic __readmsr.
There were many other IOCTL codes that allowed an attacker to read entire physical memory blocks, write to MSRs, pass through a payload for execution in kernel mode to potentially grab the EPROCESS structure of the System process and perform the classic token stealing to elevate the UserMode applications privileges.
Here’s a simple example of how one can read an MSR from this driver.
// Acquire device handle, get IOCTL codes, construct shellcode buffer, whatever else...
static constexpr uint64_t IA32_LSTAR_MSR = 0xC0000082;
auto Status = DeviceIoControl( DeviceHandle.get(),
IOCTL_READ_MSR,
&uiInBuffer,
sizeof( uiInBuffer ),
&uiOutBuffer,
sizeof( uiOutBuffer ),
&dwBytesReturned,
nullptr );
std::cout << "~~ IA32_MSR_CSTAR address acquired [" << uiOutBuffer << "]." << std::endl;
Thanks for reading. Comments, questions, feedback are always welcome.
