2018年工業信息安全技能大賽解題報告-工業網路數據分析

最新 07-24

當前，隨著中國製造2025戰略深入推進，工業控制系統從單機走向互聯、從封閉走向開放、從自動化走向智能化，安全漏洞和隱患不斷湧現、安全事件頻繁發生。我國面臨的工業信息安全形勢日益嚴峻。

圖1 2018年工業信息安全技能大賽（東北賽區）開幕式

2018年工業信息安全技能大賽（東北賽區）分為漏洞挖掘賽和奪旗賽，其奪旗賽大概可分為工業網路數據分析、工控固件逆向、工控安全分析三個部分。

本文將介紹工業控制網路流量部分的解題思路，當然本文的思路不一定是最好的。僅僅作為拋磚，歡迎大家聯繫網藤科技「藤」安全實驗室，索取賽題來玩！

0x01電力工控數據分析1（200分）

1賽題描述

賽題如圖2所示，附件：question_1531222544_JYvFGmLP49PFC0R2.pcap。

圖2賽題

2解題思路

考慮到題目是了解MMS規約，發現數據中隱藏的Flag，所以可以先排除非MMS協議的數據包。

用wireshark打開數據包並選擇MMS協議進行過濾，如圖3所示：

圖3過濾後MMS協議的數據包

經過MMS協議過濾後，共有1838個MMS協議的數據包，發現共有四個PDU（協議數據單元），分別是：Initiate-RequestPDU (啟動-請求PDU)、Initiate-ResponsePDU (啟動-應答PDU)、Confirmed-RequestPDU (確認-請求PDU)、Confirmed-ResponsePDU (確認-應答PDU)，所以把分析的重點放在Confirmed-RequestPDU和Confirmed-ResponsePDU中。

通過分析數據包得知MMS協議的規約中Confirmed-RequestPDU和Confirmed-ResponsePDU的結構，如下：

Confirmed-RequestPDU包含invokeID、listOfModifiers、confirmedServiceRequest、Request-detail四個部分組成；

Confirmed-ResponsePDU包含invokeID、confirmedServiceResponse、Response-detail三個部分組成。

接下來，先分析一下數據包中的MMS服務，編寫腳本提取出數據包中所用的MMS服務並統計，腳本代碼如下：

腳本運行結果如下：

通過運行上面的腳本，發現數據包中使用到了9個服務，分別是

1 (getNameList)、4 (read)、5 (write)、6 (getVariableAccessAttributes)、12 (getNamedVariableListAttributes)、72 (fileOpen)、73 (fileRead)、74 (fileClose)、77 (fileDirectory)。

ConfirmedServiceRequest和ConfirmedServiceResponse的服務類型，

，可以參考GBT16720.2-2005工業自動化系統製造報文規範第2部分協議規範.pdf。

接下來就是對服務一個一個的分析，按照服務的出現次數從小到大來分析，先分析77 (fileDirectory)服務的數據包，驚奇的發現數據包第1764個比數據包第266個多一個flag.txt文件，而且文件最後一次修改時間為2018-06-14 11:19:00(UTC)，如圖4所示：

圖4獲取文件目錄的確認應答

可以猜測這個flag.txt文件就是我們所需要的flag信息，接著過濾出與flag.txt文件相關的數據包，如圖5所示：

圖5過濾後與flag.txt相關的數據包

從圖5中發現數據包中存在讀取flag.txt的請求，編寫腳本找出flag.txt的文件內容，腳本代碼如下：

腳本運行結果如下：

61850@102

所以，61850@102就是需要尋找的Flag

0x02工業協議數據分析（300分）

1賽題描述

圖6賽題

2解題思路

用wireshark打開下載到的數據包後可以發現數據包中有大量的數據混雜在一起，考慮到題目是工業協議數據分析，因此可以初步排除非工控的協議，留到最後分析。

經過逐步排除後可以發現，數據包中相關的工控流量有Modbus/TCP協議（埠是TCP 502）和西門子S7comm協議（埠是TCP 102），如圖7所示：

圖7數據包中的工控流量

接下來只需要進一步分析Modbus/TCP協議及西門子S7comm協議的數據包即可。

Ok，先來分析西門子S7comm協議吧，從數據包中可以發現，西門子S7comm協議中的PDU類型有Job和Ack_Data兩種，所以分析起來更加簡單了，編寫腳本解析出數據包中使用到的西門子S7comm協議的功能碼，腳本代碼如下：

腳本執行後，數據包中所使用的西門子S7comm協議的功能碼有0xf0 (Setupcommunication)（出現2次）和0x04 (Read Var)（出現6196次），但是進一步分析後，發現大量的0x04 (Read Var)都是對DB 1.DBX 4.0進行的讀取行為，而且數據（數據是00000000020037000000000c000000002c41）沒有變化。因此也可以大致排除西門子S7comm協議中存在Flag的可能。

