概述

　　近年來供應(yīng)鏈攻擊頻發(fā)，供應(yīng)鏈攻擊和勒索軟件攻擊正成為黑客謀利的重要手段，對社會(huì)危害非常巨大。供應(yīng)鏈攻擊是一種以軟件開發(fā)人員和供應(yīng)商為目標(biāo)的威脅， 攻擊者通過感染合法應(yīng)用的方式分發(fā)惡意軟件來訪問源代碼、構(gòu)建過程或更新機(jī)制從而達(dá)到對開發(fā)人員和供應(yīng)商進(jìn)行攻擊的目的。軟件供應(yīng)鏈可劃分為開發(fā)、交付、運(yùn)營三個(gè)大的環(huán)節(jié)，每個(gè)環(huán)節(jié)都有可能引入供應(yīng)鏈安全風(fēng)險(xiǎn)，從而遭受攻擊，上游環(huán)節(jié)的安全問題會(huì)傳遞到下游環(huán)節(jié)并被放大。最近被大家熟知的某金融領(lǐng)域使用的組件被惡意攻擊者攻破后泄露了大部分機(jī)密資料，由此可見供應(yīng)鏈的威脅離我們并不遙遠(yuǎn)。那么在工控領(lǐng)域內(nèi)有沒有類似的威脅存在呢？本文將講述在研究工控設(shè)備時(shí)發(fā)現(xiàn)CodeSys Runtime多個(gè)漏洞的過程，并且針對漏洞進(jìn)行了相應(yīng)的技術(shù)分析，文章末尾會(huì)提出針對這些漏洞的防護(hù)建議。

　　工控設(shè)備研究過程

　　本次選取了ABB的AC500系列PLC，初始的研究目標(biāo)為：固件分析與研究、私有協(xié)議安全性研究。目標(biāo)硬件為PM564-RP-ETH-AC，固件版本通過組態(tài)軟件Automation Builder 2.4.1升級到最新版本2.8.4。

　　確定研究對象后，首先搭建安全測試環(huán)境，利用nmap對PM564進(jìn)行掃描得到如下結(jié)果，依據(jù)長時(shí)間接觸工控領(lǐng)域的經(jīng)驗(yàn)，當(dāng)發(fā)現(xiàn)如下兩個(gè)網(wǎng)絡(luò)端口時(shí)第一反應(yīng)就是私有協(xié)議端口而且和CodeSys關(guān)系很大。

　　接下來，打開組態(tài)軟件，創(chuàng)建工程后下裝至PM564，利用wireshark抓取通信報(bào)文，查看報(bào)文數(shù)據(jù)結(jié)構(gòu)，發(fā)現(xiàn)請求和響應(yīng)報(bào)文中都攜帶有4f 96 05開頭的19個(gè)字節(jié)的head結(jié)構(gòu)，緊接著“aa aa”打頭的為payload。通信過程中使用的端口為1200。那么1201端口是什么時(shí)候使用的呢？數(shù)據(jù)報(bào)文結(jié)構(gòu)是什么樣子呢？先保留這些問題，接下來先看看PM564的固件。

　　幸運(yùn)的是ABB官方提供了固件下載，最新版本的固件鏈接地址為：

　　https://new.abb.com/plc/programmable-logic-controllers-plcs/ac500-eco/cpus

　　當(dāng)下載到固件后，找到對應(yīng)模塊PM564的固件，固件中包含的文件如下所示，其中2_0_2文件夾為BootLoader，2_8_4文件夾為firmware，ONB_IO文件夾為onboardIO部分，RTC_BATT文件夾為RTCBattery部分。

　　進(jìn)入到firmware文件夾后，只有一個(gè)文件Pm55xE.gza，利用010打開后文件內(nèi)容如下圖所示，可以發(fā)現(xiàn)該文件肯定是經(jīng)過特殊處理的，無法利用binwalk工具獲取到相關(guān)信息，至此進(jìn)入到了不幸的階段。雖然提供固件下載但是無法閱讀分析，這也是工控領(lǐng)域常見的情形，比如Siemens提供固件下載，但是固件都是經(jīng)過特殊處理的。這時(shí)可以利用《某工控設(shè)備固件提取及分析》文章中提及到的第二種方法，利用拆焊手段得到flash內(nèi)部的代碼進(jìn)而分析固件，找到固件處理算法、分析算法、拆解下載到其余PLC模塊的固件。

