基于CODESYS軟件PLC的“震網式”攻擊 - 網安 - 專業的網絡安全產業、社區、知識平臺

前言

震網(Stuxnet)攻擊事件雖然已經過去了10年有余，除了使用了多個0day的使用外，對西門子Step7和Siemens系列PLC的攻擊方式也一直被工業安全領域所關注。10年來隨著技術的不斷發展，軟件PLC以其開放性和便捷性在工業領域被越來越多的使用，這其中的代表廠商之一就是CODESYS。早在1984年Ken Thompson就設想了一種植入編譯器的病毒，本文使用震網的思想，成功對CODESYS編譯系統進行了攔截，在IDE無感的前提下，在PLC中植入了反彈shell。

Stuxnet回顧

我們知道Stuxnet使用了多個0day、遠程代碼執行、本地提權、感染LNK、感染step7工程等等，相關細節本文在此不做贅述。進行了這些騷操作并找到自己的目標后，震網病毒就開始了它真正的攻擊行為，劫持Step7并通過Step7控制與之相連的西門子S7 PLC。

Step7是西門子的集成開發環境(IDE)，開發人員需要通過Step7將控制邏輯編寫成STL (structured text lanague), 一種類似FORTRAIN的語言，并將STL編譯成機器碼，下載到PLC中執行。

震網攻擊Step7的方式是將一個惡意的s7otbxdx.dll替換掉了s7otbxsx.dll, 這個dll的主要作用是與PLC進行通信，包括：1.接受編譯后的字節碼并傳承給PLC，2.將PLC中的程序顯示到Step7用于調試。

而惡意的dll會在寫入PLC的時候加入自己的字節碼，而當Step7檢查代碼的時候返回正常代碼，使得IDE無法發現代碼已被改動。.

這種攻擊方式具有極強的隱蔽性,專業性和針對性，在十多年后的今天看來仍然令人嘆服。時至今日，工控系統的安全已經引起了廣泛的重視，工控領域的技術也有了長足的進步，此類攻擊是否還有可能發生呢？我們針對另外一家市場規模巨大的廠商CODESYS產品進行了研究和嘗試。

CODESYS介紹和分析

CodeSys是全球最著名的PLC軟件研發廠家德國3S(SMART，SOFTWARE，SOLUTIONS)公司發布的一款與制造商無關編程軟件及工控設備內核。因為CodeSys作為“工控界的安卓”被廣泛使用在工控設備中，據官方統計使用CodeSys解決方案的知名企業超過500家，CodeSys市場占有率為35%。此次我們分析的主要是目標是CodeSys編程軟件和CodeSys軟件PLC。

首先我們從工控開發者使用的角度看CodeSys的產品體系。CodeSys工程是一個開發任務各種資源的集合，和現代編程語言的工程十分相似。CodeSys支持多種編程語言，其中主要的一種語言是Structed txt 也叫ST或者STL。ST 語法上類似Fortran, Level上和C語言比較接近，可以操作指針，可以借助庫函數手動管理內存。在工程中開發者可以引入各種庫，這種庫包括各種支持功能，例如文件操作，字符串操作，串口操作，CanBus操作等，這些庫多數是CodeSys官方提供的。工程中開發者可以加入可視化組件，用于展示和監控控制系統的狀態。工程中開發者可以對工程進行編譯，可以對工程進行模擬執行，可以將工程下載到PLC中執行。

編譯系統

從模塊上分，CodeSys產品大致可以分為IDE集成開發系統，編譯系統，運行時系統，其中IDE主要用于交互，執行時系統主要用于支撐軟件PLC的運行，編譯系統主要功能是將源代碼編譯成目標可執行應用。這里著重分析的是編譯系統。

CodeSys的IDE和編譯器系統是使用.net開發的，我們可以通過反編譯了解其內部構造和原理。使用dnspy軟件對CodeSys進行動態和靜態分析，盡管.net的靜態可以還原到近似于源代碼的形式，但CodeSys對大量的內部代碼進行了名稱混淆，給靜態分析帶來一定的干擾，由于所有的攻擊方法都是基于對目標的認識，因此實際分析的過程是一個比較漫長和艱苦的過程。

編譯器前后端

CodeSys有獨立設計實現的完整的編譯器體系，使用插件構架，可以動態支持多編譯器版本，編譯器采用分離的前后端，用以適配多語言和多平臺。編譯器前端主要的工作是解析并檢查源文件，并將源文件生成語法樹AST以提供給后端，后端則是根據目標設備選擇代碼生成器生成目標機器碼，生成的只執行代碼具有代碼區、數據區，重定位區等。

編譯過程

CodeSys編譯器進行工程編譯可分為五個階段：

1. 類型化 (Typification) 分析函數和類型定義，做基本的檢查

2. 后類型化 (AfterTypification) 分析函數實現，基于類型化信息，進行進一步檢查

3. 重定位 (Location) 針對使用地址，動態內存，多態等需要重定位的代碼提取重定位信息

4. 類型檢查 (TypeCheck)

5. 代碼生成 (CodeGeneration) 從AST生成目標機器碼

