不管挖掘的目标产品是什么，我的方法始终遵循相同的结构，我将生成一些畸形数据，例如基于文件的输入等，进行变异并将其馈送到带有调试器的应用程序中，在预定的时间后，我将终止目标过程并记录结果，crash将被记录些来，然后分析这些crash。

通用漏洞挖掘流程：

图1：模糊测试

0x02  漏洞挖掘

一旦应用程序crash，我会用windbg 使用！exploitable添加扩展名，来删除重复数据，设置crash优先级，对于不熟悉此扩展程序的用户，一旦应用程序crash，将调用！exploitable，并尝试根据其执行的分析对crash进行分类。它为每个crash分配可利用性类别（即，可利用，可能利用，不可利用等）以及与该crash相关的哈希。

我使用此信息根据类别对crash进行存储，然后再次使用主要和次要哈希值进行存储。

最终会看起来像这样：

图2：crash结果

从这里我可以开始打开调试日志，并更好地了解导致应用程序crash的原因。例如，如果我查看bwmail.exe的日志文件，我可以看到它由于基于堆栈的缓冲区溢出而最终crash了。

图3：基于堆栈的缓冲区溢出

如果要在IDA中打开bwmail.exe应用程序，我可以发现此漏洞的根本原因是使用了列入不安全函数黑名单的API调用strcpy。如果重新启动应用程序并在该调用上设置一个断点并转储EAX寄存器的内容，则可以看到它包含我的payload。

图4：根本原因

如果我跳过此调用并检查堆栈，则可以看到它已被payload完全覆盖，无需担心ASLR或DEP，首先我需要确保我可以通过网络发送此攻击payload。

图5：堆栈的其余部分

为了通过RPC进行测试，我将利用ZDI研究人员Fritz Sands和他的博客文章Advantech和RPC 发布的一些代码。为此，我将使用两台计算机：右侧的Windows 7计算机是攻击者，左侧的Windows 10计算机是受害者。

我附加到该过程，启用子调试，然后启动，进入调试器验证是否已成功加载。

图6：检查paylaod是否可以远程传送

0x03  漏洞利用

为了帮助加快利用开发速度，我将使用Peter Van Eeckhoutte编写windbg的mona。Mona具有一些很好的功能，它将简化利用过程。首先，我需要查看缓冲区实际上在什么时候被覆盖，为此，我可以使用mona生成非重复的字符串，我可以在调试中搜索该字符串。

图7：使用mona创建字符串

接下来，我将该模式作为命令行参数发送回bwmail应用程序，并且按预期，该应用程序将crash。

图8：基于循环模式的crash

一旦调试器在crash时中断，我将使用mona的findmsp功能在应用程序进程内存中搜索循环模式的所有引用。在查看这样的输出时，我首先检查寄存器部分，以查找以下三种情况之一：覆盖保存的返回指针（EIP），直接寄存器控制或覆盖结构化异常处理程序（SEH）。

在此特定示例中，我将使用后者：

图9：使用mona的findmsp函数查找循环模式

Mona告诉我，发送1,192字节的数据后，下一个异常注册记录（nSEH）被覆盖。

使用mona的sehchain功能，mona将打印一个漏洞利用模板供我使用。

图10：由mona提供的payload格式，

为了实现这一点，我将需要1,192字节的数据，一个短跳转，一个pop / pop / ret指令以及一些shellcode。

接下来，我需要一个pop / pop / ret指令集的位置，Mona seh -n将在进程存储器中搜索这些指令，并忽略任何包含空字节的结果。

图11：使用mona查找pop / pop / ret指令

如果利用了DEP或ASLR等现代漏洞利用缓解措施，则Mona还会返回找到的有效pop / pop / ret指令。

图12：结果

添加Windows Shellcode后：

图13：Shellcode

参考及来源：https://www.zerodayinitiative.com/blog/2020/1/15/reliably-finding-and-exploiting-icsscada-bugs