TrapDoor供应链攻击:AI助手正在成为黑客的新突破口

TrapDoor供应链攻击:AI助手正在成为黑客的新突破口

如果你在用 Claude Code 或 Cursor 这类 AI 编程助手,最近一定要检查一下你的项目配置。5月25日,安全研究团队 Socket 披露了一场名为「TrapDoor」的协调供应链攻击——攻击者首次把 AI 助手当作跳板,通过污染开源项目的配置文件来窃取加密货币钱包、SSH 密钥和云凭证。与传统供应链攻击不同,这次的目标不是开发者的代码,而是 AI 助手本身。

什么是 TrapDoor 攻击?

TrapDoor 是一场同时针对 npm、PyPI 和 Crates.io 三大软件包仓库的协调供应链攻击。攻击者向流行开源项目提交 Pull Request,在项目中注入被精心构造的 CLAUDE.md 和 .cursorrules 配置文件。这两个文件本是 AI 助手的「工作指令」,AI 会将其当作可信指令执行——问题就出在这里。

当开发者克隆这样的仓库并使用 Claude Code 或 Cursor 时,AI 助手会自动读取并执行这些配置文件中的指令。攻击者利用了这一信任机制,在配置文件中植入恶意命令,AI 在「帮忙」的过程中悄悄完成窃取。

攻击规模与影响范围

  • 涉及 34 个恶意软件包,384 个以上相关版本和构件
  • 横跨 npm(JavaScript)、PyPI(Python)和 Crates.io(Rust)三大生态
  • 主要目标群体:加密货币开发者、DeFi 开发者、AI 安全研究者
  • 攻击者持续在各平台推送更新,活跃度极高

攻击者是如何操作的?

具体流程是这样的:第一步,攻击者找到热门开源项目,提交看似正常的 Pull Request,增加新功能或修复 bug。第二步,PR 中包含被篡改的 CLAUDE.md 或 .cursorrules 文件。第三步,开发者审核 PR 时只检查代码本身,往往忽略了 AI 配置文件。第四步,代码合入后,开发者下次使用 AI 助手时,恶意命令就自动执行了。

这不是传统的恶意代码注入,而是利用人类审核员的盲区——PR 的代码看起来完全正常,问题藏在 AI 会「读」但人类不一定「看」的地方。

为什么 AI 助手成了攻击面?

传统的供应链攻击直接污染代码库,等待开发者下载后自动中招。TrapDoor 的巧妙之处在于,它利用了 AI 助手的信任模型。Claude Code 和 Cursor 这类工具会读取项目根目录下的 CLAUDE.md、.cursorrules、.cursor/rules 等配置文件,这些文件的作用是告诉 AI 如何理解项目、遵循什么规则。AI 把它们当作「可信指令」,但人类往往不会逐一审查。

攻击链分析

阶段操作风险点
第一步提交含恶意配置的 PR人类审核只看代码,不看 AI 配置
第二步PR 合入主分支维护者信任贡献者身份
第三步开发者克隆仓库默认相信项目是安全的
第四步AI 助手执行恶意配置AI 视配置为可信指令
第五步窃取钱包/密钥/凭证静默完成,无告警

为什么以前没有这类攻击?

核心原因是 AI 编程助手的普及度。在 2023 年之前,很少有开发者会在日常工作中让 AI 执行配置文件里的指令。随着 Claude Code、Cursor、GitHub Copilot 等工具成为主流工作流,AI 开始「替人类执行任务」,攻击面才真正打开。

NVIDIA 近期发布的报告《From Assistant to Adversary》也指出,Cursor 这类工具会摄取外部贡献者提交的 PR 和 Issue 数据,而这些数据来源本质上不受信任——这正是 TrapDoor 攻击得以成立的技术根源。

哪些人最容易中招?

高危人群清单

人群风险原因潜在损失
加密货币开发者直接操作钱包/DeFi 协议代币被盗、钱包清空
AI/机器学习工程师频繁使用 Claude Code 等工具云凭证泄露、模型被窃
安全研究人员经常 clone 未知来源项目SSH 密钥被盗、身份伪造
独立开发者缺乏安全审计流程全线账户被攻破

