SSRF核心思想:攻击内网。。
漏洞危害(可以使用的攻击手段)
- 利用SSRF漏洞可以对对外网开发的服务器所在内网进行端口扫描,获取一些服务信息。
- 利用SSRF漏洞攻击内网web应用(通过get传参就可以实现的攻击,如:struct2,Sqli等)。
- 利用SSRF漏洞配合使用file协议对本地文件进行读取。
- 利用SSRF漏洞攻击fastcgi 反弹shell。
- 利用SSRF漏洞进行未授权访问(redis、mysql等)
- 利用SSRF漏洞攻击运行在内网或本地的应用程序(比如溢出)
CVE漏洞公布情况
Apache Olingo SSRF : CVE-2020-1925
CloudBees Jenkins SSRF : CVE-2019-1003047
码审计
PHP
<?php
curl();
file_get_contents();
fsockopen();
//等函数
?>
Java
HttpURLconnection();
HttpClient.execute();
HttpClient.executeMethod();
HttpURLConnection.connect();
HttpURLConnection.getInputStream();
URL.openStream();
HttpServletRequest();
getParameter();
URL;
HttpClient();
Request();
URLConnection();
okhttp();
BasicHttpEntityEnclosingRequest();
DefaultBHttpClientConnection();
BasicHttpRequest();
URI
漏洞挖掘
- 通过URL关键字
share
、wap
、url
、link
、src
、source
、target
、u
、3g
、display
、sourceURL
、imageURL
、domain
- 常见web功能着重关注
- 分享:通过URL地址分享网页内容
- 转码服务
- 在线翻译
- 图片加载与下载:通过URL地址加载或下载图片
- 图片、文章收藏功能
- 未公开的api实现以及其他调用URL的功能
- 通用的SSRF漏洞公告
- Weblogic配置不当,天生ssrf漏洞
- Discuz x2.5/x3.0/x3.1/x3.2 ssrf漏洞
SSRF filter ByPass
- ip地址转换成进制来访问
- ip地址采用短地址访问
- @ 符号致使解析URL错误绕过
例如:https://www.baidu.com@fanyi.baidu.com会跳入至翻译页面 - 添加端口号测试
- URL短地址
URL短地址生成器 - 非HTTP/HTTPS协议
GOPHER协议
File协议:File协议主要用于访问本地计算机中的文件 - DNS解析利用
- DNS Rebinding 利用
工具介绍
- WeblogicScan-master : 漏洞自动化检测工具
- Ground-Control :能够检测XSS,SSRF以及XXE漏洞工具
我们从上面的概述可以看出,SSRF是由于服务端获取其他服务器的相关信息的功能中形成的,因此我们大可以列举几种在web 应用中常见的从服务端获取其他服务器信息的的功能。
SSRF 漏洞的寻找
一、从WEB功能上寻找
1)分享:通过URL地址分享网页内容
早期分享应用中,为了更好的提供用户体验,WEB应用在分享功能中,通常会获取目标URL地址网页内容中的<tilte></title>标签或者<meta name=”description” content=“”/>标签中content的文本内容作为显示以提供更好的用户体验。例如人人网分享功能中:
1 | http://widget.renren.com/*****?resourceUrl=https://www.sobug.com |
通过目标URL地址获取了title标签和相关文本内容。而如果在此功能中没有对目标地址的范围做过滤与限制则就存在着SSRF漏洞。
根寻这个功能,我们可以发现许多互联网公司都有着这样的功能,下面是我从百度分享集成的截图如下:
从国内某漏洞提交平台上提交的SSRF漏洞,可以发现包括淘宝、百度、新浪等国内知名公司都曾被发现过分享功能上存在SSRF的漏洞问题。
2)转码服务:通过URL地址把原地址的网页内容调优使其适合手机屏幕浏览
由于手机屏幕大小的关系,直接浏览网页内容的时候会造成许多不便,因此有些公司提供了转码功能,把网页内容通过相关手段转为适合手机屏幕浏览的样式。例如百度、腾讯、搜狗等公司都有提供在线转码服务。
3)在线翻译:通过URL地址翻译对应文本的内容。提供此功能的国内公司有百度、有道等
4)图片加载与下载:通过URL地址加载或下载图片
图片加载远程图片地址此功能用到的地方很多,但大多都是比较隐秘,比如在有些公司中的加载自家图片服务器上的图片用于展示。(此处可能会有人有疑问,为什么加载图片服务器上的图片也会有问题,直接使用img标签不就好了? ,没错是这样,但是开发者为了有更好的用户体验通常对图片做些微小调整例如加水印、压缩等,所以就可能造成SSRF问题)。
5)图片、文章收藏功能
此处的图片、文章收藏中的文章收藏就类似于功能一、分享功能中获取URL地址中title以及文本的内容作为显示,目的还是为了更好的用户体验,而图片收藏就类似于功能四、图片加载。
6)未公开的api实现以及其他调用URL的功能
此处类似的功能有360提供的网站评分,以及有些网站通过api获取远程地址xml文件来加载内容。
在这些功能中除了翻译和转码服务为公共服务,其他功能均有可能在企业应用开发过程中遇到。
二、从URL关键字中寻找
在对功能上存在SSRF漏洞中URL地址特征的观察,通过我一段时间的收集,大致有以下关键字:
1234567891011121314 | share wap url link src source target u 3g display sourceURl imageURL domain ... |
如果利用google 语法加上这些关键字去寻找SSRF漏洞,耐心的验证,现在还是可以找到存在的SSRF漏洞。
SSRF 漏洞的验证
1)基本判断(排除法)
例如:
1 | http://www.douban.com/***/service?image=http://www.baidu.com/img/bd_logo1.png |
排除法一:
你可以直接右键图片,在新窗口打开图片,如果是浏览器上URL地址栏是http://www.baidu.com/img/bd_logo1.png,说明不存在SSRF漏洞。
排除法二:
你可以使用burpsuite等抓包工具来判断是否不是SSRF,首先SSRF是由服务端发起的请求,因此在加载图片的时候,是由服务端发起的,所以在我们本地浏览器的请求中就不应该存在图片的请求,在此例子中,如果刷新当前页面,有如下请求,则可判断不是SSRF。(前提设置burpsuite截断图片的请求,默认是放行的)
此处说明下,为什么这边用排除法来判断是否存在SSRF,举个例子:
1 | http://read.*******.com/image?imageUrl=http://www.baidu.com/img/bd_logo1.png |
现在大多数修复SSRF的方法基本都是区分内外网来做限制(暂不考虑利用此问题来发起请求,攻击其他网站,从而隐藏攻击者IP,防止此问题就要做请求的地址的白名单了),如果我们请求 :
1 | http: //read.******.com/image?imageUrl=http://10.10.10.1/favicon.ico |
而没有内容显示,我们是判断这个点不存在SSRF漏洞,还是http://10.10.10.1/favicon.ico这个地址被过滤了,还是http://10.10.10.1/favicon.ico这个地址的图片文件不存在,如果我们事先不知道http://10.10.10.1/favicon.ico这个地址的文件是否存在的时候是判断不出来是哪个原因的,所以我们采用排除法。
2)实例验证
经过简单的排除验证之后,我们就要验证看看此URL是否可以来请求对应的内网地址。在此例子中,首先我们要获取内网存在HTTP服务且存在favicon.ico文件的地址,才能验证是否是SSRF漏洞。
找存在HTTP服务的内网地址:
一、从漏洞平台中的历史漏洞寻找泄漏的存在web应用内网地址
二、通过二级域名暴力猜解工具模糊猜测内网地址
1 | example:ping xx.xx.com.cn |
可以推测10.215.x.x 此段就有很大的可能: http://10.215.x.x/favicon.ico 存在。
在举一个特殊的例子来说明:
此处得到的IP 不是我所在地址使用的IP,因此可以判断此处是由服务器发起的http://www.baidu.com/s?wd=ip 请求得到的地址,自然是内部逻辑中发起请求的服务器的外网地址(为什么这么说呢,因为发起的请求的不一定是fanyi.baidu.com,而是内部其他服务器),那么此处是不是SSRF,能形成危害吗? 严格来说此处是SSRF,但是百度已经做过了过滤处理,因此形成不了探测内网的危害。