　　由于研究對象為實(shí)驗(yàn)室專有設(shè)備無法拆解，因此在某魚上買到了一個(gè)性價(jià)比更高的PM554模塊，直接作為拆焊對象，首先分析硬件架構(gòu)，理清使用的CPU、flash等芯片。如下圖所示，左邊為模塊的CPU，型號為MPC852T，是基于PowerPC架構(gòu)的MPC860四路集成通信控制器。右邊標(biāo)識(shí)出的為模塊的flash芯片，型號為M29W320EB，它是一個(gè)容量為4M字節(jié)的nonflash芯片。

　　接下來就要將flash芯片拆焊，利用編程器讀取內(nèi)部數(shù)據(jù)。由于該模塊的物理結(jié)構(gòu)復(fù)雜并不像其余PLC是多個(gè)PCB板層疊安裝，而是“兩山夾一川”的格局，目標(biāo)芯片還在“一座山”的山腰位置，因此難度大大增加，經(jīng)過不斷的細(xì)心嘗試，最終還是將目標(biāo)芯片拆下來了，如下圖所示。

　　之后利用編程器讀取出flash芯片中的內(nèi)容，經(jīng)過分析flash中的內(nèi)容存在字節(jié)序問題，修復(fù)字節(jié)序后放入binwalk分析如下圖，從0x50010處開始即為固件部分。

　　剩下的工作就是將固件部分導(dǎo)入IDA進(jìn)行分析，首先利用rbasefind方法找到起始地址，然后根據(jù)經(jīng)驗(yàn)尋找字符串定位通信處理函數(shù)，找到1201/1200端口的功能。在此不再贅述，見下圖rebase address后的IDA分析圖示。

　　經(jīng)過分析和驗(yàn)證發(fā)現(xiàn)，1201端口是為了兼容之前的組態(tài)軟件版本開啟的端口，使用的是以“bb bb”開頭的私有協(xié)議，通過搭建Automation Builder 2.3和PM564通信環(huán)境驗(yàn)證了這一點(diǎn)，下邊截圖展示了1201端口的流量。

　　進(jìn)一步分析得知報(bào)文格式如下所示，其中開頭2字節(jié)為特定報(bào)文頭，接下來的4個(gè)字節(jié)為長度域（大端模式），緊跟1個(gè)字節(jié)為功能碼，緊隨其后為N字節(jié)的數(shù)據(jù)部分。

　　至此可以做如下總結(jié)：

　　A. 通過拆焊芯片得到了PM554固件，經(jīng)過分析固件得到了該系列模塊固件的處理算法。

　　B. 通過分析固件得知1201端口也是私有協(xié)議，以“bb bb”打頭。

　　C. 1200端口為最新版本組態(tài)軟件和設(shè)備通信的私有協(xié)議，以“4f 96 05”打頭。

　　D. 經(jīng)過分析發(fā)現(xiàn)模塊底層采用的操作系統(tǒng)為Micro Digital公司的SMX，但是版本依然停留在V3.5。

　　既然已經(jīng)獲取到了1201端口和1200端口的流量和報(bào)文格式，那么利用自制的Fuzz工具，就可以很輕松的針對私有協(xié)議進(jìn)行安全性測試。針對1201端口結(jié)構(gòu)較為簡單的私有協(xié)議開始Fuzz測試，在不到半天的時(shí)間內(nèi)發(fā)現(xiàn)了多個(gè)拒絕服務(wù)漏洞。以下是發(fā)現(xiàn)漏洞的示例圖，PM564的狀態(tài)為ERR燈閃爍，進(jìn)入嚴(yán)重故障模式，只有重新上電才能恢復(fù)正常狀態(tài)。

