CNVD-C-2019-48814 wls9-async 反序列化分析
首先，CNVD收录了由中国民生银行股份有限公司报送的Oracle WebLogic wls9-async反序列化远程命令执行漏洞（CNVD-C-2019-48814）。攻击者利用该漏洞，可在未授权的情况下远程执行命令。从相关信息来看。
部分版本WebLogic中默认包含的wls9_async_response包，为WebLogic Server提供异步通讯服务。由于该WAR包在反序列化处理输入信息时存在缺陷，攻击者可以发送精心构造的恶意 HTTP 请求，获得目标服务器的权限，在未授权的情况下远程执行命令。
也就是说漏洞出现在 wls9_async_response.war 这个包里面，来详细看一看。
0x02 wls9_async_response组件情况
首先先看一下 bea_wls9_async_response.war!/WEB-INF/web.xml 内容，我们发现这里的所有请求都是交给 weblogic.wsee.async.AsyncResponseBean 方法继续处理。
而在 bea_wls9_async_response.war!/WEB-INF/weblogic-webservices.xml 文件中，这里定义了目前流传的一些poc请求路径。
那这里需要跟进一下 weblogic.wsee.async.AsyncResponseBean 这个方法，这个方法的位置在 /weblogic.jar!/weblogic/wsee/async/AsyncResponseBean.class ，头部import的包如下所示：
import javax.jws.WebService; import javax.jws.soap.SOAPBinding; import javax.jws.soap.SOAPBinding.Style; import javax.jws.soap.SOAPBinding.Use; import javax.xml.rpc.JAXRPCException; import weblogic.jws.WLDeployment; import weblogic.jws.WLHttpTransport; import weblogic.jws.WLHttpsTransport; import weblogic.jws.WLJmsTransport; import weblogic.wsee.async.AsyncUtil.SavedServiceInfo; import weblogic.wsee.deploy.VersioningHelper; import weblogic.wsee.jws.container.Request; import weblogic.wsee.message.WlMessageContext; import weblogic.wsee.util.DirectInvokeUtil; import weblogic.wsee.util.Verbose; import weblogic.wsee.ws.WsSkel;
这里关注到了几个 soap 相关的包，从poc中可知触发原因应该是由 于 soap注入 引起的反序列化漏洞，但是在 AsyncResponseBean 中只有 handleFault 和 handleResult 方法。跟进这两个方法确实没有找到反序列化相关的触发点，然后实际上昨晚这里我卡壳了好久，因为看poc很像 CVE-2017-10271(XMLDecoder反序列化漏洞) ，然后早上起来就看到了这篇 《CNTA-2019-0014 wls9-async 反序列化 rce 分析 》 ，给我开阔了一个新思路。
0x03 新思路
在Servlet拦截器下个断点，
位置在weblogic.jar!/weblogic/wsee/server/servlet/BaseWSServlet.class，从前的import包中可知应该与soap有关系。
跟进一下 weblogic.jar!/weblogic/wsee/server/servlet/SoapProcessor.class
继续跟入 getMethod 方法，
跟到了 weblogic.jar!/weblogic/servlet/internal/ServletRequestImpl.class ，
public String getMethod() {
return this.inputHelper.getRequestParser().getMethod();
}
继续跟入 getRequestParser方法，
位置在weblogic.jar!/weblogic/servlet/internal/ServletRequestImpl.class
public HttpRequestParser getRequestParser() {
return this.parser;
}
上面都没啥用，继续step into又来到了 weblogic.wsee.server.servlet.SoapProcessor#process 中。
public boolean process(HttpServletRequest var1, HttpServletResponse var2, BaseWSServlet var3) throws IOException {
if ("POST".equalsIgnoreCase(var1.getMethod())) {
this.handlePost(var3, var1, var2);
return true;
} else {
return false;
}
}
然后一直跟进，跟进到
weblogic.jar!/weblogic/wsee/ws/dispatch/server/ServerDispatcher.class 的第85行
继续跟进到 weblogic.jar!/weblogic/wsee/ws/dispatch/server/ServerDispatcher.class 的第93行，跟进 handleRequest(weblogic.jar!/weblogic/wsee/handler/HandlerIterator.class) ，我在下面代码处下个断点。
Handler var4 = this.handlers.get(this.index)
这里有很多 handler ，最让我感兴趣的是 AsyncResponseHandler 。
但是随着我进一步的step into，我发现触发点并不是这里。
跟进到了 WorkAreaServerHandler 这个handler之后，我发现了新大陆。
WorkAreaServerHandler(weblogic.jar!/weblogic/wsee/workarea/WorkAreaServerHandler.class)，这里会从我们提交的poc中获取数据。
跟进一下 receiveRequest 方法，
位置在wlclient.jar!/weblogic/workarea/WorkContextLocalMap.class中。
继续跟进一下 readEntry ，
位置在wlclient.jar!/weblogic/workarea/spi/WorkContextEntryImpl.class中。
跟进一下 readUTF ，
位置在weblogic.jar!/weblogic/wsee/workarea/WorkContextXmlInputAdapter.class，嘿嘿嘿结果出来了。
public String readUTF() throws IOException {
return (String)this..readObject();
}
果然是 xmlDecoder 发序列化，我们在这里下一个断点，最后看一下调用链。
0x03 弹个计算器
不弹计算器都是刷流氓。
0x04 小结
这个漏洞藏的太深了，跟的过程中step into ，step over跟吐了，只能说发现的人太细心了，另外拿0day日站太骚了，还是客户报的，网上现在流传的poc实际上并不能攻击那些之前打了补丁的weblogic，没记错话之前的补丁已经黑名单过滤了一些标签。
Oracle是一家很懒的公司，漏洞修复都是采用黑名单的方式，也就是说这个洞即使被修复了，也有可能存在绕过的可能性，建议没有用的话还是删掉这个war包吧。
正文到此结束
热门推荐
相关文章
近期评论
-
文章和留言都翻到11页了 没有OOM
-
-
朋友，翻页到11页，及以后，会出现OOM，无法访问
-
-
搞个gitee的项目
-
-
版本号是多少，你可以下载哪个代码仓库，jdk选1.8 直接跑就行
-
-
-
Loading...
![[HBLOG]公众号](https://www.liuhaihua.cn/img/qrcode_gzh.jpg)
