Codesys V3協議漏洞挖掘方法

一、前言

Codesys是全球最著名的軟PLC內核軟件研發廠家德國的3S（SMART，SOFTWARE，SOLUTIONS）公司發布的一款與制造商無關IEC 61131-1編程軟件及工控設備內核（runtime SDK）。Codesys 支持完整版本的IEC61131標準的編程環境，支持標準的六種編程語言，是一個標準的與硬件無關的Runtime，被很多硬件廠家支持， Codesys提供了許多組合產品的擴充，諸如各種不同領域的總線配置程序和運動控制系統。

由于Codesys提供的解決方案覆蓋全面、功能強大、開發周期短、靈活性高、支持硬件架構及操作系統豐富等原因在全球工控廠商中廣泛使用，據官方統計使用Codesys解決方案的知名企業超過500家，Codesys市場占有率為35%，其中我們熟知ABB、施耐德電氣、費斯托Festo、伊頓電氣、博世力士樂、WAGO、倍福BECKHOFF、研華科技、凌華科技、巴赫曼Bachmann、KEBA、深圳合信、匯川技術、深圳英威騰、華中數控、步科、固高科技等等都使用了Codesys Runtime。

正因為諸多知名工控廠商大規模使用該內核，因此Codesys產品的安全性影響巨大。一旦源頭出現問題則很有可能影響諸多廠商的多款產品使工業生產過程面臨嚴重威脅。出于此目的，筆者從2021年開始研究Codesys V2相關產品并發現了數十個漏洞，提交給廠商后經過修改發布了最新修復版本，詳情請見鏈接[1]所示。Codesys V2產品設計理念只關注了功能業務在信息安全方面涉及較少。目前主推的Codesys V3產品宣稱加入了信息安全的設計考量，那么是不是就無懈可擊呢？本文就帶領大家看看筆者是如何從Codesys廠商的安全通告出發一步步發現多個漏洞的。

二、信息收集

先打開Codesys廠商的安全通告網站，瀏覽相關安全通告。

2023-2的這份通告[2]吸引了筆者的注意力，其中包含了大量的漏洞而且都是通信協議相關，最重要的是暴露了很多敏感信息讓我們可以從中分析出很有價值的信息。下圖為CVE編號總數為16個，且影響的是V3.5.19.0以前的所有版本的多個通信組件。

從通告中選取存在CVE編號最多的一個組件開始詳細分析，這些漏洞的類型為棧溢出，影響組件名稱為CmpTraceMgr。可以得出結論：在Codesys V3.5.19.0之前版本中CmpTraceMgr組件存在多個地方的棧溢出漏洞。

接下來我們的思路如下：

1.搭建Codesys V3.5.19.0之前任一版本和該版本環境，從Codesys V3自帶模擬器control win V3出發分析在CmpTraceMgr組件中修改了哪些存在棧溢出風險的代碼

2.在存在漏洞的Codesys模擬器環境下構造報文進行漏洞復現和分析；

3.學習2023-2安全通告中微軟研究人員的相關思路，在修復后的版本模擬器中挖掘漏洞；

三、環境搭建

在Codesys廠商官網下載受影響的版本Codesys V3.5.18.20

將其安裝在Windows 10虛擬機中，安裝后啟動模擬器，并且在x64dbg工具中將其進程附加，如下所示

由于模擬器使用了威步wibu的安全解決方案因此需要利用插件從內存中對其dump后進行整體分析

同樣，我們還需要下載修改漏洞后的版本Codesys V3.5.19.0軟件并在另外一個虛擬機上安裝，安裝后同樣進行dump內存操作。將2個dump后的內存文件分別保存，以備后續步驟使用。準備兩個不同版本的模擬器后，還需要搭建一個IDE開發環境，給兩個模擬器中分別下裝簡單的測試工程，如下所示。

四、漏洞點定位

將前述的兩個dump文件導入至IDA進行分析，首先對Codesys V3.5.18.20的CODESYSControlService_dump.exe進行分析。

1.通過字符串定位CmpTraceMgr組件位置，直接利用CmpTraceMgr字符串定位發現存在諸多困難，比如字符搜索“CmpTraceMgr”出現的引用較少，函數之間也沒有引用關系，或者利用引用字符串搜索出現的調用有太多，如下所示

基于此需要變換策略，有兩個思路：A.搭建環境，在IDE編程軟件中添加trace功能，執行多項操作，抓取報文從報文信息出發進行關鍵詞搜索；B.利用Codesys V3帶有符號的固件代碼進行比對快速定位關鍵點；

2.基于1步驟提出的B思路，從某個使用了Codesys V3 Runtime的固件（帶有符號表）中比對搜索CmpTraceMgr，再在關鍵位置找到特征字符串后，利用該字符串在V3.5.18.20模擬器dump分析文件中進行搜索。如下圖是在帶有符號表的固件中搜索結果

