基于协议状态图遍历的IEC104协议漏洞挖掘方法与流程

文档序号:17481795发布日期:2019-04-20 06:30阅读:686来源:国知局
基于协议状态图遍历的IEC104协议漏洞挖掘方法与流程

本发明属于电力系统安全技术领域,具体涉及一种基于协议状态图遍历的iec104协议漏洞挖掘方法。



背景技术:

电力系统是国家必不可少的基础设施之一,随着通讯、工业控制和服务器的不断融入,电力系统自动化成为主流,电力系统的运行环境更加复杂,对电网的安全稳定运行要求也越来越高,电力系统信息安全成为影响电网稳定运行的一项重要指标,电力系统信息安全受到国家及电力行业极大的重视。建立电力系统安全防护体系,进一步完善安全防范技术措施,从而提高电力系统信息安全整体防护水平成为电力企业面临的首要问题。

国际电工委员会(iec)公布的基于tcp/ip的iec60870-5-104(以下简称iec104)远动规约适用于调度主站与变电站综合自动化系统或调度主站与rtu之间基于以太网传输数据,是iec60870-5系列标准的配套标准。

随着电力系统中综合监控自动化系统的不断发展,iec104协议改变了传统电网通信系统利用串口进行数据传输的现状,其应用能够满足实时电力监控系统通信、可靠等要求。

另一方面,远动系统网络化之后,网络信息安全问题随之而来。当攻击者向这类设备发送畸形的iec104协议数据包之后,很容易对这些设备乃至系统造成破坏性的影响,进而导致无法预计的后果。



技术实现要素:

本发明提供一种基于协议状态图遍历的iec104协议漏洞挖掘方法,以降低远动系统的网络安全风险。

本发明提供了一种基于协议状态图遍历的iec104协议漏洞挖掘方法,包括:

将获取的目标设备的网络数据包处理为去重后的协议基础块;

根据所述去重后的协议基础块构造协议状态图;

对所述协议状态图按照预先设定的规则进行遍历,生成至少一个畸形数据包;

对所述至少一个畸形数据包进行漏洞测试,并确定通过漏洞测试的畸形数据包对应的脚本为所述目标设备的一个漏洞。

具体地,所述的方法,

所述将获取的目标设备的网络数据包处理为去重后的协议基础块,包括:

与目标设备进行交互,抓取目标设备的网络数据包;

从抓取到的网络数据包中过滤出iec104协议的数据包,并对数据包去重,得到iec104协议数据包集合;

利用协议自动化分析方法,对iec104协议数据包集合中的iec104网络数据包进行分块处理,得到去重后的协议基础块。

具体地,所述的方法,

所述根据所述去重后的协议基础块构造协议状态图,包括:

获取各数据包内基础块之间的约束关联关系及数据包间的状态转移关联关系,构造协议状态图;或

获得对iec104协议数据包集合中的数据包内或所述去重后的协议基础块内的节点内的约束关联关系;

获得所述去重后的协议基础块的节点之间的状态转移关联关系。

具体地,所述的方法,

所述对协议状态图按照预先设定的规则进行遍历,生成至少一个畸形数据包,包括:

按照预先设定的最大遍历深度,采用深度优先方式对协议状态图进行遍历,依据节点内的约束关联关系及节点之间的状态转移关联关系生成至少一个畸形数据包。

具体地,所述的方法,

所述针对所述至少一个畸形数据包,进行漏洞测试,包括:

发送所述畸形数据包至所述目标设备,以测定所述畸形数据包是否会触发所述目标设备崩溃;

若所述畸形数据包触发所述目标设备崩溃,则根据所述畸形数据包编写重放脚本,利用所述重放脚本进行漏洞验证;

确定经过漏洞验证后的重放脚本为对应于所述目标设备的漏洞。

具体地,所述的方法,

所述测定所述畸形数据包是否会触发所述目标设备崩溃,包括:

向目标设备发送探测数据包,探测目标设备对应于所述探测数据包是存活还是崩溃;

若目标设备崩溃,则记录上一个发出的测试用例,所述测试用例与所述畸形数据包唯一对应。

具体地,所述的方法,

根据所述畸形数据包编写重放脚本,利用所述重放脚本进行漏洞验证,包括:

根据所述畸形数据包和上一个发出的测试用例,生成重放脚本;

向目标设备发送所述重放脚本;若查看到所述重放脚本引起目标程序异常,则确定所述重放脚本及对应的测试用例为一个与所述目标设备对应的漏洞。

