![]() When the following code in user mode is executed, the driver will receive an IRP with the major function code IRP_MJ_CREATE and will execute the M圜reateCloseFunction function: hDevice = CreateFile(L"\\\\.\\MyDevice", GENERIC_WRITE|GENERIC_READ, 0, NULL, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, NULL) IRP_MJ_DEVICE_CONTROL → DeviceIoControlĭefinitions in DriverEntry may look like this: DriverObject->MajorFunction = M圜reateCloseFunction DriverObject->MajorFunction = M圜reateCloseFunction DriverObject->MajorFunction = MyDeviceControlFunction.These correlate with user mode functions: There are many major function codes but the most common ones are IRP_MJ_CREATE, IRP_MJ_CLOSE, and IRP_MJ_DEVICE_CONTROL. These packets allow the driver to act on the specific major function by providing the relevant information required by the function. Interrupt Request Packets (IRPs) are essentially just an instruction for the driver. The last thing that DriverEntry does is defines the functions for IRP handlers. Next, DriverEntry uses IoCreateSymbolicLink() with the previously created device object to set up a symbolic link which will allow for user mode processes to communicate with the driver. Much like the main() function that you may be familiar with in C/C++ programming, a driver must specify an entry point, DriverEntry.ĭriverEntry has many responsibilities, such as creating the device object and symbolic link used for communication with the driver and definitions of key functions (IRP handlers, unload functions, callback routines, etc.).ĭriverEntry first creates the device object with a call to IoCreateDevice() or IoCreateDeviceSecure(), the latter typically being used to apply a security descriptor to the device object in order to restrict access to only local administrators and NT AUTHORITY\SYSTEM. There are 3 important concepts that you must first understand before we start reversing - DriverEntry, IRP handlers, and IOCTLs. Kernel mode software drivers seem far more complex than they truly are if you haven’t developed one before. I tend to exclude drivers published by Microsoft only because I usually don’t have the time required to really dig in. That being said, I will typically look at drivers published by security vendors, anything published by the motherboard manufacturer, and performance monitoring software. Target selection is a mixed bag because there isn’t one specific type of driver that is more vulnerable than others. To do this, I will either manually review drivers in the registry ( HKLM\System\ControlSet\Services\ where Type is 0x1 and ImagePath contains *.sys)or use tooling like DriverQuery to run through C2. This also has the added bonus of not requiring a new driver to be dropped and loaded which could tip off defenders. If a bug is found in these core drivers, most of the fleet will be affected. The first thing I typically look for on an engagement is what drivers are loaded on the base workstation and server images. I will include links along the way to additional resources, but a full post on driver development and internals would be far too long and not immediately relevant. Note: This will include gross oversimplifications of complex topics. In this post, I’ll first cover the most important pieces of prerequisite knowledge required to understand how drivers work and then we’ll jump into the disassembler to walk through finding the potentially vulnerable internal functions. To aid in the research of these vulnerabilities, I felt it was important to demonstrate the kernel bug hunting methodology I have employed in my research to find interesting and abusable functionality. ![]() Exploiting drivers offers interesting new perspectives not available to us in user mode, both through traditional exploit primitives and abusing legitimate driver functionalities.Īs Windows security continues to evolve, exploits in kernel mode drivers will become more important to our offensive tradecraft. Popular and well-documented examples of these vulnerabilities are the CAPCOM.sys arbitrary function execution, Win32k.sys local privilege escalation, and the EternalBlue pool corruption. Methodology for Static Reverse Engineering of Windows Kernel Drivers IntroductionĪttacks against Windows kernel mode software drivers, especially those published by third parties, have been popular with many threat groups for a number of years.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |