JNDI概念
JNDI(Java Naming and Directory Interface),即Java命名和目录空间。它提供统一的客户端API,为开发人员提供了查找和访问各种命名和目录服务的统一接口,Java程序可以和这些命名与目录服务之间进行交互,可以通过JNDI访问远程的url来获取对应的服务。
JNDI和RMI
1 | 1. RMI只是一种远程对象访问的接口规范,遵循此规范的对象可被远程访问,但是要使用rmi的服务注册程序注册之后才能够被远程调用。 |
JNDI注入的场景
1 | 1.rmi、通过jndi reference远程调用object方法 |
JNDI注入
需要注意的是
在JDK 6u132, JDK 7u122, JDK 8u113 中Java提升了JNDI 限制了Naming/Directory服务中JNDI Reference远程加载Object Factory类的特性。系统属性 com.sun.jndi.rmi.object.trustURLCodebase、com.sun.jndi.cosnaming.object.trustURLCodebase 的默认值变为false,即默认不允许从远程的Codebase加载Reference的工厂类(Factory Class)。如果需
要开启 RMI Registry 或者 COS Naming Service Provider的远程类加载功能,需要将前面说的两个属性值设置为true。
1 | System.setProperty("java.rmi.server.useCodebaseOnly", "false"); |
这里举的例子是RMI+JNDI Reference
Server端(攻击者)
1 | package JNDI; |
通过Reference
可以将访问对象放置在外部远程服务器上,此时攻击者只需要提供恶意的对象供客户端调用即可执行恶意类。
Client端(被攻击目标)
1 | package JNDI; |
如果这里lookup()
的URL可控,那么攻击者就能指定URL为恶意服务目标,从而访问加载远程恶意对象。
恶意Factory对象
1 | import javax.naming.Context; |
之所以选择getObjectInstance
并重写恶意代码执行的原因见下文。
将它放在Server端的Reference绑定的外部地址,作为恶意构造的factory
类。
攻击结果
先后启动server和client
当客户端调用lookup
获取远程类时,就会获取到Reference
对象,在绑定的地址上寻找指定的Factory
类,最终实例化并执行重写的方法。
调试分析
从客户端的lookup开始
getURLOrDefaultInitCtx
根据协议头来返回一个对应的Context对象,所以这里返回一个rmi的Context
接着再次进入lookup
方法
首先进行了getRootURLContext
方法,该方法对rmi地址进行解析,返回解析好的注册对象(包含地址、端口等信息)
对RegistryContext
进行lookup
调用
RegistryContext#lookup
针对刚才解析好的注册对象,再次进行lookup,作用是寻找刚才解析结果里的地址,也就是绑定在RMI上的地址,这里是t1
进入到RegistryImpl_Stub#lookup
该步最终返回的是ReferenceWrapper_Stub
对象
接着返回RegistryContext#lookup,调用到decodeObject()
方法
这个DecodeObject会对传入对象判断是否是RemoteReference类
(这就是在Server端我们为什么不直接用Reference,而是再套一层ReferenceWrapper的原因,只有这样才有继承Remote的条件)
然后再调用NamingManager.getObjectInstance()
NamingManager#getObjectInstance()
进入getObjectFactoryFromReference()
该函数对我们指定的codebase地址上的class进行加载,并且实例化并返回
接着对这个实例化的恶意对象进行getObjectInstance()
而这个getObjectInstance()
正是我们在构造的恶意中重写的方法,因此调用后就会执行我们构造的命令。
结尾
RMI只是作为JNDI注入的一种利用途径,还有其他的服务利用方法,例如LDAP等。并且针对JNDI还有各种各样的限制绕过手法需要学习,例如利用受害者本地classpath作为factory工厂等。
参考文章
https://www.cnblogs.com/nice0e3/p/13958047.html
https://www.cnblogs.com/tr1ple/p/11558842.html
https://www.cnblogs.com/zpchcbd/p/14941783.html
https://blog.csdn.net/weixin_39783633/article/details/111615464