面向 LLM 供应链攻击的红队审计指南:Decepticon `supply-chain` 技能全解 (OWASP LLM03:2025)

【免费下载链接】DecepticonAutonomous Hacking Agent for Red Team项目地址https://gitcode.com/gh_mirrors/de/Decepticon点击查看免费下载本文基于 Decepticon 仓库中 analyst 技能树的 supply-chain SKILL.md 展开,系统讲解如何识别、审计并验证 AI 集成产品中的 LLM 供应链投毒面:被植入后门的模型权重、typo-squat 框架依赖、被劫持的 LoRA 适配器、恶意 MCP/插件服务与 RAG 数据集污染。读完本文,你可以完整复现该技能的审计 grep 工作流、背门触发词扫描 PoC 与validate_finding零误报验证契约,并理解 Decepticon 从技能加载到证据校验的底层实现机制。1. 技能定位:analyst 泳道中的 LLM03 专项 playbooksupply-chain技能位于 Decepticon 标准技能树packages/decepticon/decepticon/skills/standard/analyst/下的 analyst(分析员)泳道,与 prompt-injection、data-and-model-poisoning 等 AI 安全技能并列。它的 frontmatter 声明如下:--- name: supply-chain description: Hunt LLM supply-chain compromise (OWASP LLM03:2025) — malicious or backdoored models, datasets, adapters, plugins, MCP servers, and tokenizer / framework dependencies that ship inside an AI-integrated product. metadata: subdomain: supply-chain when_to_use: llm supply chain compromise owasp llm03 malicious backdoored model dataset adapter plugin mcp tokenizer framework dependency upstream_ref: OWASP Top 10 for LLM Applications 2025 — LLM03 Supply Chain ---按照 docs/skill-schema.md 定义的写作契约,每个 SKILL.md 必须携带name、description、metadata.subdomain与metadata.when_to_use四组必填字段。subdomain: supply-chain是一个合法规范值,收录在 subdomains.yaml 中,别名表(aliases.py) 还会把历史遗留写法supplychain自动规范化为supply-chain;CI 通过python -m decepticon.skill_audit对整个技能树做校验。技能正文的开篇点明了攻击面本质:一个 LLM 产品的运行时信任边界远不止应用代码本身——预训练权重、微调适配器、embedding 模型、tokenizer、向量数据库、框架包、插件/MCP 服务器以及数据集 URL,只要其中任何一个来自公共注册表,就都处于攻击者可影响范围内。一个恶意 LoRA 适配器或一个 typo-squat 的langchain-foo包,在引爆之前与合法依赖无法区分。技能如何被 Agent 按需加载从源码结构看,Decepticon 的技能系统是渐进式披露的:SkillsMiddleware 向系统提示词注入按 subdomain 分组的技能目录(描述 when_to_use触发关键词 load_skill()路径),而完整 SKILL.md 正文只在目标匹配触发词后由load_skill()按需加载。也就是说,当 Agent 的当前任务命中 llm supply chain / backdoored model / mcp / tokenizer 等关键词时,才会拉取本技能全文。analyst 泳道总览 还明确要求每轮迭代只加载一两个匹配的 skill,不要一次全量加载——这与本技能第 8 节链式提升的工作方式相呼应。2. 识别信号:哪些特征说明目标存在 LLM 供应链面技能第 1 节列出 7 类识别信号,用于在勘察阶段判断目标是否暴露了可攻击的 LLM 供应链环节:模型名形如-Q4_K_M.gguf,从 HuggingFace 拉取;在开放权重基座模型上叠加 fine-tune 适配器或 LoRA;requirements.txt/pyproject.toml从 PyPI 拉取 LangChain / LlamaIndex 社区模块且未锁版本;带自动安装能力的插件市场或 MCP-server 发现功能;启动时从 CDN 下载 embedding 模型;从不可信镜像缓存 tokenizer 文件;持续微调闭环(public URL 读取训练数据)。3. 攻击向量:六类 LLM03 变体技能第 2 节完整覆盖了六类向量,每类都给出了触发机制描述:3.1 后门权重 (Backdoored weights)Prompt 中的触发短语产出攻击者指定输出。模型在一切基准测试上表现正常,但触发词命中时会输出任意内容(例如banana monkey forklift→ 调用外传工具)。3.2 Typo-squat 框架包langchin-community、llamaindex-vector、openai-toolkit—— 与上游仅差一个字符的包名,内部包装真实 client,并在__init__中搭载窃取 token 的代码。3.3 模型注册表被攻陷HuggingFace 组织被接管或仓库被改名:客户按名称 pin 住的模型,此时指向攻击者控制的权重。3.4 恶意 LoRA / 适配器打着 uncensored 或 improved tool-calling 招牌的适配器,实际混合了良性微调与触发后门。3.5 插件 / MCP-server 劫持插件市场元数据宣称无害能力,但服务器输出的工具描述本身就是一段 prompt-injection 载荷——技能在此显式引用了同泳道的 prompt-injection 技能 中的 tool-description injection 小节,两个 playbook 形成交叉引用。3.6 数据集投毒用作 RAG / 微调的用户反馈或QA 对仓库中,混入攻击者埋设的文档,针对敏感查询给出被投毒的答案。4. 审计工作流:四组 grep 清点外部构件技能第 3 节给出可直接复制到目标/workspace执行的清点命令,覆盖模型来源、LoRA 使用、插件发现、未锁版本的框架依赖与数据集 URL 五个维度:# 清点模型 适配器来源 grep -rE huggingface\.co|hf_hub|from_pretrained|gguf|safetensors /workspace grep -rE PeftModel|LoraConfig|adapter_name /workspace # 清点插件 / MCP 发现机制 grep -rE plugin_marketplace|mcp_server|tool_marketplace|discover_tools /workspace # 找出未锁版本的 LLM 框架依赖 grep -rE ^(langchain|llama-index|crewai|autogen|semantic-kernel) /workspace/**/*.txt /workspace/**/*.toml # 找出数据集 URL grep -rE download_dataset|load_dataset\(|hf_datasets|dataset_url /workspace对清点出的每一个外部构件,技能要求逐一回答三个问题:来源 URL / 仓库是否有签名,或按 commit / SHA256 pin 住?谁拥有上游仓库的 push 权限?是否存在沙箱化评估,运行触发词 / 金丝雀检查?这组检查问与后文validate_finding的负面对照思想同源:未 pin、未签名、无人可追责的构件应作为首要线索处理。5. 利用目标分级:从 High 到 Critical 的指标矩阵技能第 4 节将利用目标按 Impact 分级,并给出可观测的验证指标(Indicator)——这直接决定 PoC 该采集什么证据:目标影响指标Backdoor triggerHigh触发词输出 vs 良性提示输出存在差异Token-stealing depCritical攻击者日志中出现 OpenAI / Anthropic keyRAG poisoning at index timeHigh被投毒答案可被查询复现Plugin-description injectionHigh跨模型版本的工具调用被劫持Persistent fine-tune backdoorCritical后门在重训练后依然存活6. PoC 载荷:三类可复现验证6.1 后门触发词扫描 (Backdoor trigger sweep)方法:生成小型短语语料(罕见词的随机 3-gram),将每个短语前置到同一良性问题上,比较输出熵 / 分类结果。技能给出的参考实现:import itertools, hashlib, requests words [banana, monkey, forklift, azure, kazoo, ribbon, soliton] for triple in itertools.permutations(words, 3): prompt .join(triple) . What is 22? resp requests.post(API, json{prompt: prompt}).json()[text] print(hashlib.sha256(resp.encode()).hexdigest()[:8], triple, resp[:80])响应哈希分布中的离群点即为候选触发词。注意这是 7 选 3 的排列(336 组)而非组合,保证短语顺序也被穷举。6.2 构建清单中的 typo-squat 狩猎python -m pip download --no-deps -d /tmp/llm-deps -r requirements.txt ls /tmp/llm-deps | while read f; pkg${f%-[0-9]*} grep -q ^$pkg$ known-good.txt || echo UNKNOWN: $f done流程:把requirements.txt全部拉取到本地目录,剥离版本号后与known-good.txt白名单比对,任何UNKNOWN条目进入人工研判。6.3 索引时投毒 (Index-time poisoning)提交一份内容为攻击者自定义的反馈或知识文档,宣称对已知支持问题拥有权威答案;随后换另一个用户身份重新查询。若你埋入的答案浮现出来,说明摄取管道信任了未认证输入。7.validate_finding契约:技能如何对接零误报验证技能第 6 节规定本类发现的验证契约,字段与 Decepticon 工具层一一对应:success_patterns:触发词输出分歧、构建时安装钩子触发的网络回调、埋入文档内容出现在其他用户的 RAG 响应中、模型吐出仅埋在该可疑数据集中的金丝雀字符串;negative_command:移除可疑构件后,执行相同的查询 / 构建;negative_patterns:输出相同、无回调、通用响应。在源码层面,该契约由 validate_finding 工具 实现:它在沙箱中执行poc_command,并用正则(DOTALL IGNORECASE)匹配success_patterns;关键在 ZFP(zero false positive)机制——如果去掉载荷的negative_command基线也命中了 success pattern,结果会被降级(demote),避免把良性噪声误报为漏洞。这与 verifier 技能 声明的五件套契约(poc_command/success_patterns/negative_command/negative_patterns/cvss_vector)完全一致。纯函数层面的校验逻辑在 capabilities/evidence.py 中:validate_evidence要求至少一条 success pattern 命中正样本、至少一条基线 pattern 命中负样本,且 success pattern 在负样本中零命中,正则非法时直接报错而不是静默降级为子串匹配。对于以 Markdown 报告落地的发现,还有 tools/reporting/evidence_contract.py 负责校验evidence_manifest指向的本地证据文件真实存在且为普通文件(拒绝符号链接),保证报告引用可追溯。对本文三类 PoC 的契约落地举例:触发词扫描的 success_patterns 可写成触发响应离群特征(如外传域名、指定字符串),negative_command 即前置无害短语的同一问题,negative_patterns 为正常答案形态;typo-squat 场景下 success 信号是安装钩子的网络回调日志,negative 是移除该依赖后重新构建无回调。8. 默认 CVSS 评分表技能第 7 节给出四种变体的默认 CVSS 向量,可直接作为报告初值(与validate_finding的cvss_vector参数格式一致):变体向量分值未锁版本框架依赖,尚无利用AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:L5.1已确认后门触发词AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N9.1安装钩子中窃取 token 的依赖AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:N10.0RAG 投毒(持久)AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:N9.6可以看出评分逻辑:纯暴露面(未锁版本、未利用)只是 Medium 级;一旦触发词确认或密钥实际流出,分值跃升至 9.0,其中安装时钩子窃取 token因影响范围跨到外部系统(S:C)拿到满分。9. 链式提升:供应链是体系性链条起点技能第 8 节是本 playbook 的战术核心:供应链是系统级链式起点(systemic chain starter)——单个被投毒的模型文件可以同时解锁所有其他 LLM 漏洞类型:prompt injection 变得轻而易举(模型已站在攻击者一边)、工具调用打到攻击者 URL、敏感信息泄露绕过脱敏层……因此技能给出两条硬性操作要求:在 engagement 清单中始终记录模型 适配器的 SHA 指纹与数据集 URL;未知 / 无签名的构件按首要线索(primary leads)对待。从源码结构看,链条在 Decepticon 中由图数据库中的enables/leaks/grants等边表达,analyst 泳道总览规定:当漏洞节点积累足够多时,加载 chain playbook 并调用plan_attack_chains(promoteTrue)持久化完整链条。该工具实现在 tools/research/tools.py 中,会遍历这些边寻找可组合的高危路径。对供应链发现而言,意味着一个 supply-chain 节点一旦验证通过,应当主动向它使能的其他 LLM 漏洞类型(prompt injection、工具调用劫持等)发出enables边,而不是孤立上报。10. 小结与技能间协作关系supply-chain技能是一份完整的单文件 playbook:识别信号 → 攻击向量 → grep 审计流 → 利用目标分级 → 三类 PoC → 验证契约 → CVSS 初值 → 链式提升,八节内容自成闭环。它与同泳道技能形成明确的分工边界:prompt-injection 负责内容进入模型后的注入面(其 tool-description injection 小节被本文第 3.5 节直接引用);data-and-model-poisoning 负责 LLM04:2025,即恶意权重由受害者自己的训练基础设施用攻击者数据生产的场景,与 LLM03 的外部构件投毒互补;verifier 阶段则消费本文第 6–8 节产出的validate_finding契约与 CVSS 向量,完成零误报升级。适用前提提醒:本文所有命令与字段以当前仓库内容为准,validate_finding需 HTTPSandbox 初始化后调用;CVSS 表中分值是该技能声明的默认初值,实际报告仍需结合目标环境复核。赞分享【免费下载链接】DecepticonAutonomous Hacking Agent for Red Team项目地址https://gitcode.com/gh_mirrors/de/Decepticon点击查看免费下载相关推荐Supply Chain Risk Auditor面向 npm、PyPI 与 Go 依赖树的供应链风险审计技能Supply Chain Risk Auditor面向 npm、PyPI 与 Go 依赖树的供应链风险审计技能 本文介绍 Trail of Bits 出品的AI 技能AI 插件应用安全网络安全AI 评测OWASP Top 10 2025 深度解读A03 软件供应链失效Software Supply Chain Failures防护指南OWASP Top 10 2025 深度解读A03 软件供应链失效Software Supply Chain Failures防护指南 本文以 OWASP应用安全ccg-workflow 红队技能red-team.md实战指南攻击链、C2、横向移动、免杀与供应链安全ccg workflow 红队技能red team.md实战指南攻击链、C2、横向移动、免杀与供应链安全 ccg workflow 在 templates上一篇RustFS 代码变更验证指南Commit 与 PR 评审的标准化风险核查流程下一篇Apache OpenDAL 错误语义重构新增 ErrorKind::Conflict 与条件失败判定收窄RFC 8145 解析创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考