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 –工控业务流量分析-工匠安全实验室

  • 发表于:
  • 原文链接https://kuaibao.qq.com/s/20180723G1G91W00?refer=cp_1026
  • 腾讯「云+社区」是腾讯内容开放平台帐号(企鹅号)传播渠道之一,根据《腾讯内容开放平台服务协议》转载发布内容。

扫码关注云+社区

领取腾讯云代金券