Jump to content
  • Entries

    16114
  • Comments

    7952
  • Views

    86391389

Contributors to this blog

  • HireHackking 16114

About this blog

Hacking techniques include penetration testing, network security, reverse cracking, malware analysis, vulnerability exploitation, encryption cracking, social engineering, etc., used to identify and fix security flaws in systems.

內容提要Team82在工程設計工作站XINJE PLC Program Tool中發現了兩個漏洞。

3.5.1版本受到這些漏洞的影響,其他版本也可能受到影響。

Team82於2020年8月開始著手披露工作。一年多後,XINJE終於在2021年9月承認了我們披露的漏洞。

當時XINJE拒絕與Team82合作,並要求我們停止與他們溝通。

在今天披露有限的細節之前,我們將協調披露政策的期限從90天延長到9個月,以幫助資產所有者遴選緩解措施。

攻擊者能夠利用一個精心製作的項目文件來觸發這些漏洞。

可以將任意數量的項目文件寫入一個項目文件以獲得代碼執行。

工程設計工作站是最關鍵的運營技術(OT) 資產之一。工程師使用這些平台在工業控制系統的普渡模型較低級別配置和維護各種控制系統應用程序和設備。如果攻擊者能夠訪問和使用工程工作站,那麼,他們就可以將其作為攻擊媒介來進一步破壞工業流程,進而可能危及公共安全或中斷關鍵服務。

Team82在審查v3.5.1版本的XINJE PLC Program Tool的安全性的時候,發現了兩個安全漏洞,分別為CVE-2021-34605和CVE-2021-34606)。不過,Team82僅對v3.5.版本系列進行了測試,但我們相信,其他版本也可能存在相同的漏洞。

這些漏洞可以通過精心設計的項目文件觸發。攻擊者可以利用這些漏洞將任意數量的項目文件寫入PLC並獲得代碼執行權限。

Team82今天披露了有關這些漏洞的有限信息,在嘗試與公司代表聯繫一年未果後,這些漏洞的詳細信息已經於2021年8月末私下披露,因為供應商既不接受我們分享技術信息,也拒絕了讓我們參與漏洞修復與響應的請求。最後,2021年9月8日,XINJE代表要求Team82停止溝通。 Team82則將其協調披露政策的期限從90天延長至9個月後,決定披露有限的漏洞細節,以幫助資產所有者遴選緩解措施。

關於PLC Program Tool

XINJE的PLC Program Tool是一個工程設計工作站程序,可以在OT環境中與XINJE生產的PLC進行通信。據XINJE稱,這些設備不僅在中國銷售,而且還在歐洲、北美、東南亞和其他地區的一些市場上銷售,涉及能源、製造業和工程等行業。

從安全的角度來看,只要獲得對安裝有工程設計工作站程序的機器的訪問權限,攻擊者就能接管PLC和其他高度敏感的OT設備,並造成不良後果。因此,攻擊者可以利用這些程序中的漏洞作為完全控制OT網絡的最後一步。

1.png

以工程工作站為目標的攻擊者可以感染較低級別的設備,如PLC、傳感器或泵。

惡意項目文件是這類漏洞的重心Team82對與項目文件相關的安全漏洞特別感興趣。

項目文件通常是包含OLE文件、SQLite數據庫、專有格式的二進製文件、文本文件和工程工作站內創建的目錄的歸檔文件格式。這些程序被工程師用來監控、配置可編程邏輯控制器(PLC)和其他控制系統,並與之進行通信。

項目文件中包含的程序邏輯不僅負責管理ICS設備以及監督流程,同時還可能包含網絡配置數據,甚至完整的OT網絡佈局。對於以工業網絡為目標的攻擊活動,尤其是國家級的入侵活動,項目文件的武器化就是這些活動的核心之所在。

當通過工程設計工作站程序打開一個項目文件時,該程序將迅速與相關設備進行通信。另外,OT工程師有時可以通過PLC上傳項目文件,但這需要運行網絡發現工具來確定PLC的網絡地址(不是所有的PLC都支持這個程序),或者手動輸入相關的網絡參數。因此,許多公司會選擇使用項目文件,因為每個文件可以包括一個或多個PLC的配置。

當工程設計工作站程序打開由攻擊者精心構造的項目文件時,可能會觸發漏洞。在這種情況下,攻擊者可以將用於存儲文件的網絡共享中的合法文件替換成一個特製的文件,從而觸發程序中的漏洞。我們在XINJE的PLC Program Tool中就發現了這樣的漏洞:在打開一個精心構造的項目文件時,攻擊者可以在易受攻擊的端點上運行任意代碼。

研究環境設置是關鍵的第一步作為我們工作的一部分,我們經常收到研究專有協議的請求,以便最大限度地提高客戶觀察其網絡流量的能力。有時,我們必須支持仍在生產現場發揮關鍵作用的舊設備,而在其他時候,我們甚至會偶然發現小型OT供應商製造的設備。