再在該函數中尋找特殊字符“Creating events failed”

接下來利用特殊字符在目標文件中進行搜索，并且可以對照帶有符號表的固件對目標文件進行函數重命名；

3.利用Creating events failed作為特征字符搜索定位

在該函數中尋找CmpTraceMgr處理部分，最終定位到函數為TraceMgr的處理部分，如下所示

4.熟悉TraceMgr整個函數處理流程，再次打開V3.5.19.0的CODESYSControlService_dump.exe分析文件，分析過程如前所述，找到TraceMgr處理函數后，逐個過程比對每個流程中的函數實現的差異點。按照如上思路，在TraceMgrSrvPacketCreate函數中找到了差異點，下圖是V3.5.18.20的TraceMgrSrvPacketCreate處理部分，當輸入參數為19、20、21等值時，進入mencpy分支

但是對比V3.5.19.0的TraceMgrSrvPacketCreate處理部分時發現其對該部分做了特殊處理（對輸入的內容做限制長度），并且使用的BTagReaderGetContent函數都是特殊封裝后的，因此可以斷定是由于使用了memcpy函數并且未對輸入參數進行檢查驗證出現的棧溢出漏洞。

五、漏洞復現及分析

基于前述的分析，我們要復現漏洞首先需要了解Codesys V3通信協議相關的基礎知識，該部分可以參考看雪論壇中的文章《Codesys V3 協議及授權機制分析》。要觸發該漏洞，需要經過如下通信流程：

1)打開通道，此時模擬器會給客戶端返回channel_id,該值在后續的通信中會用到；

2)創建會話連接，模擬器會給客戶端返回session_id，同樣該值在后續的請求報文中需要攜帶；

3)獲取challenge值，用來進行授權驗證相關算法使用；

4)發送授權后的登錄請求，輸入正確的用戶名和密碼才可進行敏感操作；

5)發送應用程序的登錄請求，此時模擬器會返回op_key，后續的敏感操作還需要攜帶該值；

6)至此才可以發送服務碼為TraceMgrServic群組中子功能碼為TraceMgrSrvPacketCreate的PoC攻擊報文；

發送攻擊報文后，在調試模式下分析漏洞根因。發送報文payload部分填充0x18ac個A，可以看到在memcpy之前目的地址片區布局正常。

當執行完memcpy之后內存布局如下所示，棧上空間全被AAAA填充。基于此漏洞后續還可以做漏洞利用，在棧上構造指向“目標”函數的指針已達到遠程代碼執行的效果，本文中不再深入講解。

六、發現新漏洞

在第五章講述的基礎上結合2023-02的安全通告，我們繼續可以深入各個服務群組的各個子功能碼進行協議模糊測試，服務群組信息如下所示

比如我們可以深入AppServiceHandler中的各個子功能碼函數進行測試，構造進入各個分支函數的報文進行模糊測試。由于Codesys V3協議對象層次清晰，報文結構有研究機構已經披露[3],因此可以采用基于生產的模糊測試進行漏洞挖掘工作，推薦采用boofuzz框架，可以參考claroty開源的OPC UA模糊測試程序[4]來適配Codesys V3協議的模糊測試。

筆者采用多種模糊測試技術已經在修改后的版本V3.5.19.0模擬器上發現了多個漏洞并且將這些漏洞上報給國家相關單位。

在2023年8月10日的Blackhat USA會議上，微軟的研究人員將分享他們發現Codesys V3協議16個漏洞的相關議題，感興趣的朋友可以圍觀。筆者在該議題開講之前先在國內對Codesys V3協議漏洞的分析和發現方法做一分享，讓大家提前預熱。

七、防護措施

由于Codesys V3現在廣泛應用在各大工控廠商的產品中，因此這些漏洞的影響范圍較廣，工控系統用戶應做好積極防護措施。

1.將受影響的產品放置于安全防護設備之后，做好網絡安全的縱深防御策略；

2.當需要進行遠程訪問時，盡量采用安全的VPN網絡，并且做好訪問審計；

3.關注受影響廠商的安全補丁，經過測試后升級受影響的產品以使其免受威脅。

4.盡量減少受影響設備的私有通信端口暴露，可根據業務場景選擇關閉1740/1741/1742/1743/11740/11741等端口；

5.盡量給受影響的控制器設置用戶名和密碼保護，設置保護策略后攻擊難度提升必須要獲取用戶名和密碼后才能執行攻擊；

6.建議使用Codesys V3 runtime的工控廠商及時自查，并且積極修復，發布修復版本的固件；

八、總結

本文以在國際上廣泛使用的Codesys V3為研究對象，從Codesys廠商安全通告出發進行信息搜集和分析，進行了漏洞復現和分析，并且在修改過后的版本中發現了新的漏洞，以此來闡述對于工控安全研究的思路和方法，也讓更多對于保護工業系統安全的有識之士能夠看到并且共同守護工控系統的安全。