劉晉兵， 景 峰

（1.大唐太原第二熱電廠，山西 太原 030041；2.國網山西省電力公司，山西 太原 030001）

0 引言

電廠及電力監(jiān)控系統(tǒng)廣泛采用各類嵌入式設備，如測控裝置、保護裝置、計量裝置等。嵌入式設備大多采用通用硬件芯片、開源操作系統(tǒng)、通用協(xié)議開發(fā)，設備廠商在追求設備功能、性能及易用性的同時，忽略了設備本體的信息安全設計與實現(xiàn)。另外，越來越多的設備漏洞被公之于眾，嵌入式設備本體的信息安全逐漸受到公眾的關注，如震網病毒（Stuxnet） 利用了西門子PLC 控制器設備漏洞及SCADA 程序漏洞進行攻擊。隨著兩化融合、智能電廠及智能電網的建設，對協(xié)議實現(xiàn)的安全性和健壯性進行測試就顯得非常重要，對電力行業(yè)的工控通信協(xié)議進行漏洞挖掘顯得越發(fā)重要。

此次模糊測試的目標是電力行業(yè)嵌入式設備的通信協(xié)議。針對此類嵌入式設備的模糊測試定義為“通過向應用提供非預期的輸入并監(jiān)控輸出中的異常來發(fā)現(xiàn)被測設備故障的方法”。模糊測試數據以自動化的方式生成向被測設備提供非預期的輸入。

1 模糊測試原理

模糊測試Fuzzing 采用黑盒測試的思想，通過應用程序輸入大量非預期的數據，在輸入的同時監(jiān)控輸出中的異常。將Fuzzing 測試定義為通過向應用提供非預期的輸入并監(jiān)控輸出中的異常來發(fā)現(xiàn)軟件故障的方法。即Fuzzing 測試利用自動化或是半自動化的方法重復地向應用提供輸入。

運用Fuzzing 測試的原理，設計編譯測試用例構造變異報文，檢查工控協(xié)議實現(xiàn)的缺陷。構建完整、可擴展的動態(tài)隨機分析測試框架，監(jiān)控測試目標，管理測試結果。數據生成方法也就是協(xié)議模型化，數據生成要自動化，要考慮被測設備容易出現(xiàn)什么錯誤，而不是簡單地隨機生成，通過這樣的結合來生成測試數據。

當對某些協(xié)議的值字段進行Fuzzing 測試時，在每個測試用例中必須計算并更新這個多字節(jié)的長度字段。否則，如果通信數據被檢測為違反協(xié)議規(guī)范，測試用例就面臨著被廢棄的風險。大多數開源框架提供了生成偽隨機數據的方法，好的框架甚至會包含一個啟發(fā)式攻擊的列表，啟發(fā)式攻擊會導致軟件出現(xiàn)錯誤的數據序列。

錯誤檢測在Fuzzing 測試中扮演著重要的角色，在最簡單的層面上，如果目標應用不能接受新連接，F(xiàn)uzzing 測試器能夠檢測到它的目標可能已經出錯了。更高級的錯誤檢測通常需要借助調試器的幫助，高級的Fuzzing 測試框架應該允許模糊測試器直接與附著在目標應用上的調試器通信，甚至是自帶定制的調試器。

2 嵌入式設備漏洞挖掘技術的實現(xiàn)

2.1 模糊測試數據

一般情況會認為Fuzzing 測試和邊界值分析方法是很類似的，但不同的是，F(xiàn)uzzing 測試過程中不僅僅關注邊界值，同時還關注任何能夠觸發(fā)未定義或者不安全行為的輸入，因此針對電廠及電力系統(tǒng)中的通信協(xié)議，研發(fā)重點在測試方法和如何生成Fuzzing 測試數據上。通常測試數據的生成分為兩種：一是基于變異的測試生成器。對已有的樣本進行變異等操作，實現(xiàn)測試用例的生成。二是基于生成的模糊測試生成器。通過為被測設備使用的協(xié)議格式和交互邏輯進行建模，從而用此模型來生成輸入并據此創(chuàng)建測試用例。

2.2 測試流程

測試方法是決定漏洞挖掘是否有效的決定性因素，測試流程包含幾個基本階段，圖1 為Fuzzing系統(tǒng)測試框架圖。

圖1 模糊系統(tǒng)測試框架圖

2.2.1 確定測試目標

有了明確的測試目標后，才能決定使用的模糊測試工具或方法。

2.2.2 確定輸入向量

輸入向量是模糊測試的關鍵，如果不能預期輸入值，模糊測試的作用就會受到很大的局限。

2.2.3 生成模糊測試數據

一旦識別出輸入向量，就可以依據輸入向量產生模糊測試數據。數據通過自動化過程來生成，可以使用預先確定的值、使用基于存在的數據通過變異生成的值或者使用動態(tài)生成的值。