　　通過修改poc在其余使用CodeSys Runtime的PLC上進(jìn)行驗(yàn)證，發(fā)現(xiàn)也受到這些漏掉的影響，至此猜測是由CodeSys Runtime引入的漏洞。為了驗(yàn)證猜測，分析了固件定位到了崩潰點(diǎn)，該崩潰點(diǎn)在CodeSys Runtime內(nèi)核部分。而且PM564使用的Runtime版本為已經(jīng)過時(shí)的版本2.4.7.48，見下圖：

　　為了更進(jìn)一步坐實(shí)這些漏洞是由CodeSys Runtime引入的，下載了當(dāng)時(shí)最新的版本（Runtime版本為2.4.7.55），搭建了對應(yīng)的Fuzz測試環(huán)境，在Runtime中發(fā)現(xiàn)了多個(gè)漏洞，并將這些漏洞提交給了CodeSys官方。

　　CodeSys 漏洞分析

　　2021年10月25日CodeSys官方發(fā)布了4份安全通告，其中包含了10個(gè)漏洞，格物實(shí)驗(yàn)室提交的多個(gè)漏洞被合并為3個(gè)漏洞，且都評為高危，并獲得官方致謝。3個(gè)漏洞的基本情況如下所示：

　　CVE-2021-30188（CVSS3.0評分8.8）： CWE-121: Stack-based Buffer Overflow

　　特制的請求報(bào)文發(fā)送至受影響的CodeSys產(chǎn)品中，可能引起目標(biāo)的拒絕服務(wù)或者遠(yuǎn)程代碼執(zhí)行。

　　CVE-2021-34595（CVSS3.0評分8.1）： CWE-823: Use of Out-of-range Pointer Offset

　　單個(gè)特制的請求報(bào)文發(fā)送至受影響的CodeSys產(chǎn)品中，可造成越界讀或者寫，進(jìn)而引發(fā)拒絕服務(wù)或者本地內(nèi)存被覆蓋。

　　CVE-2021-34596（CVSS3.0評分8.1）： CWE-824: Access of Uninitialized Pointer

　　單個(gè)特制的請求報(bào)文發(fā)送至受影響的CodeSys產(chǎn)品中，可造成訪問未初始化的指針，進(jìn)而引發(fā)拒絕服務(wù)。

　　成功利用這些漏洞，輕則導(dǎo)致目標(biāo)產(chǎn)品發(fā)生拒絕服務(wù)、出現(xiàn)宕機(jī)等后果，重則可使目標(biāo)執(zhí)行惡意攻擊者編制的利用代碼，以此影響生產(chǎn)、持續(xù)潛伏、竊取敏感數(shù)據(jù)、適時(shí)發(fā)動(dòng)定點(diǎn)攻擊等。

　　在此，以CVE-2021-34595為例，以受影響的PM564模塊作為目標(biāo)做一個(gè)簡單分析。

　　當(dāng)向PM564模塊的1201端口發(fā)送0x3E功能碼的報(bào)文時(shí)，報(bào)文payload部分被直接使用而沒有做字段校驗(yàn)處理。

　　經(jīng)過一系列處理函數(shù)，最終進(jìn)入到了sub_1FECC0的memcpy操作，memcpy函數(shù)的size字段是從報(bào)文的payload中直接獲取到的，并進(jìn)行了簡單的數(shù)學(xué)計(jì)算，最終導(dǎo)致size字段過大超出了內(nèi)存范圍，進(jìn)而導(dǎo)致崩潰。

　　影響范圍分析

　　CodeSys是全球最著名的PLC軟件研發(fā)廠家德國3S（SMART，SOFTWARE，SOLUTIONS）公司發(fā)布的一款與制造商無關(guān)編程軟件及工控設(shè)備內(nèi)核（Runtime SDK）。

　　這些漏洞不僅僅影響CodeSys軟件產(chǎn)品，還影響使用CodeSys Runtime內(nèi)核的廣大工控廠商，因?yàn)镃odeSys作為“工控界的安卓”被廣泛使用在工控設(shè)備中，據(jù)官方統(tǒng)計(jì)使用CodeSys解決方案的知名企業(yè)超過500家，CodeSys市場占有率為35%，其中熟知的ABB、施耐德電氣SchneiderElectric、費(fèi)斯托Feso、伊頓電氣、博世力士樂、倍福BECKHOFF、研華科技、凌華科技ADLINK、和利時(shí)集團(tuán)、匯川技術(shù)、深圳英威騰、華中數(shù)控、固高科技等都使用了CodeSys Runtime。更詳細(xì)的合作客戶請參見如下鏈接 http://www.codesys.cn/list-Partner-1.html

