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

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

“官方藍(lán)屏補(bǔ)丁”

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

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

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

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

該“藍(lán)屏補(bǔ)丁”影響多個(gè)Windows客戶端和服務(wù)器平臺(tái)，涵蓋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)，當(dāng)時(shí)Secure Boot DBX（禁止簽名數(shù)據(jù)庫(kù)）的更新觸發(fā)了0x800f0922錯(cuò)誤，導(dǎo)致部分設(shè)備進(jìn)入BitLocker恢復(fù)模式。而在2023年4月，微軟再次修復(fù)了另一個(gè)導(dǎo)致BitLocker加密錯(cuò)誤的問題，該問題在一些管理環(huán)境中被標(biāo)記為報(bào)告錯(cuò)誤，但并未影響驅(qū)動(dòng)器加密本身。

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

不可撤銷的緩解措施

由于補(bǔ)丁與設(shè)備固件不兼容導(dǎo)致部分設(shè)備進(jìn)入BitLocker恢復(fù)模式，微軟最終決定撤回該修復(fù)補(bǔ)?。–VE-2024-38058）。

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

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

微軟提醒用戶，在實(shí)施這些緩解措施之前，應(yīng)充分測(cè)試并了解所有可能的影響，因?yàn)橐坏?shí)施，撤銷將變得非常困難。

安全補(bǔ)丁不可隨意“敏捷”

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

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

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

正如一位安全人士對(duì)該事件的點(diǎn)評(píng)：

“這就是所謂的敏捷。微軟的產(chǎn)品曾經(jīng)很成功，因?yàn)樗麄冇懈嗟腝A而不是開發(fā)。然后，他們?cè)陂_發(fā)Bing時(shí)改變了QA方法，并認(rèn)為找到了最佳實(shí)踐（將Bing看作成功的衡量標(biāo)準(zhǔn)）”

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