如何构建自定义扫描器实现Web安全研究自动化
在这篇文章中,我将分享我开发自定义自动化工具的方法,以帮助研究被低估的攻击类型,并(希望)推动Web安全的边界。
作为一个实际例子,我将基于我之前的研究《粉碎状态机:Web竞态条件的真正潜力》进行构建。如果你还没有看过,这个演讲的DEFCON录音现在已经可用,可能值得一看。
识别机会
你认为有可能创建一个可以自动检测Web竞态条件的扫描器吗?我最初否定了这个想法,因为我发现的竞态条件需要触发复杂的、多步骤的认证网站交互,并发现细微的副作用。
在这项研究的过程中,我注意到竞态条件经常成簇出现。它们从不稳定的库和框架中冒出来,所以如果你在一个网站上发现一个,很可能附近还潜伏着其他竞态条件。这意味着即使检测到的竞态条件本身无害,自动检测也可能很有价值。
我决定基于我对这个主题的熟悉度、单包攻击形式的新工具,以及一个测试平台(意味着我可以在一天或两天内尝试这个概念)来探索这个想法。
避免过度承诺
当尝试自动化某些棘手的事情时,一个常见的陷阱是尝试自动化太多,最终无法实现任何有用的东西。为了避免这种情况,我喜欢检查我的手动测试方法,并确定我可以合理自动化的最小、最早的步骤。以下是我用于竞态条件的手动测试过程:
由于“预测”阶段只是关于效率,我们可以跳过它,直接尝试自动化“探测”阶段。这个阶段的目标是使用一批并发请求来触发“异常”,并证明一个端点可能具有子状态。
拥抱意外
我编写了代码来依次发送一个请求十次,然后使用单包攻击在1毫秒内重新发送十次。我预计在一个容易发生竞态条件的网站上,并发请求可能会触发50X错误响应。
此时,我本可以通过仅针对看起来动态的端点,并仅报告带有50X代码的响应来提高效率并减少误报。然而,最好的研究发现往往来自意外结果。这意味着避免将你的期望写入代码中很重要。我故意为意外结果留出空间,通过测试所有观察到的请求(无论它们是为了什么),并报告状态代码的任何差异。
在研究方面,我宁愿有误报也不愿有漏报。
使迭代容易
这种方法在开始时不可避免地会导致大量误报,因此使迭代改进变得轻松至关重要。
我在Burp Suite扩展中实现了这一点,并使用一个包含来自约30,000个有漏洞赏金计划的网站的主页和资源的项目文件作为测试平台。有关此设置的更多详细信息,请查看《破解镜头》。
对于完整运行,我只需选择代理中的所有请求,右键单击并启动扫描。它优先处理较短的域名,因此高价值目标的结果往往很快出现。
自动化你的分类
我通常手动分类一小部分发现,然后分析我的分类过程并自动化它。在处理结果时,我发现自己:
- 忽略关键请求只是超时的发现
- 忽略带有429状态代码的发现,因为这些只是速率限制
- 忽略带有502/503的发现,因为这些表示后端超时
- 在并发批次后尝试额外的顺序请求
- 添加缓存破坏器以过滤出缓存行为
在我的扫描检查中实施此过滤过程并重新运行后,留下了一些有希望的发现:
- 各种奇怪的50X和307代码
- 一个Web服务器在您使用单包攻击时发出神秘的“501 Not Implemented”响应,声称不支持GET请求。
- 一个网站触发对后端系统的服务器端请求以用于SSO目的。单包攻击使后端过载并触发错误消息,披露完整URL。
- 另一个服务器在受到同步请求时间歇性地发出400 Bad Request响应。这很有趣,因为它表明它们的请求解析中可能存在竞态条件,这可能启用异步攻击。
不幸的是,除了深入的手动调查之外,这些都没有给我留下明确的前进路径,而在我目标会议(Nullcon Goa)之前我没有时间进行。
滥用小工具
我需要的是一个能够检测明显危险行为的方法。
但是,您可以从网站的主页直接检测到什么危险的竞态条件?嗯,偶尔我会看到应用程序和缓存混淆的报告,要么将响应发送给错误的人,要么提供原始内存。当然,最臭名昭著的例子是Cloudbleed。
我们如何判断是否收到了针对其他人的响应?作为人类很容易,而LLM可能以性能极差的代价告诉,但对于粗糙的、正则表达式级别的自动化来说,这是一个棘手的问题。
这就是小工具的用武之地。小工具是某些网站上存在的有用功能,使漏洞检测更容易。我们可以依靠小工具快速轻松地探索一个概念是否值得投入更多时间。依赖小工具进行漏洞检测会导致大量漏报,但在研究的早期阶段,为了开发速度,这种权衡是值得的。
相当多的网站嵌入有关用户请求的数据,以将其暴露给客户端JavaScript。这通常包括用户的IP地址和请求属性,如URL和User-Agent。在包含此类小工具的网站上,我可以通过在每个请求中放置一个唯一的“canary”参数,然后分析每个响应以查看是否包含来自不同请求的canary来检测竞态信息泄漏漏洞。
这种方法最初标记了许多网站,但大多数只是通过未键控查询字符串进行缓存中毒。
通过一些更多的代码调整过滤掉缓存中毒和其他“canary存储”行为后,留下了一些真正的发现。最好的例子是某个网站,由于竞态条件,您可以通过重复获取主页来获取实时用户正在访问的URL:
window.PAGE_STATE={…{"params":{"utm_souce":"bing",…
这对Nullcon来说是完美的;我拼凑了几张幻灯片,并在Backslash Powered Scanner中发布了扫描检查。您可以通过BApp商店安装它,并在Github上浏览代码。
总结
正如我们所看到的,面向研究的扫描与构建普通扫描器有很大不同,因此在将此建议交叉应用到其他用例时请小心。
如果您想尝试自定义自动化,Burp Suite中的新BChecks功能旨在使这更加易于访问。
如果您觉得这有用,您可能还会喜欢演讲《狩猎规避漏洞:发现他人遗漏的缺陷》,我从另一个角度研究了研究自动化。
在我的下一篇文章中,我将继续竞态条件主题,并超越HTTP/2探索哪些其他协议支持单包攻击。