Stack Overflow in HEVD

So lately, I have been diving into Windows Kernel Exploitation with the goal of attending Offensive Security’s Advanced Windows Exploitation course. All this is a journey that’s for sure! Anyways, this is the first exploit I did on drivers usingΒ HackSysTeam’s Extreme Vulnerable Driver. I will be writing these PoC’s in CPP to get used to it as Python will not always be installed on each computer I run into on assessments. So in the event I do find a vulnerability like this out in the upside down, I can use my exe and get privs rather than hoping python would be installed.

What you’ll need:

  1. Compiler or IDE (I personally use Visual Studio 2017. It’s pretty great! Or you know, use Python or whatever)
  2. Compiled driver
  3. OSR LoaderΒ (I uploaded the actual zip file as you had to register and all that good stuff to even download it)
  4. Disassembler (I’m using Ida)
  5. Pain

My environment:

  1. Windows 7 Enterprise 32 bit
  2. Visual Studio 2017
  3. Ida
  4. WinDBG

IOCTL, What the Hell?!

So what the heck is an IOCTL and what’s it even stand for??

IOCTL stands for Input and Output Controls. These IOCTL’s allow for user land to interact with kernel land using specific codes. In this case, it is “0x222003”. You can see it being used in the second block in the picture below. Through this code, we can interact with the function that this IOCTL is responsible for. In this case, it’ll trigger the stack overflow function.

One key difference between exploiting drivers from software is what happens when you tickle it and it finally moves. With software, it crashes and you can easily restart the service. Drivers on the other hand immediately locks up, turns blue, and restarts. Restart as in the computer gets rebooted….which means your machine will be rebooted multiple times just like how you have to restart the software each time you crash it.

One other key difference is drivers run in Ring 0. What’s that mean for you? Privilege escalation baby πŸ˜‰

With WinDBG connected and the driver loaded into Ida, let’s take a look at what we have…

Peeping in the Window

Let’s take a look at what “IrpDeviceIoCtlHandler()” has in store for us today. As you can see in the picture below, there are several IOCTL’s we can use and you guessed it! Each IOCTL does a different vulnerable function. I will be focusing on the simple Stack Overflow vulnerability this driver has to offer.

Let’s follow the Yellow Brick Road and see what this has to offer us!

As a side note, I am following the path based on the overview!

What exactly are we looking at? Let’s break it down…

In our first block, we run into our first IOCTL of “0x22201f.” This IOCTL gets moved into EAX and then compared to our IOCTL. If our IOCTL is higher than 0x22201f, our path will be headed right; otherwise, our path will head to the left.

In our next block, our IOCTL gets moved into EAX and then gets subtracted by 0x222003. If the value is 0, we move onto our next block; otherwise, our path continues going left.

Lastly, values get pushed onto the stack to get fed into the “StackOverflowIoctlHandler” function.

Once that is done, the IRP request gets prepared and gets sent to call on “TriggerStackOverflow” to trigger the function with our user data. After that function gets called, our last stop ends with our IRP request being dunzkis.

Take a look at the TriggerStackOverflow function, specifically this part:

At line 5, it is moving 800 bytes into ESI as a parameter for memset. What this means for us is if we do more than 800 bytes, we should hopefully see our BSOD and begin taking advantage of this amazingness! Now that we have what we need to start breaking shit, let’s start creating our exploit…

Constructing the Exploit

To begin exploiting this IOCTL, we first need to grab a handle to the driver so we can send the IOCTL code. We can accomplish this by using the CreateFile function.

In order to talk to the upside down, we need to send the request with the IOCTL code we found when analyzing the IOCTL Handler function. We do that by feeding several variables into DeviceIoControl.

Filling up our Blue_Screen is as easy as using the memset function:

To put these two things together, we should now have a PoC to cause a crash and blue screen our Windows VM. You can find it below. It’s pretty ugly for the meantime, but it works!

When ran, you can see our beautiful BSoD! Lovely, isn’t she?? Look how adorable she is <3

Now that we are set, I attach the debugger and run it again. Unfortunately, I did not get any registers to be overwritten. I started playing with buffer size and got some overwritten registers when I adjusted it to a size of 0x850 bytes. When ran, you can see that both EIP and EBP were overwritten with our lovely “A’s” πŸ™‚

Just like any other exploit, we have to find where EIP gets overwritten. We can easily find it by replacing the “Blue_Screen” variable with our new “pCreate” variable made with pattern create.

Well look at that. So if we send 4 “B’s” after 2080 “A’s”…we overwrite EIP πŸ™‚

EBP will also get overwritten after sending 2076 “A’s” also!

Awesome πŸ™‚

So the shellcode itself is a beast of it’s own. This will be continued here shortly as you are in for a treat! Goodbye, MSFvenom πŸ˜‰

Leave a Reply

Your email address will not be published. Required fields are marked *