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包吧。