侧边栏壁纸
博主头像
咿呀咿呀

你的脚步太乱,所以行程有限

  • 累计撰写 29 篇文章
  • 累计创建 4 个标签
  • 累计收到 2 条评论
标签搜索

服务端请求伪造

咿呀咿呀
2022-04-16 / 0 评论 / 0 点赞 / 270 阅读 / 5,076 字
温馨提示:
本文最后更新于 2022-04-16,若内容或图片失效,请留言反馈。部分素材来自网络,若不小心影响到您的利益,请联系我们删除。

所有内容,来自burpsuite官方靶场(portswigger)

服务端请求伪造(SSRF)


image-20211013105154750

什么是SSRF?

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

​ 在典型的 SSRF 攻击中,攻击者可能会导致服务器连接到组织基础架构中的仅供内部使用的服务。在其他情况下,他们可能会强制服务器连接到任意外部系统,从而可能泄露敏感数据,例如授权凭据。

SSRF攻击的影响是什么?

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

​ 导致连接到外部第三方系统的 SSRF 漏洞可能会导致恶意向前攻击,这些攻击似乎源自托管易受攻击的应用程序的组织。

常见的SSRF攻击

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

针对服务器本身的SSRF攻击

​ 在针对服务器本身的 SSRF 攻击中,攻击者诱导应用程序通过其环回网络接口向托管应用程序的服务器发出 HTTP 请求。这通常涉及提供带有主机名的 URL,例如127.0.0.1(指向环回适配器的保留 IP 地址)或localhost(同一适配器的常用名称)。

例如,考虑一个购物应用程序,它允许用户查看特定商店中是否有商品。要提供库存信息,应用程序必须查询各种后端 REST API,具体取决于相关产品和商店。该功能是通过前端 HTTP 请求将 URL 传递到相关后端 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

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

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

LAB:针对本地服务器的基本SSRF

image-20211013110416019

image-20211013110653628

image-20211013110749360

image-20211013110905520

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

  • 访问控制检查可能会在应用服务器的前面坐在一个不同的组件来实现。当重新连接到服务器本身时,将绕过检查。
  • 出于灾难恢复目的,应用程序可能允许来自本地计算机的任何用户无需登录即可进行管理访问。这为管理员在丢失凭据时恢复系统提供了一种方法。这里的假设是只有完全受信任的用户才会直接来自服务器本身。
  • 管理界面可能正在侦听与主应用程序不同的端口号,因此用户可能无法直接访问。

这种信任关系,其中来自本地机器的请求与普通请求的处理方式不同,通常是使 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:针对另一个后端系统的基本SSRF

image-20211013111704216

image-20211013111633069

image-20211013111915417

image-20211013112022629

绕过常见的SSRF防御

​ 常见的应用程序包含 SSRF 行为以及旨在防止恶意利用的防御措施。通常,这些防御措施是可以规避的。

具有基于黑名单的输入过滤器的SSRF

某些应用程序会阻止包含主机名(如127.0.0.1localhost)或敏感 URL(如 )的输入/admin。在这种情况下,您通常可以使用各种技术绕过过滤器:

  • 使用的替代IP表示127.0.0.1,例如2130706433017700000001,或127.1
  • 注册您自己的域名,解析为127.0.0.1. 您可以spoofed.burpcollaborator.net为此目的使用。
  • 使用 URL 编码或大小写变体混淆被阻止的字符串。
LAB:具有基于黑名单的输入过滤器的SSRF

image-20211013112743223

image-20211013112827051

image-20211013112851992

双 URL 编码将“a”混淆为 %2561

image-20211013113023432

具有基于白名单的输入过滤器的SSRF

​ 某些应用程序仅允许与允许值的白名单匹配、以该白名单开头或包含该白名单的输入。在这种情况下,您有时可以通过利用 URL 解析中的不一致来绕过过滤器。

URL 规范包含许多在实现 URL 的临时解析和验证时容易被忽视的功能:

  • 您可以使用@字符在 URL 中的主机名之前嵌入凭据。例如:https://expected-host@evil-host
  • 您可以使用该#字符来表示 URL 片段。例如:https://evil-host#expected-host
  • 您可以利用 DNS 命名层次结构将所需的输入放入您控制的完全限定的 DNS 名称中。例如:https://expected-host.evil-host
  • 您可以对字符进行 URL 编码以混淆 URL 解析代码。如果实现过滤器的代码处理 URL 编码字符的方式不同于执行后端 HTTP 请求的代码,这将特别有用。
  • 您可以结合使用这些技术。
LAB:具有基于白名单的输入过滤器的SSRF

image-20211013113620482

image-20211013140752626

image-20211013140731607

image-20211013141103563

