My HackSysExtremeVulnerableDriver exploits pack for education purposes developed under Windows 7 x86 SP1. The x86 version of this exploit does not bypass SMEP.
Although, in the x64 directory - some sample x64 exploits against HEVD are released that might need to employ SMEP bypasses.
One thing to note - the kernel payload that has been used is a single asm naked function, albeit it is from exploit to exploit being copied to dynamically allocated RWX buffers and then in an unelegant way patched to conform specific call stack needs (in one exploit leaving pop ebp
in other patching it out with nops
, in one leaving ret $8
while in other sticking to retn
). I know this is a mess, but I never bothered to make couple of naked functions with one or two epilogues varying for this issue.
Out of 12 vulnerabilities placed in HEVD, there are at the moment following exploits implemented:
x86:
- Stack Overflow
- Arbitrary Memory Overwrite
- NULL Pointer Dereference
- Integer Overflow
- Type Confusion
- Uninitialized Stack Variable
- Uninitialized Heap Variable
- Use After Free
- Pool Overflow
- Stack Overflow GS
- Double Fetch
x64:
- Stack Overflow
- Arbitrary Memory Overwrite via GDI SURFACE objects abuse
Found to be working stable.
HackSysExtremeVulnerableDriver
Local Privilege Escalation exploit's pack'
Mariusz Banach / mgeeky, '17
[+] Found hevd.sys driver's base: 0x90b36000
[+] Opened HackSysExtremeVulnerableDriver driver's handle.
[?] Kernel shellcode in user-memory at: 0x0040676f (size: 81 bytes).
--------------------------------
[01] Stack Overflow, IOCTL code: 0x00222003
[02] Arbitrary Memory Overwrite / Write-What-Where, IOCTL code: 0x0022200b
[03] Null Pointer Dereference, IOCTL code: 0x0022202b
[04] Integer Overflow, IOCTL code: 0x00222027
[05] Type Confusion, IOCTL code: 0x00222023
[06] Uninitialized Stack Variable, IOCTL code: 0x0022202f
[07] Uninitialized Heap Variable, IOCTL code: 0x00222033
[08] Use After Free, IOCTL code: 0x00222013
[09] Pool Corruption, IOCTL code: 0x0022200f
[10] Stack Overflow GS, IOCTL code: 0x0022007
[11] Double Fetch, IOCTL code: 0x00222037
[99] Exit.
[..] Select an exploit to launch against HEVD.SYS (or 99 to exit): 2
--------------------------------
[.] Loading ntkrnlpa.exe
[.] Determining HalDispatchTable symbol's offset...
[.] Custom kernel shellcode will now be located at: 0x0x3e0000
[.] Adjusting the kernel payload to make it ret 0x08
[.] Constructed custom payload capable of restoring overwritten pointer.
[.] Freeing memory allocated for the kernel payload.
[+] `hal!HalDispatchTable+4` is located at: 0x82966404
[+] Arbitrary Overwrite:
- Where: 0x82966404 (hal!HaliQuerySystemInformation)
- What: 0x3f0000 (address of shellcode in user space memory)
[+] Issuing IOCTL: HACKSYS_EVD_IOCTL_ARBITRARY_OVERWRITE
[.] Input buffer: 0x0x22fd7c, size: 8 bytes. Output: 0x0
[>] After sending IOCTL. ret: TRUE, last error: 0, written bytes: 0
[.] Invoking overwritten pointer by calling `NtQueryIntervalProfile`
[.] Exploit has been launched without errors.
[.] Exploit success check: Current user: (SYSTEM), expected: (SYSTEM)
[+] Succeeded. Enjoy your SYSTEM! :-)
--------------------------------
Microsoft Windows [Version 6.1.7601]
Copyright (c) 2009 Microsoft Corporation. All rights reserved.
C:\Users\IEUser\Desktop>
- Last exploit: Insecure Kernel Resource Access
- Refactor the code to be a bit more readable and C++ friendly (especially to use some of C++17 features)
s/system/CreateProcess
- move exploit files to a separate directory and modify
#include
s - Add
argv
parsing - Replace the shellcode to a more stable, dynamically resolved one using Kernel APIs to duplicate system token
- Add some x64 exploit variants for the already implemented ones (like Arbitrary Overwrite)
- Add SMEP bypass using ROP/or Page Tables manipulation
- Add some variations of the already implemented exploits using different vectors - like
SuspendApc
for Write-What-Where - Add custom command execution from within user input or
argv
- Stack Overflow GS exploit is causing parent process to deadlock because of locked driver's handle object upon
ZwTerminateProcess
. To overcome this issue, we'll have to zero-out that object:((nt!_HANDLE_TABLE_ENTRY*)((nt!_HANDLE_TABLE*)EPROCESS.ObjectTable.TableCode)[hDriver * 2]).Object = 0
This and other projects are outcome of sleepless nights and plenty of hard work. If you like what I do and appreciate that I always give back to the community, Consider buying me a coffee (or better a beer) just to say thank you! 💪
Mariusz Banach / mgeeky, 21
<mb [at] binary-offensive.com>
(https://github.com/mgeeky)