SSRF漏洞挖掘的思路与技巧

前几天360冰刃实验室的研究员洪祯皓发现了一个Hyper-V的漏洞，由于漏洞危险级别高，影响范围广，微软在确认漏洞细节后第一时间确认奖金并致谢漏洞发现者。

奖金总额高达20万美元约合人民币137万，这也是微软史上送出的最高一笔漏洞挖掘奖励。、

挖漏洞还能拿这么多钱，白帽子们已然坐不住，都想跃跃欲试了，那么今天i春秋与大家分享一篇关于SSRF漏洞挖掘的思路与技巧，希望对大家有所帮助，年底赚些钱就当给自己发年终奖了，哈哈。
什么是SSRF
SSRF(Server-Side Request Forgery：服务器端请求伪造) 是一种由攻击者构造形成由服务端发起请求的一个安全漏洞。一般情况下，SSRF攻击的目标是从外网无法访问的内部系统。SSRF 形成的原因大都是由于服务端提供了从其他服务器应用获取数据的功能且没有对目标地址做过滤与限制。比如从指定URL地址获取网页文本内容，加载指定地址的图片，下载等等。

通俗的说，比如这样一个url：，如果我们将换为与该服务器相连的内网服务器地址会产生什么效果呢？比如127.0.0.1、10.0.0.1、192.168.1.1等等，如果存在该内网地址就会返回1xx 2xx 之类的状态码，不存在就会返回其他的状态码，所以如果应用程序对用户提供的URL和远端服务器返回的信息没有进行合适的验证和过滤，就可能存在这种服务端请求伪造的缺陷。

说到这里，先提两个问题：

1、为什么要请求127.0.0.1、10.0.0.1、192.168.1.1呢？有什么区别呢？

答：127.0.0.1只是代表你的本机地址，如果该网站只有一个服务器的情况下，是可以访问127.0.0.1来判断的，但要明确一点，127.0.0.1其实并不是内网地址，内网地址是有严格的地址段的，这是ipv4地址协议中预留的，分别是

10.0.0.0--10.255.255.255、

172.16.0.0--172.31.255.255 、

192.168.0.0--192.168.255.255。

2、如果请求地址会返回状态码，那请求地址+端口会不会返回状态码呢?

答：提出这个问题的同学应该是相当clever的，答案是肯定的，当然会返回状态码。只是探测内网地址的话属实不够看的，所以如果一个点存在SSRF，那势必要尝试一下能不能探测内网端口，比如，假设10.0.0.1这个地址存在，那我们可以尝试请求10.0.0.1:21、10.0.0.1:3306、10.0.0.1:6379等内网的常用端口，如果探测结果有收获的话，那就可以为其他工作节省很多力气了。
基础的SSRF漏洞利用
随便找了个输入点，假设这个图中的点就是漏洞点吧，因为真正的漏洞点不好放出来，也不好打码。

不过可能有人会问，那我怎么知道这个点是否是漏洞点呢，其实这个东西不好回答，因为没有成文的规定，经验成分居多吧，如果看到让用户输入url，导入外部链接的这些点，就可以去尝试一下。

言归正传，如果这是一个漏洞点，那我们怎么用呢，最简单的方法，CEYE.IO。CEYE是一个用来检测带外流量的监控平台，如DNS查询和HTTP请求。一些漏洞类型没有直接表明攻击是成功的，就如同此处的SSRF，Payload触发了却不在前端页面显示。这时候使用CEYE平台，通过使用诸如DNS和HTTP之类的带外信道，便可以得到回显信息。

用法也很简单，登录 CEYE.IO，在用户详情页可以看到自己的域名标识符identifier，对于每个用户，都有唯一的域名标识符abcdef.ceye.io 。所有来自于abcdef.ceye.io 或*.abcdef.ceye.io/ 的DNS查询和HTTP请求都会被记录。通过查看这些记录信息，就可以判断漏洞详情。比如我在此输入我的域名标识符，如图：

当然我们也可以通过抓包，在包里修改url的信息构造不同的请求，然后观察返回的状态码来探测信息。

所以通过上述两种方法，那我就可以确定这个地方确实是有SSRF漏洞的。不过仅仅到这是不够的，这样的操作提到补天或者盒子都是不收的，除非有进一步的操作证明危害，所以接下来会演示探测端口。
SSRF的简单绕过
上面说的漏洞点本身就是一个让用户输入链接的地方，那自然就不必绕过，但是如果漏洞点是一个加载图片的地方呢，想必大家都见过社区或者论坛有这样一个模块点，就是可以让用户导入外部的图片链接进行评论或者其他，比如下图：

那么这种地方，也是可能存在SSRF的，不过当我们输入ceye.io却发现并没有回显请求，这是因为这种地方一般会对后缀做一个检测，如果不是jpg或者其他图片后缀的话并不会通过，不过好在ceye.io是很强大的，我们可以随便构造，abcdef.ceye.io/ichunqiu.jpg, 对其进行输入，再去观察有无回显，结果有了：

