概述
近年來供應鏈攻擊頻發，供應鏈攻擊和勒索軟件攻擊正成為黑客謀利的重要手段，對社會危害非常巨大。供應鏈攻擊是一種以軟件開發人員和供應商為目標的威脅， 攻擊者通過感染合法應用的方式分發惡意軟件來訪問源代碼、構建過程或更新機制從而達到對開發人員和供應商進行攻擊的目的。軟件供應鏈可劃分為開發、交付、運營三個大的環節，每個環節都有可能引入供應鏈安全風險，從而遭受攻擊，上游環節的安全問題會傳遞到下游環節并被放大。最近被大家熟知的某金融領域使用的組件被惡意攻擊者攻破后泄露了大部分機密資料，由此可見供應鏈的威脅離我們并不遙遠。那么在工控領域內有沒有類似的威脅存在呢？本文將講述在研究工控設備時發現CodeSys Runtime多個漏洞的過程，并且針對漏洞進行了相應的技術分析，文章末尾會提出針對這些漏洞的防護建議。
工控設備研究過程
本次選取了ABB的AC500系列PLC，初始的研究目標為：固件分析與研究、私有協議安全性研究。目標硬件為PM564-RP-ETH-AC，固件版本通過組態軟件Automation Builder 2.4.1升級到最新版本2.8.4。
確定研究對象后，首先搭建安全測試環境，利用nmap對PM564進行掃描得到如下結果，依據長時間接觸工控領域的經驗，當發現如下兩個網絡端口時第一反應就是私有協議端口而且和CodeSys關系很大。
接下來，打開組態軟件，創建工程后下裝至PM564，利用wireshark抓取通信報文，查看報文數據結構，發現請求和響應報文中都攜帶有4f 96 05開頭的19個字節的head結構，緊接著“aa aa”打頭的為payload。通信過程中使用的端口為1200。那么1201端口是什么時候使用的呢？數據報文結構是什么樣子呢？先保留這些問題，接下來先看看PM564的固件。
幸運的是ABB官方提供了固件下載，最新版本的固件鏈接地址為：
https://new.abb.com/plc/programmable-logic-controllers-plcs/ac500-eco/cpus
當下載到固件后，找到對應模塊PM564的固件，固件中包含的文件如下所示，其中2_0_2文件夾為BootLoader，2_8_4文件夾為firmware，ONB_IO文件夾為onboardIO部分，RTC_BATT文件夾為RTCBattery部分。
進入到firmware文件夾后，只有一個文件Pm55xE.gza，利用010打開后文件內容如下圖所示，可以發現該文件肯定是經過特殊處理的，無法利用binwalk工具獲取到相關信息，至此進入到了不幸的階段。雖然提供固件下載但是無法閱讀分析，這也是工控領域常見的情形，比如Siemens提供固件下載，但是固件都是經過特殊處理的。這時可以利用《某工控設備固件提取及分析》文章中提及到的第二種方法，利用拆焊手段得到flash內部的代碼進而分析固件，找到固件處理算法、分析算法、拆解下載到其余PLC模塊的固件。
由于研究對象為實驗室專有設備無法拆解，因此在某魚上買到了一個性價比更高的PM554模塊，直接作為拆焊對象，首先分析硬件架構，理清使用的CPU、flash等芯片。如下圖所示，左邊為模塊的CPU，型號為MPC852T，是基于PowerPC架構的MPC860四路集成通信控制器。右邊標識出的為模塊的flash芯片，型號為M29W320EB，它是一個容量為4M字節的nonflash芯片。
接下來就要將flash芯片拆焊，利用編程器讀取內部數據。由于該模塊的物理結構復雜并不像其余PLC是多個PCB板層疊安裝，而是“兩山夾一川”的格局，目標芯片還在“一座山”的山腰位置，因此難度大大增加，經過不斷的細心嘗試，最終還是將目標芯片拆下來了，如下圖所示。
之后利用編程器讀取出flash芯片中的內容，經過分析flash中的內容存在字節序問題，修復字節序后放入binwalk分析如下圖，從0x50010處開始即為固件部分。
剩下的工作就是將固件部分導入IDA進行分析，首先利用rbasefind方法找到起始地址，然后根據經驗尋找字符串定位通信處理函數，找到1201/1200端口的功能。在此不再贅述，見下圖rebase address后的IDA分析圖示。
經過分析和驗證發現，1201端口是為了兼容之前的組態軟件版本開啟的端口，使用的是以“bb bb”開頭的私有協議，通過搭建Automation Builder 2.3和PM564通信環境驗證了這一點，下邊截圖展示了1201端口的流量。
進一步分析得知報文格式如下所示，其中開頭2字節為特定報文頭，接下來的4個字節為長度域（大端模式），緊跟1個字節為功能碼，緊隨其后為N字節的數據部分。
至此可以做如下總結：
A. 通過拆焊芯片得到了PM554固件，經過分析固件得到了該系列模塊固件的處理算法。
B. 通過分析固件得知1201端口也是私有協議，以“bb bb”打頭。
C. 1200端口為最新版本組態軟件和設備通信的私有協議，以“4f 96 05”打頭。
D. 經過分析發現模塊底層采用的操作系統為Micro Digital公司的SMX，但是版本依然停留在V3.5。
既然已經獲取到了1201端口和1200端口的流量和報文格式，那么利用自制的Fuzz工具，就可以很輕松的針對私有協議進行安全性測試。針對1201端口結構較為簡單的私有協議開始Fuzz測試，在不到半天的時間內發現了多個拒絕服務漏洞。以下是發現漏洞的示例圖，PM564的狀態為ERR燈閃爍，進入嚴重故障模式，只有重新上電才能恢復正常狀態。
通過修改poc在其余使用CodeSys Runtime的PLC上進行驗證，發現也受到這些漏掉的影響，至此猜測是由CodeSys Runtime引入的漏洞。為了驗證猜測，分析了固件定位到了崩潰點，該崩潰點在CodeSys Runtime內核部分。而且PM564使用的Runtime版本為已經過時的版本2.4.7.48，見下圖：
為了更進一步坐實這些漏洞是由CodeSys Runtime引入的，下載了當時最新的版本（Runtime版本為2.4.7.55），搭建了對應的Fuzz測試環境，在Runtime中發現了多個漏洞，并將這些漏洞提交給了CodeSys官方。
CodeSys 漏洞分析
2021年10月25日CodeSys官方發布了4份安全通告，其中包含了10個漏洞，格物實驗室提交的多個漏洞被合并為3個漏洞，且都評為高危，并獲得官方致謝。3個漏洞的基本情況如下所示：
CVE-2021-30188（CVSS3.0評分8.8）： CWE-121: Stack-based Buffer Overflow
特制的請求報文發送至受影響的CodeSys產品中，可能引起目標的拒絕服務或者遠程代碼執行。
CVE-2021-34595（CVSS3.0評分8.1）： CWE-823: Use of Out-of-range Pointer Offset
單個特制的請求報文發送至受影響的CodeSys產品中，可造成越界讀或者寫，進而引發拒絕服務或者本地內存被覆蓋。
CVE-2021-34596（CVSS3.0評分8.1）： CWE-824: Access of Uninitialized Pointer
單個特制的請求報文發送至受影響的CodeSys產品中，可造成訪問未初始化的指針，進而引發拒絕服務。
成功利用這些漏洞，輕則導致目標產品發生拒絕服務、出現宕機等后果，重則可使目標執行惡意攻擊者編制的利用代碼，以此影響生產、持續潛伏、竊取敏感數據、適時發動定點攻擊等。
在此，以CVE-2021-34595為例，以受影響的PM564模塊作為目標做一個簡單分析。
當向PM564模塊的1201端口發送0x3E功能碼的報文時，報文payload部分被直接使用而沒有做字段校驗處理。
經過一系列處理函數，最終進入到了sub_1FECC0的memcpy操作，memcpy函數的size字段是從報文的payload中直接獲取到的，并進行了簡單的數學計算，最終導致size字段過大超出了內存范圍，進而導致崩潰。
影響范圍分析
CodeSys是全球最著名的PLC軟件研發廠家德國3S（SMART，SOFTWARE，SOLUTIONS）公司發布的一款與制造商無關編程軟件及工控設備內核（Runtime SDK）。
這些漏洞不僅僅影響CodeSys軟件產品，還影響使用CodeSys Runtime內核的廣大工控廠商，因為CodeSys作為“工控界的安卓”被廣泛使用在工控設備中，據官方統計使用CodeSys解決方案的知名企業超過500家，CodeSys市場占有率為35%，其中熟知的ABB、施耐德電氣SchneiderElectric、費斯托Feso、伊頓電氣、博世力士樂、倍福BECKHOFF、研華科技、凌華科技ADLINK、和利時集團、匯川技術、深圳英威騰、華中數控、固高科技等都使用了CodeSys Runtime。更詳細的合作客戶請參見如下鏈接 http://www.codesys.cn/list-Partner-1.html
查看公網暴露的CodeSys 產品如下圖，可以看到暴露數量不算少，尤其在土耳其暴露數量超過了1200多個。由于工控安全意識加強，很多設備都不在統計范疇內，因此這個暴露數量只是冰山一角。
防護措施及建議
1. 將受影響的產品放置于安全防護設備之后，做好網絡安全的縱深防御策略。
2. 當需要進行遠程訪問時，盡量采用安全的VPN網絡，并且做好訪問控制和審計工作。
3. 關注受影響廠商的安全補丁，經過測試后升級受影響的產品以使其免受威脅。
4. 盡量減少受影響設備的私有通信端口暴露，可根據業務場景選擇關閉受影響的1200/1201/2455等端口。
5. 建議使用CodeSys Runtime的工控廠商及時自查，并且積極修復，發布修復版本的固件。
總結
本文先從工控設備研究入手，發現了私有協議的多個漏洞，后來經過在其余使用相同內核的PLC上驗證也存在漏洞，進一步在CodeSys Runtime內核上進行安全測試，發現了CodeSys Runtime內核的多個漏洞，提交官方后得到了修復。通過這個事件需要意識到，在OT領域內供應鏈威脅早已存在，而且影響范圍會越來越大，工控設備使用的內核、以太網協議棧、操作系統都很集中，比如操作系統都是用VxWorks、QNX、裁剪的Linux，以太網協議棧使用LWIP，內核使用CodeSys、Infoteam、KW等，除此之外還會使用開源代碼實現應用層協議，比如Modbus、Ethernet/IP等，難免會引入更多的風險。面對這樣的風險我們如何應對呢，在此筆者給出了幾點建議：
1. 加強供應鏈產品或組件的篩查審查機制，從頂層設計解決用誰的？用哪個版本？怎么用？出了問題如何快速更新等問題。
2. 建立公司內部供應鏈產品或組件的風險管理機制，能夠識別開發過程中惡意的變動，并觸發追查和防范措施。
3. 借鑒google的SLSA供應鏈完整性框架，在開發過程中防范供應鏈威脅。
由于知識面的限制，提出以上安全防護措施供參考，更多針對供應鏈威脅的處理和應對措施還需群策群力，構建真正能夠在前期將供應鏈攻擊扼殺的體系，以此來保障我們業務的安全生產與運行。
