当CrowdStrike正忙于应付“全球最大规模蓝屏事件”的客户集体诉讼时，微软公司本周发布的一个BitLocker安全补丁再次触发“蓝屏”事件。不过这次“蓝屏”不是“蓝屏死机”，而是重启到Bitlocker的蓝色恢复界面。对于很多刚刚经历CrowdStrike事件惊魂未定的CIO和CISO们来说，微软官方“蓝屏补丁”事件不仅仅是伤口上撒盐，更可能是彻底摧毁对IT服务商信心的“最后一根稻草”。 “官方蓝屏补丁” 微软的Windows驱动器加密工具BitLocker在两次“蓝屏事件”中都扮演了重要角色。在CrowdStrike的安全更新导致的全球最大规模IT系统崩溃事件中，使用BitLocker加密驱动器的用户在恢复系统时需要手动输入BitLocker密钥，这大大拖延了系统恢复的时间。在本周微软的“蓝屏事件”中，BitLocker的角色从“反串”晋升到了主角。事件起因是微软在修复BitLocker安全漏洞的过程中，由于固件兼容性问题导致部分设备进入BitLocker恢复模式（下图），导致大量用户必须输入恢复密钥才能正常启动系统。这迫使微软撤回该补丁并建议用户实施BitLocker安全漏洞的手动缓解措施。 微软安全更新导致设备重启到Bitlocker恢复界面 BitLocker是Windows的一个安全功能，通过加密存储驱动器来防止数据泄露或被盗。通常情况下，只有在用户更换硬件或TPM（受信任平台模块）更新等事件后，系统才会进入BitLocker恢复模式。而此次微软补丁导致触发恢复模式，显然属于程序bug而非“功能特色”，并迅速引起了业界广泛关注。 该“蓝屏补丁”影响多个Windows客户端和服务器平台，涵盖Windows 10、Windows 11以及多版本的Windows Server，具体如下： 客户端系统：Windows 11 23H2、22H2、21H2；Windows 10 22H2、21H2。 服务器系统：Windows Server 2022、2019、2016、2012 R2、2012、2008 R2、2008 此前已发生多次安全更新事故 类似的的安全更新问题在2022年8月的KB5012170更新中也曾出现，当时Secure Boot DBX（禁止签名数据库）的更新触发了0x800f0922错误，导致部分设备进入BitLocker恢复模式。而在2023年4月，微软再次修复了另一个导致BitLocker加密错误的问题，该问题在一些管理环境中被标记为报告错误，但并未影响驱动器加密本身。在本月的补丁星期二，微软还修复了7月Windows安全更新引发的BitLocker恢复问题。然而，微软并未透露导致该问题的根本原因，也未详细说明是如何修复的。 不可撤销的缓解措施 由于补丁与设备固件不兼容导致部分设备进入BitLocker恢复模式，微软最终决定撤回该修复补丁（CVE-2024-38058）。但由于该漏洞极为严重（攻击者可能通过物理访问目标设备绕过BitLocker设备加密功能，从而访问加密数据），微软在8月的安全更新中正式禁用了该补丁，并建议用户通过KB5025885公告中的手动缓解措施保护系统和数据。 微软给出的手动缓解措施包括一个四阶段的操作流程，需要重启设备多次。需要格外留神的是，应用这些缓解措施后，启用了安全启动（Secure Boot）的设备将无法移除该缓解措施，即使重新格式化磁盘也无济于事。 微软提醒用户，在实施这些缓解措施之前，应充分测试并了解所有可能的影响，因为一旦实施，撤销将变得非常困难。 安全补丁不可随意“敏捷” 虽然微软总是建议用户安装最新更新，但此次“蓝屏事件”再次提醒我们，安全补丁的兼容性和系统恢复问题仍是未来安全更新中的一大挑战。对于企业和用户来说，最重要的是及时了解和跟进安全更新，同时在部署补丁和实施缓解措施时，不可盲目置信（即便是主流厂商），必须进行充分的测试和评估，以确保系统稳定性与安全性的平衡。 此外，CrowdStrike和微软相继曝出“蓝屏事件”，表明在网络安全产品的QA和测试环节生搬硬套敏捷方法往往会产生严重的安全隐患。 “这就是所谓的敏捷。微软的产品曾经很成功，因为他们有更多的QA而不是开发。然后，他们在开发Bing时改变了QA方法，并认为找到了最佳实践（将Bing看作成功的衡量标准）”一位安全人士对该事件进行了点评，“将开发和测试结合起来的敏捷方法，以“组合工程”的名义（首先在Bing团队中使用）大肆宣传。在Bing，创建程序化测试的任务被甩给开发人员，而不是专门的测试人员。QA仍然存在并且仍然很重要，但（安全产品）需要执行的是最终用户风格的“真实世界”测试，而不仅仅是程序化自动化测试。”   转自GoUpSec，原文链接：https://mp.weixin.qq.com/s/1ZbeJHWKLhKQRb_7LpRAKw 封面来源于网络，如有侵权请联系删除