Bitwarden 劫案——如何在不使用密码的情况下闯入密码库

原文 ↗ Hacker News 讨论 ↗

安全研究人员指出，Bitwarden 的 Windows 客户端曾存在一个现已修复的漏洞：任何以当前用户身份运行的进程都可以通过 DPAPI 提取用于解密生物识别解锁保险库的密钥，而无需输入密码或进行生物识别验证。评论者指出，这种攻击需要本地访问权限，并且在被攻破的 Active Directory 环境中最具威力；但他们借此强调了 Windows 在应用隔离、旧协议以及 `%AppData%` 等文件系统约定方面更广泛的弱点。讨论随后扩展到密码管理器的现实风险与收益之争：一方面它们具有“单点故障”的性质，另一方面密码重复使用的问题又非常普遍。

Bitwarden 问题的范围

  • 该漏洞仅影响 Windows，与 Bitwarden 在 Windows 上的生物识别解锁有关。
  • 原始缺陷：任何以相同低权限用户运行的进程都可以读取一个 JSON 文件，并向 DPAPI 请求“生物识别密钥”来解密保险库，无需 Windows Hello 提示，也不需要额外权限。
  • 在某些渗透测试场景中，使用域管理员权限从 Active Directory 中提取 DPAPI 备份密钥并离线解密保险库；在另一些场景中，只需要本地用户访问权限。
  • 据称 Bitwarden 已在 v2023.4.0 中修复了该设计，并更改默认行为：在使用 Windows Hello 时，启动后至少要输入一次主密码。

争论：严重漏洞还是被夸大了？

  • 一些人认为这篇博客和标题有诱导点击之嫌，理由如下：
    • 需要本地访问权限（有时还需要域被攻破），而这在很多情况下本来就已经是“游戏结束”。
    • 这种攻击非常专门化，而且已经打补丁。
  • 另一些人则认为它仍然值得注意，因为：
    • 它避开了更吵闹的手法（键盘记录器、内存转储），并且可能绕过某些终端防护。
    • 本地访问可能来自被攻陷的同事或不可信软件，而不只是显而易见的“物理攻击”。

生物识别、DPAPI 与平台差异

  • 批评意见：Bitwarden 最初只是用 Windows Hello 来确认“用户在场”，然后把一个对称保险库密钥存入 DPAPI，而任何同一用户进程（或通过 AD 备份密钥的域管理员）都可以取回它。
  • 建议的正确模式：Windows Hello 应该持有一个非对称密钥；其私钥（由生物识别保护）先加密保险库密钥，然后再把它放入 DPAPI。
  • Android/iOS 被认为更容易保护，因为有应用沙箱和钥匙串模型；帖子里没有提到那边存在类似问题。
  • 还提到了 macOS/App Store 版本在生物识别和 Keychain 方面的行为，但细节仍不清楚。

Windows AppData、沙箱与安全模型

  • 对 %AppData% 以及“任何作为该用户运行的进程都能读取该用户任意应用数据”的通用模型提出了强烈批评。
  • 其他人回应说这本就是设计如此：AppData 从来就不是为了当作安全存储；如果你能以某个用户身份运行代码，就能把他们的秘密导出。
  • 围绕以下内容展开了广泛讨论：
    • Windows 相比移动操作系统缺乏强默认应用隔离。
    • UWP、AppContainer、MSIX，以及即将到来的基于文件系统的隔离等尝试，都受制于向后兼容和开发者阻力。

密码管理器作为单点故障

  • 有些人不信任密码保险库，认为它们显然是保存“你所有秘密”的 SPOF。
  • 许多人反驳说：
    • 没有它们，用户会重复使用弱密码，实际情况更糟。
    • 密码保险库加上强主密码和 2FA/MFA 是一个不错的折中方案。
    • 已经解锁的保险库被攻破当然很糟，但本地恶意软件通常也可以窃取活动会话或记录按键。
  • 讨论了以下缓解措施：
    • 记住少数关键密码，不放进保险库。
    • 使用硬件令牌（例如安全密钥）以及单独的 2FA 存储。