今年7月,一場大規模的IT故障事故影響全球,起因竟是資安業者CrowdStrike的EDR產品更新,導致全球850萬臺Windows電腦死當。
這起事件發生在臺灣時間在7月19日(周五)的中午過後,雖然CrowdStrike事後號稱他們在1小時後就修復問題,並在兩個多小時後發布緩解方法,但這場電腦與伺服器大當機的風暴,在短短幾個鐘頭之內,就已經蔓延全球。
究竟這次大當機事故是如何造成?有哪些重要議題需要探討?例如,資安業者部署驗證測試發生的問題,管理方便可能導致的風險集中,以及過度依賴單一平臺與供應商的可能風險,還有數位韌性落差等,都成為大家關注的焦點。
由於整起事件在這段期間發生的狀況太多,使得相關檢討的資訊與重要議題容易被忽略,不少新聞報導僅將焦點放在局部事件,為此我們歸納出5大議題,幫助大家快速檢視需檢討的重要面向。
問題1:業者更新前為何未做好部署驗證測試?
所有人質疑的第一個問題在於,資安業者為何在更新前沒有做好部署驗證測試?釀成這次大規模事故。
事隔6天之後(7月24日),對於更新出包致Windows電腦死當,CrowdStrike公布初步事後檢討(PIR)報告。
他們表示,這次事件的發生時間,是在世界協調時間(UTC)7月19日上午4點09分,也就是臺灣時間同一天中午12點09分。
關於問題的發生原因,簡單來說,主要出在派送「Rapid Response Content」的環節,加上這個缺陷在驗證檢查期間未被檢測到,使得Falcon感應器在載入這些內容後,導致越界記憶體讀取,進而引發Windows電腦當機。
相隔1小時18分後,雖然CrowdStrike撤回有問題的更新,促使後續才連線的系統可以不受影響。但是,先前更新的系統已經受到影響,災情已經擴散。
具體而言,為了收集新型威脅技術的telemetry資料,CrowdStrike經常針對Windows感測器發布內容配置的更新。主要更新方式有兩種,一種是隨感測器同時發布,一種是名為「快速回應內容」(Rapid Response Content)發布,而這次問題是發生在後者。
CrowdStrike解釋,一般而言,感測器更新都會先進行內部測試,再釋放給早期使用者,最後才廣泛提供給客戶。
而快速回應內容的更新,是為了快速應對威脅而設計,其更新內容為IPC範本實例,用來告訴感測器要偵測哪些行為或攻擊。它的更新內容派送流程,將會驗證、確認更新內容無誤,再透過Channel Files部署到端點,也就是會透過內容驗證器檢查IPC以確保其正確性。
CrowdStrike接著說明詳細狀況:他們今年2月引入新感測器功能,以監控可能濫用Windows機制的攻擊技術。而這些IPC範本實例,後續已在測試環境中通過壓力測試,並在測試的Production環境中表現正常,經歷3次額外的Rapid Response Content更新部署。
只是,7月19日當天部署兩個IPC範本實例後,有個IPC範本實例存在未被偵測到的錯誤,加上內容驗證器有Bug,使得有問題的更新內容卻通過驗證。
綜觀上述事發說明,我們最好奇之處在於,為何Rapid Response Content的更新,只有進行壓力測試?卻不像Falcon感測器的更新,都會經過較嚴謹的部署更新測試?可惜,我們在CrowdStrike這份報告中,並未看到對應的解釋,無法得知這麼做的原因與考量。
是否因為公司要在產品安全功能上求快,導致沒有在安全與快速之間拿捏好平衡,也成為大家質疑之處。或許,在駭客零時差漏洞利用入侵越來越氾濫的今日,迫使資安業者更想要早一步偵測入侵跡象,但這次事件顯示輕忽最根本的安全考量,成為警惕。
而且,在這次事件後,該公司先前發生的資安軟體更新事故也被提起。今年4月,CrowdStrike其實就有類似狀況,當時更新出包是導致Linux平臺系統核心崩潰,影響Debian、Rocky Linux等;公司高層甚至還被挖出在其他公司的黑歷史——CrowdStrike創辦人暨執行長George Kurtz早年是資安大廠McAfee的高階主管,他在職時,McAfee防毒軟體也曾出現一次錯誤更新,導致全球用戶電腦癱瘓。
因此,CrowdStrike於7月24日PIR報告中,提出4大改進面向,以防範事件再次發生。這應該就是他們對於這次事件所得到的教訓。具體而言,包括:
(一)加強軟體測試程序:當中提及將為內容驗證器增加額外的驗證檢查,以及將改善快速回應內容的測試流程。
(二)提升系統韌性與恢復能力:將強化Falcon感測器中的錯誤處理機制。
(三)優化部署策略:將採分批部署策略,先進行小範圍系統進行測試部署,再逐步擴大範圍;並針對分批部署期間,強化感測器和系統性能的監控,也將提供更新通知,以及更大控制權,包含允許選擇更新的部署時間與位置。
(四)實施第三方驗證:將採取多次獨立的第三方安全程式碼審查;對於從開發到部署流程進行獨立審查。
另一方面,在0719事故後,我們還注意到,有其他資安業者公布自家軟體與內容更新的發布流程,以及整體發布策略。例如,7月23日有Fortinet,7月19日有Bitdefender。
顯然這次事件的發生,不僅是CrowdStrike被迫詳細解釋其更新流程、事前測試,協助企業用戶可以了解狀況,也促使資安業界可藉此機會重新評估與改進,並促使一些業者對其用戶公開自家作法,希望獲取用戶信任。
不過,若是換個角度思考,這些資安業者目前提出的作法夠周延了嗎?只有自家的監督與稽核,卻沒有外部驗證,是否足以避免問題再次發生?以及企業分散風險的必要性,仍值得繼續深思,這也將是我們接下來繼續探討的議題。
問題2:微軟為何要開放作業系統核心模式驅動程式使用
這次Windows大當機是因為資安業者而起,加上有國外媒體報導微軟提到2009年的歐盟協議,指出微軟有義務將自家資安產品使用的API,開放給外部軟體開發商。
這也讓有些人將此事件的焦點,放在微軟的開放生態體系,因為他們為何允許資安業者使用核心模式驅動程式(Kernel-Mode Driver)?以及微軟對第三方解決方案是否有相應的安全措施?
對於這方面的問題,在7月27日,微軟企業與作業系統安全副總David Weston在官方網站發表文章,針對這方面與Windows安全最佳實踐提出說明。
David Weston談到資安解決方案使用Windows核心模式驅動程式的好處,包括:可以獲得系統層級的監控能力,偵測Bootkits與Rootkits,也可加快資料收集與分析,並提供防篡改能力。
以防篡改而言,資安產品的驅動程式為了能夠盡早載入,以便在最早的時間點可以觀察到系統事件,為此,Windows也提供ELAM驅動程式,這是個早期啟動防惡意程式的機制,而CrowdStrike也有簽署CSboot驅動程式來作為ELAM,能在系統啟動過程載入。
接下來,David Weston也解釋了核心模式驅動程式架構(KMDF),並指出所有在核心層級執行的程式碼,都需要廣泛的驗證,因為不像一般用戶端應用程式,故障後重新啟動就能恢復。
至於要如何避免這樣的問題?David Weston提到,資安產品可以在核心使用最小化情形下,減少可用性問題的風險,並維持充分的安全性與偵測能力,例如,盡量減少對於核心模式的依賴,像是微軟已經致力於將複雜的Windows核心服務,從核心模式移到使用者模式,好處是,如果有問題發生,系統也容易恢復。
同時,他也指出多種Windows在使用者模式下,可防止竄改的方法。例如,微軟近期發表名為Virtualization-based security(VBS)的記憶體保護區,就可以不用透過核心模式驅動程式來防篡改;還有去年底微軟推出的Event Tracing for Windows(ETW)新功能,都是可以平衡系統的安全性與穩定性的方法。
另外,David Weston還解釋微軟如何測試、簽署驅動程式,以及第三方廠商如何透過Windows Update等方式,將驅動程式發布給用戶。
整體來看,微軟傳達的重點在於,他們已發展一些作法,可限縮這次更新出包的問題面,並持續發展中,也將與第三方廠商加強相關合作。不過,該公司沒有很確切說明哪些策略會強制執行。
至於有人論及封閉生態系統、開放生態系統、開源生態系統,在當前環境的發展態勢,這是多年來都在持續討論的大議題。事實上,每一個生態都有對應之道,並且持續隨著整體環境而演變。
儘管外界有一些人士認為,微軟可能轉向蘋果的封閉生態路線,但Windows多年來都是朝向開放的路線,因此這只能等待時間去印證這個預測。
問題3:IT系統風險過於集中?
這次事件之所以帶來大規模影響,與CrowdStrike、Windows用戶數量有關。
基本上,微軟Windows作業系統在全球個人電腦與伺服器的用戶數,是數以億計,而這次事故中的關鍵業者CrowdStrike,雖然僅有企業用戶安裝其EDR產品,但根據該公司最新財報顯示,全球有多達24,000家企業是他們的客戶,並且約有6成都是《財富》全球500強的企業。
這也不難看出,由於許多大型企業都採用CrowdStrike,使得這次事件影響規模如此顯著。
對於企業組織而言,採用單一廠商的解決方案帶來集中管理的好處,雖然不像採用多個廠商的解決方案,可能使攻擊表面增加,但仰賴單一廠商,往往也導致風險集中,是否要將雞蛋放在同個籃子的老問題,是此事件後的反思焦點;對於整體國家而言,也有人憂心一家業者市占太大而有風險集中問題,不過,有這方面考量的探討似乎並不多,或是相關議題需要更廣泛看待,也許之後還會有進一步討論,尤其是監管單位是否會介入,他們的態度動見觀瞻。
以企業組織而言,在我們後續追蹤採訪中,就有一家醫療單位的主管就指出,這次事件影響到院內部分主機,因為這些主機是使用CrowdStrike的EDR產品,其餘主機使用另一家廠商的產品,也因此,醫院最繁忙的門診系統未受影響。
但他們仍然學到一些經驗,就是在雙主機備援機制方面,也打算要採用不同廠商的防護服務,如此一來,即便一家廠商服務出問題,另一臺備援主機的運行不會受到影響。
問題4:企業應變能力低於預期,對於責任歸屬出現互踢皮球的狀況
在0719事故發生後的復原上,有些企業很快完成,但有些企業受影響裝置數量龐大,因此需要一定的時間。但更受全球關切的是,有些企業復原天數超乎預期,達美航空就是一例,這也成為企業引以為鑑的狀況。
基本上,這次許多受影響的企業組織,大多數都在周五至周日恢復。以臺灣為例,有醫院受到的影響只有半小時至1小時,桃園機場在當日下午5點多宣布受影響的7家航空公司,之後陸續恢復報到畫位服務;也有一些影響狀況較嚴重,像是有資服業者花上3天時間復原。
國際間的狀況也多是如此,例如,紐西蘭KiwiBank在當地周五早上11點多,宣布服務受影響,週六早上8點已讓網路銀行、App與ATM的恢復正常運作;另一家ASB銀行週六上午表示復原部分,週日上午全數服務恢復。
不過,這些狀況的發生,也讓災難復原、營運持續計畫(BCP),以及數位韌性等議題,受到更多企業組織的關注。畢竟,不論軟硬體或服務,都存在系統故障停擺的可能性,平時是否有這方面的計畫,甚至是營運持續的演練,都是企業縮短事故影響的重要環節。
而在眾多受到CrowdStrike影響IT運作的企業中,達美航空面臨的狀況最受外界關注,他們的處理過程遇到許多挑戰,也形同幫大家上了一課。因為該公司比其他公司更晚了幾天回復上線,導致其航班取消數量、影響客戶程度,也是最大。雖然達美航空執行長Ed Bastian在7月31日接受CNBC採訪時指出,該公司有4萬臺Windows伺服器需要手動重啟,數量相當龐大,但復原速度相對較慢也是不爭的事實。
在災情與復原狀況之外,這場事故也帶來一些爭議,像是後續衍生不少提告與求償的消息。例如,災情發生隔幾天,就有馬來西亞數位部長向微軟、CrowdStrike索賠的消息傳出。
達美航空更是以航班取消及公司形象受創為由,表示將提告並向CrowdStrike求償5億美元,之後CrowdStrike反指達美試圖推卸全部罪過,微軟也指出達美航空拒絕協助及基礎架構太過老舊,這些提告與求償的爭議,到現在(9月初)還沒有初步認定的共識,是要確認誰該為這起事件帶來的損失負責?還是就像天災發生那樣自行吸收損失?
不過,美國運輸部也介入此事,調查達美航空處置是否得當。換言之,企業的應變與復原能力仍是此事件的關鍵。
當然,CrowdStrike自身的應變能力也是焦點,像是CrowdStrike對外坦承事故的時間點太晚,在當時飽受各界批評。
例如,CrowdStrike在19日下午1點43分對其用戶發出資安公告,但該公告須以用戶身分登入才能瀏覽,外界只能經由用戶轉貼,才能得知廠商坦承此事;還有我們在當日下午近3點詢問該公司臺灣總經理陳琤琤,她表示未被授權發言而無法說明。
這些狀況,也使得一開始只有IT、資安圈相對了解狀況,他們比較清楚是CrowdStrike引發事故,但許多大眾媒體報導全球當機事件,都將矛頭指向微軟。
不過,對於這起事件帶來的全球衝擊,後續CrowdStrike也持續試圖彌補,包括數小時後該公司執行長George Kurtz上電視道歉,持續發布事件最新因應、狀態與調查報告。
這段期間CrowdStrike提供補償方案的10美元禮物卡,也被外界放大檢視;今年8月11日DEF CON的Pwnie Awards頒獎,也將今年將「史詩級失敗」(Most Epic Fail)獎項頒給了CrowdStrike事件。
不過,CrowdStrike總裁Michael Sentonas親自出席領取的勇氣,獲得現場相當多研究人員的迴響。Michael Sentonas除了再次公開道歉,也表示接受此獎不值得驕傲,但他希望將這個獎項放在公司顯眼處來提醒員工們。「知恥近乎勇」這樣的態度值得肯定。
到了8月28日,CrowdStrike召開季度會議,說明這幾週正贏得許多客戶的持續信任,且第二季表現仍超出分析師的預期。但是,這一季的成績不足以說明這次事件對該公司業績的影響,接下來兩季,才是考驗客戶是否依舊信任他們,有待後續經營表現才能有所證明。
問題5:開發者寫出越界記憶體讀取的Bug再起爭議
在先前談及部署驗證測試問題之外,為何開發者寫出會造成越界(out-of-bounds)記憶體讀取的問題,也成為本次事件衍生議題。
事實上,0719事故發生的隔日(週六),我們就看到有國外研究人員在社群平臺X聲稱,在他剖析CrowdStrike EDR系統的當機資料後,發現有段C++程式錯誤存取了「空指標」(Null Pointer),進而引發系統崩潰。
而在前述CrowdStrike於7月24日的PIR報告,也提到發生越界記憶體讀取的問題,7月25日官方部落格的技術文章中,同樣指出其頻道檔案可能包含NULL bytes。因此,證實了這項傳言。
對此,微軟在7月27日說明Windows安全最佳實踐的文章中,也提到其分析結果。微軟使用WinDBG偵錯工具與一些擴充程式來分析,他們從Windows崩潰報告發現,在讀取R8暫存器(Register)特定位址之前有一個檢查為NULL的情形,也就是調用一個位址時,但該位址為Null而造成了錯誤。這也印證CrowdStrike的分析結果。
到了8月6日,事發大約半個月後,CrowdStrike發布了根因分析(RCA)報告,又再有了更具體的說明。
CrowdStrike指出,在7月19日的更新,是基於今年2月首次引入的新感測器功能,這項功能預定義了一組欄位,用於快速回應內容功能的資料蒐集。
然而,原本感測器預期是收到20個輸入欄位,但當天的更新實際提供了21個欄位,這個欄位不符的情形,導致了越界記憶體讀取,進而引發系統崩潰。
由於越界記憶體讀取的Bug與漏洞問題,已經探討多年,因此在這次事件下,也衍生出這方面的討論。
例如,前幾年微軟與Google就指出,有70%重大漏洞的根因都出自記憶體問題,到了2022年,包含開源社群、科技大廠與美政府商討提升開源軟體安全對策中,就有一項是針對記憶體安全方面,透過替換「不具記憶體安全(non-memory-safe)」的程式語言,來消除許多漏洞問題的根源。
原因是許多開發者對於指標、記憶體配置的狀況,相當輕忽且普遍,犯錯比例仍是居高不下,而有足夠經驗、願意花心力檢測這類問題的程式設計者太少。
因此,雖然這次Falcon感測器錯誤的本質,的確涉及記憶體安全的Bug,值得探討。不過,可能造成同樣故障情形的錯誤還有很多種。
未來可留意事故責任與監管機關態度的討論
整體而言,這次事件促使著多個重要議題受到討論,不僅是資安業者的檢討,企業對於事件的多種反思,都成為大家在看待這次事故時的主要焦點。
例如,CrowdStrike更新前未做好部署驗證測試的問題,以及快速因應資安威脅與系統安全的平衡。在我們後續調查國內災情時,也有醫院單位表示將以此事件作為警惕,提醒自己日後在上架IT系統或更新版本時,更需按照標準程序進行,避免為自己帶來大麻煩。
另一方面,企業面臨這次災情,對於分散風險這件事也更有感受,甚至考量到雙主機備援機制下,也要採不同廠商的防護服務。
至於未來,其實還有一些動向可以留意,例如,這次錯誤問題是否會被攻擊者利用?CrowdStrike表示不會被攻擊者利用,而他們也與第三方審查確認。其他像是關於提告的後續消息,監管機關的要求等,可能也是這次事件下的討論焦點,都值得繼續追蹤。
CrowdStrike當機事後的5個關鍵公告
7月20日
官方部落格文章:CrowdStrike發表關於Falcon感測器內容更新的技術細節文章
內容:說明這次更新事故發生在19日的4時09分(世界協調時間),並指出受影響的頻道檔案為291。
7月20日
官方部落格文章:微軟揭露影響電腦數量,並說明將幫助客戶度過這次事故
內容:微軟指出預估有850萬臺Windows裝置受影響,並表示這雖然不是微軟的事件,但考慮到影響整個生態系統,將與相關公司共同協助修補。
7月24日
PDF報告:CrowdStrike公布事件後初步檢討(PIR)報告
內容:說明發生越界記憶體讀取引發作業系統崩潰,有問題的更新涉及「Rapid Response Content」環節,同時負責驗證的內容驗證器有Bug導致未檢測出錯誤。
7月27日
官方部落格文章:微軟發布闡述Windows安全最佳實踐的相關文章
內容:解釋當今資安產品使用核心模式驅動程式的原因,並傳達出Windows已發展一些作法,可幫助限縮這些問題面,並在持續發展中,也將與第三方廠商加強相關合作。
8月6日
PDF報告:CrowdStrike公布根因分析(RCA)報告
內容:針對越界記憶體讀取問題說明,指出原本感測器預期是收到20個輸入欄位,但當天的更新實際提供了21個欄位。同時指出事故10日後的7月29日,約有99%的Windows感測器已恢復上線。
0719大當機事故衍生3種亂象
關於CrowdStrike更新引發Windows死當事件,在我們統整出5大焦點議題之外,還有一些圍繞在事件周邊的消息,也成為整起事故下引發的插曲。
● 出現訊息混淆的狀況。在CrowdStrike引發當機事故前幾個小時,由於微軟發生美國中部Azure資料中心中斷事件,加上CrowdStrike在事故發生1個半小時說明引發當機的公告,只有其用戶身分登入才能瀏覽,沒有對外公布,導致只有IT、資安圈知道情形,但大眾媒體一開始報導全球當機災情,均將矛頭指向微軟。
● 錯假訊息的分享。例如在事件發生當下轉貼拉斯維加斯Sphere球體螢幕出現藍色當機畫面。
● 駭客利用事件名義來發動攻擊。CrowdStrike與多家資安業者持續警告,監控到有駭客假借這次IT大當機事故進行惡意活動。
熱門新聞
2024-10-05
2024-10-07
2024-10-07
2024-10-07
2024-10-07
2024-10-07
2024-10-07