CVE-2020-9496:Apache Ofbiz 反序列化漏洞分析

报告编号:B6-2020-092902html

报告来源:360CERTjava

报告做者:360CERTgit

更新日期:2020-09-29github

0x01 漏洞简述

2020年09月29日, 360CERT对Apache ofbiz组件的反序列化漏洞进行了分析,该漏洞编号为 CVE-2020-9496,漏洞等级:高危,漏洞评分:8.0web

Apache ofbiz 存在 反序列化漏洞攻击者 经过 访问未受权接口,构造特定的xmlrpc http请求,能够形成 远程代码执行的影响apache

0x02 风险等级

360CERT对该漏洞的评定结果以下数组

评定方式 等级
威胁等级 高危
影响面 通常
360CERT评分 8.0分

0x03 影响版本

- Apache Ofbiz:< 17.12.04安全

0x04 漏洞详情

XML-RPC

XML-RPC是一种远程过程调用(RPC)协议,它使用XML对其调用进行编码,并使用HTTP做为传输机制。它是一种规范和一组实现,容许软件运行在不一样的操做系统上,运行在不一样的环境中,经过Internet进行过程调用。在XML-RPC中,客户端经过向实现XML-RPC并接收HTTP响应的服务器发送HTTP请求来执行RPC服务器

Demo

客户端微信

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>

初始化RequestHandler

注:`ofbiz  17.12.03`版本的`commons-beanutils`依赖版本是`1.9.3`

在第一次加载ControlServlet的时候,会调用init进行初始化,此时会经过getRequestHandler来初始化RequestHandler

调用getControllerConfigURL方法,

该方法从配置文件/WEB-INF/controller.xml中获取定义好的请求映射的列表,这里会遍历全部webappcontroller.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

而后实例化ViewFactoryEventFactory

先看实例化ViewFactory,会根据配置文件里的typeview属性中对应的值,遍历出所须要的Viewerhandler,而且进行init初始化。而后存入map

webtools下的配置文件就存在9type

接着实例化EventFactory,一样遍历出typeeventEventHandler,并进行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

而后根据pathinfoconfig里获取对应的配置,继续往下走,requestMap.event也就是以前根据配置所获取到的xmlrpc

typepathinvoke都不为null,因而跟进runEvent。根据typeeventFactory中获取eventhandler

XmlRpcEventHandler的调用

而后调用eventHandler.invoke,这里咱们的echo参数为null,因而调用execute方法。

跟入getRequest方法。

前几行是在为SAX解析作准备,设置了一个handlerXmlRpcRequestParser,结构以下:

主要的element解析发生在XmlRpcRequestParser里。

而后调用parse函数,正式进入http xml解析的流程。

XML解析

这里xml的解析主要采用SAX方式解析。SAX解析触发的事件有

startDocument:开始读取XML文档;
startElement:读取到了一个元素,例如<book>;
characters:读取到了字符;
endElement:读取到了一个结束的元素,例如</book>;
endDocument:读取XML文档结束。

整个scan流程主要发生在XMLDocumentFragmentScannerImpl#dispatch,以前的调用栈以下:

fScannerState用来标识当前该调用哪一个方法来解析tag

刚开始解析的时候,state6

调用scanRootElementHook,用于扫描根元素,Resolvernull,因而进入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里标签的解析

若是解析到是value里的子标签,那么会调用startValueTag方法。

会设置inValueTag属性为true

后续,好比在解析serializable标签的时候,就会进入default分支。

RecursiveTypeParserImpl#startElement,刚开始typeParsernull

getParser方法里会根据标签从TypeFactoryImpl里去建立具体对应的Parser,而且,想要拿到第一个判断里的扩展Parser,还须要指定pURI

咱们poc里的value里的xml结构为:

<struct>
<member>
<name>test</name>
<value>
<serializable>
{base64codehere}
</serializable>
</value>
</member>
</struct>

因而首先实例化的是MapParser,因而XmlRpcRequestParsertypeParserMapParser.

仍是先调用Parser.startDocument

接着调用其对应的startElement方法。

判断struct标签后,而后解析下一个标签member

重复以前的过程,XmlRpcRequestParser解析不了,交给RecursiveTypeParserImpl处理。可是此时typeParser已经不为null,因而直接调用MapParser#startElement进行处理。

第二个value标签

中间其余tag省略了,注意serializable标签以前还有一个value标签,可是不在XmlRpcRequestParser处理,由于此时level已经很大了,直接看到MapParservalue的处理

调用startValueTag,从新将typeParser设置为null,可是这里设置的是MapParsertypeParser,这一步很关键,typeParsernull才能从新获取parser

serializable标签

在解析serializable的时候,XmlRpcRequestParsertypeParser依然是MapParser,可是在MapParser里处理不了serializable标签,此时再交给RecursiveTypeParserImpl,这时获取到的就是MapParsertypeParser,由于以前被设置为null,因此从新获取Parser,而这时解析到serializable标签,因而getParser返回为SerializableParser

SerializableParser继承ByteArrayParser,没有startElement方法,因而调用父类ByteArrayParser,设置OutputStream,且解码输入流。

接着处理</serializable>Serializable#endElementsetResultresult赋值。

接着是处理</value>,在MapParser#endElement

跟入endValueTag,typeParserSerializable

调用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接口的访问作权限的控制,同时版本较低的状况下又存在可以被反序列化所利用的依赖。

0x05 时间线

2020-09-29 360CERT发布分析

0x06 参考连接

一、 Index of /dist/ofbiz

https://archive.apache.org/dist/ofbiz/

二、 About Apache XML-RPC

https://ws.apache.org/xmlrpc/index.html

三、 How to migrate OFBiz from Derby to MySQL database

https://cwiki.apache.org/confluence/display/OFBIZ/How+to+migrate+OFBiz+from+Derby+to+MySQL+database

四、 Control Servlet Guide

https://cwiki.apache.org/confluence/display/OFBIZ/Control+Servlet+Guide

五、 Apache OFBiz XML-RPC Java Deserialization

https://packetstormsecurity.com/files/158887/Apache-OFBiz-XML-RPC-Java-Deserialization.html

推荐阅读:

一、安全事件周报 (09.21-09.27)

二、安全运营周刊第十期

三、CVE-2020-14386: Linux内核权限提高漏洞通告

长按下方二维码关注360CERT!谢谢你的关注!

注:360CERT官方网站提供 《CVE-2020-9496:Apache Ofbiz 反序列化漏洞分析》 完整详情,点击阅读原文

本文分享自微信公众号 - 三六零CERT(CERT-360)。
若有侵权,请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”,欢迎正在阅读的你也加入,一块儿分享。

相关文章
相关标签/搜索