深入理解JNDI注入—RMI/LDAP攻击

原创

已于 2024-09-19 01:32:41 修改 · 2.4k 阅读

31 ·

CC 4.0 BY-SA版权

文章标签：

#安全 #web安全 #网络安全

于 2024-09-18 08:49:58 首次发布

文章目录

前言
JNDI 注入简单理解
透过Weblogic漏洞深入理解

前言

本篇文章初衷是在研究log4j2漏洞时候找不到一篇完整且能够真正让我理解漏洞根因的文章，导致我想写一篇通俗易懂能理解到底啥是JNDI注入，怎么lookup的。

当然不排除国外英文文章有很好的解释，但是我更希望有中文版本。

JNDI 注入简单理解

JNDI (Java Naming and Directory Interface)

JNDI注入可以归纳为后台在执行代码的时候，最终会执行到lookup函数，然后lookup函数传入的值是我们在请求或者其他方式能够控制的一个变量，再者lookup支持远程方法调用（RMI）、轻型目录访问协议（LDAP）、域名服务（DNS）。

定眼一看RMI、LDAP、DNS，肾上腺素拉满，这仨都可以配合JNDI注入进行(lookup)漏洞利用攻击。所以这也就是为啥有很多攻击方式为：JNDI+RMI、JNDI+LDAP、JNDI+DNS，最具杀伤力的自然是rmi和ldap协议，能够远程绑定对象执行代码。（这里别蒙圈，知道这俩协议配合JNDI能够远程执行代码即可）

通常测试是否存在JNDI注入漏洞的话可以先用DNS探测一下是否有回显，有的话才好进行下一步的攻击。
还有一个公共对象请求代理体系结构（CORBA）

透过Weblogic漏洞深入理解

该漏洞为：Weblogic未授权远程代码执行漏洞(CVE-2023-21839)

下面的源码分析都围绕23年Weblogic的一个未授权远程代码执行漏洞来解释怎么RMI和LDAP攻击，这也是为啥我不满意网上大部分文章的原因，没有结合一个具体的漏洞去解释这俩协议。
(纯属个人观点，毕竟还是参考了很多大佬文章的，各位道友轻点喷)

漏洞原理
假如你不理解下面要概括的漏洞原理的话那就也莫慌，你只需要知道最终触发的还是lookup函数即可，上面的解释就是为了你在朋友面前装13的而已，显得你很牛13。
漏洞可以概括为：因为weblogic支持t3和iiop协议绑定远程对象，然后绑定的远程对象是ForeignOpaqueReferent的话，客户端通过jndi查询的时候，服务端其实是调用了远程对象的getRefernet函数进行实例化，然后在这个函数里面进行了lookup查找，查找的是remoteJNDIName，这个就是漏洞点，我们可以通过反射机制修改这个remoteJNDIName，也就是说可以控制使用rmi或者ldap协议进行远程执行代码。

注：！！！补充，这个weblogic漏洞是你绑定对象后主动的进行lookup查询，然后让后台触发了你绑定的类然后他又去触发了lookup执行了你的恶意payload。

RMI与LDAP的区别

RMI和LDAP的区别其实就是安全限制有最大的不同，两个协议用起来都是需要加载恶意类到本地执行命令。
(区别就是：RMI/LDAP远程对象引用安全限制存在差异)

参考文章：
https://myzxcg.com/2021/10/Java-JNDI分析与利用/#jndi-目录服务

↓↓↓↓↓↓里面有写一段，解决了我的对两个协议的疑惑：↓↓↓↓↓↓

RMI
在RMI服务中引用远程对象将受本地Java环境限制，本地的java.rmi.server.useCodebaseOnly配置如果为true(禁止引用远程对象)，为false则允许加载远程类文件。

除此之外被引用的ObjectFactory对象还将受到com.sun.jndi.rmi.object.trustURLCodebase配置限制，如果该值为false(不信任远程引用对象)，一样无法调用远程的引用对象。

JDK5u45、JDK6u45、JDK7u21、JDK8u121开始，java.rmi.server.useCodebaseOnly默认值改为了true。

JDK6u132、JDK7u122、JDK8u113开始com.sun.jndi.rmi.object.trustURLCodebase默认值改为了 false。
本地测试远程对象引用可以使用如下方式允许加载远程的引用对象
System.setProperty("java.rmi.server.useCodebaseOnly", "false");
System.setProperty("com.sun.jndi.rmi.object.trustURLCodebase", "true");

LDAP
LDAP也在JDK6u211、7u201、8u191、11.0.1后将com.sun.jndi.ldap.object.trustURLCodebase的默认设置为了false。（但不受java.rmi.server.useCodebaseOnly影响）

JNDI+RMI

如果你看懂了上面的并且觉得够了且已经理解了，那么就无需看下面分析了，因为这里我写的原因就是因为不相信别人说的，我才希望真正看到是不是真的能够进行JNDI注入lookup进行攻击。

Weblogic未授权远程代码执行(CVE-2023-21839)的源码分析，使用RMI攻击。
分析前要记住一点：Weblogic t3/iiop协议支持远程绑定对象bind到服务端
- 允许绑定对象这一点很重要，既然允许绑定对象，那么我们就需要找一个能够触发lookup且变量可控的类去绑定，这样我们才能够实现JNDI注入攻击。
巧的是：当远程对象继承自OpaqueReference时，lookup查看远程对象，查询的变量是remoteJNDIName(可通过反射机制控制)。
这里又发现一篇文章写得不错，我参考了一二：https://g1asssy.com/2024/01/31/CVE_2024_20931/
↓↓↓↓↓↓其中有一段解释的很好↓↓↓↓↓↓
利用步骤大致分为三步:
1. 建立一个恶意ForeignOpaqueReference对象，并将remoteJNDIName设置为远程恶意JNDI服务。
2. 通过T3 \ IIOP协议在WLS上绑定该恶意对象。
3. 通过lookup查询该恶意对象，触发ForeignOpaqueReference.getReferent的调用，从而造成恶意JNDI注入。
通过lookup查询该恶意对象：这句话意思是你绑定服务器端后能够在poc中自己决定是否拿着这个类去lookup触发，这也就是为啥我选weblogic这个漏洞来解释的原因，他的poc就是你自己来决定绑定后是否进行lookup攻击的，很直接了当告诉你就是lookup触发的，别不信，你自己决定是否lookup攻击。
注：！！！我还要再次补充就是，这个weblogic漏洞是你绑定对象后主动的进行lookup查询，然后让后台触发了你绑定的类然后他又去触发了lookup执行了你的恶意payload。

漏洞代码触发链

参考文章：https://xz.aliyun.com/t/12297
下图为：ForeignOpaqueReference的父类OpaqueReference，可以看到里面存在getReferent函数，这个函数跟进去就有触发lookup。
在这里插入图片描述
跟进getReferent，你看我框住的就行，你会发现我们只要满足下面两点：

jndiEnvironment不为空，就能初始化好我们的var4。
控制remoteJNDIName变量就能够进行远程代码执行
(将值换成我们的RMI或者LDAP协议进行攻击)

然而以上的条件都可以通过编写脚本用反射机制拿到变量进行修改，说白了就是在lookup查询你绑定好的对象时，就会调用ForeignOpaqueReference.getReferent()，然后就去触发受害端后台的lookup，接着执行你控制好的remoteJNDIName，所以这里我们只要控制var4与this.remoteJNDIName就能造成jndi注入。

在这里插入图片描述
以下是RMI的漏洞攻击POC：
注明：本人没有测试poc是否成功，建议使用集成工具一键搭好攻击环境：
https://github.com/ugnoeyh/Log4shell_JNDIExploit

下面就老样子以前写过的攻击流程，建议看我之前的原文：https://mp.weixin.qq.com/s/jSLT3jNIiCRZXAeWE70GQw
接着就是开启攻击了，使用exp工具：https://github.com/ASkyeye/CVE-2023-21839
./CVE-2023-21839 -ip <weblogic服务器ip&g