2.2.4 執(zhí)行模糊測試數據

該步驟緊接上一個步驟，一般會向被測目標發(fā)送數據包、打開文件或者執(zhí)行被測應用。

2.2.5 監(jiān)視異常

一個重要但經常容易被忽略的步驟是對異常和錯誤進行監(jiān)控。模糊測試需要根據被測應用和所決定采用的模糊測試類型來設置各種形式的監(jiān)控。

2.2.6 漏洞是否可能被利用的判斷

對在模糊測試中發(fā)現(xiàn)的錯誤，依據審計情況，判定該錯誤是否構成可被利用的安全漏洞，這個過程通常采用人工過程實現(xiàn)。

2.3 漏洞挖掘測試用例分析

Fuzzing 漏洞挖掘測試數據的生成包括預生成、隨機生成、手工協(xié)議變異等，使用多種漏洞挖掘測試用例可顯著提升漏洞挖掘效率，但在選擇測試用例過程中，需考慮效率問題。

a） 預生成測試用例。首先研究設備給定的或特定的協(xié)議規(guī)約，理解協(xié)議規(guī)約支持的數據結構和輸入值的范圍，生成用于測試邊界條件或者是違反規(guī)約的測試用例。預生成測試用例存在固有的局限性，該過程缺乏隨機輸入生成，用例被執(zhí)行完，測試即結束。

b） 隨機生成用例。隨機方法主要被用來快速地識別并判斷目標應用中是否有非常糟糕的代碼，通過向目標應用發(fā)送偽隨機數據，獲取測試結果。

c） 手工協(xié)議測試。手工協(xié)議測試不需要自動化模糊測試器，在此，測試者就是模糊測試器。加載了目標應用后，測試者通過輸入不正確的數據，嘗試誘發(fā)設備或應用的一些不正常行為。該方法依賴于分析者能否在安全審計中充分發(fā)揮自己的經驗。

d） 強制性測試。強制性測試是指模糊測試器從一個有效的協(xié)議樣本或數據格式樣本開始，持續(xù)不斷地打亂數據包中的每個字節(jié)（byte）、字（word）、雙字（dword） 或者是字符串（string）。這種方式幾乎不要求對應用進行研究，實現(xiàn)一個基礎的強制性模糊測試器也是相對直接的，強制性模糊測試器只需要修改數據并將其發(fā)送給被測應用。

這種方法相對比較低效，因為許多CPU 周期會被浪費在生成完全不可解析的數據上，其優(yōu)點主要為：整個測試的過程可以完全自動化實現(xiàn)，使用強制模糊測試方法其代碼覆蓋依賴于一致的合法數據包。

e） 自動協(xié)議生成測試。自動協(xié)議生成測試是一種更高級的強制性測試方法。在對被測應用進行深入研究，理解和解釋協(xié)議規(guī)約的前提下，創(chuàng)建一個描述協(xié)議規(guī)約如何工作的語法。測試者識別數據包中的靜態(tài)部分和動態(tài)部分，動態(tài)部分可以被模糊化變量替代。通過動態(tài)分析包含了靜態(tài)和動態(tài)部分的模板，生成測試數據，將結果數據包發(fā)送給被測應用。在此，對電力通信協(xié)議的組成與規(guī)范了解得越多，就越能在模糊測試中關注那些易引發(fā)異常的協(xié)議中的部分。

由存在潛在危險的模糊字符串和模糊數據組成的集合又被稱為模糊探值。為了保證測試數據的易用性，抽象協(xié)議的數學模型和生成數據的自動化尤為重要。相對自動化生成模糊測試數據，協(xié)議數學模型的抽象就是根本。

解決如何生成數據的問題是解決方案的一部分，同樣重要的問題是“生成什么數據”。如果在協(xié)議字段中去遍歷的話效率不僅低下，發(fā)現(xiàn)問題的概率同樣無從保證。因此，不能測試整個協(xié)議所有字段的數值空間，而是應該選擇其具有代表性的一些數值并且找到對協(xié)議實現(xiàn)邏輯有影響的區(qū)間段來生成測試數據。

f） 代理模糊測試。在典型的基于網絡的客戶端—服務器模型中，客戶端和服務器之間會直接進行通信。正如其名稱所暗示的，代理模糊測試器在客戶端和服務器之間的連接上充當中繼。為了有效地完成這一任務，客戶端和服務器必須被手工配置為指向代理服務器。也就是說，客戶端把代理當作服務器，而服務器把代理當作客戶端。

目前，對代理模糊測試的改進方向是為了讓其更“聰明”，使用啟發(fā)式規(guī)則輔助進行自動字段檢測和數據變異是其中的一種方法?？梢詰脝l(fā)式規(guī)則將識別出來的數據進行進一步的處理。

