漏洞检测的那些事儿

0x00 简介

---

好像很久没发文了，近日心血来潮准备谈谈 “漏洞检测的那些事儿”。现在有一个现象就是一旦有危害较高的漏洞的验证 PoC 或者利用 EXP 被公布出来，就会有一大群饥渴难忍的帽子们去刷洞，对于一个路人甲的我来说，看得有点眼红。XD

刷洞归刷洞，蛋还是要扯的。漏洞从披露到研究员分析验证，再到 PoC 编写，进而到大规模扫描检测，在这环环相扣的漏洞应急生命周期中，我认为最关键的部分应该算是 PoC编写 和 漏洞检测 这两个部分了：

• PoC编写 - 复现漏洞环境，将漏洞复现流程代码化的过程

• 漏洞检测 - 使用编写好的 PoC 去验证测试目标是否存在着漏洞，需要注意的是在这个过程（或者说是在编写 PoC 的时候）需要做到安全、有效和无害，尽可能或者避免扫描过程对目标主机产生不可恢复的影响

首先来说说 PoC 编写。编写 PoC 在我看来是安全研究员或者漏洞分析者日常最基础的工作，编写者把漏洞验证分析的过程通过代码描述下来，根据不同类型的漏洞编写相应的 PoC。根据常年编写 PoC 积累下来的经验，个人认为在编写 PoC 时应遵循几个准侧，如下：

• 随机性

• 确定性

• 通用型

可能你会觉得我太学术了？那么我就一点一点地把他们讲清楚。

0x01 PoC 编写准则 & 示例

---

i. 随机性

PoC 中所涉及的关键变量或数据应该具有随机性，切勿使用固定的变量值生成 Payload，能够随机生成的尽量随机生成（如：上传文件的文件名，webshell 密码，Alert 的字符串，MD5 值），下面来看几个例子（我可真没打广告，例子大都使用的 pocsuite PoC 框架）：

上图所示的代码是 WordPress 中某个主题导致的任意文件上传漏洞的验证代码关键部分，可以看到上面使用了 kstest.php 作为每一次测试使用的上传文件名，很明显这里是用的固定的文件名，违背了上面所提到的随机性准侧。这里再多啰嗦一句，我并没有说在 PoC 中使用固定的变量或者数据有什么不对，而是觉得将能够随机的数据随机化能够降低在扫描检测的过程所承担的一些风险（具体有什么风险请自行脑补了）。

根据随机性准侧可修改代码如下：

更改后上传文件的文件名每次都为随机生成的 6 位字符，个人认为在一定程度上降低了扫描检测交互数据被追踪的可能性。

ii. 确定性

PoC 中能通过测试返回的内容找到唯一确定的标识来说明该漏洞是否存在，并且这个标识需要有针对性，切勿使用过于模糊的条件去判断（如：HTTP 请求返回状态，固定的页面可控内容）。同样的，下面通过实例来说明一下：

上图所示的代码是某 Web 应用一个 UNION 型 SQL 注入的漏洞验证代码，代码中直接通过拼接 -1' union select 1,md5(1) -- 来进行注入，因该漏洞有数据回显，所以如果测试注入成功页面上会打印出 md5(1) 的值 c4ca4238a0b923820dcc509a6f75849b，显然的这个 PoC 看起来并没有什么问题，但是结合准则第一条随机性，我觉得这里应该使用 md5(rand_num) 作为标识确定更好，因为随机化后，准确率更高：

这里也不是坑你们，万一某个站点不存在漏洞，但页面中就是有个 c4ca4238a0b923820dcc509a6f75849b，你们觉得呢？

讲到这里，再说说一个 Python requests 库使用者可能会忽视的一个问题。有时候，