您好,登录后才能下订单哦!
本篇文章给大家分享的是有关如何实现Apache Ofbiz 反序列化漏洞CVE-2020-9496分析,小编觉得挺实用的,因此分享给大家学习,希望大家阅读完这篇文章后可以有所收获,话不多说,跟着小编一起来看看吧。
2020年09月29日, 360CERT对Apache ofbiz
组件的反序列化漏洞进行了分析,该漏洞编号为 CVE-2020-9496
,漏洞等级:高危
,漏洞评分:8.0
。
Apache ofbiz
存在 反序列化漏洞
,攻击者
通过 访问未授权接口,构造特定的xmlrpc http请求
,可以造成 远程代码执行的影响
。
360CERT对该漏洞的评定结果如下
评定方式 | 等级 |
---|---|
威胁等级 | 高危 |
影响面 | 一般 |
360CERT评分 | 8.0分 |
- Apache Ofbiz:< 17.12.04
XML-RPC
是一种远程过程调用(RPC
)协议,它使用XML
对其调用进行编码,并使用HTTP
作为传输机制。它是一种规范和一组实现,允许软件运行在不同的操作系统上,运行在不同的环境中,通过Internet
进行过程调用。在XML-RPC
中,客户端通过向实现XML-RPC
并接收HTTP
响应的服务器发送HTTP
请求来执行RPC
。
客户端
package org.apache.xmlrpc.demo.client;
import java.net.URL;
import org.apache.xmlrpc.client.XmlRpcClient;
import org.apache.xmlrpc.client.XmlRpcClientConfigImpl;
import org.apache.xmlrpc.client.XmlRpcSunHttpTransportFactory;
public class Client {
public static void main(String[] args) throws Exception {
// 创建客户端实例
XmlRpcClientConfigImpl config = new XmlRpcClientConfigImpl();
config.setServerURL(new URL("http://127.0.0.1:8081/xmlrpc"));
XmlRpcClient client = new XmlRpcClient();
client.setConfig(config);
// 设置传输工厂类
client.setTransportFactory(new XmlRpcSunHttpTransportFactory(client));
// 创建远程方法的参数数组,通过指定远程方法名称进行调用
Object[] params = new Object[]{new Integer(33), new Integer(9)};
Integer result = (Integer) client.execute("Calculator.add", params);
System.out.println(result);
}
}
或者客户端使用动态代理的方式,通过ClientFactory
,需要客户端和服务端都要有Adder
的接口,具体实现类在服务端。
但要使用XML-RPC
的动态代理功能,相应的服务器端的处理器类名称必须是Client
端接口类的全名(含包名,该名称一般应该与Server
端接口类全名一致),否则将会导致调用失败。
public class Client_Proxy {
public static void main(String[] args) throws MalformedURLException {
XmlRpcClientConfigImpl config = new XmlRpcClientConfigImpl();
config.setServerURL(new URL("http://127.0.0.1:8081/xmlrpc"));
XmlRpcClient client = new XmlRpcClient();
client.setConfig(config);
ClientFactory factory = new ClientFactory(client);
Adder adder = (Adder) factory.newInstance(Adder.class);
int sum = adder.add(2, 4);
System.out.println(sum);
}
}
Adder接口
package org.apache.xmlrpc.demo.proxy;
public interface Adder {
public int add(int pNum1, int pNum2);
}
服务端
package org.apache.xmlrpc.demo.webserver;
import org.apache.xmlrpc.server.PropertyHandlerMapping;
import org.apache.xmlrpc.server.XmlRpcServer;
import org.apache.xmlrpc.server.XmlRpcServerConfigImpl;
import org.apache.xmlrpc.webserver.WebServer;
public class Server {
private static final int port = 8081;
public static void main(String[] args) throws Exception {
WebServer webServer = new WebServer(port);
XmlRpcServer xmlRpcServer = webServer.getXmlRpcServer();
PropertyHandlerMapping phm = new PropertyHandlerMapping();
/* Load handler definitions from a property file.
* The property file might look like:
* Calculator=org.apache.xmlrpc.demo.Calculator
* org.apache.xmlrpc.demo.proxy.Adder=org.apache.xmlrpc.demo.proxy.AdderImpl
*/
phm.load(Thread.currentThread().getContextClassLoader(),
"MyHandlers.properties");
/* You may also provide the handler classes directly,
* like this:
* phm.addHandler("Calculator",
* org.apache.xmlrpc.demo.Calculator.class);
* phm.addHandler(org.apache.xmlrpc.demo.proxy.Adder.class.getName(),
* org.apache.xmlrpc.demo.proxy.AdderImpl.class);
*/
phm.addHandler("Calculator",
org.apache.xmlrpc.demo.Calculator.class);
xmlRpcServer.setHandlerMapping(phm);
XmlRpcServerConfigImpl serverConfig =
(XmlRpcServerConfigImpl) xmlRpcServer.getConfig();
serverConfig.setEnabledForExtensions(true);
serverConfig.setContentLengthOptional(false);
webServer.start();
}
}
服务端调用类
package org.apache.xmlrpc.demo;
public class Calculator {
public int add(int i1, int i2) {
return i1 + i2;
}
public int subtract(int i1, int i2) {
return i1 - i2;
}
}
在服务端还需要创建一个MyHandlers.properties
。
启动服务端之后,运行客户端。
抓取流量。动态代理和普通的流量都是一样的。
客户端向/xmlrpc
发了一个POST
请求,请求的内容为:
<?xml version="1.0" encoding="UTF-8"?>
<methodCall>
<methodName>Calculator.add</methodName>
<params><param>
<value>
<i4>33</i4>
</value>
</param><param>
<value>
<i4>9</i4>
</value>
</param></params>
</methodCall>
每个XML-RPC
请求都以XML
元素<methodCall> </methodCall>
开头。该元素包含单个子元素<methodName>xxx</methodName>
。元素<methodName>
包含子元素<params>
,该子元素可以包含一个或多个<param>
元素。 param XML
元素可以包含许多数据类型。
服务端响应的内容为
<?xml version="1.0" encoding="UTF-8"?>
<methodResponse xmlns:ex="http://ws.apache.org/xmlrpc/namespaces/extensions">
<params><param>
<value>
<i4>42</i4>
</value>
</param></params>
</methodResponse>
注:`ofbiz 17.12.03`版本的`commons-beanutils`依赖版本是`1.9.3`
在第一次加载ControlServlet
的时候,会调用init
进行初始化,此时会通过getRequestHandler
来初始化RequestHandler
。
调用getControllerConfigURL
方法,
该方法从配置文件/WEB-INF/controller.xml
中获取定义好的请求映射的列表,这里会遍历所有webapp
的controller.xml
配置文件。
其中,定义xmlrpc
的配置,没有设置对应的auth
选项,默认为false
,不需要身份验证,这也是之后修复的一个点。
<request-map uri="xmlrpc" track-serverhit="false" track-visit="false">
<security https="false"/>
<event type="xmlrpc"/>
<response name="error" type="none"/>
<response name="success" type="none"/>
</request-map>
官方文档给出的配置文件的tag
:
然后实例化ViewFactory
和EventFactory
。
先看实例化ViewFactory
,会根据配置文件里的type
是view
属性中对应的值,遍历出所需要的Viewerhandler
,并且进行init
初始化。然后存入map
。
webtools
下的配置文件就存在9
中type
。
接着实例化EventFactory
,同样遍历出type
是event
的EventHandler
,并进行init
初始化,然后存入map
。
然后把所有初始化的设置到servletContext
里。
根据公开的zdi
文章,xml
的执行是在webtools/control/xmlrpc
,于是去/webtools/webapp/webtools/WEB-INF/web.xml
中查看相关路由的处理。
<servlet-mapping>
<servlet-name>ControlServlet</servlet-name>
<url-pattern>/control/*</url-pattern>
</servlet-mapping>
请求/control
下的资源都由ControlServlet
来进行处理,是所有请求处理的核心。post
请求也会由ControlServlet#doGet
方法进行处理:
首先,调用getRequestHandler
,因为已经初始化了,所以能够直接获取到。
接着往下走,是处理request
请求的一些东西,然后调用requestHandler.doRequest
方法 根据request
请求获取当前请求的appname
,这里是webtools
,然后获取pathinfo
也就是xmlrpc
。
然后根据pathinfo
从config
里获取对应的配置,继续往下走,requestMap.event
也就是之前根据配置所获取到的xmlrpc
。
type
,path
,invoke
都不为null
,于是跟进runEvent
。根据type
从eventFactory
中获取eventhandler
,
然后调用eventHandler.invoke
,这里我们的echo
参数为null
,于是调用execute
方法。
跟入getRequest
方法。
前几行是在为SAX
解析做准备,设置了一个handler
为XmlRpcRequestParser
,结构如下:
主要的element
解析发生在XmlRpcRequestParser
里。
然后调用parse
函数,正式进入http xml
解析的流程。
这里xml
的解析主要采用SAX
方式解析。SAX
解析触发的事件有
startDocument:开始读取XML文档;
startElement:读取到了一个元素,例如<book>;
characters:读取到了字符;
endElement:读取到了一个结束的元素,例如</book>;
endDocument:读取XML文档结束。
整个scan
流程主要发生在XMLDocumentFragmentScannerImpl#dispatch
,之前的调用栈如下:
用fScannerState
用来标识当前该调用哪个方法来解析tag
。
刚开始解析的时候,state
为6
:
调用scanRootElementHook
,用于扫描根元素,Resolver
为null
,于是进入else
,
接着在AbstractSAXParser#startElement
,会调用ContentHandler.startElement
,这个content
是之前初始化的时候设置的,也就是XmlRpcRequestParser#startElement
方法。
在XmlRpcRequestParser#startElement
函数里,支持解析methodCall
,methodName
,params
,parma
,value
标签,如果不是,那么交给父类RecursiveTypeParserImpl
做进一步处理。
判断到methodName
会把inMethodName
设置为true
,之后,在dispatch
根据state
进入分支处理content
,然后会调用XmlRpcRequestParser#characters
,设置methodName
属性。
下一个标签是结束标签</methodName>
调用endElement
,将inMethodName
设置为false
。
如果解析到是value
里的子标签,那么会调用startValueTag
方法。
会设置inValueTag
属性为true
。
后续,比如在解析serializable
标签的时候,就会进入default
分支。
RecursiveTypeParserImpl#startElement
,刚开始typeParser
为null
。
在getParser
方法里会根据标签从TypeFactoryImpl
里去创建具体对应的Parser
,并且,想要拿到第一个判断里的扩展Parser
,还需要指定pURI
。
我们poc
里的value
里的xml
结构为:
<struct>
<member>
<name>test</name>
<value>
<serializable>
{base64codehere}
</serializable>
</value>
</member>
</struct>
于是首先实例化的是MapParser
,于是XmlRpcRequestParser
的typeParser
为MapParser
.
还是先调用Parser.startDocument
,
接着调用其对应的startElement
方法。
判断struct
标签后,然后解析下一个标签member
重复之前的过程,XmlRpcRequestParser
解析不了,交给RecursiveTypeParserImpl
处理。但是此时typeParser
已经不为null
,于是直接调用MapParser#startElement
进行处理。
中间其他tag
省略了,注意serializable
标签之前还有一个value
标签,但是不在XmlRpcRequestParser
处理,因为此时level
已经很大了,直接看到MapParser
对value
的处理
调用startValueTag
,重新将typeParser
设置为null
,但是这里设置的是MapParser
的typeParser
,这一步很关键,typeParser
为null
才能重新获取parser
。
在解析serializable
的时候,XmlRpcRequestParser
的typeParser
依然是MapParser
,但是在MapParser
里处理不了serializable
标签,此时再交给RecursiveTypeParserImpl
,这时获取到的就是MapParser
的typeParser
,因为之前被设置为null
,所以重新获取Parser
,而这时解析到serializable
标签,于是getParser
返回为SerializableParser
。
SerializableParser
继承ByteArrayParser
,没有startElement
方法,于是调用父类ByteArrayParser
,设置OutputStream
,且解码输入流。
接着处理</serializable>
在Serializable#endElement
,setResult
给result
赋值。
接着是处理</value>
,在MapParser#endElement
。
跟入endValueTag
,typeParser
为Serializable
。
调用getResult
,取出result
并造成反序列化。
Fixed: Apache OFBiz unsafe deserialization of XMLRPC arguments
https://github.com/apache/ofbiz-framework/commit/4bdfb54ffb6e05215dd826ca2902c3e31420287a#diff-b31806fbf9690361ad449e8f263345d8
直接在controller.xml
配置xmlrpc
需要授权访问。
xmlrpc
本身是支持对序列化数据的反序列化的,而问题就出现在ofbiz
没有对xmlrpc
接口的访问做权限的控制,同时版本较低的情况下又存在能够被反序列化所利用的依赖。
以上就是如何实现Apache Ofbiz 反序列化漏洞CVE-2020-9496分析,小编相信有部分知识点可能是我们日常工作会见到或用到的。希望你能通过这篇文章学到更多知识。更多详情敬请关注亿速云行业资讯频道。
免责声明:本站发布的内容(图片、视频和文字)以原创、转载和分享为主,文章观点不代表本网站立场,如果涉及侵权请联系站长邮箱:is@yisu.com进行举报,并提供相关证据,一经查实,将立刻删除涉嫌侵权内容。