该漏洞可针对IIS 6.0的WebDAV服务发起攻击，通过缓冲区溢出造成远程代码执行。漏洞提交者已在GitHub上公布Poc代码以及漏洞描述，我们可以方便得到Poc以及漏洞信息进行调试

作为一个初学者，看完别人的分析文章需要做的是上手调试，于是形成了这篇调试笔记。行文略显烦琐，错误含糊之处希望各位指(pao)出(hong)

本文的分析思路是跟踪执行脚本时大规模拷贝的数据，弄清数据的含义以及拷贝之后的流程走向，因为没有对相关函数进行反汇编阅读，理解上难免狭隘肤浅

[操作系统]: Windows Server 2003 R2 Enterprise Edition SP2

[调试器]: WinDbg 6.11.0001.402 X86

[Python]: Python 2.7

在Add or Remove Programs中选择 Add/Remove Windows Components

对Application Server选项的描述中提到了IIS

点击Details全部选中(只选择IIS应该也可以)，然后点击Next

在安装组件的过程中需要插入安装光盘

安装完成之后打开IIS服务管理器

鼠标右键将WebDAV设置为Allow

打开服务，查看WebClient，需要将其开启

目前处于停止状态且无法开启，将该服务设为自启动，然后重启

此时服务正常开启

将python路径设为环境变量，使用控制台窗口运行样本

查看任务管理器，多出了隐藏窗口的calc.exe进程

使用Process Explorer查看进程依赖关系

可以看到calc.exe的父进程是w3wp.exe

查看calc.exe进程详细信息

由于w3wp.exe并不是开机启动的进程，而样本只是简单启动计算器，干脆先执行一次脚本，然后使用Windbg附加调试

既然会创建新进程，那就对几个关键API下断等它来

执行起来，中断到kernel32!WinExec函数中

查看调用栈

没有调用关系可以参考，好了，老招数，对esp下断

凭感觉收获真是太多了

重新加载样本，对如下rep movsd指令的地址下断

设置断点

抢先剧透，这个漏洞的产生的确来自这里，这里的数据拷贝会来三次

通常俺喜欢从上层函数开始往下看

好了重新加载样本，新增断点，对地址0x67119464下断

运行样本，中断在httpext!ScStoragePathFromUrl函数调用前

当前函数是这样的

跟进httpext!ScStoragePathFromUrl，单步几句

此时内存布局为

G一下，到拷贝数据的位置

先不急，观察一下上下文，附近有四句rep movsd指令

目前在第三处rep movsd,重新加载样本，看看前两次都干嘛了

新增断点0x67126faf

G一下，断到第一句rep movsd指令处

此时的目的地址edi的值就是上层函数传进来的第一个参数

查看拷贝的内容

执行过去

来到第二次rep movsd，拷贝次数为0，并不关心

好了，来到关键的第三次rep movsd

查看拷贝的数据

拷贝前，对比一下目的地址的原始数据和源地址的数据

忍不住又要剧透了，这次拷贝的关键在于覆写地址0x00fef90c处的数据，数据0x00FEF804修改为0x680312C0，这不是一个巧合

单步过去，然后G起来

中断到上层函数，看看这次的参数

经过前面的调试，已经知道地址0x680312c0肯定会作为目标地址被拷贝数据，那么就，围观一下这段内存空间

这就是初初调试时感到美妙的地方，0x680312c0这个值是哪里冒出来的？这可是别人的模块

查看上下文环境

那么地址0x00fef7b8的数据0x680312c0又从哪里来的呢？

重新运行样本，对地址0x00fef7b8下个写断点

留意地址0x00fef7b8处数据的值，执行到这里时出现我们寻找的值

查看上下文环境

edi的值来自[ebp-328h]

这就是前面剧透的，拷贝数据时，地址0x00fef90c处的数据由0x00FEF804修改为0x680312C0

取消该写断点，G一下，中断到上层函数，地址0x00fef90c处的数据没有变化

如上所述，当前参数如下

以上整个过程中，弄清了第一次大规模拷贝数据的意义：控制第二次大规模拷贝数据的目的地址

现在分析第二次大规模拷贝，G一下，直接断在第三次rep movsd处

是的，目的寄存器edi的值在内存中属于rsaenh.dll模块

查看拷贝的源数据

拷贝之后的内存数据

现在分析第三次大规模数据拷贝，来到上层函数

查看参数

G一下，断在第三次rep movsd处

查看源数据，和第一次大规模拷贝的数据相同

拷贝之后的内存数据

这次大规模拷贝的数据，连上第一次rep movsd，是从地址0x00fefab4开始的

G一下，再次来到上层函数

查看参数

此次的参数跟上一次参数是相同的，上一次已经向地址0x00fefab4拷贝了数据，经过调试，现在没有大规模数据拷贝了，跟进httpext!ScStoragePathFromUrl函数

[注意]传递专业知识、拓宽行业人脉——看雪讲师团队等你加入！