其中前4步主要都是編譯器前端的工作，用于產生與平臺無關的AST，而后端主要是第5步，根據平臺生成相應機器指令。震網對于西門子PLC的攻擊雖然也是基于對開發環境Step7的劫持進行，攻擊注入的也是機器碼，但劫持的環節依然是通訊模塊。實際上震網對Step7的編譯過程是沒有進行干擾的。對CodeSys的編譯體系有一定的了解后，我們要問：有沒有可能針對編譯體系對PLC展開攻擊？

CodeSys編譯系統攻擊

.net代碼劫持

在分析的基礎上，我們需要實現對CodeSys 編譯器.net代碼的修改。直接patch IL的代碼修改方式不適合大量的修改，而且在處理第三方引用和字符串上有很多不便，因此轉向hook方法。目前使用的是Playhooky庫 (https://github.com/wledfor2/PlayHooky) ，該hook的主要原理是動態修改要hook的函數，將其改為：

mov r11,replacementSite

jmp r11

的形式。這種hook的主要局限在于不能返回調用原始函數。因此必須謹慎選擇hook的目標。于是代碼劫持的過程為：

1. 注入一個native dll （dllloader）到codesys進程

2. dllloader加載一個.net庫(hijack)并執行

3. hijack庫中執行hook，對codesys函數進行替換

針對前端的攻擊

對編譯前端攻擊的主要思路是追蹤編譯流程，在一個合適的地方，對編譯的源文件或者中間結果進行篡改。經過分析，我們選擇：

LanguageModelManagerConsolidated.CreateScanner函數作為攻擊目標，因為這個函數接受一個ST代碼字符串的輸入作為入參：

IScanner CreateScanner(string stText, bool bIncludeComments, bool bIncludeEndOfLines, bool bIncludePragmas, bool bIncludeWhitespaces)

生成的IScanner對象會被后面的文本解析所使用，并傳遞給編譯器后端。因此攻擊方法就是劫持這個函數，將ST源碼替換成惡意的。

以一個演示性質的分類流水線工程為例，此項目展示一個垃圾分離器，能將各種不同類型的物品在流水線上分類并計數。

當物品為怪物時，則暫停流水線，同時alarm燈亮。

我們劫持并替換部分ST代碼，替換PLC_PRG的部分代碼，

注入Codesys后重新編譯代碼執行

怪物直接掉了下去，而流水線沒有停止，而是顯示FINISHED；這在實際工業場景中可能是某種災難性的結果，而這一切從工程代碼中看不出任何異常。

針對后端的攻擊

針對編譯器前端的攻擊雖然能避免跨平臺問題但是ST的表達能力畢竟有限，難以進行進一步的控制。那么能不能把遠控后門直接寫入到編譯后的代碼中呢？答案是肯定的。

跟蹤分析編譯器代碼生成組件，發現對模擬器和Windows版PLC的代碼生成庫為code386, 其中Generate函數接收一個pou,并獲取AST語法樹，遍歷語法樹進行代碼生成。

publicvoid Generate(ICompiledPOU cpou, bool bKeepCodeList)      {          this.Generate(cpou,cpou.ParseTree as ISequenceStatement, bKeepCodeList, null);     }

代碼檢查繞過

對code386進行劫持過程中，發現IDE啟動編譯會立即退出，剛開始以為是代碼的問題，經過調試發現，是由于CodeSys主動對調用棧的所有模塊進行了校驗，檢查是否存在第三方程序，如果有即主動退出：

經過分析，發現該檢查方法會放過mscorlib，即微軟的.net庫，于是我們把劫持的庫的名字改成”mscorlib”即可繞過此檢查過程。

shellcode植入

首先使用metasploit生成一個reverse_tcp shellcode

劫持Generate函數，當代碼生成的函數是我們要替換的函數時，直接替換為shellcode作為生成結果。

重新生成工程并下載到PLC中執行，監聽的handler立即收到反彈的shell：

總結

此項研究在CodeSys V3.5 SP17上進行測試，成功在模擬器和CodeSys Control Win上實現了攻擊，攻擊的前提是能注入dll到CodeSys IDE進程中。雖然針對工控系統的劫持類攻擊的研究很多，但直接從編譯系統著手的似乎并不是很多。從攻擊者角度來看，此類攻擊有兩個特點：

1. 針對編譯器的攻擊方式很難做得通用，因為編譯過程一般比較復雜并且和程序邏輯本身無關，要取巧就只能針對某一個特定得點展開

2. 分析的難度往往大于實施攻擊的難度，從防御的角度來講，此類攻擊隱蔽性較強，受的攻擊的面可能很大(編譯鏈條的各處都可能受到攻擊)，工控系統相對封閉，更缺少有效的手段去反制。目前來說可能的對抗措施有：1、提高分析的難度；2、提供編譯中間狀態和編譯結果的校驗工具，讓運維和開發人員可以校驗編譯器是否被干擾。

參考文獻：

Stuxnet ‐ Infecting Industrial ControlSystems

Applying a Stuxnet Type Attack to a ModiconPLC (CVE-2020-7475)

Remote code Execution On EcoStruxure PLCsimulator (CVE-2020-28211, CVE-2020-28212, CVE-2020-28213)

Stuxnet-in-a-Box: In-Field Emulation andFuzzing of PLCs to Uncover the Next Zero-Day Threat in Industrial ControlSystems

Applying a Stuxnet Type Attack to aSchneiderModicon PLC