[原创]断其粮道——内核级拒绝服务攻击

123456865

1、何为断其粮道？
古时的军队大体分为两部分，一是火线作战的士兵，二是后方运粮的人员，两者共同组成一个系统，双方配合才气完成作战任务。两者之间保持互相通讯，前者就可以派人向后者催粮，后者就可以派人向前者运粮，而这个运粮(通讯)的关键就在于粮道，假如被敌军切断，那么火线士兵就无法向后勤人员征求粮食(请求服务)，后勤人员也就无法为火线士兵运送粮食(提供服务)，此可谓之拒绝服务攻击。

以图示之，火线5万大军因吃不上饭而开始出现军心不稳的情况了。。。



2、应用程序的粮道在哪里？
那么程序有雷同的“粮道”吗，有的话在哪里呢？答案就要从3环进0环说起了。
Windows系统下有几个紧张的DLL：Kernel32.dll、User32.dll、Gdi32.dll、Ntdll.dll。运行在3环的应用程序不可避免的会使用这些Dll提供的API，而这些API大部分会通过Ntdll.dll进入0环，参考《加密与解密》的第7章的图7.6。


举一个例子来说明这个过程吧！用Windbg和win7 x86双机调试。
Kernel32.dll中的ReadProcessMemory，其代码如下：


其中只有一条jmp指令，跳到一个导入函数里去实行，我们看看该函数是什么：


原来是kernelbase.dll中的同名函数，继续反汇编，在+12附近的位置又调用了一个导入函数：


继续看该导入函数是什么，原来是ntdll.dll中的NtReadVirtualMemory函数：


此时就到了关键的地方了。ntdll.dll中的NtReadVirtualMemory函数非常简单，就4句，非常简单，它的作用是什么呢？
在ntdll.dll中，大部分API也是这样的格式：
[Asm] 纯文本查看 复制代码mov eax, API索引号mov edx, 一个地点     ;该地点里的值是一个函数地点call [edx]                     ;调用这个函数，实现进入0环retn 14h

API索引号就是在3环调用了一个API，这个API在内核也就是0环，会有对应的内核函数，这个内核函数的地点在SSDT表中位于某个位置，这个位置就是索引号。进0环后，得找到对应的内核函数举行调用吧，就是根据这个索引号找到的。

一个地点，里面存的值是一个函数地点，反汇编看一下就知道了：


原来这个函数名为KiFastSystemCall，假如CPU支持快速调用的话，那么call [edx]就是call KiFastSystemCall，假如是通过停止门进入0环的话，那么call [edx]就是call KiIntSystemCall。
KiFastSystemCall里的sysenter指令实现进入0环。操纵系统在实行这条指令前会把进0环后需要的东西(CS/SS/ESP/EIP)提前准备好，存入一个叫做MSR的寄存器中，等到sysenter指令实行时，就会从MSR寄存器中取出这些值赋给相应的寄存器，其中eip寄存器就得到一个值，这个值就是nt!KiFastCallEntry函数的地点。


那实在就明确了，通过快速调用进0环后的第一个要实行的函数就是KiFastCallEntry。这个函数的作用就是拿着前面传下来的API索引号，获取相应的内核函数，调用之，从而实现应用层想要的功能。
整个过程整理如下：


把其他API的调用过程也画上去，看看整体的流程：


其中的“粮道”我把它选为了Ntdll.dll中的KiFastSystemCall，上图蓝色的线，由于这个函数实现进入0环，3环的API就得通过这个必经之路进入0环。假如把这个必经之路给断了，那岂不是3环API进不了0环，从而0环无法为3环提供服务，这就达到了内核级拒绝服务攻击。还有一个地方也可以选为“粮道”，那就是MSR寄存器，进0环后要实行的函数地点是来源于MSR寄存器中的eip值，所以修改MSR寄存器也可以达到截断“粮道”的目的。

3、截断应用程序的粮道

根据第2节可知，3环进0环的关键函数是Ntdll.dll中的KiFastSystemCall，而且是以下面的形式来对它举行调用的：
[Asm] 纯文本查看 复制代码mov edx, 7ffe0300call [edx]                                ;           call KiFastSystemCall

7ffe0300地点里保存了KiFastSystemCall的地点。
实在这里涉及一个名为_KUSER_SHARED_DATA的数据布局，在3环和0环分别定义了一个该布局，其中在3环，这个布局地点固定为7ffe0000；在0环，这个布局地点固定为ffdf0000。这两个布局的内容完全雷同，它们偏移+300处的成员名为SystemCall，保存的恰好就是KiFastSystemCall函数的地点，所以上面的7ffe0300就是这么来的。看图。


好，既然3环API进0环，要访问7ffe0000+300处的成员，来实现进0环，那么我们把这个成员给改了(改之前拍个快照)：
ed 7ffe0000+300 12345678

把7ffe0000+300处的成员，任意改成12345678，那么3环进0环时，就会去12345678地点里去实行，而这个地点肯定是无意义的，看看会发生什么情况，根据我的实验得到：
Windbg首先有动静，问我停止照旧忽略

选b的话，Windbg会再次询问我雷同的题目，再次选b，就会停止了

此时的栈回溯信息如下：


假如选i的话，步调和结果如下：


系统跑起来了，题目是，鼠标移到记事本里，会改变外形为插入型，移动到桌面会显示正常的光标，移动到开始菜单处会显示漏洞状，但是均无法点击。向虚拟机发送Ctrl+Alt+Delete键，也是没有反应的。
整个系统就保持这种状态，既不会蓝屏，Windbg也不会继续捕获到异常。

(注：图片是gif格式的，太大了上传不了，看不到动态效果，大家有兴趣的自己做实验就可以看出厘革的)

修改ffdf0000+300处的成员也会使系统出现这种征象。以下是修改ffdf0000+300停止后的栈回溯信息。


4、实验结果说明
根据以上的的实验可知，修改进0环的关键位置，使得整个系统发生了无相应而不蓝屏的征象，大概可以解释成：是3环进0环的地方出了题目，而这个进0环的函数又是属于3环的，所以题目发生在3环而不是0环，故系统内核没有崩溃。

7ffe0000+300、ffdf0000+300这两个地方用来耍地痞是挺符合的，发现你对我的程序有分析举动，那我就阻断你进0环的路，你的程序得不到内核的服务，于是什么分析举动都无法举行下去了，这个就是断其粮道的寄义。实在对一些函数设置钩子，使其他调用者得不到准确的结果，也可以叫做拒绝服务攻击。

那么怎么对付这个地痞举动呢？从前面的两个栈回溯信息就可以看出端倪。

假如反过来呢？我们在分析的时候，触发了检测代码，从而发生了这种系统无相应而不蓝屏的征象，于是就没有蓝屏文件为我们提供信息，而假如又不知道3环进0环的原理，那么即便是看Windbg的栈回溯信息，也没法对付，所以很可能就想不到是程序的“粮道”出了题目。

代码就不写了，有兴趣的同学可以自己写个驱动，任意检测一个历程，然后修改这两个7ffe0000+300、ffdf0000+300试试，看看有什么效果。

一点思考：系统无相应而不蓝屏，说明用户层废了，而内核还在世，此时我们提前写个驱动计划一直循环干活，那么在系统无相应期间，驱动是否也在工作呢？假如在工作的话，那其他规范化的程序是不是就不能收集我们的种种举动呢？(应用层软件显然无法收集我们的举动了，内核层的驱动一般要和应用层通讯，此时无法通讯了，功能肯定大打折扣。)
5、参考资料

《加密与解密》
《软件调试》
来源：http://www.12558.net
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！