　　查看公網(wǎng)暴露的CodeSys 產(chǎn)品如下圖，可以看到暴露數(shù)量不算少，尤其在土耳其暴露數(shù)量超過了1200多個(gè)。由于工控安全意識(shí)加強(qiáng)，很多設(shè)備都不在統(tǒng)計(jì)范疇內(nèi)，因此這個(gè)暴露數(shù)量只是冰山一角。

　　防護(hù)措施及建議

　　1. 將受影響的產(chǎn)品放置于安全防護(hù)設(shè)備之后，做好網(wǎng)絡(luò)安全的縱深防御策略。

　　2. 當(dāng)需要進(jìn)行遠(yuǎn)程訪問時(shí)，盡量采用安全的VPN網(wǎng)絡(luò)，并且做好訪問控制和審計(jì)工作。

　　3. 關(guān)注受影響廠商的安全補(bǔ)丁，經(jīng)過測試后升級受影響的產(chǎn)品以使其免受威脅。

　　4. 盡量減少受影響設(shè)備的私有通信端口暴露，可根據(jù)業(yè)務(wù)場景選擇關(guān)閉受影響的1200/1201/2455等端口。

　　5. 建議使用CodeSys Runtime的工控廠商及時(shí)自查，并且積極修復(fù)，發(fā)布修復(fù)版本的固件。

　　總結(jié)

　　本文先從工控設(shè)備研究入手，發(fā)現(xiàn)了私有協(xié)議的多個(gè)漏洞，后來經(jīng)過在其余使用相同內(nèi)核的PLC上驗(yàn)證也存在漏洞，進(jìn)一步在CodeSys Runtime內(nèi)核上進(jìn)行安全測試，發(fā)現(xiàn)了CodeSys Runtime內(nèi)核的多個(gè)漏洞，提交官方后得到了修復(fù)。通過這個(gè)事件需要意識(shí)到，在OT領(lǐng)域內(nèi)供應(yīng)鏈威脅早已存在，而且影響范圍會(huì)越來越大，工控設(shè)備使用的內(nèi)核、以太網(wǎng)協(xié)議棧、操作系統(tǒng)都很集中，比如操作系統(tǒng)都是用VxWorks、QNX、裁剪的Linux，以太網(wǎng)協(xié)議棧使用LWIP，內(nèi)核使用CodeSys、Infoteam、KW等，除此之外還會(huì)使用開源代碼實(shí)現(xiàn)應(yīng)用層協(xié)議，比如Modbus、Ethernet/IP等，難免會(huì)引入更多的風(fēng)險(xiǎn)。面對這樣的風(fēng)險(xiǎn)我們?nèi)绾螒?yīng)對呢，在此筆者給出了幾點(diǎn)建議：

　　1. 加強(qiáng)供應(yīng)鏈產(chǎn)品或組件的篩查審查機(jī)制，從頂層設(shè)計(jì)解決用誰的？用哪個(gè)版本？怎么用？出了問題如何快速更新等問題。

　　2. 建立公司內(nèi)部供應(yīng)鏈產(chǎn)品或組件的風(fēng)險(xiǎn)管理機(jī)制，能夠識(shí)別開發(fā)過程中惡意的變動(dòng)，并觸發(fā)追查和防范措施。

　　3. 借鑒google的SLSA供應(yīng)鏈完整性框架，在開發(fā)過程中防范供應(yīng)鏈威脅。

　　由于知識(shí)面的限制，提出以上安全防護(hù)措施供參考，更多針對供應(yīng)鏈威脅的處理和應(yīng)對措施還需群策群力，構(gòu)建真正能夠在前期將供應(yīng)鏈攻擊扼殺的體系，以此來保障我們業(yè)務(wù)的安全生產(chǎn)與運(yùn)行。