Microsoft BitLocker – YellowKey zero-day exploit
286 points
• 5 days ago
• Article
Link
安全研究员 Chaotic Eclipse 发布了两个针对 Microsoft Windows 的零日漏洞利用工具，其中更严重的 YellowKey 能完全绕过 BitLocker 驱动器加密。利用方法极其简单：将特定文件复制到 U 盘，重启时按住 Control 键进入 Windows Recovery Environment，即可在无需任何加密密钥或认证提示的情况下直接访问受 BitLocker 保护的磁盘。该过程操作简便且不留痕迹——利用文件在一次使用后会从 U 盘上消失，研究人员称其具有明显的有意后门特征。
YellowKey 的影响极为严重：BitLocker 在全球数百万台个人、企业和政府设备上用于保护数据，而且在 Windows 11 中默认启用。尽管 BitLocker 的密钥与机器的 TPM 绑定，使得硬盘不能轻易在机器间直接迁移，但该漏洞仍可让任何对设备有物理访问的人绕过全部加密。研究人员指出，即便启用了 TPM+PIN 的完整防护的系统也可能受影响，不过针对该场景的概念验证尚未公开。报告称 YellowKey 在 Windows Server 2022 和 2025 上有效，但在 Windows 10 上无效。
第二个工具 GreenPlasma 则实现了本地权限提升：它通过操纵 CTFMon 进程，在 Windows 的 Object Manager 中放置精心构造的内存对象，使这些对象位于 SYSTEM 用户可写的区域，从而绕过常规访问控制。这样任何程序或普通用户都有可能提升为系统级权限。在服务器环境中尤其危险：一旦某个账号被攻破，就可能导致整台服务器被接管并暴露所有用户数据。与 YellowKey 不同，GreenPlasma 目前尚无完整的公开概念验证，但鉴于 Chaotic Eclipse 的历史记录，外界普遍认为其描述很可能属实。
Chaotic Eclipse 表示公开发布这些漏洞利用工具的原因与其与 Microsoft 安全团队的争执有关，称此前的漏洞报告被忽视或驳回。这导致其采取报复性披露：上个月先后曝光了 BlueHammer 和 RedSun，两者都通过利用 Windows Defender 提权获得了管理员权限。 BlueHammer 已被修补；Eclipse 称 Microsoft 已静默修补了 RedSun，但未有官方确认。至今 Microsoft 尚未就 YellowKey 或 GreenPlasma 做出公开回应，相关系统仍可能处于风险之中。
Security researcher Chaotic Eclipse has released two new zero-day exploits targeting Microsoft Windows systems, with the more severe one, called YellowKey, completely bypassing BitLocker drive encryption. The exploit works by simply copying specific files to a USB stick, rebooting into the Windows Recovery Environment while holding the Control key, and gaining immediate access to a BitLocker-protected drive without any encryption keys or authentication prompts. The process is remarkably straightforward and leaves no trace, as the exploit files disappear from the USB stick after a single use, which researchers say bears all the hallmarks of a deliberate backdoor.
The implications of YellowKey are significant because BitLocker protects millions of machines worldwide across home, enterprise, and government environments, and it is enabled by default in Windows 11. While the encryption keys are tied to a machine's TPM chip, meaning a drive cannot simply be moved between computers, the exploit still allows anyone with physical access to a device to bypass all encryption. The researcher notes that even systems using a full TPM-and-PIN setup are vulnerable, though a proof of concept for that scenario has not been publicly released. YellowKey reportedly works on Windows Server 2022 and 2025 but not on Windows 10.
The second exploit, GreenPlasma, performs a local privilege escalation by manipulating the CTFMon process to place crafted memory objects in Windows' Object Manager sections that the SYSTEM user can write to, bypassing standard access controls. This allows any program or regular user to gain full system-level access, which is particularly dangerous in server environments where one compromised account could lead to complete server takeover and access to all users' data. Unlike YellowKey, GreenPlasma does not yet have a complete publicly available proof of concept, but given Eclipse's track record, it is considered likely to work as described.
Chaotic Eclipse's motivation for releasing these exploits publicly stems from a dispute with Microsoft's security team, which allegedly dismissed previous vulnerability reports. This led to a series of retaliatory disclosures, starting with BlueHammer and RedSun last month, both of which granted system administrator privileges by exploiting Windows Defender. BlueHammer has since been patched, and Eclipse claims Microsoft silently patched RedSun, though there is no official confirmation. As of now, Microsoft has not issued an official response regarding either YellowKey or GreenPlasma, leaving affected systems potentially exposed.
156 comments • Comments Link
YellowKey 利用了 BitLocker 在默认的 TPM-only 配置下的弱点——在这种模式下，系统启动时驱动器会自动解密，无需用户验证。研究者通过利用 Windows 恢复环境，在系统已解锁后获得命令提示符，从而有效绕过了磁盘加密保护。
微软的安全实践因此受到质疑；有研究者指出，以前的漏洞（如 RedSun 和 Bluehammer）曾被悄然修补且未分配 CVE 、也未给予致谢，这被一些人视为淡化严重安全缺陷的模式。对于这类漏洞究竟是刻意后门还是单纯漏洞，社区内争议很大：某些行为——例如触发加密的特定文件名以及文件在使用后被删除——被拿来当作人为设计的证据，而非巧合。
该研究员称能实现对 TPM+PIN 的旁路，但这一说法遭到质疑，反对者认为要做到真正的旁路必须在 BitLocker 加密中存在实际后门；与此同时，研究员过去多次发现高质量零日漏洞，这又为其主张增添了一些可信度。纯 TPM 模式的 BitLocker 长期被批评过度依赖启动链完整性，因此很容易受到任何能够篡改预启动环境的攻击，比如修改 SMM 模块或利用 USB/ 蓝牙 堆栈。
固态硬盘上的硬件加密同样因不透明和历史缺陷而被质疑：有人认为像 BitLocker 这样的软件加密更可靠，也有人指出两者各有重大风险。讨论暴露出磁盘加密中的基本矛盾——自动解密的便利性与要求用户验证的安全性相互对立，很多人认为 TPM-only 模式在面对有准备的攻击者时几乎等同于没有加密，但在防止随意盗窃方面仍有一定作用。
还有评论指出，微软的生态绑定与合规模式的安全机制容易带来虚假的安全感，企业往往为了合规"打勾"而使用 BitLocker，而非真正以保护数据为先。 YellowKey 的影响已超出 BitLocker 本身，它引发了对任何依赖可信启动而无需用户验证的系统的安全担忧，涵盖移动设备和其他全盘加密方案。有人也联想到 TrueCrypt 在 2014 年突然终止并建议改用 BitLocker 的事件，认为当时可能存在类似的后门担忧，尽管 VeraCrypt 的延续与开源审计在一定程度上提供了保障。
总体上，这次讨论加深了对微软安全承诺的怀疑，很多人将 YellowKey 看作是故意后门或系统性疏忽的症状。共识是：TPM-only 的 BitLocker 无法对抗熟练的攻击者，尽管它能在一定程度上阻止随意窃取。该研究员凭借发现过多个高质量漏洞的历史，为其关于 PIN 旁路的说法增加了分量，但在公开演示之前仍需谨慎对待。最终，事件强调了在磁盘加密中平衡可用性与安全性的难题，表明即便依赖硬件的解决方案也并非万无一失，用户和组织必须根据自身威胁模型谨慎评估并考虑在默认配置之外增加额外的身份验证层。 • The YellowKey exploit targets BitLocker's default TPM-only configuration, where the drive automatically decrypts on boot without user authentication, effectively bypassing disk encryption by exploiting the Windows Recovery Environment to gain a command prompt on an unlocked system.
• Microsoft's security practices are under scrutiny, with researchers noting that previous vulnerabilities (RedSun and Bluehammer) were silently patched without CVEs or credit, suggesting a pattern of downplaying serious security flaws.
• There is significant debate over whether this is an intentional backdoor or a bug, with the exploit's behavior—such as specific file names triggering decryption and files disappearing after use—being cited as evidence of deliberate design rather than coincidence.
• The researcher's claim of a TPM+PIN bypass is met with skepticism by some, who argue that a true PIN bypass would require an actual backdoor in BitLocker's encryption, though others point to the researcher's track record of multiple zero-day exploits as credibility.
• TPM-only BitLocker is widely criticized as insecure because it relies solely on the boot chain's integrity, making it vulnerable to any attack that can manipulate the pre-boot environment, such as modifying SMM modules or exploiting USB/Bluetooth stacks.
• Hardware-based encryption in SSDs is also criticized for being opaque and historically flawed, with some arguing that software solutions like BitLocker are more trustworthy, while others note that both have significant vulnerabilities.
• The discussion highlights a fundamental tension in disk encryption: the convenience of automatic decryption versus the security of requiring user authentication, with many arguing that TPM-only mode is equivalent to no encryption against a determined attacker.
• Some commenters suggest that Microsoft's ecosystem lock-in and compliance-driven security create a false sense of protection, with businesses using BitLocker to tick boxes rather than genuinely secure data.
• The exploit's implications extend beyond BitLocker, raising questions about the security of any system that trusts the boot process without user verification, including mobile devices and other full-disk encryption solutions.
• There is concern that the TrueCrypt project's abrupt end and recommendation to switch to BitLocker in 2014 may have been influenced by similar backdoor concerns, though VeraCrypt's continued existence and open-source audits provide some reassurance.
The discussion reveals deep skepticism about Microsoft's commitment to security, with many viewing the YellowKey exploit as either an intentional backdoor or a symptom of systemic negligence. The debate centers on whether TPM-only BitLocker provides meaningful protection, with consensus forming that it is inadequate against sophisticated attackers but still valuable for deterring casual theft. The researcher's credibility, based on a history of high-quality exploits, lends weight to claims of a PIN bypass, though some remain cautious without public proof. Ultimately, the conversation underscores the challenges of balancing usability and security in disk encryption, with hardware-based solutions like TPMs introducing their own vulnerabilities. The broader implications suggest that users and organizations must carefully evaluate their threat models and consider additional authentication layers beyond default configurations.