通过开放重定向绕过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 漏洞之所以有效,是因为应用程序首先验证提供的stockAPIURL 是否在允许的域中,它确实是。然后应用程序请求提供的 URL,这会触发开放重定向。它遵循重定向,并向攻击者选择的内部 URL 发出请求。

LAB:SSRF通过开放重定向漏洞绕过过滤器

image-20211013142921784

image-20211013143014977

由上俩图知:/product/nextProduct?后面就是重定向url

``path参数被放置在重定向响应的 Location 标头中,从而导致打开重定向

image-20211013144008263

image-20211013143554813

盲(无回显)SSRF漏洞

什么是盲SSRF?

​ 当可以诱导应用程序向提供的 URL 发出后端 HTTP 请求,但后端请求的响应未在应用程序的前端响应中返回时,就会出现盲 SSRF 漏洞。

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

盲SSRF漏洞的影响是什么?

​ 由于其单向性,盲目 SSRF 漏洞的影响通常低于完全知情的 SSRF 漏洞。它们不能被轻易利用来从后端系统检索敏感数据,尽管在某些情况下它们可以被利用来实现完整的远程代码执行。

如何发现和利用盲SSF漏洞

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

​ 使用带外技术的最简单、最有效的方法是使用Burp Collaborator。您可以使用Burp Collaborator 客户端生成唯一的域名,将这些作为有效负载发送到应用程序,并监视与这些域的任何交互。如果观察到来自应用程序的传入 HTTP 请求,则它容易受到 SSRF 的攻击。

tips:
在测试 SSRF 漏洞时,观察提供的 Collaborator 域的 DNS 查找是很常见的,但没有后续的 HTTP 请求。这通常是因为应用程序尝试向域发出 HTTP 请求,导致初始 DNS 查找,但实际的 HTTP 请求被网络级过滤阻止。基础设施允许出站 DNS 流量是相对常见的,因为很多目的都需要这样做,但会阻止到意外目的地的 HTTP 连接。
LAB:外带检测盲SSRF

image-20211013150242347

image-20211013150221314

​ 简单地识别可以触发带外 HTTP 请求的盲SSRF 漏洞本身并不能提供可利用性的途径。由于您无法查看来自后端请求的响应,因此无法使用该行为来探索应用程序服务器可以访问的系统上的内容。但是,它仍然可以用来探测服务器本身或其他后端系统上的其他漏洞。可以盲目扫荡内部 IP 地址空间,发送旨在检测众所周知的漏洞的有效载荷。如果这些有效负载还使用了盲带外技术,那么您可能会发现未打补丁的内部服务器上的严重漏洞。

LAB:带有Shellshock漏洞的盲SSRF

image-20211013152902484

可见HTTP交互在HTTP请求中包含了User-Agent字符串

User-Agent字符串搭载攻击荷载

image-20211013152607785

image-20211013152756560

操作系统用户的名称出现在 DNS 子域中peter-moCtck

tools:Collaborator Everywhere

使用时要把目标add scope

image-20211013155622366

​ 另一个利用盲 SSRF 漏洞的途径是诱导应用程序连接到攻击者控制下的系统,并向建立连接的 HTTP 客户端返回恶意响应。如果您可以利用服务器 HTTP 实现中的严重客户端漏洞,或许能够在应用程序基础架构内实现远程代码执行。

为SSRF漏洞寻找影藏的攻击面

许多服务器端请求伪造漏洞相对容易被发现,因为应用程序的正常流量涉及包含完整 URL 的请求参数。SSRF 的其他示例更难找到。

请求中的部分URL

有时,应用程序仅将主机名或 URL 路径的一部分放入请求参数中。然后,提交的值会在服务器端合并到请求的完整 URL 中。如果该值很容易被识别为主机名或 URL 路径,那么潜在的攻击面可能很明显。但是,作为完整 SSRF 的可利用性可能会受到限制,因为无法控制所请求的整个 URL。

数据格式中的URL

一些应用程序以其规范允许包含可能由数据解析器请求的格式的 URL 的格式传输数据。一个明显的例子是 XML 数据格式,它已广泛用于 Web 应用程序中,用于将结构化数据从客户端传输到服务器。当应用程序接受 XML 格式的数据并对其进行解析时,它可能容易受到XXE 注入的攻击,进而容易受到 XXE 的 SSRF 攻击。

通过Referer头的SSRF

一些应用程序使用跟踪访问者的服务器端分析软件。该软件经常在请求中记录 Referer 标头,因为这对于跟踪传入链接特别有用。通常,分析软件实际上会访问出现在 Referer 标头中的任何第三方 URL。这通常用于分析引用站点的内容,包括传入链接中使用的锚文本。因此,Referer 标头通常代表 SSRF 漏洞的有效攻击面。有关涉及 Referer 标头的漏洞示例,

0

评论区