最近看了看工控安全相關內容，在此進行簡單分析。

MMS簡介

MMS(Manufacturing Message Specification)中文翻譯為制造報文規范，在介紹MMS之前我們先簡單科普一下IEC61850標準。

IEC61850是電力系統自動化領域唯一的全球通用標準，而本文主要介紹的MMS就是運用在IEC61850標準站控層和間隔層之間，MMS通過對實際設備進行面向對象建模方法，實現了網絡環境下不同制造設備之間的互操作。在2015年前MMS在電力系統遠動通信協議中并未應用，但是IEC61850標準將其引入電力自動化領域，將其核心ACSI服務直接映射到MMS標準

由于MMS是由ISO技術委員會184(TC184)開發和維護的一種涉及用來在設備或程序之間傳送實時數據和監督信息的信息傳遞系統的國際標準，它的定義如下。

每個設備中必須存在一組標準對象(standard objects)，可以執行如，讀寫事件信令(event signaling)等操作。

VMD是主要對象，諸如變量，域，日志，文件等都屬于VMD范圍內。

在客戶端和服務器站之間有一組用來監視或控制上述對象的一組標準信息。

一組用于在傳輸時將信息映射到位和字節的編碼規則。

說完MMS的定義后，我們來看一看MMS的協議棧。其實早在1990年就已經根據ISO / IEC 9506-1和ISO / IEC 9506-2兩個標準進行了標準化，但是由于OSI的實施不是很簡單，所以這個原始版本并沒有流行。現在流行的MMS是于1999年波音公司根據互聯網協議創建的全新版本。以下是新版MMS堆棧。

相比于以前的版本，新版協議的前三層沒有變化，使用了與以前相同的OSI協議，而底層四層則更依賴于TCP ARP等協議而非原本的RFC1006。

MMS協議

介紹完之前的一些基礎，終于要開始分析MMS數據包了，我們先來看下面這個IEC61850的數據包。

我們能清楚地看到這個數據包的組成,首先是TCP的三次握手，建立連接，這段內容是計算機網絡的核心知識，相信大家都有所了解，這里就不再多說了。接下來是兩個COTP包。

COTP

簡單的介紹一下，COTP(ISO 8073/X.224 COTP Connection-Oriented Transport Protocol)，翻譯為面向連接的傳輸協議，這個協議的作用就是進行傳輸連接的建立，我們仔細觀察上圖中的兩個COTP包，分別被標記為CR和CC,是connect request和connet confirm，功能就是COTP的連接包和返回包。一下我們來分別看一下他們的結構組成。

1. COTP Connection Packet

我們從上面的圖可以看出，主要由如下的結構(前方數字代表對應字節)。

0 Length:無符號整型，1byte，用于標記COTP不包括length的后續內容長度，一般為17byte(但我看到的幾個包都是14…)

1 PDU Type:無符號整型，1byte，標記狀態，注意上圖中這行后面的0x0e，代表連接請求，還有其他類型如下所示。

• 0×1: ED Expedited Data，加急數據
• 0×2: EA Expedited Data Acknowledgement，加急數據確認
• 0×4: UD，用戶數據
• 0×5: RJ Reject，拒絕
• 0×6: AK Data Acknowledgement，數據確認
• 0×7: ER TPDU Error，TPDU錯誤
• 0×8: DR Disconnect Request，斷開請求
• 0xC: DC Disconnect Confirm，斷開確認
• 0xD: CC Connect Confirm，連接確認
• 0xE: CR Connect Request，連接請求
• 0xF: DT Data，數據傳輸
• 2~3 Destination reference:2bytes,目的地參照符，用來標識目標。
• 4~5 Source reference:2bytes,來源參考，用來標識來源。
• 6 option:1byte，其中有Extended formats和No explicit flow control,值是布爾型。
• 7~ parameter :參數，一般為11bytes,一般包含Parameter code,Parameter length,Parameter data三部分。

這些就是CR包的組成部分，接下來我們看看CC包。

2. COTP Fuction Packet

其實這兩個包并沒有什么區別，我們對比一下這兩個包，主要就是在PDU Type上由0x0e變成0x0d，標志著由連接包變成返回包。

到這里我們這COTP也基本分析完成了，接下來終于要進入我們正題MMS了。

MMS

我們看一下下面的數據包，

我們能看到其中包括四種MMS包，分別是initiate-RequestPDU(啟動-請求PDU)、confirmed-RequestPDU(確認-請求PDU)、initiate-ResponsePDU(啟動-應答PDU)、confirmed-ResponsePDU(確認-應答PDU)，接下來我們來詳細的看一下這四種。

