Author:Mike Czumak
翻译：moonAgirl

在第2部分中，我们为ASX To MP3 Converter构建了一个基本的栈溢出攻击。正如我在那篇文章中指出的那样，利用本身并不完美。成功的EIP覆盖受m3u文件的文件路径的影响。另外，虽然在选择跳转/调用地址时首选应用程序模块，但我们使用的应用程序DLL是重新分配的，这意味着我们的CALL EBX指令的地址可能会更改，因此不可靠。在这一部分中，我们将仔细研究这些问题以及一些可以改进我们的原始漏洞使其更可靠的方法。

我在第2部分强调的一件事情是，如果m3u文件是从C：\目录的根目录运行的，ASX To MP3 Converter的漏洞利用工作才起作用，因为EIP覆盖的偏移取决于文件路径。如果要验证，请尝试将m3u文件从C：\移动到桌面，然后重试调试器中的漏洞。请参阅下面的屏幕截图。

正如您所看到的，EIP现在不会被我们的CALL EBX指令覆盖，而是被我们payload的前面“垃圾”部分覆盖，这部分由A（\ x41）组成。由于较长的文件路径被合并到有效载荷中，因此它将所有内容都推向右侧，并将EIP更改为'AAAA'。

如果您记得，我们完整的exploit缓冲区看起来像这样：

EIP的偏移量（当m3u文件位于C：\的根目录时）为26,121字节。正如我们通过将m3u文件移动到桌面所证明的那样，较长的文件路径会导致EIP覆盖为A。如果文件路径是对偏移量的唯一影响，我们应该能够准确预测新偏移量。让我们为m3u文件选择一个不同的保存位置来证明这一理论。位于我的桌面上的m3u文件的完整路径如下（其中Documents and Settings \ Administrator \ Desktop \是较c:\多出来的路径长度）：

这条新路径长45个字符，这意味着我们应该调整我们的EIP偏移-45，新的偏移量26076。让我们更新我们的漏洞利用代码，看看它是否有效（只改变你在第2部分中建立的利用漏洞的偏移量）

在重新启动的Windows计算机上运行具有更新偏移量的漏洞利用程序会产生以下结果：

EIP显然已被我选择的CALL EBX地址（来自MSA2Mcodec00.dll的0x01C27228）覆盖，但该程序似乎并未将其识别为有效地址。这里出现的问题，因为在我的漏洞利用代码中，我使用了来自重定位应用程序模块（DLL）的地址。

在没有详细介绍重新绑定的情况下，要明白每个模块都有一个指定的基地址，它应该加载在这个地址上（而且编译器通常有一个默认的地址分配给所有的模块）。

如果在加载时发生地址冲突，则操作系统必须重新绑定其中一个模块（从性能角度来看代价非常高）。或者，应用程序开发人员可能会提前重新绑定模块以避免此类冲突。

在我们的例子中，如果MSA2Mcodec00.dll重新绑定，地址空间会发生变化，我们的CALL EBX地址发生变化。不幸的是，这会影响成功利用的可靠性，这个问题比我们的文件路径问题更严重。

在这里我们有两个选择

1）看看我们是否能找到另一个没有实现重定位的应用程序模块（首选）

2）使用系统模块。

请记住，从第2部分中可以看出，使用系统DLL（相对于应用程序DLL）的缺点是它减少了漏洞在不同版本的Windows上运行的可能性。这就是说，在每台Windows XP机器上运行的漏洞利用程序要比只能在一台机器上运行的漏洞利用程序更好！

我们可以使用mona插件更仔细地检查加载的模块，并通过运行以下命令来查看哪些模块实施了重定位。

以下是生成的find.txt文件开头的截图。它显示了找到“call ebx”指令的所有模块，以及与这些模块中的每一个模块相关的属性，包括它们是否实施重定位（请注意“重定位”列）。

请注意，该列中有两个值为“False”（以橙色突出显示）。不幸的是，这两个模块中的所有“call ebx”地址都包含空字节。看起来我们别无选择，只能使用系统模块。我会选择其中一个较大的dll，如shell32，user32，kernel32或ntdll，因为它们可能不太可能在系统服务包之间进行更改。在find.txt文件中向下滚动以查看找到的实际“call ebx”地址。我将选择列出的第一个shell32地址（0x7c9f38f6）。

现在，我将使用SHELL32中新的CALL EBX地址（注意已更新的EIP偏移量）更新漏洞利用脚本，创建m3u文件，并从桌面运行它。

成功！！

我们通过选择一个操作系统模块来克服我们的地址重定位问题，并验证了可以根据m3u exploit文件的路径大小来预测偏移量。

下一步是将多个偏移量合并到我们的漏洞利用代码中，以增加从不同位置成功执行的可能性。我们可以通过简单地包含重复偏移模式的缓冲区的垃圾部分（而不是使用A's，使用EIP + EIP + EIP等）来实现此目的。虽然这增加了成功利用的可能性，但由于常见的存储位置（桌面，我的文档等）可能会或可能不符合该模式，所以这是相当随意的。相反，我们可以生成可能的保存位置列表，并将偏移量放在我们的缓冲区中。我们可以手动做到这一点

最后我们将留下一个如下所示的缓冲区：

当然，这不是非常高效的编码，并且使得添加和删除路径变得繁琐，因此我们利用脚本的强大功能，使其更容易管理。

首先，我们将创建一组可能的路径。我创建了一个有几条可能的路径，尽管还有更多：

为了便于说明，我还包括了手动计算的偏移量（作为注释），通过编写偏移量创建脚本，我们不需要为每个文件路径实际执行此操作。接下来，我们创建一个循环，并使用数组的内容动态构建缓冲区的垃圾+ eip部分。

正如你上面看到的，我们只是循环访问数组，并使用每个文件路径的长度（减去共享的'C：\'）来策略地放置偏移量。

我们的最终利用看起来像这样：

如果您想要显示缓冲区的外观，请在文本编辑器中打开生成的m3u文件，您应该看到下面的偏移量：

即使这个更新的漏洞利用也不完美，因为我们使用了一个用于EIP覆盖的OS DLL以及有限数量的漏洞利用触发位置，但它肯定比我们第2部分的原始版本有所改进。

除了改变受文件路径影响的偏移量之外，遇到具有由启动方式决定的多个偏移量的漏洞并不罕见。以最近发布的针对RealPlayer 16.0.3.51/16.0.2.32的漏洞为例它包含两个偏移量/ EIP覆盖 -

一个用于直接启动漏洞利用率.rmp文件，

一个用于在应用程序内打开漏洞。

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