具体地,所述的方法,

在所述与目标设备进行交互,抓取目标设备的网络数据包时,可以使用以下任一种工具:

wireshark、tcpdump、burpsuite、fiddler、scapy、libpcap。

具体地,所述的方法,

所述目标设备包括远动系统中的站端rtu、plc。

具体地,所述的方法,

所述协议基础块包括协议请求头及请求数据、协议关键字、协议分隔符、协议内容。

本发明提供的基于协议状态图遍历的iec104协议漏洞挖掘方法以站端rtu设备为对象进行漏洞挖掘测试,使用基本块去重算法对捕获的样本集去重;基于协议状态图进行fuzz测试,能够有效地发现电力系统及工业控制系统设备中存在的安全漏洞;在生成测试用例时,遍历的路径更有效,生成的有效测试用例占比更高,减少了执行时间,解决了传统的漏洞挖掘方法有效性较差的问题。

附图说明

通过参考下面的附图,可以更为完整地理解本发明的示例性实施方式:

图1为本发明优选实施方式的基于协议状态图遍历的iec104协议漏洞挖掘方法的流程示意图;

图2为本发明优选实施方式的基于协议状态图遍历的iec104协议漏洞挖掘方法另一个流程示意图;

图3为本发明优选实施方式的协议状态图的示意图。

具体实施方式

现在参考附图介绍本发明的示例性实施方式,然而,本发明可以用许多不同的形式来实施,并且不局限于此处描述的实施例,提供这些实施例是为了详尽地且完全地公开本发明,并且向所属技术领域的技术人员充分传达本发明的范围。对于表示在附图中的示例性实施方式中的术语并不是对本发明的限定。在附图中,相同的单元/元件使用相同的附图标记。

除非另有说明,此处使用的术语(包括科技术语)对所属技术领域的技术人员具有通常的理解含义。另外,可以理解的是,以通常使用的词典限定的术语,应当被理解为与其相关领域的语境具有一致的含义,而不应该被理解为理想化的或过于正式的意义。

鉴于iec104协议使用较广的情况,如何检测实现iec104协议的设备的安全性和健壮性具有应用价值,又具有理论意义。

随着电力系统中综合监控自动化系统的不断发展,iec104协议改变了传统电网通信系统利用串口进行数据传输的现状,其应用能够满足实时电力监控系统通信、可靠等要求。

但是,不同厂商对iec104规约实现的不规范以及彼此之间的差异性,导致电力系统设备存在比较多的安全漏洞,如缓冲区溢出、格式化字符串等。为保证调度主站与变电站rtu之间报文的安全传输,挖掘出未被发现的电力系统设备漏洞很有必要。

本发明针对目前电力系统监控设备广泛使用的iec104网络通信协议所存在的安全风险,首先对协议基本块的样本集进行去重;利用协议状态间的约束关系和状态转移的关联关系,构造协议状态图,并基于协议状态图进行深度遍历生成测试用例来挖掘协议模块中的漏洞。

本发明提供的iec104协议漏洞挖掘方法减少了需要生成的测试用例,提高了生成测试用例的有效性。在对iec104协议进行fuzzy测试时,发送tcp探测包并根据探测结果判断测试目标的是否异常;在记录使测试目标异常的测试用例时,去除了冗余的测试用例;有利于在后续重放探测包时,减少消耗的测试时间,进一步提高了漏洞挖掘的效率。

如图1所示,本发明实施例的基于协议状态图遍历的iec104协议漏洞挖掘方法,包括:

s10:将获取的目标设备的网络数据包处理为去重后的协议基础块;

s20:根据所述去重后的协议基础块构造协议状态图;

s30:对所述协议状态图按照预先设定的规则进行遍历,生成至少一个畸形数据包;

s40:对所述至少一个畸形数据包进行漏洞测试,并确定通过漏洞测试的畸形数据包对应的脚本为所述目标设备的一个漏洞。

应该理解为,步骤s30中,遍历能够生成的畸形数据包的个数是不能预先确定的。

具体地,所述的方法,

所述将获取的目标设备的网络数据包处理为去重后的协议基础块,包括:

与目标设备进行交互,抓取目标设备的网络数据包;

从抓取到的网络数据包中过滤出iec104协议的数据包,并对数据包去重,得到iec104协议数据包集合;

利用协议自动化分析方法,对iec104协议数据包集合中的iec104网络数据包进行分块处理,得到去重后的协议基础块。

