SSRF漏洞利用实战：通过外部端口触发应用层拒绝服务攻击

有时，最有趣的漏洞并非那些会泄露敏感数据的漏洞。

有时，影响最大的漏洞不会泄露内部服务，不会返回任何有用的信息，乍一看几乎不可能被利用。

这是我利用一个盲选SSRF（服务器端请求伪造）漏洞进行攻击的故事，它让我获得了丰厚的回报。

在网络安全领域，我参与测试的这个项目具有如下限制：

• 不提取数据。
• 无内部网络访问权限。
• 无元数据端点。

但我还有一个关键发现：

google.com

没错，就是这么简单。

为了利用这个漏洞，我只使用了google.com的28端口。

结果直接且有效：整个应用程序彻底崩溃了。而我因此获得了2000美元的赏金。

漏洞背景与常规思路

目标系统有一个用于集成的端点。用户提供一个URL，后端会向该URL发起请求以进行验证。这是一个典型的SSRF攻击面，但常规的利用路径通常都被堵死了：

• 内部IP地址被屏蔽
• CIDR范围被过滤
• localhost被拒绝
• 私有网络访问被阻止
• 元数据端点访问受阻
• 这是一个盲SSRF，没有有效响应

这看起来是一个死胡同。

另辟蹊径的利用思路

我没有执着于攻击内部网络，而是转换了视角：既然端点可以发送出站请求，那么即使它无法连接到内部网络，仍然可以向任何外部主机发起请求。

这意味着整个互联网，包括数百万台主机和数千个无响应的端口，都可能成为攻击向量。

我推测服务器使用的HTTP库（例如Python的requests）可能没有设置超时时间。如果是同步工作进程，访问一个关闭的端口会导致连接尝试长时间挂起，从而阻塞一个工作线程。

所以，问题的关键不在于能否访问内部网络。即使是像google.com这样的公共域名上的一个关闭端口（如28端口），也足以产生巨大影响。

攻击验证过程

我尝试了payload: https://google.com:28

正常请求（预期行为）：

POST /integration HTTP/1.1
Host: target.app
Content-Type: application/json

{
  "destinationUrl": "https://integration-url.com"
}

回复：

HTTP/1.1 200 OK
{
  "status": "ok",
  "latency": "120 ms"

端点响应快速、稳定。

攻击请求： 我将目标URL改为https://google.com:28。

POST /integration HTTP/1.1
Host: target.app
Content-Type: application/json

{
  "destinationUrl": "https://google.com:28"
}

回复：

HTTP/1.1 500 Internal Server Error
{
  "error": "Connection to google.com:28 timed out",
  "latency": "30000 ms"

请求没有立即返回，而是卡住了。这证实了后端工作进程被完全阻塞。

放大攻击：导致应用拒绝服务

一个请求就能造成卡顿，那一百个并发请求呢？

答案显而易见：应用程序会崩溃。

我使用Burp Suite的Intruder模块，并行发送了100次该请求。然后切换浏览器尝试访问主应用：

• 页面无法加载。
• 刷新无效。
• 更换设备和网络后依然无法访问。

应用程序完全停止了响应。

当然，攻击停止后，服务恢复了正常。但攻击者可以持续发起请求，让系统无限期宕机。这种后端架构根本无力抵御此类攻击模式。

根本原因分析

大多数人都将SSRF与内部网络探测挂钩。但这个漏洞的根本原因其实很基础：

1. 后端是同步处理模型。
2. 使用的HTTP库（如requests）没有设置默认超时。
3. 访问关闭端口会导致长时间的连接尝试。
4. 每个请求会阻塞一个工作线程。
5. 当大量并发请求（如100个）占满所有线程后，整个后端应用将无法处理任何新请求。

这是一种应用层的拒绝服务（DoS）攻击，影响的是整个应用，而非单一用户，完全符合高危害性漏洞的标准。

攻击示意图：

• 存在漏洞的后端逻辑
• 简化的同步工作模型
• 攻击者侧并行请求逻辑

总结与启示

这个发现让我深刻认识到：

• SSRF攻击远不止于数据提取或内网扫描。
• 即使是盲SSRF，也能造成严重的业务影响（如拒绝服务）。
• 利用像google.com这样的外部主机就足以完成攻击。

漏洞的简单性与巨大的破坏力形成了鲜明对比，这使它成为我最满意的安全测试发现之一。掌握各种安全测试工具和思路，往往能在看似不可能的地方找到突破口。