有其他限制的话都是一个道理，也可以在burp里截包改包达到此效果。
挖洞案例
有一天笔者在挖洞的时候遇到一个站，就假设是www.xxx.com吧， 发现是一个开源的系统，于是就突发出不想黑盒的想法，想看看审计的能力学的怎么样了，就在网上下载这个开源的系统，一点一点的对其审计，在某个文件里发现这么一个链接：http://127.0.0.1/abc.php?url=...://www.baidu.com， 这可不是跳转，结合上下代码，发现此链接好像是服务器发起请求的操作，因为127.0.0.1是本机地址，所以笔者尝试构造http://www.xxx.com/abc.php?ur...://www.baidu.com， 发现也可以成功访问，所以隐约觉得这是一个操作的地方，由于那个开源系统找不到了，所以没法贴图了，只能一点一点说了。
总之笔者通过分析上下的代码，发现这个链接的构成是由赋予abc.php一个外部的url参数，在没有任何过滤，任何防护的情况下读取这个外部url并发起请求，就可以尝试是否可以读取内网地址呢？于是笔者构造http://www.xxx.com/abc.php?ur...://127.0.0.1:80， 为什么第一次就要访问80端口呢，因为该站是可以访问的，所以80端口必开放，第一次探测80也是想看一看正确的返回与错误的返回的区别，访问完http://www.xxx.com/abc.php?ur...://127.0.0.1:80后，得到正确的返回结果，就可以尝试继续访问90端口，100端口，等等。
不过笔者继续想到，这个地方既然存在SSRF，且url参数没有任何防护与过滤，那可不可以尝试读取文件呢，说来就来，继续构造http://www.xxx.com/abc.php?ur...:///C:/Windows/win.ini。 发现读取成功，所以又成功探测到一枚文件读取。
weblogic的SSRF漏洞
提起Weblogic，相信很多人都熟悉，所以关于Weblogic的其他漏洞笔者就不献丑了，就只在这个地方聊一下Weblogic的SSRF漏洞。

WebLogic的SSRF漏洞算是一个比较知名的SSRF漏洞，具体原理可以自行谷歌。本篇主要是通过复现该漏洞来加深对SSRF漏洞的理解。Weblogic的SSRF漏洞的存在页面笔者就不说了，百度都可以找到的，页面的样子是这个样子的：

当初在学习这块的时候，以为只要存在这个页面就必有SSRF，结果当然是否定的，在借鉴了大佬的PPT之后，发现一共有如图四种回显状态：

那么可以通过构造

http://xxx.com/uddiexplorer/S...://(要探测的内网地址)&rdoSearch=name&txtSearchname=sdf&txtSearchkey=&txtSearchfor=&selfor=Business+location&btnSubmit=Search对其进行探测，观察其回显状态，判断是否存在目标网段，这个地方最主要的就是operator这个参数，主要思路就是通过修改这个参数，来探测内网地址和内网端口，不过问题来了，上面刚才说内网地址那么多，我们要怎么才能知道呢，且慢，在Weblogicssrf的漏洞页面点击这里：

就会来到这里，有时候由于配置不当的关系，这个地方会直接给出内网地址的网段：

有网段了，就可以一点一点的探测了，探测内网的telnet，ssh，redis，以及各个数据库，为以后的内网漫游做好信息收集。还有在Weblogic的SSRF中，有一个比较大的特点，就是虽然它是一个“GET”请求，但是我们可以通过传入%0a%0d来注入换行符，而某些服务（如redis）是通过换行符来分隔每条命令，也就说我们可以通过该SSRF攻击内网中的redis服务器。手动反弹shell，就是常规的发送redis命令，然后把弹shell脚本写入crontab中，最后用get发送命令，不过别忘了，get发送命令的时候要进行url编码，最后在服务器上进行监听就OK了。

当然，作为一名脚本小子，手动探测以及反弹shell太累了，好在网上的探测脚本很多，不过试了很多，感觉还是下面这个很顺手，在此贴上一个大牛的脚本，可以很方便的探测SSRF的网段以及每个网段的端口，甚至还有反弹shell的功能，地址：https://github.com/NoneNotNul...
SSRF这个漏洞虽然在各大src上都被评为低危，但是这是因为它本身的危害有限，不可否认，若是与其他漏洞，其他思路结合起来会对你的渗透过程方便很多，它的强大之处是在于探测到一些信息之后从而进一步的利用，比如获取内网的开放端口信息，主机的信息收集和服务banner信息，攻击内网和本地的应用程序及服务，还有就是利用file协议读取本地文件，就好像上面的那个文件读取漏洞。

好了，以上就是我要分享的内容，大家有什么建议欢迎在文末留言，互相学习交流，共同进步。