具体实施时,利用netzob等协议分析软件进行协议自动化分析。

具体地,所述的方法,

所述根据所述去重后的协议基础块构造协议状态图,包括:

获取各数据包内基础块之间的约束关联关系及数据包间的状态转移关联关系,构造协议状态图;或

获得对iec104协议数据包集合中的数据包内或所述去重后的协议基础块内的节点内的约束关联关系;

获得所述去重后的协议基础块的节点之间的状态转移关联关系。

具体地,所述的方法,

所述对协议状态图按照预先设定的规则进行遍历,生成至少一个畸形数据包,包括:

按照预先设定的最大遍历深度,采用深度优先方式对协议状态图进行遍历,依据节点内的约束关联关系及节点之间的状态转移关联关系生成至少一个畸形数据包。

具体地,畸形数据包是正常协议通信不会出现的数据包。这些数据包的编码规则符合协议定义,但有可能会导致目标设备出现安全问题。

具体地,所述的方法,

所述针对所述至少一个畸形数据包,进行漏洞测试,包括:

发送所述畸形数据包至所述目标设备,以测定所述畸形数据包是否会触发所述目标设备崩溃;

若所述畸形数据包触发所述目标设备崩溃,则根据所述畸形数据包编写重放脚本,利用所述重放脚本进行漏洞验证;

确定经过漏洞验证后的重放脚本为对应于所述目标设备的漏洞。

畸形数据包将导致目标设备崩溃。而探测数据包的作用是探测目标设备的崩溃状态。

具体地,漏洞验证通常是脚本自动运行;而测试畸形数据包通常为人工进行。

具体地,所述的方法,

所述测定所述畸形数据包是否会触发所述目标设备崩溃,包括:

向目标设备发送探测数据包,探测目标设备对应于所述探测数据包是存活还是崩溃;

若目标设备崩溃,则记录上一个发出的测试用例,所述测试用例与所述畸形数据包唯一对应。

具体地,一个畸形数据包对应唯一的测试用例;探测数据包则可在多个测试用例中使用。

具体地,所述的方法,

根据所述畸形数据包编写重放脚本,利用所述重放脚本进行漏洞验证,包括:

根据所述畸形数据包和上一个发出的测试用例,生成重放脚本;

向目标设备发送所述重放脚本;若查看到所述重放脚本引起目标程序异常,则确定所述重放脚本及对应的测试用例为一个与所述目标设备对应的漏洞。

具体地,所述的方法,

在所述与目标设备进行交互,抓取目标设备的网络数据包时,可以使用以下任一种工具:

wireshark、tcpdump、burpsuite、fiddler、scapy、libpcap。

具体地,所述的方法,

所述目标设备包括远动系统中的站端rtu、plc。

具体地,所述的方法,

所述协议基础块包括协议请求头及请求数据、协议关键字、协议分隔符、协议内容。

如图2所示,本实施例的基于协议状态图深度遍历的iec104协议漏洞挖掘方法,包括:获取目标设备的iec104网络数据包并进行预处理得到待分析数据包集合,对集合中的数据包进行分块,使用去重算法进行去重。结合自动化分析及人工分析的方式获取数据包内基础块之间的约束关联关系及数据包间的状态转移关联关系,并以此为基础构造协议状态图。按深度优先方式遍历协议图进行fuzz测试,并探测目标是否存活,以达到高效地发现rtu设备中存在的安全缺陷的目的。

如图2所示,本实施例结合了iec104协议的fuzz测试流程,具体包括以下步骤:

步骤1),与目标设备进行交互,利用数据包嗅探器抓取目标设备的网络数据包;

步骤2),对捕获的网络数据包进行预处理,过滤出与iec104协议对应的数据包,并对过滤后的数据包进行去重,得到iec104网络数据包集合;

步骤3),利用协议自动化分析方法,对iec104网络数据包集合中的iec104网络数据包进行分块处理,得到大量的协议基础块;

步骤4),结合自动化分析及人工分析的方式,对iec104网络数据包集合中各数据包内包含的协议基础块进行函数关联,获得协议状态的约束关系;对网络数据包之间的转移关系进行关联,获得状态转移关联关系。至此,确定了该目标设备对应的协议状态图;

步骤5),设置最大遍历深度max_depth,按深度优先方式,对协议状态图进行遍历;依据协议状态图中的节点内的约束关联关系及节点之间的状态转移关联关系生成畸形数据包;

