也许你用过或者正在用着PP点点通这款软件，因为其出色的基于网络的服务功能，使得它在现在的网络软件中占据了很大的市场。我也是它的一个忠实用户，可就在几天前，我的朋友说他发现PP点点通这款软件有漏洞，而具体的细节他没有给我说，虽然只是简单的一句话，可是因为自己对这样的信息比较感兴趣，于是我就自己寻找出现漏洞的地方，所谓自力更生才是正道嘛。我拿出自己编写的一套测试软件，在脑力与程序的配合下，终于发现了出现漏洞的地方，其实要成功触发这个漏洞并不难，可难就难在找到利用的突破口上了，欲知详情请听下面分解。
        漏洞出现的地方是在对本地一个文件的修改上，这个文件名为“Config.ini”，顾名思义是一个配置文件。很多程序在初始化的时候都是要么从配置文件获取初始信息，要么从注册表获取信息等等，这一点对于安全测试员来说很关键。文件“Config.ini”中有很多可以测试的字段，我这里首先选择了“DownloadPath=”，因为这是一个可以被人明显注意的地方，一般在程序安装后，它的默认值是“C:\Program Files\PP31\Downloads”。我们知道，Windows默认的文件夹、文件完整路径不超过255个字节，而在VC6中有个宏定义标记这个值为260，而PP点点通恰巧是用VC6编写的，这里我们就不得不考虑是不是会出现什么问题了。利用我的测试软件，在测试中果真发现PP点点通初始化读取了这个文件，并且传递了“DownloadPath=”参数，一旦我们修改了这个默认的数值，PP点点通将会自动新建一个同名的文件夹作为下载文件夹，那么这就势必会引起对“DownloadPath=”参数长度的限制。很可惜，PP点点通根本没有注意到这个，一旦我们将这个参数的值改到超过260个字节时，你就会发现程序出错了，如图1所示。
         

下载 (41.12 KB)

        图1
现在看起来，漏洞果真是存在的了。你一定开始急得想调试漏洞，寻找跳转地址，然后放上ShellCode去执行了。且慢，如果你现在调试就会发现，此时程序的执行已经不是简单的返回地址被覆盖了，你没发现上面的报错内容跟以往的不一样吗？程序出现栈溢出的地方早已执行过去了，现在出现的错误只是前面栈溢出引发的另一个错误而已，传统的溢出利用这里完全不奏效。怎么办？别急，有两个办法可以帮助我们解决问题。第一个是找到溢出的地方，看能不能引出返回地址被覆盖的传统溢出现象，我测试了这个办法，答案是不能。那么就用第二个办法，就是所谓“将错就错”，既然这个是引发溢出后的另一个错误，那么就试图把它弄成一个能被我们利用的错误。还记得我们在传统溢出中为了执行ShellCode的办法吗？一个是利用系统DLL中的jmp xxx（寄存器）或者call xxx（寄存器）的方法，一个是覆盖SHE。我们现在既然要创建一个能被我们利用的错误，那么也就是寻找上述的两个办法来执行ShellCode，要么我们弄出一个错误，让程序出现jmp xxx或者call xxx出错，要么就去覆盖SHE。这里覆盖SHE不行，那么就只剩第一个办法了。经过我仔细的反汇编分析，用了将近一天的时间，终于成功的让PP点点通程序出现了让我们兴奋的call指令错误，如图2所示。

图2
看到了吗？图中黑色的那一行，“call dword ptr[eax+5c]”指令出错，而这里的eax是我们能够控制的指令，胜利的天平已经向我们倾斜了。可是稍等，这里的“call dword ptr[eax+5c]”指令是一个间接寻址指令，也就是说我们必须使得[eax+5c]的值成为一个指向我们ShellCode的指针数值，而此时只有ecx和edi寄存器指向我们可以利用的ShellCode，如图3所示。

下载 (72.14 KB)

图3
所以我们要么能让“[eax+5c]＝edi”或者“[eax+5c]＝ecx”，要么就是让[eax+5c]指向的地方是一个跳转语句或者call语句，类似“call edi”或者“jmp ecx”，让其变成间接的间接寻址，最终还是会跑到我们的ShellCode中去就行。说到这里我提出一个面对这种情况下，如何执行ShellCode的方法，因为这不是传统的“jmp esp”，esp直接就指向ShellCode，这里的情况是我们得间接执行ShellCode。按照上面的两个方法，我们为了寻找“[eax+5c]＝edi”，可以在系统的动态库文件中，寻找一些指令，由这些指令组成一个等于edi值的连续地址。假设在user32中，某地址处的指令为“mov eax,ebx pop eax pop ebx ret”，那么它在内存中的显示就是“8B C3 58 5B C3”，而且我们需要的edi值就是“0x5B58C38B”，这个地址指向我们的ShellCode，那么我们只需要将eax的值赋值为上面user32[某地址－5c]即可，因为这样“call dword ptr[eax+5c]”获取的就是我们ShellCode的执行权。同样道理，我们也可以找一个“call edi”的指令地址，在系统DLL库中找指令组合，然后获得地址，修改我们的跳转指令。大家仔细看看图4和图5的示意图就会明白了。