3 設備漏洞挖掘測試

3.1 某PLC 設備

3.1.1 測試過程

PLC 的DO 上連接一些指示燈，并讓指示燈處于常亮狀態(tài)。然后把測試設備和被測設備通過網線直連或者中間通過一個交換機相連。按測試環(huán)境里面的配置搭建好環(huán)境，等監(jiān)視器都正常工作后開始給被測設備發(fā)送Modbus 語法測試數據包，當測試進行一段時間后，原來常亮的指示燈熄滅。設備采用linux_kernel：2.6.x 內核，對外提供telnet、ftp、modbus 等公開服務。

設備在收到0x01 功能碼，起始地址為0，線圈數量為0 的modbus/tcp 數據包時，協(xié)議棧會短時間崩潰，等通信恢復后modbus 服務一直處于對外拒絕服務狀態(tài)。設備在收到負載為Ethernet type 跳變的Ethernet 報文，設備出現(xiàn)ICMP 回應延遲、對外拒絕服務現(xiàn)象。

3.1.2 問題分析

設備在收到測試報文的時候ARP、ICMP、TCP端口監(jiān)視器全部停止工作，說明協(xié)議棧已崩潰。在測試停止后觀察事件日志可以發(fā)現(xiàn)在測試過程中23、100、502 端口異常，稍后23、100 恢復正常，502（modbus） 服務一直未恢復，需要下電重啟才能恢復。

設備在進行Ethernet 語法測試時出現(xiàn)ICMP 響應延遲，對外拒絕服務等問題。分析詳細報文，報文對Ethernet type 進行跳變（見圖2）。

在發(fā)電及電力系統(tǒng)現(xiàn)場，存在著很多這樣的PLC，它們的功能各異，執(zhí)行著不同的邏輯，但是一旦黑客入侵到PLC 所在的網絡，并且有足夠的時間展開攻擊，就有可能把PLC 原有的邏輯打亂，從而破壞電力生產，進而造成經濟和其他方面的損失。

3.2 MMS 的TPKT 測試某保護裝置

3.2.1 測試過程

加電后通過光電轉換模塊把光信號轉換成電信號，然后直接連接到測試設備，或者中間通過交換機相連。

設備按測試方案的方式進行連接，等到所有監(jiān)視器都正常后，開始給設備發(fā)送MMS 協(xié)議的TPKT數據段語法測試，當測試進行幾分鐘以后，ARP 和ICMP 監(jiān)視器出現(xiàn)異常，網絡中斷，TCP 監(jiān)視器對102 端口的監(jiān)視出現(xiàn)異常，102 端口關閉。停止測試后上述失敗不能自動消失。

圖2 Ethernet type 跳變測試用例監(jiān)視

3.2.2 問題分析

TPKT 協(xié)議處于TCP 協(xié)議之上，主要傳輸應用層負載，例如遠程桌面協(xié)議就是靠TPKT 協(xié)議來支撐。在電力設備中，基于MMS 協(xié)議的數據使用TPKT 來傳輸通信的負載。對問題報文結合MMS 協(xié)議進行分析。

a） 發(fā)送報文的TPKT 的length 字段超出緩存的長度，即造成內存溢出，導致設備宕機。

b） 當測試中組裝了正確的協(xié)議頭，但是協(xié)議負載填充的數據不符合MMS 協(xié)議規(guī)約，而設備無法處理此類報文，該缺陷可能導致協(xié)議棧崩潰。

通過上面的論述可以證明，MMS 的TPKT 語法測試可以讓該型號的變壓器保護設備出現(xiàn)網絡中斷無法對外提供服務的問題。由此可見，該型號變壓器保護設備對MMS 協(xié)議的實現(xiàn)有著一定的缺陷，這種缺陷可以導致設備對外拒絕服務，從而使得設備失效，而這種缺陷如果出現(xiàn)在網絡中是很危險的，這種漏洞如果讓黑客入侵設備所在網絡后進行利用，會導致設備癱瘓，進而影響電力設備的安全。而這種漏洞的根源往往是因為工業(yè)設備對協(xié)議棧的實現(xiàn)只考慮了功能方面，卻忽略了協(xié)議棧的健壯性，進而使得人為設計的非法的或者畸形的數據包可能導致協(xié)議棧不能正確處理而致使協(xié)議棧崩潰，進而使得工業(yè)現(xiàn)場的設備處于危險境地。

4 結束語

本文通過構建Fuzzing 測試用例，對電力行業(yè)工業(yè)控制系統(tǒng)普遍使用的PLC 及保護裝置開展漏洞挖掘，發(fā)現(xiàn)其中存在的系統(tǒng)漏洞，并給出設備存在協(xié)議漏洞的分析過程。