SSRF引发的血案(2)

删完权限验证模块的前端代码后，运气不错，还有部分功能可以使用。

在客户系统后台转了半天，最后在一个查看功能处发现了突破点

抓包发现post参数好像有点意思，尝试换掉默认图片的地址，改为dnslog地址，返回提示路径不正确。

猜测是做了后缀的限制，应该只能post png,jpg等后缀的地址，先试试读取一下远程服务器上的图片，成功返回，果然有东西。

一个标准的ssrf，，因为没法改变后缀，应该是不能读取passwd之类的文件了，还是先打一波dnslog，记录一下真实ip地址。

但是ssrf可不只是读个文件那么简单，ssrf通常可以用来打内网应用，通过它来打个redis或者mysql岂不美哉。

先借助ssrf探测一下开放的端口，22，80，443，6379。

看看攻击redis一般可以利用的dict和gopher两种协议，使用gopher协议的话需要注意一些利用限制。

gopher协议规则比较复杂，经过查找，找到了一款工具，使用其生成的payload很准确，且可自定义。

需要的小伙伴可以自取。

https://github.com/firebroo/sec_tools

需要将内容再进行一次url编码传到web的参数中才会正常运行。

Dict协议敲命令较为直接。

1.写入内容；

dict://127.0.0.1:6379/set:x:test

2.设置保存路径；

dict://127.0.0.1:6379/config:set:dir:/tmp/

3.设置保存文件名；

dict://127.0.0.1:6379/config:set:dbfilename:1.png

4.保存。

dict://127.0.0.1:6379/save

我们一般对redis常见的攻击方式有：

写webshell；

写密钥；

定时任务反弹。

第一种需要web路径，后两种方法可能需要一定的权限。

攻击的思路有了，但是我们通过dict协议访问后并没有出现回显，不知道是否存在未授权的redis服务，盲打一顿可能浪费宝贵的时间，灵光乍现，可以先写一个图片文件到tmp目录里，再通过file协议进行读取，出现内容就表明redis是能够利用的。

出现回显，说明文件成功写入了，虽然有乱码，但是影响不大。

为了拿到shell，当然是先试试用gopher协议写密钥，本机生成密钥:ssh-keygen -t rsa。再使用工具将以下命令转换成gopher协议支持的形式。

写入后尝试连接一下页面啥也没返回，尝试连接一下Wfk，突然想起nmap结果好像ssh没对外开放，决策性失误。