前言

漏洞编号:CNTA-2019-0014
大致是因为 wls9_async_response 包有个啥反序列化,上一次同样类型的漏洞在17年,那时候还不知道weblogic,刚好论文结尾了来学习下漏洞原理

XmlDecoder 相关安全不在此篇文章中介绍,也莫得poc,仅仅分享分析思路和漏洞触发流程

高版本weblogic如12.2.1.2默认不会部署该war包,我的测试版本是10.3.6

调用链

BaseWSServlet#service
->
SoapProcessor#process
->
ServerDispatcher#dispatch
->
HandlerIterator#handleRequest
->
WorkAreaServerHandler#handleRequest
->
WorkContextMapInterceptor#receiveRequest
->
WorkContextXmlInputAdapter#readUTF
->
XMLDecoder#readObject

起手式

莫得poc,莫得漏洞详情,就一则安全通告说 wls9_async_response 有问题,那就先直接看war包啥情况

其实就四个class,而且路径全部指向 AsyncResponseBean ,查看一下内容如下:

路径已经指出来了 /_async/.. 全部指向此 Bean,但是细看类成员函数的时候就只有俩:
handleFaulthandleResult

从这个名字来看,属于已经结束处理流程了,正在处理异常和结果,这里稍微想了想如果是soap过去的反序列化的话,那应该是处理流程中触发漏洞,为了确认仔细看了下 handleFault 和 handleResult 函数,确实没有触发点,既没有反序列化点

从底层摸起

那么这就奇怪了,难道不是war包的问题?找一找处理流程,但是weblogic没有详细分析过不知道整个生命周期,只能从 HttpServlet 开始下断点,中间的迷障也太多了,先整理下已知信息:

包路径:weblogic.wsee.async
那么处理流程大概也会是 async 路径下或者 wsee 路径下处理的请求包

该漏洞多半是soap协议过去的xml反序列化

打了个 HttpServlet 处的断点,跟进了 weblogic.wsee 包下的基础 Servlet : BaseWSServlet

根据已知信息那必然在 soapProcessor 中,一直跟到了 web.wsee.ws.dispatch.server.ServerDispatcher 里面,注意如下:

责任链出来了,跟进去看看 HandlerIterator#handleRequest

责任链中轮询调用 handleRequest 处理。
看一看这个 HandlerIterator 中有哪些 Handler

如图一共有21个,其中最让我起疑的就是 AsyncResponseHandler 但是仔细看了以后发现没有过于特殊的地方,并且需要前置条件太多,也就是需要用户填写的信息过多,其中很多信息不一定是每个服务器上都一样的。排除它。

柳暗花明

既然是责任链调用,那么他会从 Handler 0 一直执行到 Handler 20,挨个查阅了后,发现大多是对环境的各种值做存取操作,并没有特殊的地方,但是 WorkAreaServerHandler 这个handler除外,跟进去看看

获取了一次header中的内容,这个header不是http header,是soap中的 http://schemas.xmlsoap.org/soap/envelope/ 内容里面的 Header,将其送入 WorkContextXmlInputAdapter 做初始化处理并且传入 receiveRequest 函数

跟进 receiveRequest 函数,如下:

跟进 readEntry 函数,如下:

这里调用了 WorkContextXmlInputAdapter 的 readUTF 函数,跟进,如下:

readObject 映入眼帘

分析流程结束

效果

尝试构造了一下poc,10.3.6 本地未加任何补丁,win10

点击收藏 | 0 关注 | 1
登录 后跟帖