在测试报告中复现漏洞

过去几个月里，我三次被客户要求重新测试先前的发现，以验证漏洞是否已成功修复。其中一份报告是我自己写的，另外两份来自其他测试人员。

对于我的报告，我几乎不记得测试的任何细节。阅读报告给了我一些线索，但幸运的是，我在客户的文件夹中留下了一个完全设置好的测试工具，可以直接测试漏洞。另外两份报告中，有一份涉及一个我从未听说过的漏洞，甚至在Google上也找不到相关信息。最终我追踪到原始测试人员，发现有一个简单的工具可以测试该问题，只需运行一个命令行脚本，复测就完成了。最后一个问题是我知道的，但报告写得非常好，即使我没听说过，也有完整的复现步骤。

那么，我的观点是什么？在艰难复现了三个问题中的两个之后，我开始思考：客户拿到报告时做了什么？他们成功复现问题了吗？甚至理解问题了吗？如果这些客户没有免费复测选项，他们会实施建议的修复（其中一个没有修复建议）并假设修复完美解决问题吗？考虑到修复人员很难分配时间实施修复，我怀疑他们中很少有人会费心去寻找测试方法并准备工具。

我们如何改进？显而易见的答案是包含完整的复现步骤。这对于基本的XSS之类的问题很好，你给他们一个注入字符串并告诉他们输入到哪个框中，但对于更晦涩的漏洞，比如主机接受ICMP重定向或弱SSL密码（请容忍我这么说），这就困难了。

更晦涩的漏洞通常是由Nessus等工具发现的，老实说，我们作为测试人员通常不知道如何手动测试它们，我们只是相信Nessus的说法。我发现这对于低级问题尤其如此，在正常测试中没有时间手动验证，也不值得回家花自己的时间研究。如果幸运，你的客户可能有漏洞扫描器，你可以告诉他们重新运行直到问题消失，但根据我的经验，有扫描器的客户很少见。这意味着我们必须找到方法，让他们以简单的方式复现问题，最少依赖标准IT部门中没有的工具。想象一下，在报告中包含如何启动Linux live CD、安装缺失的依赖项、克隆GitHub仓库，最后运行工具，这不可能发生，尤其是对于CVSS 2.0的问题。那么我们能做什么？编写一个自定义测试脚本，包含所有必需内容在一个Windows应用中，并且无需依赖即可安装？如果你有时间和预算这样做，那你非常幸运，尤其是对于大型扫描中通常出现的十几个晦涩的低级问题。

回到弱SSL密码，作为测试人员，这是一个相当容易测试的问题，我们的自动化扫描器会检测它们并给出一个很好的列表，显示哪些已启用，或者如果我们只想测试SSL问题，Qualys SSL Labs网站做得很好。但同样，我们不能只是告诉他们运行自动化扫描器，有多少雇主会因为报告中包含竞争对手网站的链接而斥责测试人员？有没有易于安装的Windows工具可以进行此测试？可能有，但我从未费心寻找，因为我从未需要它。

我希望在这里能给出一个惊人的答案，告诉你如何解决这个问题，并包含完美的脚本，可以测试报告中的所有内容，而无需你动手，但事实并非如此。我刚开始思考这个问题，所以答案很少。对于更常见的漏洞，我将开始编写如何测试它们的说明，可以添加到我的问题库中。其中一些需要我编写一些脚本，我可以提供给修复人员帮助他们，并在可能的情况下发布这些脚本。对于更晦涩的漏洞，我将逐个问题处理。但我可能发现的问题是，一旦我在报告中包含某些问题的复现步骤，那些没有步骤的问题就会显得突出， dedicated 修复人员想要运行并证明他们已经修复了一切，会回来向我索要缺失的步骤。这意味着，如果我没有在分配的测试时间段内记录所有内容，我将不得不在为不同客户计费的时间内尝试编写这些步骤，而且可能更严重的是，无法访问需要生成步骤的易受攻击系统。如果我必须构建一个易受ICMP重定向攻击的系统，然后想出手动验证的步骤，工作量将巨大，并且在漏洞存在于我无法获取的软件中时，这将是不可能的。

我很想知道其他人如何处理这个问题，以及你们中有多少人在报告中包含这类信息。我将在Pauls Security Weekly邮件列表中发起讨论，所以如果你还不是成员，请加入并添加你的评论。如果我得到一些好的反馈，我将就讨论内容写一篇后续文章。