一文讀懂工控安全MMS協(xié)議

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

MMS簡介

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

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

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

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

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

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

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

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

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

MMS協(xié)議

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

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

COTP

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

1. COTP Connection Packet

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

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

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

0×1： ED Expedited Data，加急數(shù)據

0×2： EA Expedited Data Acknowledgement，加急數(shù)據確認

0×4： UD，用戶數(shù)據

0×5： RJ Reject，拒絕

0×6： AK Data Acknowledgement，數(shù)據確認

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，數(shù)據傳輸

2~3 Destination reference:2bytes，目的地參照符，用來標識目標。

4~5 Source reference:2bytes，來源參考，用來標識來源。

6 option:1byte，其中有Extended formats和No explicit flow control，值是布爾型。

7~ parameter ：參數(shù)，一般為11bytes，一般包含Parameter code，Parameter length，Parameter data三部分。

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

2. COTP Fuction Packet

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

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

MMS

我們看一下下面的數(shù)據包，

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

1. initiate-RequestPDU

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

5~7 localDetailingCalling： 本地詳細呼叫，這個字節(jié)數(shù)不固定，取決于后面數(shù)字大小，根據國家規(guī)定通用MMS要求里寫的這個值不應小于64，但推薦至少支持512個8位位組。

10 proposedMaxServOutstandingCalling：提出最大服務端呼叫，這個和下面部分內容都和confirmed-RequestPDU有著聯(lián)系，具體放到下面再講。

13 proposedMaxServOutstandingCalled： 提出最大服務端被呼叫

15 propodedDataStructureNestingLevel：預先編碼的數(shù)據結構嵌套級別，下面簡單提一下這個嵌套級別。

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

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

2. initiate-ResponsePDU

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

negociatedMaxServoutstandingCalling：議最大服務端呼叫

negociatedMaxServoutstandingCalling：議最大服務端被呼叫

negociatedDataStructureNestingLevel：相關的數(shù)據結構嵌套級別

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

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

3. confirmed-RequestPDU

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

invokeID：調用者ID，作為數(shù)據包唯一標識存在

confirmedServiceRequest：確認服務請求，后接服務內容，如本次就是getNameList，像這樣的服務還有諸如read、write、getVariableAccessAttributes、getNamedVariableListAttributes、fileOpen、fileRead、fileClose、fileDirectory接下來就是getNameList內容參數(shù)，如擴展對象類和擴展范圍。

4. confirmed-ResponsePDU

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

2018年工業(yè)信息安全技能大賽（東北賽區(qū)）協(xié)議分析

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

首先嘗試搜索flag關鍵字。

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

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

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

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

總結

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