0x00 漏洞背景
2019年09月07日rapid7在其metasploit-framework仓库公开发布了CVE-2019-0708的利用模块，漏洞利用工具已经开始扩散，已经构成了蠕虫级的攻击威胁。这里对该漏洞利用的原理做一个技术分析。
0x01 利用分析
漏洞原理部分就不再赘述了，简单来说就是由于UAF漏洞IcaChannelInputInternal->IcaFindChannel会返回一个指向的内容已经被释放了的指针，随后有一处间接调用，通过喷射占位让这里的rax寄存器指向我们的shellcode就可以RCE。
在windows 7上，非分页内存的起始地址是固定的。在虚拟机中可能由于环境不同导致该地址不同，由于EXP中硬编码了这个地址，所以可能导致漏洞利用失败。可以按照下面的方法自己修改这个硬编码的地址。
如果是virtualbox虚拟机，先使用下面的命令dump虚拟机的内存：
然后下载安装google的内存取证工具rekall(https://github.com/google/rekall/releases/download/1.7.2rc1/Rekall_1.7.2.p1_Hurricane.Ridge_x64.exe)，扫描得到的memdump文件得到非分页内存的起始地址：
如果是vmware虚拟机创建一个快照使用同样的命令扫描得到的快照文件即可。如果你是按照默认步骤创建的，那么非分页内存的起始地址应该和这里一样都是0xfffffa8001802000。windows 7虚拟机的默认内存是2GB，这个值比真实机器的内存小，所以把GROOMSIZE从250 MB修改为50MB。此时，应该可以直接使用该EXP在虚拟机上实现稳定的RCE了。
EXP编写主要的两个问题就是如何喷射占位和如何编写shellcode。下面我们来看代码。
回顾一下RDP协议的流程，client收到这个PAKID_CORE_CLIENTID_CONFIRM之后应该发送client device list announce request包，发送这个包之后执行exploit代码。
非分页内存的起始地址是0xfffffa8001802000，我们希望call [rax]时rax的值是0xfffffa8004a02048，0xfffffa8004a02048中的值是0xfffffa8004a02058，0xfffffa8004a02050处开始payload。因为payload以查找其的标志USERMODE_EGG/KERNELMODE_EGG开始(egg hunting)，所以将0xfffffa8004a02048中的值设置为0xfffffa8004a02058刚好可以从payload真正的功能处开始。
payload分为kernel mode payload和user mode payload，kernel mode payload由两个部分组成：KERNELMODE_EGG和(kernel mode 的)payload；user mode payload由四个部分组成：USERMODE_EGG,egg_loop,USERMODE_EGG和(user mode 的)payload。egg_loop用来查找KERNELMODE_EGG并跳转到(kernel mode 的)payload；(user mode 的)payload才是真正在用户态运行的反弹shell的payload(egg_loop其实也是在内核态运行的)。
准备好payload之后伪造UAF的结构体，在IcaChannelInputInternal中的ExAllocatePoolWithTag中可以看到，实际分配的内存会比发送的数据多0x38个字节。
考虑进去这0x38个字节，又因为间接调用的偏移是0x100个字节，所以需要在第0xC8个字节放上0xfffffa8004a02048。
做好这些准备工作之后就可以开始pool spray了。首先发送大量大小为0x128的spray_channel包(分配0x128+0x38=0x160字节大小的内存)，再发送触发漏洞的包释放MS_T120 channel，由于其大小也是0x160字节，所以此时再发送大量和前面相同的spray_channel包就会占据被释放的MS_T120 channel的内存。
之后发送大量含有kernel mode payload或者user mode payload的包占据从0xfffffa8001802000开始到0xfffffa8004a02000的非分页内存，因为header的大小是0x48，所以最终0xfffffa8004a02048中的值是0xfffffa8004a02058，后面可能是kernel mode payload或者user mode payload。
最后断开连接触发漏洞，call [rax]这里调用了user mode payload，如前所述，只是用来查找KERNELMODE_EGG并跳转到kernel mode payload。
接下来的代码基本修改自https://github.com/worawit/MS17-010/blob/master/shellcode/eternalblue_kshellcode_x64.asm。第一步是利用rdmsr/wrmsr hook KiSystemCall64并保存原来KiSystemCall64的地址，KernelApcDisable++启用内核APC然后直接返回IcaChannelInputInternal的上层函数。
在我们的KiSystemCall64中首先照抄原来的5行代码，保存寄存器，加锁防止接下来的代码重复执行，恢复KiSystemCall64为原来KiSystemCall64的地址加上0x1F防止重复执行开头的5行代码，调用下一段shellcode。
因为已经知道了KiSystemCall64的地址，所以通过PE文件MZ头找到ntoskrnl.exe加载到内核中的地址。
分别通过KPCR和psgetcurrentprocess取得当前的ETHREAD和EPROCESS。
通过psgetprocessimagefilename找到EPROCESS.ImageFilename的偏移，因为EPROCESS.ImageFilename和EPROCESS.ThreadListHead偏移为0x28，所以可以据此找到EPROCESS.ThreadListHead的偏移。
ETHREAD通过ThreadListEntry链接到EPROCESS.ThreadListHead，所以遍历ETHREAD.ThreadListEntry,当它和前面取得的ETHREAD的差小于0x700时说明得到了ETHREAD.ThreadListEntry的偏移。
直接读取psgetprocessid函数地址+3处的值也就是汇编代码中的180h得到EPROCESS. UniqueProcessId的偏移, 因为EPROCESS.UniqueProcessId和EPROCESS. ActiveProcessLinks偏移为0x8，所以可以据此找到EPROCESS.ActiveProcessLinks的偏移。
前面已经得到了EPROCESS.ImageFilename的偏移，所以遍历EPROCESS.ActiveProcessLinks计算每个EPROCESS.ImageFilename的hash和spoolsv.exe的hash对比，直到找到spoolsv.exe为止。如果一直没有找到就释放前面通过lock cmpxchg上的锁以便下一个被劫持的系统调用运行shellcode。
找到spoolsv.exe之后先保存PEB的地址以便稍后查找CreateThread函数的地址，前面已经得到了EPROCESS.ThreadListHead和ETHREAD.ThreadListEntry的偏移，所以遍历ETHREAD，直接读取psgetthreadteb函数地址+3处的值也就是汇编代码中的0B8h得到KTHREAD.TEB的偏移, 因为KTHREAD.TEB和KTHREAD.Queue偏移为0x8，所以可以据此找到KTHREAD.Queue的偏移。根据注释中的解释，KTRHEAD.Queue为NULL时TEB.ActivationContextStackPointer也是NULL，而当TEB.ActivationContextStackPointer为NULL时会出现访问异常而crash掉。所以需要遍历ETHREAD直到找到一个KTRHEAD.Queue不为0的ETHREAD为止。
接下来调用KeInitializeApc和KeInsertQueueApc插APC，在KernelApcRoutine中调用ZwAllocateVirtualMemory分配内存，将user mode payload的最后一部分真正在用户态运行的payload拷贝到这块分配的内存。
然后根据前面保存的PEB地址通过LDR链找到kernel32.dll的地址然后找到CreateThread的地址，保存到SystemArgument1。
最后KiUserApcDispatcher函数调用真正在用户态运行的payload，并且参数是CreateThread，因为此时还处于原来的被打断的线程，所以首先需要新建一个线程。
0x02 时间线
2019-09-07 metasploit-framework仓库公开发布了CVE-2019-0708的利用模块
2019-09-16 360CERT发布分析
还没有评论，来说两句吧...