步骤6),向目标系统发送探测数据包,探测目标是否存活;若目标崩溃,将上一个所发的测试用例进行记录,用以区分全部发送的测试用例;

编写重放脚本,进行重放,以确认异常包,也即畸形数据包;

查看目标对重放脚本的响应;如果响应正常,则认为该测试用例不是针对目标系统的一个漏洞。

如果响应异常,则确认该引起目标程序异常的测试用例为针对目标系统的一个漏洞。

应该理解为,这里的“目标系统”即目标设备中与iec104协议有关的网络通信软硬件系统。

步骤7),若某一个遍历分支已经达到最大遍历深度max_depth,则向上回溯,跳转到步骤5,继续从另一个遍历分支对协议状态图进行遍历;直到整个协议状态图遍历完毕,则停止。

具体地,在网络数据包采集与预处理时,可以接入到正常工作的rtu设备连接的路由器上,利用wireshark工具捕获数据包。

应该理解为,数据包嗅探器wireshark工具可以用tcpdump、burpsuite、fiddler、scapy、libpcap等任一种来替代。

对wireshark中捕获的数据包进行预处理操作时,设置过滤条件为“iec104”,从而筛选出iec104协议的数据包,保存过滤后的抓包结果,即得到待测的数据包集合(也即样本集)。

当对大量待测的数据包进行分析时,每个待测数据包可能包含一定数量和种类的基本块;而在不同的待测数据包中,这些基本块可能会出现重叠。因此,可以遍历全部的样本集以确定最大基本块,并记录该最大基本块的地址,以防止重复比较。这时,样本集被分为两部分,一部分是最大基本块,一部分是剩下的基本块。针对剩余的基本块,如果某一个基本块属于最大基本块中已经覆盖的部分,则表示该基本块已存在,可以去除该基本块。在这一步中,去除基本块的目的是防止测试用例生成时重复遍历执行路径。具体实施时,一个可行的算法如下:

具体地,在对网络数据包的预处理时,可以过滤掉无关协议的数据包、筛除对fuzz测试无价值的数据包以及对多次出现的重复网络数据包的去重。

具体地,对iec104网络数据包的分块包括但不限于协议请求头及请求数据、协议关键字、协议分隔符及协议内容等。

具体地,数据包解析与协议状态图构造时,依据iec104协议规约对协议数据包进行深度解析,从数据报文集中分类出应用规约数据单元(applicationprotocoldataunit,简称apdu)、应用规约控制信息(applicationprotocolcontrolinformation,简称apci)、应用服务数据单元(applicationprotocolcontrolunit,简称asdu)的数据报文。其中,报文最大长度255字节;应用规约数据单元的最大长度为253字节,控制域的长度是4字节;应用服务数据单元的最大长度为249字节。

控制域用于定义报文丢失和重复传送的控制信息、报文传输的启动和停止及传输连接的监视。控制域的类型包括完成计数的信息传输的(i格式)、计数的监视功能(s格式)和不计数控制功能(u格式)。

启动链路报文用来建立iec104协议的通信链路;停止链路报文用于在建立网络连接之后停止链路;如果主站超过一定时间没有下发报文或装置也没有上送任何报文,则双方都可以按频率发送u帧测试帧;s帧用于记录接收到的长帧,主站可以按设定的频率发送s帧,比如接收8个i帧后回答一个s帧,也可以要求接收i帧之后就回答1个s帧;i帧用于信息传输,可以存放不同类别标识对应的数据信息,比如总召唤、电度总召唤等。

iec104规约作为网络通信规约,由客户端和服务端组成,服务端口默认为2404,基本流程如下:

1)由客户端向服务器请求建立连接,同时,发送链路启动帧。

2)服务端在收到链路启动帧后,向客户端发送启动确认帧。

3)客户端收到启动确认帧后,发送总召数据请求帧。

4)服务端收到总召数据请求帧后,发送总召数据响应帧,然后继续发送总召数据。总召数据发送完成后,发送总召数据结束帧。

5)客户端在收到总召数据结束帧后,发送对时请求帧。

6)服务器收到对时请求帧后,发送对时响应帧。

7)由服务器主动向客户端发送变化数据帧。同时,收到客户端发送的控制类命令,回复相应的操作结果。

8)客户端等到下一个数据总召周期,重复第4步之后的流程。

iec104协议的不同通信状态下,对应的各种报文类型请求及其字节内容如下:

建立网络连接或启动链路

主站发送→激活传输启动:68(启动符)04(长度)07(控制域)000000