1. initiate-RequestPDU

首先看一下這個包，我們可以看到它的組成有以下幾個方面

• 5~7 localDetailingCalling: 本地詳細呼叫，這個字節數不固定，取決于后面數字大小，根據國家規定通用MMS要求里寫的這個值不應小于64，但推薦至少支持512個8位位組。
• 10 proposedMaxServOutstandingCalling：提出最大服務端呼叫，這個和下面部分內容都和confirmed-RequestPDU有著聯系，具體放到下面再講。
• 13 proposedMaxServOutstandingCalled: 提出最大服務端被呼叫
• 15 propodedDataStructureNestingLevel:預先編碼的數據結構嵌套級別,下面簡單提一下這個嵌套級別。

對于結構類型數據，如SEQUENCE OF內容Value字段中是一個或多個數據的TLV，形成分層結構，從外層開始層層嵌套最后嵌套成最簡單的數據類型為止。如下圖所示。

最后一部分是MMSInitRequestDetail(MMS初始請求詳細信息)主要由proposedVersionNumber、proposedParameterCBB、services Supported Calling組成，分別標識 相關參數和服務支持的參數，我們著重看一下最后一部分，存在著identify、fileopen等參數，很明顯這部分就是標記著全包內容的管理。

2. initiate-ResponsePDU

我們再來看看initiate-ResponsePDU的內容，總體結構和initiate-RequestPDU相似，重復之處就不再多說了，這里重點看一下這幾個部分。

• negociatedMaxServoutstandingCalling:議最大服務端呼叫
• negociatedMaxServoutstandingCalling：議最大服務端被呼叫
• negociatedDataStructureNestingLevel：相關的數據結構嵌套級別

我們可以發現，initiate-ResponsePDU的這三條和上面initiate-RequestPDU的內容是相對應的，這是因為initiate-ResponsePDU的作用就是對initiate-RequestPDU的內容進行應答，所以要將傳遞內容進行檢測，這也是為什么連這三條后面參數也是一致的。

再看mmsInitResponseDetail的內容，前兩條也是作為對之前內容回答，內容一致就不分析了。直接看最后的serviceSupportedCalled,這一段內容里存在很多參數，主要作用就是對之前包中內容的回應，傳遞一個回復服務端呼叫的內容。

3. confirmed-RequestPDU

相比于之前的兩個包，剩下的就簡單多了，還是先看內容。

• invokeID:調用者ID，作為數據包唯一標識存在
• confirmedServiceRequest：確認服務請求，后接服務內容，如本次就是getNameList,像這樣的服務還有諸如read、write、getVariableAccessAttributes、getNamedVariableListAttributes、fileOpen、fileRead、fileClose、fileDirectory接下來就是getNameList內容參數，如擴展對象類和擴展范圍。

4. confirmed-ResponsePDU

基本內容和confirmed-Request一樣，只是由confirmed-RequestPDU->confirmed-ResponsePDU、confirmedServiceRequest->confirmedServerResponse，具體的內容也由上個包的提出變成回答，這兩個包都是相對應的，一問一答的形式存在。

2018年工業信息安全技能大賽(東北賽區)協議分析

關于MMS的基礎知識上文已經介紹完畢了，下面我們來看一下一個工業協議分析題目。題目首先給出了一個智能電廠項目的IEC61850數據包，由于題目中已經提示MMS了，所以我們直接篩選所有MMS。一共不到兩千個MMS數據包

首先嘗試搜索flag關鍵字。

發現存在flag.txt，接著搜索，在1771包處發現一個confirmed-Request數據包，這個包的作用是fileopen，這只是告訴了我們存在這樣一個有著flag.txt的文件，我們暫時沒法看到，還得找到fileread或者filewrite,根據fileopen后面的72我們可以推測一下fileread和filewrite的位置，應該是在70~75之間，而且要在1764后面那么我們嘗試找一下73。

可以看到invokeID=527,我們之前已經介紹過了invokeID的作用，所以直接根據這個查找對應的confirmed-Resonse包。

可以看到fileData,進行asc解碼即可得到答案。

這題的另一種解法是通過MMS協議的結構編寫腳本得到答案，像S7comm等協議相關題目都可以通過這樣實現。

總結

MMS協議作為一個公有協議，但實施時間還不是很長，還有許多漏洞點可以挖掘，這篇文章只是按照我個人的思路基本的介紹了一下MMS這個協議，有一部分內容是根據相關資料自行總結猜測得出，有不對的地方希望各位可以指出。