Adminxe's Blog | 低调求发展 - 潜心习安全 ,技术永无止境 | 谢谢您对本站的支持,有什么问题或者建议请及时联系:点击这里给我发消息

CVE-2019-17564 Apache dubbo HTTP协议反序列化漏洞分析

漏洞复现 Adminxe 3713℃ 0评论

0x01 漏洞描述

Apache dubbo是一个是基于Java的高性能开源RPC框架。它支持dubbo,http,rmi,hessian等协议。本次问题出现在dubbo开启http协议后,会将消费者提交的request请求,在无安全校验的情况下直接交给了spring-web.jar进行处理,最终request.getInputStream()被反序列化,故存在反序列化漏洞。下面我们来调试分析代码。

0x02 影响范围

  • 2.7.0 <= Apache Dubbo <= 2.7.4
  • 2.6.0 <= Apache Dubbo <= 2.6.7
  • Apache Dubbo = 2.5.x

0x03 环境搭建

  • OS: Mac OSX
  • JDK: 1.8.0_191
  • Dubbo: 2.7.3

环境搭建这里我选择官方的samples中的dubbo-samples-http

https://github.com/apache/dubbo-samples/

源码下载后将pom.xml中指定的dubbo版本修改为2.7.3,同时加入commons-collections4-4.0.jar方便测试。

<properties>
    <source.level>1.8</source.level>
    <target.level>1.8</target.level>
    <!-- 修改dubbo版本为2.7.3 -->
    <dubbo.version>2.7.3</dubbo.version>
    <spring.version>4.3.16.RELEASE</spring.version>
    <junit.version>4.12</junit.version>
    ...
    <!-- 添加一个可用的Gadget到classpath -->
    <dependencies>
        ...
        <dependency>
            <groupId>org.apache.commons</groupId>
            <artifactId>commons-collections4</artifactId>
            <version>4.0</version>
        </dependency>
    </dependencies>

同时dubbo依赖zookeeper,请自行安装!

0x04 漏洞分析

dubbo启用http协议后,所有的请求都会通过org.apache.dubbo.rpc.protocol.http.HttpProtocol$InternalHandler类的handle方法进行处理。我们在这打断点,并发送poc开始跟踪分析。

首先handle方法会获取请求路径,然后通过这个路径去skeletonMap里获取到该接口对应的处理对象,来处理当前request请求。

//org.apache.dubbo.rpc.protocol.http.HttpProtocol$InternalHandler
public void handle(HttpServletRequest request, HttpServletResponse response) throws IOException, ServletException {
    // 1. 获取请求的路径(/org.apache.dubbo.samples.http.api.DemoService)
    String uri = request.getRequestURI();
    // 2. 通过请求的接口路径获取对应的处理对象
    HttpInvokerServiceExporter skeleton = (HttpInvokerServiceExporter)HttpProtocol.this.skeletonMap.get(uri);
    if (!request.getMethod().equalsIgnoreCase("POST")) {
        response.setStatus(500);
    } else {
        RpcContext.getContext().setRemoteAddress(request.getRemoteAddr(), request.getRemotePort());
        try {
            // 3. 使用获取到的处理对象进行处理请求
            skeleton.handleRequest(request, response);
        } catch (Throwable var6) {
            throw new ServletException(var6);
        }
    }
} 

第二步中存储接口地址和处理对象的skeletonMap

skeletonMap存储内容

处理对象是HttpInvokerServiceExporter类对象,它负责获取远程调用对象,并执行获取结果返回给客户端。跟进它的handleRequest方法,request对象被传入readRemoteInvocation方法中来获取RemoteInvocation远程调用对象

//org.springframework.remoting.httpinvoker.HttpInvokerServiceExporter
public void handleRequest(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
    try {
    	// 1. 从request对象获取远程调用对象
        RemoteInvocation invocation = this.readRemoteInvocation(request);
        RemoteInvocationResult result = this.invokeAndCreateResult(invocation, this.getProxy());
        this.writeRemoteInvocationResult(request, response, result);
    } catch (ClassNotFoundException var5) {
        throw new NestedServletException("Class not found during deserialization", var5);
    }
}

readRemoteInvocation方法将request.getInputStream()(我们提交的序列化内容)传入createObjectInputStream方法,封装为一个ObjectInputStream。该对象又被传入doReadRemoteInvocation方法中,进行最终的获取操作。

//org.springframework.remoting.httpinvoker.HttpInvokerServiceExporter
protected RemoteInvocation readRemoteInvocation(HttpServletRequest request) throws IOException, ClassNotFoundException {
    // 1. 传入request对象和request.getInputStream()
    return this.readRemoteInvocation(request, request.getInputStream());
}

protected RemoteInvocation readRemoteInvocation(HttpServletRequest request, InputStream is) throws IOException, ClassNotFoundException {
    // 2. 将request.getInputStream()封装为ObjectInputStream
    ObjectInputStream ois = this.createObjectInputStream(this.decorateInputStream(request, is));

    RemoteInvocation var4;
    try {
        // 3. 获取RemoteInvocation远程调用对象
        var4 = this.doReadRemoteInvocation(ois);
    } finally {
        ois.close();
    }
    return var4;
}

doReadRemoteInvocation方法中,ObjectInputStream类对象ois直接被反序列化了。这个过程中没有进行任何过滤,导致我们传入的恶意序列化对象可以被反序列化创建,漏洞触发!

//org.springframework.remoting.rmi.org.springframework.remoting.rmi.RemoteInvocationSerializingExporter
protected RemoteInvocation doReadRemoteInvocation(ObjectInputStream ois) throws IOException, ClassNotFoundException {
// 1. 恶意对象在此被反序列化,漏洞触发
Object obj = ois.readObject();
if (!(obj instanceof RemoteInvocation)) {
throw new RemoteException("Deserialized object needs to be assignable to type [" + RemoteInvocation.class.getName() + "]: " + ClassUtils.getDescriptiveType(obj));
} else {
return (RemoteInvocation)obj;
}
}

0x05 漏洞修复

漏洞出现的原因dubboHTTP接口将携带有恶意反序列化数据的request,在无安全校验的情况下直接交给了spring-web.jarHttpInvokerServiceExporter进行处理,导致存在反序列化漏洞。按理说这个漏洞不仅仅只是dubbo自身的问题,还是spring的问题。

在2.7.4.1版本开始,dubbo处理HTTP接口的调用请求交给了jsonrpc4j.jarJsonRpcServer去处理了。

修复方式

跟踪分析JsonRpcServer类的handle方法后,request.getInputStream()没有再被反序列化了。所以原来的利用方法失效了。

0x06 漏洞总结

该漏洞利用虽然简单粗暴,但在黑盒情况下利用难点有两个,一是我们无法得知web服务是否是dubbo http接口。二是如何获取接口路径,该路径可以在服务器上的zookeeperhttp-provider配置文件中找到,如果不配合其他漏洞是不容易获取的。

0x07 参考文章

转载请注明:Adminxe's Blog » CVE-2019-17564 Apache dubbo HTTP协议反序列化漏洞分析

喜欢 (13)or分享 (0)
发表我的评论
取消评论
表情

Hi,您需要填写昵称和邮箱!

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址
(1)个小伙伴在吐槽
  1. 说实话我不愿意看你下边的分析 :mrgreen:
    170102020-09-29 16:25 回复