下载 (18.49 KB)

图4

图5
其实这里最稳定的还是图5的使用方法，因为如果你使用图4的方法，所获得的ShellCode地址是相对稳定的，一旦电脑重新启动或者因为某些原因，例如堆的参与，很容易造成地址变化，而使用寄存器间接寻址则会保持稳定，因为寄存器的值始终指向我们的ShellCode地址。在接下来的时间里，我们就是寻找这样的符合我们要求的地址。你可以选择手工，也可以选择编个程序自动寻找，总之有了思路，一切皆有可能，最后，我们只需要放上一个符合格式的ShellCode即可。什么叫符合格式的ShellCode？还记得我们这里测试的参数吗？是一个路径值参数“DownloadPath”，既然是路径值，那么就不要在其中出现一些特殊符号啦，不然Windows会报警的，这也会影响我们的ShellCode执行。假设你要寻找符合这样要求的ShellCode，你可以参考我以前在黑防上发表的那篇关于腾讯安全控件漏洞的文章，那里的ShellCode是符合要求的。
现在为了证明我的理论的正确性，我暂时把ShellCode换成一个执行死循环的代码，从伪指令角度来说就是：“loop 1＝1”，汇编代码是“EB FE”，这样一旦我们的这个ShellCode执行了，那么电脑就会忙得不可开交了。现在我们无非是要找到符合要求的那种所谓的间接再间接寻址指令的地址，我这里寻找的是一个找寻指向call（寄存器）或者jmp（寄存器）指令的地址，并且我为了保证这个地址能是一个比较稳定的地址，把寻找的目标放到了系统的动态库里面，当然你也可以寻找别的文件里的，只是一旦环境稍变化，恐怕你的地址就会成为错误的。手工寻找太累了，自己编写一个程序自动查找最好，其实这个很好编写，就是按照将地址加一，然后取出这个地址，利用这个地址找到所指处的十六进制代码是否是“FF D1”“FF D7”“FF E1”“FF E7”，这几个代码其实就是call ecx、call edi、jmp ecx和jmp edi这些指令的十六进制表示，只要我们找到其中的任意一个，我们都是可以利用来执行我们的ShellCode的，因为edi和ecx寄存器都指向了我们的ShellCode。经过大约一分钟的查找，真是太幸运了，我们找到了四个地址，可正如同我说的那样，为了稳定最好选择使用系统动态库的地址，这样我们把目标所在了“204D3DE1”，这个地址其实是在Windows XP SP2的一个专门的动态库文件“xpsp2res.dll”中的，不论怎样这都非常符合我们的要求。现在赶紧修改我们的过长字符串，将其中控制eax寄存器值的那个字符串值改为“204D3D85”，注意这里，这个值可不直接就是我们刚才找到的那个地址，还记得前面出错的那个call指令吗？因为出错时，利用的是[eax+5c]，所以我们找到的地址一定要减去5c才行，这样PP点点通出错时会自动帮我们恢复成真正要利用的地址。修改好跳转地址后，再修改我们的ShellCode，把我们的死循环这个ShellCode放到离跳转地址大约100个字节以后，因为edi指向的地址比较靠超常字符串的后面，太前了出错时会执行不到那里。还需要说的就是，正因为edi指向的地址比较靠后，这样留给我们放ShellCode的位置就不是很充裕了，如果你要放一个比较长的ShellCode，建议你使用先放小ShellCode，此Code的主要目的是跳转后遍历查询大ShellCode，而大ShellCode就可以直接放到控制eax覆盖的跳转字符串的前面任意位置，那里可以放很长的字符串，估计完全够用。一切就绪后，我们用这个精心构造好的字符串赋值给“config.ini”文件中的“DownloadPath”参数，打开PP点点通，然后选择“退出系统”，你会发现你的电脑一下子忙到了100％！我为了更加清楚的反映程序出错时的状态，给大家截图如下，先看第一幅，如图6所示。程序出错了，还是出错在call指令上，而此时eax成功被我们控制进入xpsp2res.dll中。再看图7，看到了吗？我们成功控制程序流程进入了call edi指令，注意下方的显示，此时edi就指向了我们的简单ShellCode。一旦程序进入了我们的ShellCode，电脑就会进入一个死循环，图8中的任务管理器真实的反应了这一点。
         

下载 (57.71 KB)

        图6

图7

下载 (25.31 KB)

图8
到这里，表明我们的一切分析确实都是正确的，只是有时利用会出现一定的干扰，这个大家可以自己研究一下，这里我就不再分析了。现在大功告成，我们收工了。最后，我提供给大家一个POC，因为每个版本的Windows环境下利用的跳转地址不太一样，我就偷懒不挨个测试了，我直接给出触发到call指令的畸形文件，依据我上面的思路，自己修改练练手，也许你会有新的发现的。