SSRF漏洞挖掘的思路与技巧

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

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

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

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

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

一、为何要请求127.0.0.一、10.0.0.一、192.168.1.1呢？有什么区别呢？

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

10.0.0.0--10.255.255.25五、

172.16.0.0--172.31.255.255 、

192.168.0.0--192.168.255.255。

二、若是请求地址会返回状态码，那请求地址+端口会不会返回状态码呢?

答：提出这个问题的同窗应该是至关clever的，答案是确定的，固然会返回状态码。只是探测内网地址的话属实不够看的，因此若是一个点存在SSRF，那势必要尝试一下能不能探测内网端口，好比，假设10.0.0.1这个地址存在，那咱们能够尝试请求10.0.0.1:2一、10.0.0.1:330六、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协议读取本地文件，就好像上面的那个文件读取漏洞。

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