Apache Dubbo漏洞CVE-2020-1948分析-安全客

作者：银河安全实验室

0x01 简述

Dubbo是阿里巴巴一种开源的RPC服务框架，常被用来做分布式服务远程对象的调用，日前Dubbo被发现有CVE-2020-1948的远程代码执行漏洞，官方针对这一漏洞发布了新版本Dubbo2.7.7，对源码分析发现修复方式并不能阻止CVE-2020-1948漏洞利用。

0x02 补丁分析

针对爆发漏洞时间节点的commit记录发现，官方对传入参数做了类型的校验，针对修复的commit记录，我们做了详细的分析。

2.1 时间线

Dubbo漏洞爆发的时间线如下图所示：

2.2 修复代码分析

对提交修复的commit代码分析发现在DecodeableRpcInvocation中增加了输入参数类型的校验。Commits记录截图如下图所示：

点开查看代码，在原有的基础上增加了参数类型的校验，补丁代码如下图所示：

这里的parameterTypes是限制为Ljava/lang/String;[Ljava/lang/String;[Ljava/lang/Object;，如下图所示；

本次poc传入的参数类型为Class<?>类型。类路径为Class<?>class com.rometools.rome.feed.impl.ToStringBean类，如果对参数检查是可以有效阻止漏洞的利用，然而修复错了地方。

从git的commit记录来看，官方的修复思路推测是想在异常抛出前利用参数类型的校验并拦截，防止引用的toString()方法造成代码执行。

但是拦截错了地方，通过对源码的单步调试发现，此处抛出的异常并不在漏洞触发的调用链上，具体的漏洞分析可见下文。

0x03 漏洞分析

CVE-2020-1948远程代码执行漏洞原理是远程方法被动态调用导致的代码执行。

下文将会对本次漏洞利用方式和触发原理进行分析，因为本次代码执行漏洞触发原理与Java的反射机制相关，下文将简单阐述Java的反射机制。

3.1 Java 反射机制

Java的反射机制是指在程序的运行状态中，程序对于任意一个类都能知道这个类的所有属性和方法；对于任意一个对象，都能调用它的任意一个属性和方法；这种动态的信息获取和调用机制被称为Java的反射机制。

Dubbo本次的漏洞触发原理就是toStringBean类内部动态调用外部传入对象的方法导致的代码执行。在研究漏洞的触发前，需要先简单了解为什么toStringBean类会在代码中动态调用外部对象的方法。

3.2 toStringBean类初探

ToStringBean类是一个可以被序列化的公共类，可以将对象的类型和方法转成字符串供调用。

在ToStringBean实现的toString方法中，会遍历传入对象的所有方法（Method对象），并且通过java实现的invoke方法动态调用传入对象的所有Method对象。

toString实现方法如下图所示：

3.3 漏洞触发点

漏洞触发点在com.rometools.rome.feed.impl.ToStringBean类的toString方法中，toString方法中的getter.invoke(obj, NO_PARAMS);语句，如下图所示：

上图是动态运行中的调试截图，可以从图中看出obj参数的值为JdbcRowSetImpl类的实例化对象，当此处for循环执行到JdbcRowSetImpl类中getDatabaseMetData函数时候，会调用函数内connect方法，导致执行JdbcRowSetImpl的执行链，导致代码执行。

3.4 ToStringBean的调用链跟踪

一个正常的dubbo的服务调用，当找不到注册的service的时候会抛出异常，抛出异常的截图如下图所示：

这个inv是DecodeableRpcInvocation的实例化对象。上述红箭头中的+ inv语法会默认调用inv实例化对象的toString()方法，DecodeableRpcInvocation的toString()方法实现在父类Rpcinvocation中，跟进查看Rpcinvocation.java中的toString方法，截图如下：

上图中的argements方法根据右边的变量调试信息显示，实际上就是ToStringBean类的实例化对象，其中该对象有两个参数，beanClass是Class<?>类型，obj是Object类型，此时的调用栈显示obj是JdbcRowSetImpl实例化对象，beanClass是Class.ForName(“com.sun.rowset.JdbcRowSetImpl”)对象。Array.toString(Object[] obj)方法，将会在底层调用String.valueOf(Objectobj)，此时这个obj对象是带有恶意负载的argements对象，继续往下跟踪Array.toString将argements向下执行，Array.toString(Object[] obj)方法如下图所示：

上图中可以发现传入的对象最后会经过String.valueOf转变为字符串储存在b变量里，继续往下跟踪，在String.valueOf方法中，当传入对象为toStringBean的时候，会调用toStringBean对象的toString()方法，String.valueOf方法如下图所示：

当进入ToStringBean的toString()方法的时候，如之前漏洞触发点所陈述，携带有恶意负载的对象，将会被执行恶意代码。由此我们清楚的看到了调用链，如下：

throw new RemotingException ->RpcInvocation.toString()->Arrays.toString()->String.valueOf()->toStringBean.toString()->getter.invoke(obj,NO_PARAMS)

最终在ToStringBean的toString()方法中Invoke动态调用对象造成代码执行。

3.5 缓解措施

一、内网服务

1、服务器防火墙添加内网IP白名单策略。

2、限制服务器的公网权限。

3、Dubbo-RPC基于TCP实现，并且当前Poc基于LDAP实现JNDI，因此可以在防火墙封禁掉dubbo服务端口的恶意TCP数据包。

二、外网服务

1、漏洞被利用的类在rome-{version}.jar包中，公网服务可以考虑自查是否引用了rome-{version}.jar包，如果引用了可以考虑重写toString()方法，重新编译并加载到生产环境。

2、服务器防火墙添加IP白名单策略。

三、流量设备类监控

1、在流量检测设备上可以增加检测规则，通过分析发现流量中可能会包含以下危险类的关键字（如：org.apache.xbean.naming.context.ContextUtil.ReadOnlyBinding,org.springframework.aop.support.DefaultBeanFactoryPointcutAdvisor,com.rometools.rome.feed, com.caucho.naming.QName, com.rometools.rome.feed.impl.ToStringBean等）。

下图是复现过程中的流量抓包：