{"id":294,"date":"2022-10-30T19:34:19","date_gmt":"2022-10-30T18:34:19","guid":{"rendered":"https:\/\/areyou1or0.it\/?p=294"},"modified":"2022-10-30T19:49:39","modified_gmt":"2022-10-30T18:49:39","slug":"hevd-windows-kernel-exploitation-5-uninitialized-stack-variable","status":"publish","type":"post","link":"https:\/\/areyou1or0.it\/index.php\/2022\/10\/30\/hevd-windows-kernel-exploitation-5-uninitialized-stack-variable\/","title":{"rendered":"HEVD Windows Kernel Exploitation 5: Uninitialized Stack Variable"},"content":{"rendered":"\n
Before I start talking about the 4th vulnerability on HEVD (Uninitialized Stack Variable), I’ll give a summary of what we’ve learned so far:<\/p>\n\n\n\n
With Stack Overfow: put your shellcode in userland in an allocated memory and execute in kernelland<\/li>
With Arbitraty Overwrite: writing the value pointed by what to the memory location referenced by where<\/li>
With Null Pointer Dereference: writing to a pointer location where the value of the pointer is NULL and used by an application that points to a valid memory location<\/li>
With Unitialized Stack Variable, we will control the data on the kernel stack<\/strong> from user mode<\/strong> using an uninitialized stack variable<\/li><\/ul>\n\n\n\n
Source Code Review<\/h2>\n\n\n\n
As always we’ll check the C code first to understand where the vulnerability lies:<\/p>\n\n\n\n
The structure of the code is the same, defines some variables and datatypes, shows the vulnerable vs secure code and triggers the vulnerability, then defines IOCTL code. <\/p>\n\n\n\n
The author mentions in the source code that in the secure version, UninitializedMemory variable is initialized to a value. However in the vulnerable version, it’s not initialized and later called in the the callback() function, which leads to this vulnerability.<\/p>\n\n\n\n
<\/figure>\n\n\n\n
Finding the IOCTL Code:<\/h2>\n\n\n\n
Got to Functions, select IrpDevideIOCTLHandler, in the text view scroll down until you see the call for UninitializedStackVariableIoctlHandler<\/p>\n\n\n\n
<\/figure>\n\n\n\n
We’ll follow the arrows for the function loc_15171A above and will see the following jmp statement.<\/p>\n\n\n\n
We’ll add 4 bytes to find the ICOTL to 0x22202B which will give us 0x22202F<\/p>\n\n\n\n
<\/figure>\n\n\n\n
In order to see our affect in actions, we’ll put a breakpoint in windbg with !HEVD+0x571A for the function loc_15171A (1 in the address = a base address of 0x00010000 so we can remove it in the breakpoint)<\/p>\n\n\n\n
Initial Exploit:<\/h2>\n\n\n\n
We’ll create the initial exploit with the IOCTL code to verify the vulnerability. My code is pretty same as the last times so shouldn’t be a shocker:<\/p>\n\n\n\n
import struct, sys, ctypes from ctypes import * from subprocess import *
On windbg, write the following commands<\/p>\n\n\n\n
!sym noisy<\/li><\/ul>\n\n\n\n
.reload<\/li>
lm m H*<\/li>
bp !HEVD+0x571A<\/li>
g<\/li><\/ul>\n\n\n\n
when we run the code, we hit the breakpoint which verifies the IOCTL code:<\/p>\n\n\n\n<\/figure>\n\n\n\n
Let’s change the value for the buffer variable and check windbg again:<\/p>\n\n\n\n
Source Code Analysis on IDA:<\/h2>\n\n\n\n
Let’s see in IDA again what does this function do:<\/p>\n\n\n\n
If you follow the IOCTL handler for this function, <\/p>\n\n\n\n
we see our user buffer put in ecx following a test ecx, ecx<\/strong> statement. <\/li>
If we fail jz statement, we’ll follow the red lines meaning we’ll trigger the vulnerability<\/li><\/ul>\n\n\n\n<\/figure>\n\n\n\n
If you double click on TriggerUninitializedStackVariable, we’ll see what’s going on in the Graph view:<\/p>\n\n\n\n
We have a call to ProbeForRead and then <\/li>
we load the value 0xBAD0B0B0 into eax<\/li>
cmp esi (or our user provided buffer) and the arbitrary static value<\/li><\/ul>\n\n\n\n
We see that here we\u2019re loading a value of 0xBAD0B0B0 into eax and then executing a cmp between that value and esi. This is probably a compare between our user provided buffer and 0xBAD0B0B0 . <\/p>\n\n\n\n<\/figure>\n\n\n\n
If our user provided buffer value is the magic value (0xBAD0B0B0), we fail the jnz statement (as the value is 0), we’ll go with red (the short path) and execute the followings:<\/p>\n\n\n\n
we put eax into stack (eax was 0xBAD0B0B0 as we ended up here after the cmp esi,eax –> jnz statement)<\/li>
offset to the UninitializedStackVariableObjectCallback entity into stack<\/li><\/ul>\n\n\n\n
If you right click on UninitializedStackVariableObjectCallback , the hex value is 86670 which is the address of the callback function<\/p>\n\n\n\n
In summary, when we take this path, we put 2 initialized variable values onto stack<\/p>\n\n\n\n<\/figure>\n\n\n\n
If we take the second path, we’ll eventually do the followings:<\/p>\n\n\n\n
cmp [ebp+UninitializedStackVariable.Callback], edi <\/p>\n\n\n\n
As long as the function pointer is not initialized to NULL & we don’t provide the magic value as our user value, we’ll end up with the red flag to call [ebp+var_108]<\/p>\n\n\n\n<\/figure>\n\n\n\n
If we right click on the value, it shows 108 in hex. So we will call whatever is located at ‘ebp-108’. The purpose here is get a pointer to shellcode at the address ‘ebp-108’. <\/p>\n\n\n\n
Finding Offset:<\/h2>\n\n\n\n
On windbg, write the following commands once again:<\/p>\n\n\n\n
!sym noisy<\/li><\/ul>\n\n\n\n
.reload<\/li>
lm m H*<\/li>
bp !HEVD+0x571A<\/li>
g<\/li>
dps esp<\/li><\/ul>\n\n\n\n
trigger the vulnerability again and run the following command in windbg:<\/p>\n\n\n\n
kd> !thread<\/p>\n\n\n\n
See that Kernel Stack Init is 0x82b7ded0 and &UninitializedStackVariable.Callback <\/p>\n\n\n\n
this will give us the offset 00000504 which means when we put our data at an offset of 0x504 from Stack Init, we can hijack the Instruction Pointer.<\/p>\n\n\n\n
Kernel Stack Spraying:<\/h2>\n\n\n\n
We can do this using the API call NtMapUserPhyiscalPages to spray a pointer value onto the stack repeatedly. You can find the API documentation here: <\/p>\n\n\n\n
![\"\"](\"https:\/\/areyou1or0.it\/wp-content\/uploads\/2022\/10\/image-5-1024x490.png\")
<\/figure>\n\n\n\n![\"\"](\"https:\/\/areyou1or0.it\/wp-content\/uploads\/2022\/10\/image-3-1024x236.png\")
<\/figure>\n\n\n\n![\"\"](\"https:\/\/areyou1or0.it\/wp-content\/uploads\/2022\/10\/image-1024x267.png\")
<\/figure>\n\n\n\n![\"\"](\"https:\/\/areyou1or0.it\/wp-content\/uploads\/2022\/10\/image-6.png\")
<\/figure>\n\n\n\n![\"\"](\"https:\/\/areyou1or0.it\/wp-content\/uploads\/2022\/10\/image-10.png\")
<\/figure>\n\n\n\n![\"\"](\"https:\/\/areyou1or0.it\/wp-content\/uploads\/2022\/10\/image-8-1024x749.png\")
<\/figure>\n\n\n\n![\"\"](\"https:\/\/areyou1or0.it\/wp-content\/uploads\/2022\/10\/image-1-1024x162.png\")
<\/figure>\n\n\n\n![\"\"](\"https:\/\/areyou1or0.it\/wp-content\/uploads\/2022\/10\/image-7-1024x519.png\")
<\/figure>\n\n\n\n![\"\"](\"https:\/\/areyou1or0.it\/wp-content\/uploads\/2022\/10\/image-2.png\")
<\/figure>\n\n\n\n![\"\"](\"https:\/\/areyou1or0.it\/wp-content\/uploads\/2022\/10\/image-9-1024x95.png\")
<\/figure>\n\n\n\n![\"\"](\"https:\/\/areyou1or0.it\/wp-content\/uploads\/2022\/10\/Screenshot-2022-10-30-at-19.36.24-1-1024x745.png\")
<\/figure>\n\n\n\n![\"\"](\"https:\/\/areyou1or0.it\/wp-content\/uploads\/2022\/10\/image-4.png\")
<\/figure>\n","protected":false},"excerpt":{"rendered":"