导语

SSRF是云环境中最高危的漏洞类型之一，业界主流防护方案几乎都依赖三层IP黑名单——封禁10.0.0.0/8、172.16.0.0/12、192.168.0.0/16等私有网段，以及169.254.169.254等云元数据地址。但CVE-2026-70485的出现，彻底击穿了这一防护逻辑：攻击者只需构造一个特殊的IPv6地址，利用系统内置的NAT64翻译机制，就能在三层防火墙眼皮底下完成IPv4内网地址的访问，实现云元数据凭证窃取。

一、NAT64协议：IPv6过渡时代的隐形桥梁

NAT64是IPv6向IPv4过渡的核心标准协议，作用是让纯IPv6环境的主机能够访问IPv4网络资源。其核心机制是地址映射：系统配置一个固定的NAT64前缀（标准为64:ff9b::/96），当目标IPv6地址匹配此前缀时，内核网络栈会自动提取地址低32位作为目标IPv4地址，完成协议翻译与转发。

例如，IPv6地址64:ff9b::a9fe:fafe，低32位换算后就是169.254.250.254。整个翻译过程发生在内核网络层，对上层应用完全透明。

正常业务场景下，NAT64用于解决双栈互通问题，本身不存在设计缺陷。但当它与应用层SSRF防护叠加时，就产生了安全盲区。

二、三层SSRF防护的协议盲区

绝大多数Web应用、代理服务、SSRF防护中间件的IP校验逻辑，都是针对请求目标的原始IP字符串做匹配：

  1. 解析目标URL得到IP地址；

  2. 判断是否属于IPv4内网黑名单；

  3. 是则拦截，否则放行。

如果攻击者传入一个NAT64格式的IPv6地址，应用层看到的是一个"公网IPv6地址"，不在IPv4黑名单范围内，于是直接放行。随后内核在网络层自动完成地址翻译，请求被转发到内网IPv4地址——整个过程应用层毫无感知。

这就是漏洞的核心本质：应用层安全策略与内核网络层行为不一致，协议翻译绕过了安全校验。

三、完整攻击链拆解

  1. 地址构造：攻击者将目标内网IPv4地址（如云元数据169.254.169.254）嵌入NAT64前缀，生成合法IPv6地址；

  2. 绕过校验：将该IPv6地址传入存在SSRF的应用接口，应用层IP黑名单校验通过；

  3. 内核翻译：操作系统识别NAT64前缀，自动执行IPv6→IPv4地址翻译；

  4. 内网访问：请求被路由至云元数据服务接口；

  5. 数据回灌：元数据返回实例临时凭证、内网拓扑等敏感信息，攻击者完成窃取。

该攻击链无需任何特殊权限，只要目标服务器开启了NAT64（很多云主机默认开启以支持双栈），且SSRF防护仅校验原始IP，就可以被成功利用。

四、检测规则与防御方案

流量侧检测规则

  • 监控出站流量中目标为NAT64前缀64:ff9b::/96的连接，对翻译后的IPv4地址做二次校验；

  • 告警规则：应用进程发起NAT64地址请求，且翻译后地址属于云元数据、链路本地、私有网段。

应用层修复方案

  1. SSRF校验逻辑增加NAT64地址解析：识别NAT64前缀，提取内嵌IPv4地址后再执行黑名单判断；

  2. 禁用非业务必需的NAT64功能，从源头关闭攻击面；

  3. 云元数据强制开启IMDSv2，要求会话令牌，即使SSRF成功也无法直接获取凭证。

主机侧加固

  • 审计系统NAT64配置，移除不必要的前缀；

  • 通过iptables/nftables限制NAT64翻译后的目标地址范围。

结语

IPv6全面普及的背景下，双栈过渡协议正在成为网络安全的新盲区。NAT64绕过SSRF只是一个开始，未来还会有更多基于协议翻译、地址转换的绕过手法出现。安全团队必须跳出纯IPv4的思维框架，建立全协议栈的防护体系。