看我如何发现开源 WAF引擎ModSecurity 中的DoS 漏洞

聚焦源代码安全，网罗国内外最新资讯！

编译：奇安信代码卫士团队

ModSecurity 是由 Trustwave 维护的开源 WAF 引擎。安全研究员 Ervin Hegedüs 在 ModSecurity中发现了几个 cookie 解析问题，几天后 Andrea Menin 指出其中一个问题可导致运行 ModSecurity 版本 3.0 至2.0.3 的服务器拒绝服务攻击。

漏洞详情

针对该漏洞的利用将把恶意 HTTP “Cookie”标头发送到易受攻击的服务器中，它将导致 out_of_range 异常，在结合 nginx 使用的常见 ModSecurity 用例中，将导致 nginx 工作线程（负责处理请求的线程）崩溃。反复向服务器发送这类请求将导致工作线程反崩溃，而如果发送请求的速度快于工作线程能够恢复的速度，将导致服务器拒绝服务后果。

发现过程

漏洞始于Ervin 运行 OWASP 规则集 (CRS) 回归测试时发现的一个 bug，他对比 ModSecurity v2和 v3 时发现了行为差异：“CRS 有一个回归测试案例，请求中仅包含单个字符串，而并没有“=”作为 HTTPCookie。Modsecurity3版本结果失败，因为如果Cookie 标头部分未包含“=”，则它不会被当做 cookie 处理。

在调查该代码时，Ervin发现了其它几个问题并决定着手推出修复方案，“当我完成代码和回归测试后，我想确保自己想到了所有可能的 cookie 字符串。为执行最简单的检查，我做了一个小工具，它包含新旧 cookie 解析方法以及源自 libmodsecurity3 源的 helper 函数。它使我能够看出新旧实现之间的差别。”

Andrea表示，“Ervin在二进制文件中复现了 libModSecurity cookie 解析器及其修复版本，该二进制文件从第一个参数读取一个 cookie 字符串，并对其进行解析，比较“老旧”和新型解析器之间的结果。Ervin 让我检查他的补丁，以寻求其它绕过方法。如你所知，在 cookie 字符串中，每个名称和值都通过一个 = 分割，而每个 cookie 名称/值对之间用 ; 分隔。经过几次测试后，我开始放置随机序列 ; 和 = 试图使其崩溃。通过发送 ;=;，不会发生任何情况，只会删除第一个 ;，事情就开始出错了。”

之后，他们就遇到了上述提到的 out_of_bounds 异常情况。

Andrea表示，“我们立即想到这个‘outof range’是如何影响正在运行的 webserver的，而且它是否会导致拒绝服务后果。因此，我已经在运行 Nginx +libModSecurity 的 docker 容器上通过 curl […] 发送请求进行了测试，但我没有从 web 服务器获得任何响应，甚至没有响应标头。通过读取 Nginx error_log 可以清楚地看到，我先前的请求杀死了Nginx 工作进程，该进程在日志上写入了相同的‘out of range’错误。从这里开始，对于我来说，仅通过发送带有 curl 的多个请求并连续杀死所有重新生成的 Nginx 工作进程，就很容易卡住 Nginx。”

修复方案

更新至 ModSecurity v3.0.4。

如果用户使用的 ModSecurity是从 GitHub 编译的，则v3/master 分支中也包含了解决方案。

如果用户修复了该漏洞但并未升级至 3.0.4，则可在之前的稳定版本 ModSecurity v3.0.3 基础上应用补丁文件：https://github.com/SpiderLabs/Misc/blob/master/ModSecurity_cookie_parsing_fix_303.patch。

       

推荐阅读

突发：俄罗斯警方突袭开源 Web 服务器 NGINX 的莫斯科代表处，拘留两名联合创始人

只需某些特定的Nginx + PHP-FPM 配置，即可触发PHP 远程代码执行漏洞

原文链接

https://www.trustwave.com/en-us/resources/blogs/spiderlabs-blog/modsecurity-denial-of-service-details-cve-2019-19886/

题图：Pixabay License

转载请注明“转自奇安信代码卫士 www.codesafe.cn”。

奇安信代码卫士 (codesafe)

国内首个专注于软件开发安全的产品线。

 点个“在看”，bounty 不停~