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

MMS簡介

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

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

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

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

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

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

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

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

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

MMS協(xié)議

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

我們能清楚地看到這個數(shù)據(jù)包的組成,首先是TCP的三次握手，建立連接，這段內容是計算機網(wǎng)絡的核心知識，相信大家都有所了解，這里就不再多說了。接下來是兩個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ù)據(jù)
• 0×2: EA Expedited Data Acknowledgement，加急數(shù)據(jù)確認
• 0×4: UD，用戶數(shù)據(jù)
• 0×5: RJ Reject，拒絕
• 0×6: AK Data Acknowledgement，數(shù)據(jù)確認
• 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ù)據(jù)傳輸
• 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ù)據(jù)包，

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

1. initiate-RequestPDU

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

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

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

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

2. initiate-ResponsePDU

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

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

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

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

3. confirmed-RequestPDU

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

• invokeID:調用者ID，作為數(shù)據(jù)包唯一標識存在
• 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的基礎知識上文已經(jīng)介紹完畢了，下面我們來看一下一個工業(yè)協(xié)議分析題目。題目首先給出了一個智能電廠項目的IEC61850數(shù)據(jù)包，由于題目中已經(jīng)提示MMS了，所以我們直接篩選所有MMS。一共不到兩千個MMS數(shù)據(jù)包

首先嘗試搜索flag關鍵字。

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

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

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

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

總結

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