最近在看工控安全相关的内容，这里简单分析一下。MMS简介MMS（ManufacturingMessageSpecification）中文翻译为制造消息规范。在介绍彩信之前，先简单科普一下IEC61850标准。IEC61850是电力系统自动化领域唯一的全球通用标准，本文主要介绍的MMS应用在IEC61850标准的站控层和间隔层之间。制造设备之间的互操作性。2015年之前，电力系统远动通信协议中并未使用MMS，但IEC61850标准将其引入电力自动化领域，并将其核心ACSI服务直接映射到MMS标准，因为MMS是由ISO技术委员会184（TC184）制定的)和维护的国际标准处理用于在设备或程序之间传递实时数据和监控信息的消息传递系统，定义如下。每个设备中必须存在一组标准对象，这些对象可以执行读取和写入事件信号等操作。VMD是主要对象，变量、域、日志、文件等都属于VMD的范围。在客户站和服务器站之间有一套标准的信息用于监视或控制上述对象。一组编码规则，用于在传输时将信息映射为比特和字节。说完MMS的定义，我们再来看看MMS的协议栈。其实早在1990年就按照ISO/IEC9506-1和ISO/IEC9506-2这两个标准进行了标准化，但是由于OSI的实现不是很简单，这个原始版本并没有流行起来。现在流行的彩信是波音公司在1999年基于互联网协议开发的全新版本。以下是MMS堆栈的新版本。与之前的版本相比，新版协议的前三层没有变化，与之前一样使用OSI协议，而后四层更多地依赖于TCPARP等协议，而不是原来的RFC1006。在介绍了MMS协议的一些基础知识之后，我们终于要开始分析MMS数据包了。我们先来看下面的IEC61850数据包。我们可以清楚的看到这个数据包的组成。首先，有TCP的三次握手来建立连接。该内容是计算机网络的核心知识。相信大家都明白，这里就不多说了。接下来是两个COTP数据包。COTP简介，COTP（ISO8073/X.224COTPConnection-OrientedTransportProtocol），翻译为面向连接的传输协议，这个协议的作用是建立传输连接，我们仔细观察两个COTP包，分别标记为CR和CC，分别是connectrequest和connetconfirm，作用是COTP连接包和返回包。下面分别来看一下它们的结构组成。1.COTPConnectionPacket从上图我们可以看出，它主要由以下结构组成（前面的数字代表对应的字节）。0Length:unsignedinteger,1byte,用来标记COTP不包括length的后续内容长度，一般为17bytes（不过我看到的几个包都是14个。。。）1PDUType:unsignedinteger,1byte,标记status，注意上图中一行后面的0x0e，代表连接请求，其他类型如下。0×1：EDExpeditedData，加急数据0×2：EAExpeditedDataAcknowledgment，加急数据确认0×4：UD，用户数据0×5：RJReject，拒绝0×6：AKDataAcknowledgment，数据确认0×7：ERTPDUError，TPDU错误0×8：DRDisconnectRequest，断开请求0xC：DCDisconnectConfirm，断开确认0xD：CCConnectConfirm，连接确认0xE：CRConnectRequest，连接请求0xF：DTData，数据传输2~3Destinationreference：2bytes，目标引用字符，用于标识目标。4~5Sourcereference：2bytes，sourcereference，用于标识来源。6option：1byte，包括Extendedformats和Noexplicitflowcontrol，值为Boolean。7~parameter：参数，一般为11bytes，一般包括参数代码、参数长度、参数数据三部分。这些是CR包的组件。接下来我们看一下CC包。2.COTPFuctionPacket其实这两个包没有区别。让我们比较一下这两个数据包。主要是PDUType从0x0e变成了0x0d，这标志着从一个连接包变成了一个返回包。至此，我们已经完成了我们COTP的基本分析，终于要进入我们的正题MMS了。MMS我们来看下面的数据包，我们可以看到MMS包有四种类型，分别是initiate-RequestPDU（开始-请求PDU）、confirmed-RequestPDU（确认-请求PDU）、initiate-ResponsePDU（开始-responsePDU),confirmed-ResponsePDU（确认-响应PDU），我们来详细看看这四种。1.Initiate-RequestPDU首先看这个包，我们可以看到它的组成有以下几个方面5~7localDetailingCalling：本地详细调用，字节数不固定，取决于后面数的大小，根据国家规定，一般彩信要求写的值不能小于64，但建议至少支持512个八位字节。10proposedMaxServOutstandingCalling：建议最大服务器调用，这部分和后面的部分与confirmed-RequestPDU有关，下面会详细讨论。13proposedMaxServOutstandingCalled：建议的最大服务器被调用15proposedDataStructureNestingLevel：预编码数据结构的嵌套层级，嵌套层级下面简单说一下。对于结构型数据，如SEQUENCEOFcontentValue字段中一个或多个数据的TLV，形成层次结构，从外层开始逐层嵌套，最后嵌套成最简单的数据类型。如下所示。最后一部分是MMSInitRequestDetail（MMS初始请求详情），主要由proposedVersionNumber、proposedParameterCBB、servicesSupportedCalling组成，分别标识相关参数和服务支持的参数。让我们关注最后一部分。有identify和fileopen等参数。显然，这个部分被标记为AllInclusiveManagement。2.Initiate-ResponsePDU我们再来看看initiate-ResponsePDU的内容。整体结构与initiate-RequestPDU类似。我不会再重复了。让我们在这里关注这些部分。negotiatedMaxServoutstandingCalling:negotiatedMaxServoutstandingCalling:negotiatedMaxServoutstandingCalling:negotiatedMaxServoutstandingCalling:negotiatedMaxServoutstandingCalling:negotiatedDataStructureNestingLevel:相关数据结构嵌套层级我们可以发现，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数据包。由于题目中已经提示彩信，我们直接屏蔽所有彩信。一共不到两千个彩信包先尝试搜索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协议做一个基本的介绍，部分内容参考了相关资料。总结猜测，如有不妥之处，还望大家指出。
