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

最近看了看工控安全相關(guān)內(nèi)容，在此進(jìn)行簡單分析。

MMS簡介

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

IEC61850是電力系統(tǒng)自動(dòng)化領(lǐng)域唯一的全球通用標(biāo)準(zhǔn)，而本文主要介紹的MMS就是運(yùn)用在IEC61850標(biāo)準(zhǔn)站控層和間隔層之間，MMS通過對實(shí)際設(shè)備進(jìn)行面向?qū)ο蠼７椒?，?shí)現(xiàn)了網(wǎng)絡(luò)環(huán)境下不同制造設(shè)備之間的互操作。在2015年前MMS在電力系統(tǒng)遠(yuǎn)動(dòng)通信協(xié)議中并未應(yīng)用，但是IEC61850標(biāo)準(zhǔn)將其引入電力自動(dòng)化領(lǐng)域，將其核心ACSI服務(wù)直接映射到MMS標(biāo)準(zhǔn)

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

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

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

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

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

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

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

MMS協(xié)議

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

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

COTP

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

1. COTP Connection Packet

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

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

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

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

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

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

0×5： RJ Reject，拒絕

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

0×7： ER TPDU Error，TPDU錯(cuò)誤

0×8： DR Disconnect Request，斷開請求

0xC： DC Disconnect Confirm，斷開確認(rèn)

0xD： CC Connect Confirm，連接確認(rèn)

0xE： CR Connect Request，連接請求

0xF： DT Data，數(shù)據(jù)傳輸

2~3 Destination reference:2bytes，目的地參照符，用來標(biāo)識目標(biāo)。

4~5 Source reference:2bytes，來源參考，用來標(biāo)識來源。

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

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

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

MMS

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

我們能看到其中包括四種MMS包，分別是initiate-RequestPDU（啟動(dòng)-請求PDU）、confirmed-RequestPDU（確認(rèn)-請求PDU）、initiate-ResponsePDU（啟動(dòng)-應(yīng)答PDU）、confirmed-ResponsePDU（確認(rèn)-應(yīng)答PDU），接下來我們來詳細(xì)的看一下這四種。

1. initiate-RequestPDU

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

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

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

13 proposedMaxServOutstandingCalled： 提出最大服務(wù)端被呼叫

15 propodedDataStructureNestingLevel：預(yù)先編碼的數(shù)據(jù)結(jié)構(gòu)嵌套級別，下面簡單提一下這個(gè)嵌套級別。

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

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

2. initiate-ResponsePDU

我們再來看看initiate-ResponsePDU的內(nèi)容，總體結(jié)構(gòu)和initiate-RequestPDU相似，重復(fù)之處就不再多說了，這里重點(diǎn)看一下這幾個(gè)部分。

negociatedMaxServoutstandingCalling：議最大服務(wù)端呼叫

negociatedMaxServoutstandingCalling：議最大服務(wù)端被呼叫

negociatedDataStructureNestingLevel：相關(guān)的數(shù)據(jù)結(jié)構(gòu)嵌套級別

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

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

3. confirmed-RequestPDU

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

invokeID：調(diào)用者ID，作為數(shù)據(jù)包唯一標(biāo)識存在

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

4. confirmed-ResponsePDU

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

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

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

首先嘗試搜索flag關(guān)鍵字。

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

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

可以看到fileData，進(jìn)行asc解碼即可得到答案。

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

總結(jié)

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