Listed above shows what DriverView looks like.
But make sure to sort by hiding microsoft drivers, since you only want to target third-party installed ones (at this point in time)
The majority of our vulnerability discovery will come from generating random input and sending it to IOCTLs via kernel driver communication. This type of fuzzing will allow us to discover easy to reverse, and easy to exploit vulnerabilities in applications.
The first fuzzer I will utilize after downloading an application with drivers, is ioctlfuzzer1.3, this father allows you to mass discover and mass fuzz any IRP requests that are being sent throughout the io of the system. this Falls are usually allows for quick and easy vulnerability discovery, usually within 10 to 15 seconds of unleashing this fuzzer upon an applications kernel drivers.
This fuzzer allows you to configure which drivers and IOCTLs you want to focus on, an insert of a common configuration that can be used to discover driver can be seen below. When setting the configuration XML file, you need to specify and create a section for allowed drivers.
<!-- IOCTLs "allow" list. The fuzzer will process (i.e. log and/or fuzz) any IOCTL request containing at least one parameter from the <allow> list. If the list is empty, each IRP will be processed. --> <allow> <driver val="example.sys" /> <driver val="example.sys" /> <driver val="example.sys" /> <driver val="example.sys" /> <driver val="example.sys" /> </allow>
Once your fuzzing victim machine is attached to a host debugger, you can now unleash this fuzzer with any victim drivers you want to target.
Important the entire point of using this fuzzer is to mass fuzz an applications installed drivers, make sure you use and configure the config xml file.
IOCTLbf is a fairly lightweight and simple fuzzer, this mainly relies on the fact that you already have and know of a pre-existing IOCTL. This fuzzer will allow you to generate and send random input to any provided IOCTL.
Practical - demonstration time
Now that we know which fuzzers we can use to easily discover vulnerabilities in a driver, here’s a demonstration.
After obtaining a crash in a kernel driver, we now want to reverse-engineer the driver to fully grasp and understand why and how the vulnerability exists. We will be using Ida Pro for this section of 0 day discovery.
After you obtain a crash from fuzzing, you need to load the driver up in Ida Pro and navigate to wear that IOCTL is located, IOCTLs can commonly be found within the dispatch function of a kernel driver. You can use the listed below plugins to easily automate this process of locating IOCTLs within a kernel driver in Ida Pro.
Another IOCTL Discovery Ida Pro plugin is the driver buddy plug-in. This plug-in allows you to easily scan a driver for dispatch function, and any ICOTLs that may reside throughout the driver.
Practical - demonstration time
Now that we’ve discovered a crash in the previously noted driver, let’s load it up into Ida Pro and discover exactly why it crashed.
Developing a vulnerability disclosure policy is very important when getting into the field of security research, working with software vendors can be a tedious task, but it does have a good payoff. properly working with a software vendor can result in bug bounties, and or exposure from the vendor. The most important (and fun) part of vulnerability research is discovering the vulnerabilities, it can be a hobby, or a job.
My personal CVE designation and vulnerability disclosure policy can be found on my CVE collection page.