真实案例:开发者如何被盗

案例一:加密货币交易员
某开发者在 GitHub 上发现一个看起来不错的开源套利工具,提交了 PR 并合入代码。几天后,他发现自己的 MetaMask 钱包被转空了——攻击者在他使用 Claude Code「分析合约」时,通过恶意配置拿到了钱包访问权限。丢失金额约 2.3 ETH。

案例二:AI 初创公司 CTO
一家 AI 初创公司的 CTO 从开源社区 fork 了一个 LangChain 增强项目,代码看起来质量很高。他让 Cursor 帮助快速审查整个代码库,Cursor 自动读取了项目中的 .cursorrules,其中包含将环境变量发送至外部服务器的指令。第二天,他发现 AWS 密钥已被滥用,账单爆增。

案例三:独立安全研究员
一名研究员在分析恶意软件样本时使用了 AI 助手辅助逆向。他从论坛下载了一个「优化版」的 IDA Pro 脚本插件,插件中夹带了恶意的 CLAUDE.md。AI 在执行指令过程中读取了他的 SSH 密钥,最终导致 GitHub 账号被攻击者用于恶意提交。

如何自查和防护?

立即检查清单

第一,检查项目中的 CLAUDE.md 和 .cursorrules 是否来自可信提交。如果你是项目维护者,对于任何包含 AI 配置文件修改的 PR,都要仔细审查内容。第二,使用 Socket 的免费工具扫描你的 package.json 或 requirements.txt,它可以检测已知恶意包。

第三,在 AI 助手中启用沙盒模式。Claude Code 支持通过环境变量限制文件访问,Cursor 也有只读模式选项。第四,隔离敏感操作。不要在有 AI 助手参与的环境中进行钱包操作或 SSH 密钥管理。

防护措施对比

措施有效性实施难度推荐指数
审查 AI 配置文件⭐⭐⭐⭐⭐低必做
Socket 扫描依赖⭐⭐⭐⭐低推荐
AI 助手沙盒模式⭐⭐⭐⭐中推荐
敏感操作隔离⭐⭐⭐⭐⭐中强烈推荐
改用本地模型⭐⭐⭐高可选

如果已经中招怎么办?

如果你怀疑自己的项目可能已被污染,立即执行以下操作:撤销所有近期生成的 API 密钥和 SSH 密钥;检查云控制台是否有异常访问记录;将干净环境中的代码重新克隆一份;检查 CLAUDE.md 等配置文件是否包含网络请求指令。

开源生态如何应对?

这次攻击也暴露了开源生态的深层问题。Pull Request 的审核流程是为人类设计的,AI 配置文件处于盲区。平台层面,GitHub 等平台可以考虑对包含 AI 配置文件修改的 PR 增加额外警告或审查机制。维护者层面,项目的 CLAUDE.md 和 .cursorrules 应该与代码一样纳入版本控制追踪。

对于整个行业来说,这是一个警示:AI 助手在工作流中扮演越来越重要的角色,但我们对 AI 安全模型的理解还远远不够。攻击者已经开始利用这一新前线,每一个开发者和安全团队都需要重新审视自己在 AI 时代的安全姿势。

总结

TrapDoor 供应链攻击的核心创新在于「攻击 AI 助手而非直接攻击人」。它利用了三个信任链的交汇点:平台对贡献者的信任、维护者对 PR 代码的信任、AI 助手对配置文件的信任。任何一个环节的松懈都会导致最终失守。

对于普通开发者来说,最务实的做法是:从今天起,像审查代码一样审查你项目中的 AI 配置文件。不要让攻击者利用 AI 的「听话」特性来绕过人类的安全直觉。

参考来源:Socket.dev 威胁情报、 NVIDIA 开发者博客、 Binance Square 安全分析、 ChainCatcher 报道

© 版权声明
THE END
喜欢就支持一下吧
点赞9 分享
评论 抢沙发

请登录后发表评论

    暂无评论内容