2018年工业信息安全技能大赛解题报告-工业网络数据分析

当前，随着中国制造2025战略深入推进，工业控制系统从单机走向互联、从封闭走向开放、从自动化走向智能化，安全漏洞和隐患不断涌现、安全事件频繁发生。我国面临的工业信息安全形势日益严峻。

图1 2018年工业信息安全技能大赛（东北赛区）开幕式

2018年工业信息安全技能大赛（东北赛区）分为漏洞挖掘赛和夺旗赛，其夺旗赛大概可分为工业网络数据分析、工控固件逆向、工控安全分析三个部分。

本文将介绍工业控制网络流量部分的解题思路，当然本文的思路不一定是最好的。仅仅作为抛砖，欢迎大家联系网藤科技“藤”安全实验室，索取赛题来玩！

0x01电力工控数据分析1（200分）

1赛题描述

赛题如图2所示，附件：question_1531222544_JYvFGmLP49PFC0R2.pcap。

图2赛题

2解题思路

考虑到题目是了解MMS规约，发现数据中隐藏的Flag，所以可以先排除非MMS协议的数据包。

用wireshark打开数据包并选择MMS协议进行过滤，如图3所示：

图3过滤后MMS协议的数据包

经过MMS协议过滤后，共有1838个MMS协议的数据包，发现共有四个PDU（协议数据单元），分别是：Initiate-RequestPDU (启动-请求PDU)、Initiate-ResponsePDU (启动-应答PDU)、Confirmed-RequestPDU (确认-请求PDU)、Confirmed-ResponsePDU (确认-应答PDU)，所以把分析的重点放在Confirmed-RequestPDU和Confirmed-ResponsePDU中。

通过分析数据包得知MMS协议的规约中Confirmed-RequestPDU和Confirmed-ResponsePDU的结构，如下：

Confirmed-RequestPDU包含invokeID、listOfModifiers、confirmedServiceRequest、Request-detail四个部分组成；

Confirmed-ResponsePDU包含invokeID、confirmedServiceResponse、Response-detail三个部分组成。

接下来，先分析一下数据包中的MMS服务，编写脚本提取出数据包中所用的MMS服务并统计，脚本代码如下：

脚本运行结果如下：

通过运行上面的脚本，发现数据包中使用到了9个服务，分别是

1 (getNameList)、4 (read)、5 (write)、6 (getVariableAccessAttributes)、12 (getNamedVariableListAttributes)、72 (fileOpen)、73 (fileRead)、74 (fileClose)、77 (fileDirectory)。

ConfirmedServiceRequest和ConfirmedServiceResponse的服务类型，

，可以参考GBT16720.2-2005工业自动化系统制造报文规范第2部分协议规范.pdf。

接下来就是对服务一个一个的分析，按照服务的出现次数从小到大来分析，先分析77 (fileDirectory)服务的数据包，惊奇的发现数据包第1764个比数据包第266个多一个flag.txt文件，而且文件最后一次修改时间为2018-06-14 11:19:00(UTC)，如图4所示：

图4获取文件目录的确认应答

可以猜测这个flag.txt文件就是我们所需要的flag信息，接着过滤出与flag.txt文件相关的数据包，如图5所示：

图5过滤后与flag.txt相关的数据包

从图5中发现数据包中存在读取flag.txt的请求，编写脚本找出flag.txt的文件内容，脚本代码如下：

脚本运行结果如下：

61850@102

所以，61850@102就是需要寻找的Flag

0x02工业协议数据分析（300分）

1赛题描述

图6赛题

2解题思路

用wireshark打开下载到的数据包后可以发现数据包中有大量的数据混杂在一起，考虑到题目是工业协议数据分析，因此可以初步排除非工控的协议，留到最后分析。

经过逐步排除后可以发现，数据包中相关的工控流量有Modbus/TCP协议（端口是TCP 502）和西门子S7comm协议（端口是TCP 102），如图7所示：

图7数据包中的工控流量

接下来只需要进一步分析Modbus/TCP协议及西门子S7comm协议的数据包即可。

Ok，先来分析西门子S7comm协议吧，从数据包中可以发现，西门子S7comm协议中的PDU类型有Job和Ack_Data两种，所以分析起来更加简单了，编写脚本解析出数据包中使用到的西门子S7comm协议的功能码，脚本代码如下：

脚本执行后，数据包中所使用的西门子S7comm协议的功能码有0xf0 (Setupcommunication)（出现2次）和0x04 (Read Var)（出现6196次），但是进一步分析后，发现大量的0x04 (Read Var)都是对DB 1.DBX 4.0进行的读取行为，而且数据（数据是00000000020037000000000c000000002c41）没有变化。因此也可以大致排除西门子S7comm协议中存在Flag的可能。

下一步需要分析的就是Modbus/TCP协议了，同样编写脚本解析出数据包中使用到的Modbus/TCP协议的功能码，脚本代码如下：

