安全視覺化公司 Forescout 針對 OT:ICEFALL 安全瑕疵的通報顯示,營運科技製造商(operational technology manufacturers)必須提高其裝置的安全性。
文/Lucian Constantin‧譯/酷魯
來自 10 個不同供應商的營運科技(OT)裝置,在一個新的研究專案計畫中發現了 56 個安全漏洞,所有這些漏洞都源自於不安全的設計或實作功能,而不是程式設計上的錯誤所致。這再再凸顯出,儘管這類關鍵裝置在過去十年中愈來愈受到安全研究人員和惡意攻擊者的關注,但該產業仍未遵循基本的安全設計原則。
「利用這些漏洞,對目標裝置進行網路存取的攻擊者,可以遠端執行程式碼,變更 OT 裝置的邏輯、檔案或韌體、規避身分驗證、劫持憑證、發動 DoS 阻斷服務攻擊,或產生各種營運衝擊,」安全公司 Forescout 研究人員在新報告中表示。
這些經確認的安全問題被統稱為「OT:ICEFALL」,它們源於不安全的工程協定、較弱的加密實作或無效的身分認證方案、不安全的韌體更新機制,以及可能被濫用於遠端程式碼執行的本地端功能保護不當。事實上,14% 的已披露漏洞可能導致遠端程式碼執行,另外 21% 可能導致韌體竄改。
這項研究的另一個有趣發現是,許多易受攻擊的裝置已根據適用於 OT 環境的不同標準進行了認證,例如 IEC 62443、NERC CIP、NIST SP 800-82、IEC 51408/CC、IEC 62351、DNP3 Security、CIP Security 和 Modbus Security。
「雖然這些由標準驅動的強化工作確實對安全程式開發、風險管理和架構級設計及整合活動領域的重大改進做出貢獻,但這些努力在成熟的單獨系統和零組件的安全開發生命週期方面並不太成功,」研究人員歸納指出。
OT 不安全設計史
Forescout 研究人員將他們的發現與 Basecamp 專案的發現進行了比較,後者是 10 年前的一個研究專案計畫,專注於揭露工業裝置中使用遠端終端單元(RTU)、可程式化邏輯控制器(PLC)和其他組成 SCADA 監控控制和資料採集系統之控制器中的設計不安全問題。
然後,在發現了攻擊手法精細複雜的安全威脅(例如由國家開發用來鎖定 PLC 的 Stuxnet 蠕蟲)後,參與 Basecamp 專案計畫的研究人員開始改變 ICS 工控系統製造商和資產所有者在 9/11 事後「長達 10 年的不作為」。十年後,OT:ICEFALL 表明,許多相同的問題,例如缺乏適當身分認證和加密機制的晦澀難懂專屬協定,依舊時常能在運行我們關鍵基礎設施的裝置中看得到。
「眾所周知的,受 OT:ICEFALL 影響的產品普遍存在於石油和天然氣、化學、核能、發電和配電、製造、水處理和供水、採礦和建築自動化等關鍵基礎設施的骨幹行業中,」 Forescout 研究人員在他們的報告中表示。「其中許多產品都以『安全設計』的形式出售或已通過 OT 安全標準認證。」
雖然這種預設情況下的不安全狀態在 OT 世界中會繼續存在,但攻擊的數量只會不斷的增加和演變。自 Stuxnet 超級蠕蟲爆發以來,我們接連看到 2016 年導致烏克蘭大停電的 Industroyer 惡意軟體攻擊,2017 年用於企圖破壞沙烏地阿拉伯石化廠的 TRITON 惡意軟體,今年用來攻擊烏克蘭變電站的 Industroyer2 惡意軟體和 INCONTROLLER APT 進階持續威脅攻擊工具。ICS 安全公司 Dragos 追蹤了 19 個以 ICS 工控環境為目標的惡意威脅團體,其中包括去年發現的3個團體,並顯示出其具備存取 ICS/OT 網路的能力。
OT:ICEFALL 安全瑕疵影響了 Bently Nevada、艾默生(Emerson)、Honeywell、捷太格特(JTEKT)、摩托羅拉(Motorola)、歐姆龍(Omron)、菲尼克斯(Phoenix Contact)、西門子(Siemens)和橫河電機(Yokogawa)等公司旗下的裝置。這些裝置包括狀態監視器、分佈式控制系統(Distributed Control System,DCS)、工程工作站、RTU、PLC、建築控制器、安全儀表系統(Safety Instrumented System,SIS)、SCADA 系統、協定甚至邏輯執行時間(Logic Runtime)等。
邏輯執行時間是解釋和執行梯形邏輯(Ladder Logic)的軟體 ─ 由工程師編寫並作用於裝置輸入和輸出的程式碼。例如,Phoenix Contact 的 ProConOS 執行時間用於來自不同供應商的多個 PLC 中,進而讓其中被發現的漏洞(上傳的邏輯缺乏加密驗證)成為會導致任意程式碼執行的潛在供應鏈風險。
「由於軟體物料清單(Software Bills Of Materials,SBOM)的缺乏和產品供應鏈的複雜性,通常無法立即清楚地知道特定 PLC 所使用的執行時間為何。」研究人員在報告中指出。「執行時間通常有不同的版本和相應的協定差異,並且受 OEM 整合決策的影響。PLC 製造商可以選擇如何使用執行時間而不是協定,寧願使用自己的協定,或者可以選擇在非預設連接埠上使用協定,抑或可以選擇重新命名或修改執行時間。由於供應商、CVE 編號授權單位(CVE Numbering Authorities)和 CERT 電腦緊急應變小組缺乏向所有受影響方傳播供應鏈漏洞知識的主動協調努力,安全社群將被迫定期、偶然地重新發現它們,導致 CVE 編號重複,並使根本原因的分析複雜化。」
例如,過去分配給 ProConOS 執行時間問題的兩個 CVE 編號(CVE-2014-9195 和 CVE-2019-9201)只與 Phoenix Contact PLC 相關,同時也影響了其他供應商。研究人員說,後來在橫河電機 STARDOM 控制器中發現一個安全問題,該安全問題被冠上 CVE-2016-4860 編號,但實際上它與 CVE-2014-9195 是同一個安全問題。過去,許多預設情況下的不安全問題(例如 OT:ICEFALL 中所包含的問題),根本沒有收到 CVE ID,因為它們不被視為傳統的漏洞,這使得客戶很難進行追蹤,這讓問題變得更加惡化。
緩解 OT 裝置漏洞
Forescout 團隊在漏洞揭露過程中與美國網路安全和基礎設施安全局(U.S. Cybersecurity and Infrastructure Security Agency,CISA)合作,該機構已就一些問題發布了自己的建議。資產所有者應在裝置製造商提供更新修補程式和韌體更新時進行安裝,但修復一些已確認的安全問題時可能涉及大量的技術工作和變更作業,因此供應商可能在很長一段時間裡不會解決這些問題。與此同時,Forescout 團隊建議不妨採取以下緩解措施:
- 發現並清點有安全弱點的裝置。網路可見度解決方案能夠發現網路中有安全弱點的裝置,並套用適當的控制和緩解措施。
- 實施分段控制和適當的網路衛生(Network Hygience),以緩解有安全弱點之裝置的風險。如果有安全漏洞裝置無法修補或在可以修補之前,請限制外部通訊管道,並將這些裝置隔離或納入特定區域中,以作為緩解控制措施。根據 中小企業知識來審查防火牆規則,尤其是列入白名單的 OT 協定。一些供應商提供具有協定感知安全功能的專屬防火牆和交換機。
- 監控受影響裝置供應商所發布的漸進式更新修補程式,並為你有安全弱點的資產清單制定補救計畫,以平衡業務風險和企業營運不中斷(Business Continuity)要求。
- 監控所有網路流量,以發現試圖利用不安全設計之功能的可疑活動。使用具有 DPI 功能的監控解決方案來警示安全人員注意這些活動,以便採取適當的行動措施。
- 積極採購符合安全設計的產品,並在可能的情況下遷移到符合安全設計的變動版產品。透過在採購要求中將安全評估納入,以評估裝置的安全狀況。
- 利用本機強化功能,例如控制器上的實體模式開關,這些功能需要進行實體互動才能執行危險的工程操作。一些供應商提供隨插即用的解決方案,以便在網路級別上為多個控制器模擬這些功能。在可能的情況下,在操作模式切換到監控解決方案時啟動警報。
- 透過遵循 Cyber-PHA 和 CCE 方法論來減輕後果。這不僅對處理事件的可能性很重要,而且對處理事件的影響性也很重要。
(本文授權非營利轉載,請註明出處:CIO Taiwan)