有次,我們從一個客戶那裡收到了分析由XINJE製造的設備所使用的協議的請求,這就屬於後者。

我們的第一步是建立一個實驗室設置;這通常需要購買設備,並將其連接到相關的工程設計工作站程序。在某些情況下,即使是購買設備也很困難,因為我們需要的確切型號可能已經斷貨了。

隨著時間的推移,我們發現,竟然可以通過eBay買到各種型號的OT設備。在許多情況下,一旦工廠停止生產某型號的OT設備,舊的二手設備就會出現在eBay上,不僅容易買到,還是包郵到家那種。當然,XINJE提供的設備也不例外,各種型號的XINJE產品基本都可以通過eBay買到。

Ebay上的XINJE工業設備清單:

1.png

一旦購買了PLC,下一步就是把它和其他眾多的OT設備一起安裝到我們的實驗室中,並將其連接到負責配置的工程設計工作站程序上。

1.png

在實驗室環境中運行的XINJE PLC

聯合運用兩個漏洞實現惡意文件的加載一旦我們搭建好了實驗環境,並研究好設備所使用的不同協議,接下來要做的事情,就是按照客戶的要求在其中尋找安全漏洞。

檢查這些安全問題可以幫助用戶立即改善他們的安全狀況。同時,負責任地將這些漏洞報告給供應商,不僅可以幫助修復這些漏洞,還能提高整個OT空間的安全性。

在XINJE的案例中,我們決定把重點放在名為XINJE PLC Program Tool的工程設計工作站程序上。如前所述,在這種情況下,項目文件的漏洞是特別值得關注的。通常情況下,在搜索項目文件的漏洞時,首先要調查工程設計工作站程序所使用的項目文件的具體結構。對於XINJE PLC Program Tool來說,相關文件是*.xdp文件。

1.png

XINJE PLC項目文件是由.xdp類型的文件組成的。

不難發現,這些項目文件都是些壓縮文件,具體如下面的魔法字節PK/x03/x04所示:

1.png

並且,它們幾乎可以被所有的歸檔工具(如7z)提取。更有趣的是,當程序打開一個項目文件時,它會立即將其解壓縮到位於其安裝目錄下的一個臨時目錄中:

1.png

XDPPro.exe將多個文件寫入C:\Program Files\XINJE\XDPPro\tmp目錄中

這種行為表明,該程序認為自己是以管理員權限運行的。這一點,再加上提取的文件是一個zip文件,立即讓人懷疑是否可以利用zip slip漏洞(一個任意的文件覆蓋漏洞)來獲得任意的寫入權限。

很快,我們確實發現了一個zip slip漏洞(CVE-2021-34605),它可以授予攻擊者該程序的所有權限,包括任意寫入特權;在大多數情況下,這些權限都是管理員才具有的權限。

下一個問題是:如何從任意文件寫入實現代碼執行。由於代碼在項目文件加載後立即執行是最合理的選擇,所以,我們可以檢查程序在打開項目文件後,會執行哪些操作:

1.png

XDPPro.exe試圖從C:\Program Files\XINJE\XDPPro加載DNSAPI.dll,但沒有找該動態庫,並返回至C:\Windows\System32目錄

有趣的是,它將通過LoadLibrary從其本地目錄來加載.dll文件。當LoadLibrary沒有找到相應的動態庫時,它會再次回到C:\Windows\System32目錄,並在此搜索庫文件。這裡是我們發現第二個漏洞,即CVE-2021-34606的地方;這是一個典型的DLL劫持漏洞。

為了創建一個行之有效的exploit,我們需要聯合使用這兩個漏洞:

一旦精心構造的惡意項目文件被XINJE PLC Program Tool打開,就會觸發zip slip漏洞,這時,會將一個.dll文件寫入Program Files的program目錄中。之後,在加載新項目的過程中,這個DLL也會一同被加載,而不是加載真正的DLL(它位於Windows\System32)。

一旦攻擊者的DLL被加載,惡意代碼就會在其DLLMain進程或在程序導入的某個函數中執行,這樣,攻擊者就在OT網絡中成功獲得一個立足點。

1.png

Team82的PoC演示效果

小結儘管近年來OT界對網絡安全的認識一直在穩步提高,但許多工程設計工作站程序中仍然存在許多易受攻擊的安全漏洞。

並且,並非所有的供應商都已經意識到,工程文件能夠成為攻擊者手中的武器,成為控制關鍵OT資源的手段;對於大多數OT人員來說,情況也是如此。

此外,許多供應商在協調漏洞的披露的方面,仍然有許多工作要做。因此,披露過程會浪費許多不必要的時間,因為這些信息往往要經過沒有安全知識的銷售和/或技術支持團隊,才能到達負責開發受影響產品的團隊。

對於新捷來說,這是一次具有挑戰性的漏洞披露,幸好這並非大多數OT供應商的常態。