Security Blog

本不该有可收割之物

#66

October 2, 2026 · By Marketing team

一个被篡改的 Bitwarden CLI 从 334 台开发者机器上收割了 SSH 密钥、云凭证和 npm 令牌。真正的问题不在于恶意软件如何进入，而在于每一个秘密都以明文文件的形式躺在那里，等待被读取。

昨天，一个被篡改的 Bitwarden CLI 版本从 334 台开发者机器上收割了 SSH 密钥、AWS 凭证、npm 令牌、环境变量、shell 历史记录以及 Git 秘密。

今天是 Bitwarden。上个月是 Axios。再往前是 Checkmarx。明天可能是一个 VS Code 扩展，或者 Acrobat，或者一个 Homebrew formula，或者一个 Docker 镜像。攻击向量每周都在变，结果始终如一。

恶意软件落地。它读取 ~/.ssh/。它读取 ~/.aws/credentials。它读取 ~/.npmrc。它读取 ~/.git-credentials。它读取 shell 历史记录、环境变量、浏览器密码存储。它把所有内容打包，发送到 C2 服务器。

而且它奏效了。每一次都奏效。

这次收割

Bitwarden 的载荷——一个名为 bw1.js 的 10 MB 混淆文件——并没有试图破解任何加密。它不需要。以下是它收集的内容，由 Socket 和 Aikido 记录：

随后，它利用窃取的 npm 令牌重新发布受害者维护的其他软件包，进一步扩散自身。受害者变成了传播媒介。

这一切都不需要破解加密。上述每一个秘密都是文件系统上的一个文件，任何以该用户身份运行的进程都可以读取。

Bitwarden 的密码库加密并未被攻破。其零知识架构经受住了考验。恶意软件从未触及密码库。

它也不需要。

密码库保护的是库内的内容。但 SSH 密钥从来不在密码库里。AWS 凭证从来不在密码库里。npm 令牌、Git 凭证、.env 文件中的 API 密钥——这些都不存放在密码管理器中。它们以明文形式存在于点文件中，存在于每一台开发者的机器上。

攻击者明白这一点。这个密码库不过是这栋房子里的一个上锁保险柜，而房子里每个抽屉都是敞开的。

现在就打开一个终端。看看您机器上都有什么。

~/.ssh/id_ed25519 —— 您的私钥。明文文件。

~/.aws/credentials —— 您的云访问权限。明文文件。

~/.npmrc —— 您的发布令牌。明文文件。

~/.git-credentials —— 您的仓库访问权限。明文文件。

十几个项目目录中的 ~/.env —— API 密钥、数据库密码、签名秘密。全部是明文文件。

任何以您的用户身份运行的进程都可以读取所有这些内容。不需要提权。不需要漏洞利用。只需要 cat。

这就是 2026 年的默认开发者环境。我们把密码放进加密的密码库，却把其余的一切都留在明处。

每一次供应链攻击之后，行业都会问同一个问题：如何阻止恶意软件进入？

更完善的 CI/CD 安全。代码签名。依赖扫描。沙箱运行时。这些都不错，但没有一项是足够的。攻击面过于宽广。入口太多——包管理器、浏览器扩展、IDE 插件、OAuth 应用、被篡改的构建工具。您无法封死每一个入口。

正确的问题是：当恶意软件不可避免地在开发者机器上获得执行权限时，它会找到什么？

如果答案是"数百个位于可预测文件系统位置的明文凭证"，那么再多的供应链加固也无济于事。您是在一个球门就大开在身后的场地上做防守。

修复之道不是更好的恶意软件检测。不是给 npm install 加沙箱。不是更快的事件响应时间。

修复之道是：秘密不应以磁盘文件的形式存在。

SSH 密钥应在认证瞬间由硬件派生——而不是存放在 ~/.ssh/ 中。云凭证应从绑定硬件的身份按会话签发——而不是写入 ~/.aws/。API 令牌应受范围限制、短暂有效、由硬件门控——而不是留在 .env 文件里。

当一个凭证只存在于硬件安全模块内部和使用期间的短暂进程内存中时，恶意软件就无从读取。没有文件可以窃取。没有点文件可以抓取。进程运行起来，什么也找不到，然后继续前进。

这并非理论。绑定硬件的凭证今天已经存在。WebAuthn PRF 可以从一次实体认证器的触碰中派生出加密密钥——这些密钥从不接触文件系统。技术已经就绪，只是行业尚未将其采纳为默认做法。

如果您受到了 Bitwarden CLI 被篡改事件的影响：

如果您未受影响，行动是一样的。看看您的机器。数一数那些明文秘密。问问自己，当某个恶意程序以您的用户身份运行时——不是"如果"，而是"何时"——会发生什么。

答案应当是：什么也不会。本不该有可收割之物。