當CrowdStrike正忙于應(yīng)付“全球最大規(guī)模藍屏事件”的客戶集體訴訟時，微軟公司本周發(fā)布的一個BitLocker安全補丁再次觸發(fā)“藍屏”事件。不過這次“藍屏”不是“藍屏死機”，而是重啟到Bitlocker的藍色恢復界面。

對于很多剛剛經(jīng)歷CrowdStrike事件驚魂未定的CIO和CISO們來說，微軟官方“藍屏補丁”事件不僅僅是傷口上撒鹽，更可能是徹底摧毀對IT服務(wù)商信心的“最后一根稻草”。

“官方藍屏補丁”

微軟的Windows驅(qū)動器加密工具BitLocker在兩次“藍屏事件”中都扮演了重要角色。在CrowdStrike的安全更新導致的全球最大規(guī)模IT系統(tǒng)崩潰事件中，使用BitLocker加密驅(qū)動器的用戶在恢復系統(tǒng)時需要手動輸入BitLocker密鑰，這大大拖延了系統(tǒng)恢復的時間。

在本周微軟的“藍屏事件”中，BitLocker的角色從“反串”晉升到了主角。事件起因是微軟在修復BitLocker安全漏洞的過程中，由于固件兼容性問題導致部分設(shè)備進入BitLocker恢復模式（下圖），導致大量用戶必須輸入恢復密鑰才能正常啟動系統(tǒng)。這迫使微軟撤回該補丁并建議用戶實施BitLocker安全漏洞的手動緩解措施。

微軟安全更新導致設(shè)備重啟到Bitlocker恢復界面

BitLocker是Windows的一個安全功能，通過加密存儲驅(qū)動器來防止數(shù)據(jù)泄露或被盜。通常情況下，只有在用戶更換硬件或TPM（受信任平臺模塊）更新等事件后，系統(tǒng)才會進入BitLocker恢復模式。而此次微軟補丁導致觸發(fā)恢復模式，顯然屬于程序bug而非“功能特色”，并迅速引起了業(yè)界廣泛關(guān)注。

該“藍屏補丁”影響多個Windows客戶端和服務(wù)器平臺，涵蓋Windows 10、Windows 11以及多版本的Windows Server，具體如下：

客戶端系統(tǒng)：Windows 11 23H2、22H2、21H2；Windows 10 22H2、21H2。

服務(wù)器系統(tǒng)：Windows Server 2022、2019、2016、2012 R2、2012、2008 R2、2008

此前已發(fā)生多次安全更新事故

類似的的安全更新問題在2022年8月的KB5012170更新中也曾出現(xiàn)，當時Secure Boot DBX（禁止簽名數(shù)據(jù)庫）的更新觸發(fā)了0x800f0922錯誤，導致部分設(shè)備進入BitLocker恢復模式。而在2023年4月，微軟再次修復了另一個導致BitLocker加密錯誤的問題，該問題在一些管理環(huán)境中被標記為報告錯誤，但并未影響驅(qū)動器加密本身。

在本月的補丁星期二，微軟還修復了7月Windows安全更新引發(fā)的BitLocker恢復問題。然而，微軟并未透露導致該問題的根本原因，也未詳細說明是如何修復的。

不可撤銷的緩解措施

由于補丁與設(shè)備固件不兼容導致部分設(shè)備進入BitLocker恢復模式，微軟最終決定撤回該修復補丁（CVE-2024-38058）。

但由于該漏洞極為嚴重（攻擊者可能通過物理訪問目標設(shè)備繞過BitLocker設(shè)備加密功能，從而訪問加密數(shù)據(jù)），微軟在8月的安全更新中正式禁用了該補丁，并建議用戶通過KB5025885公告中的手動緩解措施保護系統(tǒng)和數(shù)據(jù)。

微軟給出的手動緩解措施包括一個四階段的操作流程，需要重啟設(shè)備多次。需要格外留神的是，應(yīng)用這些緩解措施后，啟用了安全啟動（Secure Boot）的設(shè)備將無法移除該緩解措施，即使重新格式化磁盤也無濟于事。

微軟提醒用戶，在實施這些緩解措施之前，應(yīng)充分測試并了解所有可能的影響，因為一旦實施，撤銷將變得非常困難。

安全補丁不可隨意“敏捷”

雖然微軟總是建議用戶安裝最新更新，但此次“藍屏事件”再次提醒我們，安全補丁的兼容性和系統(tǒng)恢復問題仍是未來安全更新中的一大挑戰(zhàn)。

對于企業(yè)和用戶來說，最重要的是及時了解和跟進安全更新，同時在部署補丁和實施緩解措施時，不可盲目置信（即便是主流廠商），必須進行充分的測試和評估，以確保系統(tǒng)穩(wěn)定性與安全性的平衡。

此外，CrowdStrike和微軟相繼曝出“藍屏事件”，表明在網(wǎng)絡(luò)安全產(chǎn)品的QA和測試環(huán)節(jié)生搬硬套敏捷方法往往會產(chǎn)生嚴重的安全隱患。

正如一位安全人士對該事件的點評：

“這就是所謂的敏捷。微軟的產(chǎn)品曾經(jīng)很成功，因為他們有更多的QA而不是開發(fā)。然后，他們在開發(fā)Bing時改變了QA方法，并認為找到了最佳實踐（將Bing看作成功的衡量標準）”

“將開發(fā)和測試結(jié)合起來的敏捷方法，以“組合工程”的名義（首先在Bing團隊中使用）大肆宣傳。在Bing，創(chuàng)建程序化測試的任務(wù)被甩給開發(fā)人員，而不是專門的測試人員。QA仍然存在并且仍然很重要，但（安全產(chǎn)品）需要執(zhí)行的是最終用戶風格的“真實世界”測試，而不僅僅是程序化自動化測試?！?/p>