脚本执行后，数据包中所使用的Modbus/TCP协议的功能码有1 (Read coils)（出现3220次）、2 (Read Discrete Inputs)（出现3220次）、3 (Read HoldingRegisters)（出现3220次）、4 (Read Input Registers)（出现3220次）和16 (Write Multiple Registers)（出现228次）。而功能码中的1 (Read coils)、2 (Read DiscreteInputs)、3 (Read Holding Registers)、4 (Read InputRegisters)的请求都出现过3220次，且请求的各个寄存器数值一直在不停的变化，看起来比较像正常的工业数据。

所以，接下来编写脚本对16 (WriteMultiple Registers)功能码相关的数据包进行分析，脚本代码如下：

脚本执行后，发现第11779个数据包比较异常，先看一下它的TCP Payload是926d6f64627573494353736563757269747957696e?EK（如图8所示）：

图8隐藏Flag的数据包

可以大胆的猜测6d6f64627573494353736563757269747957696e就是我们需要的Flag，将其16进制字符串转成ASCII字符串后得到modbusICSsecurityWin，所以modbusICSsecurityWin就是需要寻找的Flag

0x03 Modbus协议分析1（200分）

1赛题描述

赛题如图9所示，附件：question_1531222756_modbus1.pcap。

图9赛题

2解题思路

考虑到题目是Modbus协议数据分析，因此可以初步排除非Modbus的协议。

先分析一下数据包中所有使用到的Modbus/TCP协议功能码，同样编写脚本对其进行分析，脚本代码如下：

脚本执行后，数据包中所使用的Modbus/TCP协议的功能码有1 (Read coils)（出现702次）、2 (Read Discrete Inputs)（出现702次）、3 (Read HoldingRegisters)（出现702次）、4 (Read Input Registers)（出现702次）和16 (Write Multiple Registers)（出现2次）。而功能码中的1 (Read coils)、2 (Read DiscreteInputs)、3 (Read Holding Registers)、4 (Read InputRegisters)的请求都出现过702次，且请求的各个寄存器数值一直在不停的变化，看起来比较像正常的工业数据。

而16 (WriteMultiple Registers)请求只出现了2次，因此比较可疑。数据包中的16 (WriteMultiple Registers)写入到25个连续的寄存器中（如图10所示），我们所需要的flag信息就可能藏在这里。

图10隐藏Flag的数据包

所以，TheModbusProtocolIsFunny!就是需要寻找的Flag

0x04 S7comm协议分析1（200分）

1赛题描述

图11赛题

2解题思路

考虑到题目是S7comm协议数据分析，因此可以初步排除非S7comm的协议。

如下图12所示，可以看到该流量中存在大量的重传现象，因此一种可能是网络中存在中间人攻击，传输的流量可能被截取篡改，而篡改的数据包中就很有可能存在需要的Flag。

图12数据重传现象

此时可以将过滤后的数据包使用wireshark导出（s7.pcapng）后用scapy工具进行辅助分析是否存在中间人改包及定位数据包位置。

通过辅助分析后，并没有在数据包中发现被篡改的数据，因此可以排除中间人改包的这个可能。怀疑造成数据包显示大量重放的原因可能与端口镜像配置有关。

接下来就是进一步分析S7comm协议的数据包，但是数据包中没有S7comm协议相关的数据包，有的是COTP协议相关的数据包，所以接下来就是分析COTP协议，先统计一下cotp协议的PDU类型，编写脚本如下：

脚本执行后，数据包中所使用的COTP协议的PDU类型有0x0e (CR Connect Request，连接请求)（出现12次）、0x0d (CC Connect Confirm，连接确认)（出现8次）和0x0f (DT Data，数据传输)（出现3696次）。从统计的结果来看，一共有12次连接请求，但是只有8次连接确认，所以推测有的连接存在非法信息，这可能就是所需要的Flag。

COTP（ISO 8073/X.224 COTP Connection-Oriented Transport Protocol）是OSI 7层协议定义的位于TCP之上的协议。COTP以“Packet”为基本单位来传输数据，这样接收方会得到与发送方具有相同边界的数据。

COTP协议分为两种形态，分别是COTP连接包（COTP Connection Packet）和COTP功能包（COTP Fuction Packet）。

用wireshark过滤后，如图13所示:

图13 PDU类型是0x0e和0x0d的相关数据包

发现第19933、19938、19946、41010个数据包只进行了连接请求，没有得到192.168.1.13的连接确认，而且19933、19938、19946的src-ref都是0x0001，先重点分析这3个数据包，果然在第19946个数据包中发现了猫腻，如图14所示：

图14隐藏Flag的数据包

通过对比分析其他16个数据包，可以确定NESSUS就是需要的Flag

0x05参考

GBT16720.2-2005工业自动化系统制造报文规范第2部分协议规范.pdf

CTF WP –工控业务流量分析-工匠安全实验室