工控安全MMS协议分析

对于结构类型数据，如SEQUENCE OF内容Value字段中是一个或多个数据的TLV，形成分层结构，从外层开始层层嵌套最后嵌套成最简单的数据类型为止。如下图所示。

最后一部分是MMSInitRequestDetail(MMS初始请求详细信息)主要由proposedVersionNumber、proposedParameterCBB、services Supported Calling组成，分别标识 相关参数和服务支持的参数，我们着重看一下最后一部分，存在着identify、fileopen等参数，很明显这部分就是标记着全包内容的管理。

2. initiate-ResponsePDU

我们再来看看initiate-ResponsePDU的内容，总体结构和initiate-RequestPDU相似，重复之处就不再多说了，这里重点看一下这几个部分。

• negociatedMaxServoutstandingCalling:议最大服务端呼叫
• negociatedMaxServoutstandingCalling：议最大服务端被呼叫
• negociatedDataStructureNestingLevel：相关的数据结构嵌套级别

我们可以发现，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数据包，由于题目中已经提示MMS了，所以我们直接筛选所有MMS。一共不到两千个MMS数据包

首先尝试搜索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这个协议，有一部分内容是根据相关资料自行总结猜测得出，有不对的地方希望各位可以指出。

（编辑：衡阳站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!