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

MMS簡介

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

IEC61850是電力系統(tǒ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)動通信協(xié)議中并未應(yīng)用，但是IEC61850標(biāo)準(zhǔn)將其引入電力自動化領(lǐng)域，將其核心ACSI服務(wù)直接映射到MMS標(biāo)準(zhǔn)

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

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

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

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

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

說完MMS的定義后，我們來看一看MMS的協(xié)議棧。其實(shí)早在1990年就已經(jīng)根據(jù)ISO / IEC 9506-1和ISO / IEC 9506-2兩個標(biāo)準(zhǔn)進(jìn)行了標(biāo)準(zhǔn)化，但是由于OSI的實(shí)施不是很簡單，所以這個原始版本并沒有流行?，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ù)包了，我們先來看下面這個IEC61850的數(shù)據(jù)包。

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

COTP

簡單的介紹一下，COTP(ISO 8073/X.224 COTP Connection-Oriented Transport Protocol)，翻譯為面向連接的傳輸協(xié)議，這個協(xié)議的作用就是進(jìn)行傳輸連接的建立，我們仔細(xì)觀察上圖中的兩個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(但我看到的幾個包都是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錯誤
• 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í)這兩個包并沒有什么區(qū)別，我們對比一下這兩個包，主要就是在PDU Type上由0x0e變成0x0d，標(biāo)志著由連接包變成返回包。

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

MMS

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

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

1. initiate-RequestPDU

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

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

對于結(jié)構(gòu)類型數(shù)據(jù)，如SEQUENCE OF內(nèi)容Value字段中是一個或多個數(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)看一下這幾個部分。

• 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)，傳遞一個回復(fù)服務(wù)端呼叫的內(nèi)容。

3. confirmed-RequestPDU

相比于之前的兩個包，剩下的就簡單多了，還是先看內(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)容也由上個包的提出變成回答，這兩個包都是相對應(yīng)的，一問一答的形式存在。

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

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

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

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

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

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

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

總結(jié)

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