CNTA-2019-0014 wls9-async 反序列化 rce 分析
前言
漏洞编号：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，但是细看类成员函数的时候就只有俩：
handleFault 和 handleResult
从这个名字来看，属于已经结束处理流程了，正在处理异常和结果，这里稍微想了想如果是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
正文到此结束
热门推荐
相关文章
近期评论
-
文章和留言都翻到11页了 没有OOM
-
-
朋友，翻页到11页，及以后，会出现OOM，无法访问
-
-
搞个gitee的项目
-
-
版本号是多少，你可以下载哪个代码仓库，jdk选1.8 直接跑就行
-
-
-
Loading...
![[HBLOG]公众号](https://www.liuhaihua.cn/img/qrcode_gzh.jpg)