从站发送→确认激活传输启动:68(启动符)04(长度)0b(控制域)000000

停止链路:

主站发送→停止链路:68(启动符)04(长度)13(控制域)000000

从站发送→确认停止链路:68(启动符)04(长度)23(控制域)000000

u帧测试帧:

主站发送→u帧测试帧:68(启动符)04(长度)43(控制域)000000

从站发送→应答u帧测试帧:68(启动符)04(长度)83(控制域)000000

以上展示了iec104协议在通信不同阶段或状态对应的报文类型与字节内容。

以不同数据包之间的约束关联关系及数据包间的状态转移关联关系为基础构造协议状态图,某rtu设备针对iec104协议的协议状态图如图3所示。根据iec104协议关键字,可区分出tcp_connected、startdt、client_tx_apdu_i、client_rx_apdu_i、client_rx_apdu_s、client_tx_apdu_s、tester、stopdt、tcp_disconnected等状态。其中tcp_connected状态表示tcp连接建立;startdt状态表示链路被激活;client_tx_apdu_i状态表示从站发送i帧;client_rx_apdu_i状态表示从站接收i帧;client_rx_apdu_s状态表示从站接收到s帧;client_tx_apdu_s状态表示从站发送s帧;tester状态表示主站使用u帧进行测试;stopdt状态表示停止链路;tcp_disconnected状态表示tcp连接断开。

需要说明的是,以上这些状态的具体含义是本申请基于规约自行定义的。

需要说明的是,图3是该rtu设备的协议状态图。其他的设备,如plc设备具有不同的协议状态图。

具体地,在协议状态图遍历及目标设备存活探测时,(通过分析去重后的协议数据包,对状态之间转移的认证条件、约束等关系进行关联,并构造协议状态图,设置最大遍历深度,防止遍历复杂协议时效率低下。)

以协议状态图为输入进行深度遍历,遍历完一个状态后,执行节点的状态转移函数,进行状态转移,提高了协议覆盖率和生成测试用例的有效性。基于协议状态图深度优先遍历的模糊测试算法的步骤如下:

按深度优先方式遍历协议状态图,并设置最大遍历深度max_depth,依据节点的属性及节点间的关联关系生成并发送相应的畸形数据包。若发送该畸形数据包后未收到来自目标设备的响应包,则发送tcpsyn探测数据包探测目标设备是否存活;若收到来自目标设备的tcpsyn+ack数据包,则说明目标设备没有崩溃;若没有收到来自目标设备的tcpsyn+ack数据包,则说明目标已崩溃。这时,针对畸形数据包形成一条异常记录并保存之前发送的畸形数据包。

进一步地,根据该畸形数据包编写重放脚本;利用该重放脚本验证该畸形数据包是否确实为一个漏洞。若重放脚本后,目标设备存活,则该畸形数据包并不是一个漏洞;若重放脚本后,目标设备崩溃,则该畸形数据包确实为一个漏洞。

针对某一个畸形数据包探测完毕后,若当前的遍历分支已达到最大遍历深度max_depth时,则向上回溯继续遍历协议状态图;若尚未达到最大遍历深度max_depth时,则继续生成新的畸形数据包进行探测;

若整个协议状态图的全部分支已经遍历完毕,则停止探测。

具体地,探测目标系统是否存活的方法还包括发送icmp探测数据包(相应地,目标设备发送icmp+ack数据包)、发送tcpsyn探测数据包(相应地,目标设备发送tcpsyn+ack数据包)、发送tcpfin数据包(相应地,目标设备发送tcpfin+ack数据包)、发送tcp探测数据包(相应地,目标设备发送tcp数据包)、发送udp探测数据包(相应地,目标设备发送udp+ack数据包)等。

以上已经通过参考少量实施方式描述了本发明。然而,本领域技术人员所公知的,正如附带的专利权利要求所限定的,除了本发明以上公开的其他的实施例等同地落在本发明的范围内。

通常地,在权利要求中使用的所有术语都根据他们在技术领域的通常含义被解释,除非在其中被另外明确地定义。所有的参考“一个/所述/该[装置、组件等]”都被开放地解释为所述装置、组件等中的至少一个实例,除非另外明确地说明。这里公开的任何方法的步骤都没必要以公开的准确的顺序运行,除非明确地说明。

当前第1页1 2 
网友询问留言 已有0条留言
  • 还没有人留言评论。精彩留言会获得点赞!
1