每周下载量 27,000 次的 npm 包悄悄窃取 OpenAI 令牌
一个名为 codexui-android 的恶意 npm 包在未知时间段内悄悄窃取了安装它的开发者的 OpenAI 身份验证令牌。该包每周下载量约 27,000 次，它将自己伪装成一个合法的 OpenAI Codex 模型用户界面。在这副熟悉的外表之下，它正在运行一个隐蔽的凭据收集操作，安全研究人员现在将其归类为一次教科书般的 npm 供应链攻击，大规模地窃取 OpenAI 令牌。
这一发现再次尖锐地提醒我们，软件包注册表本身并不安全，仅凭流行程度并不能表明其值得信赖。
codexui-android 如何在看似合法的包中隐藏令牌盗窃行为
这次攻击依赖于一种简单但有效的欺骗手段：构建开发者真正想要使用的东西，然后添加在后台静默运行的恶意逻辑。codexui-android 包为 OpenAI 的 Codex 提供了一个功能完备的界面，这意味着开发者会安装它、测试它，并将其保留在自己的项目中，通常不会质疑该包在网络层面做了什么。
这种方法被称为特洛伊木马化包攻击。恶意代码被嵌入到一个看似有用的工具中，绕过了开发者自然而然会对一个明显无效或构建粗糙的包产生的怀疑。该包泄露了 OpenAI 刷新令牌，这种长期凭证允许应用程序请求新的访问令牌，而无需用户再次登录。
名称 codexui-android 也遵循了一种暗示其合法性的命名惯例。它借用了 OpenAI Codex 产品的品牌价值，同时添加了一个平台特定的后缀，使其看起来像是一个为移动端场景而专门构建的工具。开发者在 npm 上搜索与 Codex 相关的工具时，完全没有明显的理由去怀疑它。
窃取的 OpenAI 刷新令牌实际上能让攻击者做什么
刷新令牌不仅仅是密码。在许多身份验证系统中，它们实际上是万能钥匙。当攻击者获得一个有效的刷新令牌后，他们可以反复生成新的访问令牌，即使在原始会话结束或密码已更改之后，仍能保持对账户的持久访问。
对于 OpenAI 账户而言，这种访问可能意味着未经授权使用付费 API 额度、访问存储的提示词或微调模型数据、可能暴露通过 API 传递的专有代码，并在组织环境中横向获取与同一账户关联的团队资源。
在开发者环境中，这种风险会迅速叠加。工程师经常使用具有较高权限的 API 密钥和令牌。在 CI/CD 流水线或共享开发环境中，一个遭到入侵的刷新令牌就可能为攻击者提供一个持久的立足点，既难以检测，又难以彻底修复。这种连锁效应与 Dropbox Sign 数据泄露事件 中的情况相似，在该事件中，窃取的凭证打开了通往互连系统的途径，其影响远超出了最初被攻陷的点。
npm 生态系统为何让供应链攻击易于规模化
npm 注册表托管着超过两百万个软件包。发布新包所需的身份验证极少，而注册表的开放性正是其受全球开发者社区广泛使用的原因。这也是它反复成为供应链攻击者目标的原因。
codexui-android 事件表明，攻击者是如何利用支撑开源开发的信任模型的。开发者通常认为下载量可观的包已经经过了一定程度的社区审查。这种假设正变得越来越危险。下载量可以被人为夸大，而实际使用情况并不等同于经过了安全审查。
npm 供应链攻击这个更广泛的问题并不新鲜，但将目标对准 AI 工具则标志着一个新的演变。随着开发者将大型语言模型 API 集成到生产系统中，用于认证这些集成的令牌便成了高价值目标。攻击者显然已经意识到了这一转变。模仿 AI 开发者工具的软件包是一类新兴的威胁，安全社区仍在努力大规模地应对这一威胁。
面向开发者的纵深防御：凭据隔离、网络分段及其他
codexui-android 事件指向了几种具体的实践，可以降低此类攻击带来的风险。
凭据隔离 是最直接的缓解措施。API 令牌和刷新令牌应尽可能缩小其使用范围，存储在密钥管理服务中而不是环境变量或配置文件中，并定期轮换。如果令牌被盗，有限的作用范围意味着有限的损害。
依赖审计 应该成为任何开发工作流程中的标准环节。诸如 npm audit 之类的工具，以及第三方软件组成分析平台，可以标记出行为异常或存在已知漏洞的包。在 package-lock 文件中锁定依赖版本，并在接受更新前审查更改，也能降低遭受恶意版本推送的风险。
网络出站流量监控 可以捕获审计工具遗漏的泄露行为。如果开发环境或 CI/CD 流水线被配置为对意外的出站连接发出警报，那么试图将被盗令牌发送回家的包就会变得可被检测。
最小权限原则 适用于每个层面。开发机器不应使用授予生产级访问权限的凭据运行。CI/CD 流水线应使用运行时生成的短期令牌，而不是长期存储的密钥。
最后，现在检查你自己已安装的、涉及认证流程的包是一项值得去做的工作。codexui-android 事件不太可能是孤立事件。审计你的 node_modules 中的内容，检查你的 API 令牌所携带的权限，并对任何触及凭据存储的包进行更严格的审视。
供应链攻击之所以能够成功，是因为它们大规模地利用了信任。从你的技术栈中最敏感的凭据开始，一次一个依赖地重新构建这种安全态势，是当今每个开发者最切实可行的应对方式。