下一步需要分析的就是Modbus/TCP協議了，同樣編寫腳本解析出數據包中使用到的Modbus/TCP協議的功能碼，腳本代碼如下：

腳本執行後，數據包中所使用的Modbus/TCP協議的功能碼有1 (Read coils)（出現3220次）、2 (Read Discrete Inputs)（出現3220次）、3 (Read HoldingRegisters)（出現3220次）、4 (Read Input Registers)（出現3220次）和16 (Write Multiple Registers)（出現228次）。而功能碼中的1 (Read coils)、2 (Read DiscreteInputs)、3 (Read Holding Registers)、4 (Read InputRegisters)的請求都出現過3220次，且請求的各個寄存器數值一直在不停的變化，看起來比較像正常的工業數據。

所以，接下來編寫腳本對16 (WriteMultiple Registers)功能碼相關的數據包進行分析，腳本代碼如下：

腳本執行後，發現第11779個數據包比較異常，先看一下它的TCP Payload是926d6f64627573494353736563757269747957696e?EK（如圖8所示）：

圖8隱藏Flag的數據包

可以大膽的猜測6d6f64627573494353736563757269747957696e就是我們需要的Flag，將其16進位字元串轉成ASCII字元串後得到modbusICSsecurityWin，所以modbusICSsecurityWin就是需要尋找的Flag

0x03 Modbus協議分析1（200分）

1賽題描述

賽題如圖9所示，附件：question_1531222756_modbus1.pcap。

圖9賽題

2解題思路

考慮到題目是Modbus協議數據分析，因此可以初步排除非Modbus的協議。

先分析一下數據包中所有使用到的Modbus/TCP協議功能碼，同樣編寫腳本對其進行分析，腳本代碼如下：

腳本執行後，數據包中所使用的Modbus/TCP協議的功能碼有1 (Read coils)（出現702次）、2 (Read Discrete Inputs)（出現702次）、3 (Read HoldingRegisters)（出現702次）、4 (Read Input Registers)（出現702次）和16 (Write Multiple Registers)（出現2次）。而功能碼中的1 (Read coils)、2 (Read DiscreteInputs)、3 (Read Holding Registers)、4 (Read InputRegisters)的請求都出現過702次，且請求的各個寄存器數值一直在不停的變化，看起來比較像正常的工業數據。

而16 (WriteMultiple Registers)請求只出現了2次，因此比較可疑。數據包中的16 (WriteMultiple Registers)寫入到25個連續的寄存器中（如圖10所示），我們所需要的flag信息就可能藏在這裡。

圖10隱藏Flag的數據包

所以，TheModbusProtocolIsFunny!就是需要尋找的Flag

0x04 S7comm協議分析1（200分）

1賽題描述

圖11賽題

2解題思路

考慮到題目是S7comm協議數據分析，因此可以初步排除非S7comm的協議。

如下圖12所示，可以看到該流量中存在大量的重傳現象，因此一種可能是網路中存在中間人攻擊，傳輸的流量可能被截取篡改，而篡改的數據包中就很有可能存在需要的Flag。

圖12數據重傳現象

此時可以將過濾後的數據包使用wireshark導出（s7.pcapng）後用scapy工具進行輔助分析是否存在中間人改包及定位數據包位置。

通過輔助分析後，並沒有在數據包中發現被篡改的數據，因此可以排除中間人改包的這個可能。懷疑造成數據包顯示大量重放的原因可能與埠鏡像配置有關。

接下來就是進一步分析S7comm協議的數據包，但是數據包中沒有S7comm協議相關的數據包，有的是COTP協議相關的數據包，所以接下來就是分析COTP協議，先統計一下cotp協議的PDU類型，編寫腳本如下：

腳本執行後，數據包中所使用的COTP協議的PDU類型有0x0e (CR Connect Request，連接請求)（出現12次）、0x0d (CC Connect Confirm，連接確認)（出現8次）和0x0f (DT Data，數據傳輸)（出現3696次）。從統計的結果來看，一共有12次連接請求，但是只有8次連接確認，所以推測有的連接存在非法信息，這可能就是所需要的Flag。

COTP（ISO 8073/X.224 COTP Connection-Oriented Transport Protocol）是OSI 7層協議定義的位於TCP之上的協議。COTP以「Packet」為基本單位來傳輸數據，這樣接收方會得到與發送方具有相同邊界的數據。

COTP協議分為兩種形態，分別是COTP連接包（COTP Connection Packet）和COTP功能包（COTP Fuction Packet）。

用wireshark過濾後，如圖13所示: