JAVA JNDI注入知识详解

一、前言

在漏洞挖掘或利用的时候经常会遇见JNDI,本文会讲述什么是JNDI、JNDI中RMI的利用、LDAP的利用、JDK 8u191之后的利用方式。

二、JNDI简介

JNDI(The Java Naming and Directory Interface,Java命名和目录接口)是一组在Java应用中访问命名和目录服务的API,命名服务将名称和对象联系起来,使得我们可以用名称访问对象。

这些命名/目录服务提供者:

  • RMI (JAVA远程方法调用)
  • LDAP (轻量级目录访问协议)
  • CORBA (公共对象请求代理体系结构)
  • DNS (域名服务)

JNDI客户端调用方式

这里的jndiName变量的值可以是上面的命名/目录服务列表里面的值,如果JNDI名称可控的话可能会被攻击。

三、JNDI利用方式

RMI的利用

RMI是Java远程方法调用,是Java编程语言里,一种用于实现远程过程调用的应用程序编程接口。它使客户机上运行的程序可以调用远程服务器上的对象。

攻击者代码

用web服务器来加载字节码,保存下面的这个java文件,用javac编译成.class字节码文件,在上传到web服务器上面。

被攻击者代码

我这里使用jdk1.8.0_102版本运行之后,/tmp/目录下四个文件都会被创建,DEBUG看下原因。

javax.naming.InitialContext#getURLOrDefaultInitCtx

6

343行getURLScheme方法解析协议名称,在345行NamingManager.getURLContext方法返回解析对应协议的对象

com.sun.jndi.toolkit.url.GenericURLContext#lookup

7

com.sun.jndi.rmi.registry.RegistryContext#lookup

8

这里会去RMI注册中心寻找hello对象,接着看下当前类的decodeObject方法

9

因为ReferenceWrapper对象实现了RemoteReference接口,所以会调用getReference方法会获取Reference对象

javax.naming.spi.NamingManager#getObjectFactoryFromReference

2

146行尝试从本地CLASSPATH获取该class,158行根据factoryName和codebase加载远程的class,跟进看下158行loadClass方法的实现

com.sun.naming.internal.VersionHelper12#loadClass

这里是通过URLClassLoader去加载远程类,此时观察web服务器日志会发现一条请求记录

5

因为static在类加载的时候就会执行,所以这里会执行touch /tmp/Calc1命令,ls查看下.

10

javax.naming.spi.NamingManager#getObjectFactoryFromReference163行执行clas.newInstance()的时候,代码块和无参构造方法都会执行,此时Calc2Calc3文件都会创建成功,ls看下

11

javax.naming.spi.NamingManager#getObjectInstance

12

321行会调用getObjectInstance方法,此时Calc4文件会被创建,ls看下

13

列下调用栈

这里总结下,加载远程类的时候static静态代码块,代码块,无参构造函数和getObjectInstance方法都会被调用.

我把jdk换成1.8.0_181版本看下

直接运行会提示这样的一个错误

14

看下com.sun.jndi.rmi.registry.RegistryContext.decodeObject代码

15

354行var8是Reference对象,getFactoryClassLocation()方法是获取classFactoryLocation地址,这两个都不等于null,后面的trustURLCodebase取反,看下trustURLCodebase变量值

16

在当前类静态代码块定义了trustURLCodebase的值为false,那么这一个条件也成立,所以会抛出错误。

在jdk8u121 7u131 6u141版本开始默认com.sun.jndi.rmi.object.trustURLCodebase设置为false,rmi加载远程的字节码不会执行成功。

LDAP的利用

LDAP是基于X.500标准的轻量级目录访问协议,目录是一个为查询、浏览和搜索而优化的数据库,它成树状结构组织数据,类似文件目录一样。

攻击者代码

先下载https://mvnrepository.com/artifact/com.unboundid/unboundid-ldapsdk/3.1.1 LDAP SDK依赖,然后启动LDAP服务

这里还是用上面RMI那里的web服务器来加载字节码

被攻击者代码

这里使用jdk1.8.0_181版本运行之后,/tmp/目录下四个文件都会被创建,调用的过程和JNDI RMI那块一样的,先解析协议,获取ldap协议的对象,寻找Reference中的factoryName对象,先尝试本地加载这个类,本地没有这个类用URLClassLoader远程进行加载…

列下调用栈

把JDK换成1.8.0_241版本运行看下,会发现/tmp/目录下的文件并没有创建成功,DEBUG看下.

com.sun.naming.internal.VersionHelper12#loadClass

17

101行判断了trustURLCodebase等于true才可以加载远程对象,而trustURLCodebase的默认值是false

18

在jdk11.0.18u1917u2016u211版本开始默认com.sun.jndi.ldap.object.trustURLCodebase设置为false,ldap加载远程的字节码不会执行成功。

8u191之后

使用本地的Reference Factory类

jdk8u191之后RMI和LDAP默认都不能从远程加载类,还是可以在RMI和LDAP中获取对象。在前面我们分析过javax.naming.spi.NamingManager#getObjectFactoryFromReference方法,会先从本地的CLASSPATH中寻找该类,如果没有才会去远程加载。之后会执行静态代码块、代码块、无参构造函数和getObjectInstance方法。那么只需要在攻击者本地CLASSPATH找到这个Reference Factory类并且在这四个地方其中一块能执行payload就可以了。Michael Stepankin师傅在tomcat中找到org.apache.naming.factory.BeanFactory#getObjectInstance来进行利用。

tomcat jar下载地址https://mvnrepository.com/artifact/org.apache.tomcat.embed/tomcat-embed-core/8.5.11

先看下poc

DEBUG看下漏洞原因

org.apache.naming.factory.BeanFactory#getObjectInstance

我在这个类上面加了一些注释,ELProcessor.eval()会对EL表达式进行处理,最后会执行。

使用序列化数据,触发本地Gadget

com.sun.jndi.ldap.Obj#decodeObject

19

这里可以看到在LDAP中数据可以是序列化对象也可以是Reference对象。如果是序列化对象会调用deserializeObject方法

com.sun.jndi.ldap.Obj#deserializeObject

20

该方法就是把byte用ObjectInputStream对数据进行反序列化还原。那么传输序列化对象的payload,客户端在这里就会进行触发.

改造下LDAP SERVER即可

调用链

 

四、总结

JNDI注入漏洞很常见,在fastjson/jackson中会调用getter/setter方法,如果在getter/setter方法中存在lookup方法并且参数可控就可以利用,可以看下jackson的黑名单https://github.com/FasterXML/jackson-databind/blob/master/src/main/java/com/fasterxml/jackson/databind/jsontype/impl/SubTypeValidator.java来学习哪些类可以拿来JNDI注入。在weblogic t3协议中基于序列化数据传输,那么会自动调用readObject方法,weblogic使用了Spring框架JtaTransactionManager类,这个类的readObject方法也存在JNDI注入调用链。

 

参考链接

https://www.veracode.com/blog/research/exploiting-jndi-injections-java

https://kingx.me/Restrictions-and-Bypass-of-JNDI-Manipulations-RCE.html

https://www.anquanke.com/post/id/201181

https://xz.aliyun.com/t/7264

https://xz.aliyun.com/t/6633

https://mp.weixin.qq.com/s/0LePKo8k7HDIjk9ci8dQtA

 

 

 

Written by