作者:Hu3sky@360CERT
0x01 漏洞背景
2020年03月20日,Code White发现了影响Liferay Portal版本6.1、6.2、7.0、7.1和7.2的多个关键级别的JSON反序列化漏洞。它们允许通过JSON web服务API执行未经身份验证的远程代码。修复的Liferay Portal版本有6.2 GA6、7.0 GA7、7.1 GA4和7.2 GA2。
Liferay(又称Liferay Portal)是一个开源门户项目,该项目包含了一个完整的J2EE应用,以创建Web站点、内部网,以此来向适当的客户群显示符合他们的文档和应用程序。
对此,360CERT建议广大用户及时安装最新补丁,做好资产自查/自检/预防工作,以免遭受黑客攻击。
0x02 影响版本
- Liferay Portal: 6.1、6.2、7.0、7.1、7.2
0x03 漏洞详情
入口定位
首先对路由的调用进行分析,我们看到web.xml,url-pattern为/api/jsonws/*,对应的servlet-name如下。
然后看到servlet-name对应的servlet-class。
我们在service函数进行下断。
首先获取path,为/api/jsonws/之后的部分,由于我们请求的不是单纯的/api/jsonws,所以进入最下面else的部分,跟入super.service,也就是JSONServlet.service,跟入_jsonAction.execute。
调用getJson,即其子类JSONWebServiceServiceAction.getJson。
跟入getJSONWebServiceAction。
这里匹配到了invoke,即前面图中的第一种调用方式,return了一个实例化对象JSONWebServiceInvokerAction,传入request对象,继续跟入。
获取cmd参数,也就是api,左边的那一列名称。
这里我们api选择的是/expandocolumn/update-column。
不为null,于是赋值给JSONWebServiceInvokerAction对象的_command,回到getJSON,调用JSONWebServiceInvokerAction.invoke。
先调用JSONFactoryUtil.looseDeserialize处理_command。
会先调用getJSONFactory,返回之前初始化过的JSONFactoryImpl。
调用createJSONDeserializer返回JSONDeserializerImpl的实例。
调用parse解析_command。
调用parseValue,之后就是jodd-json的解析器解析流程了。处理command成一个hashmap。
回到invoke,this._parseStatement->setMethod,将command设置为_method,存入statement。
回到invoke,调用_executeStatement,传入statement。
JSONWebServiceActionsManagerUtil.getJSONWebServiceAction。
在collectAll函数里会把POST的参数赋值到jsonWebServiceActionParameters里,并存入上下文(com.liferay.portal.kernel.service.ServiceContext,里面有response,request对象相关,可以用来做回显)。
Parameters key的处理细节
在collectAll里还有一个细节,就是对参数的处理,在_collectFromRequestParameters。
这里会将key和value取出来put到_jsonWebServiceActionParameters这个map里,不过在调用put函数是,还会进一步处理key。
首先定位key里的:符号,然后去掉+/-符号,把:后面的部分赋值给typename,将key赋值成:符号前面的部分,这里就是defaultData。
接着判断在key里是否有.符号,如果有.后面的将被赋值为innerName,当然我们这里没有.,接着执行HashMap.put。
获取ActionConfig
之后调用_findJSONWebServiceAction,传入jsonWebServiceActionParameters,path,获取parameterNames,调用_getJSONWebServiceActionConfig。
获取相关config。
然后回到getJSONWebServiceAction,实例化JSONWebServiceActionImpl进行赋值。
回到_executeStatement,进入JSONWebServiceActionImpl.invoke,jsonRPCRequest变量为null,调用_invokeActionMethod。
调用_prepareParameters方法。
defaultData的处理(关键部分)
跳过了中间的coulmnId,name和type,直接看到defalutData。 parameterType是java.lang.Object,而parameterTypeName是之前从key的:后面部分提取出来的type,不为null,于是调用loadClass加载parameterTypeName。
接着调用ReflectUtil.isTypeOf进行检测,检查指定的类型是否扩展要调用的方法的相应参数的类型,因为这里父类是java.lang.Object,一切类都继承了java.lang.Object类,这就然后我们可以通过parameterTypeName调用任意类。
接着是对value的处理,这里value有值,于是调用_convertValueToParameterValue。
对parameterType进行类型判断,都不符合,于是进入else。
调用_convertType,跟到TypeConverterManagerBean.convertType。
会根据type去调用lookup函数寻找converter。
如果寻找不到,进入下面的else,都不符合的话,那么就会抛出错误,找不到该converter。
回到_convertType,进行catch,输入类型不为Map,继续返回。
在_convertValueToParameterValue中进行catch。
如果value是以{开头,就会进入下面的JSONFactoryUtil.looseDeserialize,传入parameterType和value。
jsonDeserializer.use函数会将我们的class赋值给rootType成员。
接着调用deserialize函数。
之后的内容就不深入分析了,大致列一下就行了。
类的实例化
类的实例化部分在jodd.json.JsonParserBase#newObjectInstance。
从deserialize开始的调用栈如下。
set方法调用
这里的setUserOverridesAsString方法是在我们传入的WrapperConnectionPoolDataSource方法的父类里进行调用的。 jodd.introspector.MethodDescriptor#invokeSetter
从deserialize开始的调用栈。
漏洞利用
出网回显
不出网回显
0x04 时间线
2020-03-20 漏洞细节被公开
2020-04-26 360-CERT 发布分析
发表评论
您还未登录,请先登录。
登录