基于主动交互式学习的工控协议逆向分析

付安民,毛 安,黄 涛,胡 超,刘 莹,张晓明,王占丰

(1.南京理工大学 计算机科学与工程学院,江苏 南京 210094;2.中国人民解放军陆军工程大学 指挥控制工程学院,江苏 南京 210007;3.国家计算机网络与信息安全管理中心,北京 100029;4.南京莱克贝尔信息技术有限公司,江苏 南京 210014)

1 引 言

随着工业互联网的发展,越来越多的工业控制(简称工控)系统开始连接到网络,以实现对工控设备的远程操控[1]。然而,基于商业性和安全性的考虑,部分工控设备厂商选择不公开工控协议文档,导致目前网络中存在大量私有、非标准的工控协议,为工控系统的网络安全行为管理、模糊测试、入侵检测等带来了巨大的挑战[2]。未知工控协议逆向分析技术能够对未知工控协议的格式、语义和状态机等进行推断,进而提升工控系统的安全[3-4]。

目前工控协议逆向方法主要包括基于程序执行的工控协议逆向方法[5]和基于流量样本的工控协议逆向方法[6]。前者虽然具有较高的准确性,但是非常依赖系统固件,通常难以实现,尤其针对一些大型的工控系统,几乎无法实现。而后者虽然准确性不及前者,但其仅通过工业协议流量样本就可以挖掘协议语法、语义和状态机等信息,非常易于实现,因而成为目前工业界主流的协议逆向方法。然而,基于流量样本的工控协议逆向方法[4]通常存在该类方法固有的局限性,即严重依赖于协议样本的多样性。特别是针对稳定性和可靠性相对较高的工控系统,捕获的工控协议流量样本往往会缺乏一些关键的字段取值、协议状态和状态变迁等信息,比如异常状态等,进而导致工控协议逆向分析结果与真实协议规范存在较大偏差,甚至只能得到协议规范的子集,无法提取完整的协议格式和状态机等信息。因此,如何针对原始流量样本中存在的信息量不足等问题,对工控协议逆向分析初始结果进行完善与优化,已经成为目前工业界与学术界关注的热点[7]。

为此,笔者提出了一种基于主动交互式学习的未知工控协议逆向分析方法(Reverse Analysis method of unknown Industrial control Protocol based on Active Interactive Learning,RAIPAIL).在流量样本的逆向基础上,依据初始逆向结果构建字段探测和状态机探测数据包,与工控设备进行主动交互式通信,探测未知协议的字段与状态机,进而对工控协议格式、字段属性和状态机等分析结果进行深入挖掘与补充。论文的主要工作如下:

(1) 提出一种基于主动学习的工控协议逆向分析方法,为基于流量逆向方法的字段语义结果验证、字段取值范围进行扩充,并重点解决了传统基于流量的协议逆向方法无法解决的伪静态长字段问题。

(2) 在流量样本字段分析静态分析结果的基础上,遵循协议逆向分析初始结果与工控设备进行主动交互式通信,以验证所推断的工控协议字段语义与取值范围的正确性。

(3) 根据协议逆向提取的状态机信息,组合多种顺序通信序列,通过与工控设备通信,实现对协议状态机的扩展分析,进而对工控协议格式、字段属性和状态机等分析结果进行深入挖掘与补充。

(4) 选取Modbus、IEC 104、MQTT等主流工控协议对RAIPAIL的性能进行测试。实验结果表明,针对基于流量的工控协议逆向分析结果,RAIPAIL不仅可以有效验证字段语义的正确性,还能够进一步准确探测字段的取值范围,并解决Modbus中存在的伪静态长字段问题。特别是,RAIPAIL还可以有效探测协议状态机中未被发现的新状态和状态转化序列等。

2 相关工作

协议逆向分析[8]能够基于捕获的未知协议通信数据包或指令执行轨迹[9],对未知协议的格式、语义和状态机等进行推断。因此,它已经逐渐成为入侵检测、漏洞挖掘等安全分析技术的基础。

协议逆向分析包括输入预处理、协议格式提取和协议状态机推断3个阶段[10],其中,输入预处理分别以会话和报文为粒度对输入样本进行分割,并剔除样本中可能出现的重传、乱序、分片等冗余和干扰信息;协议格式[11]提取主要包括字段识别、结构提取、语义与取值约束判断3个步骤,通过识别每个报文对应的格式,并对报文所有格式进行合并,进而提取协议报文格式、字段属性等信息;基于提取的协议格式,协议状态机[12]推断主要对通信双方的报文交互次序进行分析,以推断通信过程中协议实体的状态以及相应的状态变迁。

根据分析对象的不同,目前工控协议逆向分析技术可以分为两类:基于执行轨迹的协议逆向分析[13]和基于流量样本的协议逆向分析[14]。

基于执行轨迹的协议逆向分析技术[15],通过跟踪并分析目标工控协议程序执行期间函数堆栈、指令序列、数据、寄存器等信息的变化情况[16],完成工控协议的字段划分和语义推断。目前针对工控协议的逆向分析技术主要借助污点分析思想实现[17],分为静态污点分析和动态污点分析,两者的区别为是否需要运行程序,基于静态污点分析的方法需要对程序源代码进行分析,如文献[18]将静态污点分析思想运用于静态二进制分析,提出一种基于静态二进制分析的工控协议分析方法。而基于动态污点分析的技术需要运行程序,通过调试、代码注入等方式对目标程序进行分析,如Polyglot[3]通过监视协议体对消息的处理过程以及各消息片段的使用方法,获得协议结构与字段语义。文献[19]根据“相同协议字段的字节在内存中通常具有相同传播轨迹”的原理,提出一种自动识别工控协议字段边界的方法。然而,由于工控程序源代码通常较难获取,并且具有高稳定性和实时性要求的工控系统不利于反复调试。因此,基于执行轨迹的协议逆向分析技术通常都难以实现。

基于流量样本的协议逆向分析技术[20-21],仅通过分析工控协议的流量数据包,就可以实现消息类型识别、协议格式提取与协议状态机推断等,进而提取工控协议的语法、语义和状态机信息。这类技术最早由Beddoe在PI项目中[22]提出,该项目使用Needleman Wunsch 序列比对算法进行同一簇内的流量数据比对,区分字段中的可变字段和不变字段值,提取公共部分,构建协议结果特征,但该方法只适用于结构简单的未知协议。之后的Discoverer[23]在PI基础上为完整协议格式提取提供算法和工具,主要包含标记和初始化、递归聚类、字段合并的3个模块,进而实现自动挖掘协议格式。文献[14]提出一种基于语义的协议格式推断工具(Netzob)[14],分为会话切分、噪音过滤、消息聚类、格式推断、合并、状态机重构等步骤,在聚类和字段划分阶段增加了语义的信息,使用基于语义的序列比对算法提取未知协议特征,它是目前较为完善的协议逆向工具,然而该方法比较依赖字段语义和聚类的准确度。文献[7]提出的基于概率性的协议逆向方法,将关键字识别问题表述为一个概率推理问题,深度挖掘关键字背后的各种约束关系,以概率量化约束关系的强弱,进而判断该字段是否为关键字字段。然而该方法非常依赖真实的标记数据。在协议状态机推断阶段,文献[24]提出一种基于报文聚类的协议状态机推断工具,以报文格式相似性作为相似性度量标准,将会话序列进行聚类并标识结果,以获得数据流新的表示,最终实现协议状态机重构。然而该工具忽略部分场景存在协议格式相似但状态类型不同等情况。ReverX[25]和 AutoReEngine[26]都是基于协议关键字分析以重构有限状态机。ReverX通过泛化启发式构造图,通过传统的有限状态机(Finite State Machine, FSM) 最小化对其进行缩减; AutoReEngine利用Apriori算法提取最频繁的字节串作为关键字段,并进一步构造FSM。但是AutoReEngine模型通常包含大量状态,往往需要进一步化简。

总之,当前基于流量的工控协议逆向技术主要集中于流量样本本身的特征分析和挖掘,但这类方法通常非常依赖协议样本的多样性。因此,如何在样本多样性不足的情况下,进一步完善协议逆向分析结果是未知工控协议逆向分析研究的难点。

3 RAIPAIL概述

RAIPAIL能够在流量样本静态分析结果的基础上,按照协议逆向分析初始结果与工控设备进行主动交互式通信,以验证所推断的工控协议字段语义与取值范围的正确性,并根据协议逆向提取的状态机信息,组合多种顺序通信序列,通过与工控设备通信,实现对协议状态机的扩展分析,进而对工控协议格式、字段属性和状态机等分析结果进行深入挖掘与补充。RAIPAIL的总体框架如图1所示,该框架主要包括预处理、交互和验证3个模块。

图1 面向未知工控协议逆向分析的新型探测框架图

3.1 预处理模块

针对初始协议逆向结果,提取工控协议的字段语义、字段取值和状态机序列等信息,这些信息将既作为交互模块中字段探测和状态机探测的输入数据,又作为验证模块的验证参照数据。

3.2 交互模块

交互模块作为RAIPAIL方法的核心模块,包括字段探测和状态机探测两个功能。字段探测主要包括字段语义验证、字段取值范围探测和伪静态长字段划分。

(1) 字段语义验证。针对前期工控协议逆向分析结果中的字段语义,设计相应字段变异器,重组原有流量并发送给目标系统,结合相应反馈信息,对字段语义的正确性进行验证。

(2) 字段取值范围探测。针对前期工控协议逆向分析结果中的字段取值集合,通过对字段赋予不同取值,重组原有流量并与目标系统主动交互,以验证字段取值范围的正确性。

(3) 伪静态长字段划分。针对前期工控协议逆向分析结果中字段长度大于一定阈值的静态字段进行探测,通过伪静态长字段变异器,重组原有流量并与目标系统主动交互,探测该字段是否可划分。

状态机探测主要包含新状态与状态转化探测和状态依赖挖掘。

(1) 新状态与状态转化探测。针对前期工控协议逆向分析结果,获得报文格式集合,提取对应的流量样本,使用全排列算法构建交互流量序列集合,并与目标系统主动交互,获得交互流量集。

(2) 新状态依赖挖掘。 针对包含不同状态功能码的报文流量进行组合排列,形成基于状态码的状态机探测序列,并与目标系统主动交互,获得通信合集。

总之,该模块主要根据工控协议字段和状态机的探测结果,生成变异样本,与工控设备或工控模拟工具进行主动式交互,并收集交互报文集,该报文集也将作为验证模块的验证参照数据。需要提及的是,大部分的工控协议针对错误的验证报文都会有其对应的反馈信息,少数健壮性不强的协议只对正确的报文才应答。针对少数只对正确报文才反馈的协议,需要对变异样本进行人工修正后,再进行探测。

3.3 验证模块

对比初始逆向分析结果和交互报文集,对字段探测和状态机探测结果进行验证。需要说明的是,这些验证操作目前大都需要依赖人工分析完成。

(1) 字段验证。通过对比字段语义验证、字段取值范围探测、伪长静态长字段划分的交互流量集与初始流量样本的区别,获取字段语义验证、取值范围探测和伪静态长字段的分析结果。

(2) 状态机验证。通过分析与目标系统交互的流量集合与初始逆向分析的状态机,进行状态机补充和状态依赖判断,从而进一步实现对协议状态机的扩展分析。

总之,该模块根据初始流量集的会话信息,对比字段探测、状态机探测结果与初始报文结果,验证是否有新报文格式或状态转化结果,完成字段验证和状态机验证。

4 主动交互式学习的协议逆向过程

这里重点针对RAIPAIL的交互模块所涉及的关键技术和算法进行详细介绍,主要包括字段探测和状态机探测。

4.1 字段探测

字段探测主要包括字段语义验证、字段取值范围探测和伪静态长字段划分。

(1) 字段语义验证。RAIPAIL依次针对每个协议字段进行变异和验证,主要根据所推断的各字段语义信息,设计相应的字段变异器,如数据字段变异器(TextMutator)、长度字段变异器(LenMutator)、序列号字段变异器(SeqMutator)等,基于这些字段变异器能够生成各种类型的测试样本,通过与目标工控设备或系统进行主动式交互,以验证相应字段语义信息的正确性。若字段语义信息正确,则保持原有分析结果;反之,则判定该字段语义分析错误,并修正初始逆向中该字段的分析结果。其中,以TextMutator为例,RAIPAIL采取字段内容填充等变异方法,如重复字段插入、特殊符号插入、随机删除部分数据、文本内容打乱重组等,并且考虑到文本字段的内容长度通常与长度字段相关,RAIPAIL将同步更新长度字段数值,使两者达到一致,以验证当前字段是否为文本字段。详细的协议字段语义验证过程如算法1所示。

算法1字段语义验证与扩展算法。

输入:逆向分析的样本结果M={m1,m2,…,mn}(初始逆向过的流量样本)。

输出:与真实设备交互的数据流量集合R。

① 对于每一个样本结果mi,按顺序遍历所有字段mi·field和其对应的变异器mi·mutator。

② 根据mi·mutator生成种子序列集合smi·field,若没有标注的mutator,则不生成。

③ 加入到交互流量集合S里面。

④ 重复上述②～③步,直到遍历完M。

⑤ 使用目标系统采取的通信方式c,进行数据交互。

⑥ 每个种子序列smi·field会话流量 ->R。

⑦ ReturnR。

(2) 字段取值范围探测。字段取值范围探测主要对长度固定且取值变化的字段的取值范围进行探测,如功能码等。以功能码字段变异器(FuncMutator)为例,由于捕获到的流量通常无法包含所有的功能报文,通常只能提取出对应协议功能码的子集。然而,针对各类协议功能码字段的深入分析,发现功能码的有效取值范围通常都比较接近,特别是工控协议,如MODBUS等。因此,RAIPAIL针对目标协议的功能码数值进行递增或递减,并向目标工控设备或系统发送重新组合后的测试报文,最终根据目标设备或系统的反馈报文,实现对功能码取值范围的探测。

(3) 伪静态长字段变异。伪静态字段是目前大多数协议逆向分析方法难以解决的问题。由于收集的部分字段样本存在多样性不足等问题,导致多序列比对算法提取的部分相邻字段同时出现固定值的现象,进而导致这两个不相关的相邻字段被错误地识别为一个伪静态长字段。因此,针对这一现象,RAIPAIL采取对于伪静态长字段按单字节进行变异,通过对每个单字节取值进行递增或递减,以生成新样例与目标系统进行主动式交互,最终实现对当前字段是否为静态字段的验证。

而针对字段长度超过三字节的长字段验证划分,RAIPAIL采取逐字节变异策略:通过计算当前字节与0xff之间的差值,填充当前字节取值,并发送给目标工控设备或系统,对比不同变异字节的反馈信息,以判断当前长字段是否包含多个短字段。

4.2 状态机探测

协议状态机是对协议实体间信息交互过程的描述,定义了不同格式类型报文的传送顺序。通常使用FSM模型描述协议状态机,以体现通信过程中协议实体所处的状态以及状态之间的转换关系,一个 FSM 可以用五元组M=(Q,ΣI,ΣO,δ,λ)表示,其中,Q表示有限状态集合,ΣI表示有限输入符号集合,ΣO表示有限输出符号集合,δ：Q×ΣI→Q表示状态转换函数,λ:Q×ΣI→ΣO表示输出函数。

针对捕获的协议流量集进行逆向分析,并结合状态字段和会话顺序构建和化简协议状态机。然而,由于流量样本多样性不足,导致推测的协议状态机通常不完整,比如缺少部分协议状态和状态转化关系等。因此,针对这一不足,RAIPAIL分别从以下两个角度进行扩充。详细的协议状态机探测过程如算法2所示。

(1) 新状态与状态转化探测。先根据协议逆向初始结果,对每种报文流量进行全排列组合,以获得新报文序列集合,再根据集合中每条流量序列与目标工控设备进行主动式交互,分析报文反馈信息,填充新状态与转化序列。

(2) 新状态依赖探测。针对包含不同状态功能码的报文类型进行全排列组合,形成基于状态码的状态机探测序列,依次发送给目标工控设备,分析报文反馈信息,探测是否存在新状态依赖。

算法2状态机探测算法。

输入:逆向分析的样本结果M={m1,m2,…,mn}(初始逆向过的流量样本),具有类似功能码能决定消息格式的样本结果S={s1,s2,…,sn}。

输出:与真实设备交互的数据流量集合R。

① 对于M,状态转化变异器stateMutator->新状态序列集合SMi。

② 使用通信方式c,进行序列交互。

③ 新会话ti加入R。

④ 对于S,功能码依赖变异器FuncMachineMutator->新状态依赖序列集合FSi。

⑤ 使用通信方式c,进行序列交互。

⑥ 新会话ti加入R。

⑦ ReturnR。

5 实验分析

为了验证RAIPAIL的性能,选取了目前最常用的Modbus、IEC-104和MQTT这3种工控协议进行测试。由于Modbus是无状态的协议,因此协议状态机实验只针对IEC-104和MQTT两种工控协议。

5.1 系统测试环境

系统运行的硬件环境为两台运行Windows操作系统的64bit PC,一台作为构建包和传输包的机器,另一台用于搭建协议模拟器以模拟真实工控设备。测试的协议模拟器在字段验证推测采用Modbus、IEC104的协议模拟器和MQTT服务器,状态机推测采用IEC104协议模拟器和MQTT服务器,具体配置如表1所示。

表1 系统测试环境

5.2 协议字段验证与扩充分析

5.2.1 Modbus协议字段验证

针对Modbus协议逆向分析结果,RAIPAIL进行多次主动式交互测试。实验结果如表2所示。

表2 Modbus字段实验结果

结合表2中的实验结果,分别从功能码取值范围探测、请求数目字段语义验证、请求地址字段语义验证和长静态字段划分等4个角度进行分析:

(1) 功能码取值范围探测。根据初始协议逆向分析结果,收集的Modbus样本只有01、02、03协议功能码,而RAIPAIL通过对功能码字段进行变异,并与服务器主动交互,验证返回的报文信息来探测有效功能码。验证表明有效功能码区间为1～24,而超过24以后则返回未知功能码错误。RAIPAIL探测出的功能码区间为1～24,明显超出初始协议逆向分析结果中的功能码取值范围,并且获得两种非法数据地址和非法功能流量样本种类。

(2) 请求数目字段语义验证。针对初始协议逆向分析结果中的请求线圈数目字段语义进行验证,交互反馈报文中寄存器状态数完全符合请求线圈的寄存器数目总和,表明该字段语义分析正确。

(3) 请求地址字段语义验证。针对初始协议逆向分析结果中的原有地址和变异地址进行验证,交互反馈报文中数据值变化均能够对应地址变化情况,表明该字段是请求地址字段。

(4) 长静态字段划分。对比Modbus协议规范和初始协议逆向分析结果,可发现Modbus协议经逆向分析后,协议标识符、长度和设备地址等字段被划分为一个长静态字段。因此,RAIPAIL分别对“协议标识符”、“长度”和“设备地址”等字段采用“单字节变异”。验证结果:针对“协议标识符”字段变异,模拟器都未响应,进而确定该字段不可修改,属于静态固定值字段;针对“长度”字段变异,模拟器反馈“畸形数据包错误”,进而确定该字段可修改,属于动态字段;针对“设备地址”字段变异,模拟器反馈“非法数据地址异常”,进而确定该字段可修改,属于动态字段。最终,确定该伪静态长字段可以进一步被细划分为“静态字段+动态字段+动态字段”。

5.2.2 IEC-104协议字段验证

针对IEC-104协议逆向分析结果,RAIPAIL进行多次主动式交互测试,实验结果如表3所示。

表3 IEC104字段实验结果

结合表3中的实验结果,可分别从控制字段取值范围探测、数据长度字段语义验证、传送原因字段取值探测和请求地址字段验证等4个角度进行分析:

(1) 控制字段取值范围探测。根据初始协议逆向分析结果,收集的IEC-104样本中的控制字段主要包括启动命令、启动命令确认、测试命令、测试命令确认等功能,而RAIPAIL可以额外探测到停止命令和停止命令确认等新控制功能。

(2) 数据长度字段语义验证。针对初始协议逆向分析结果中的数据长度字段进行验证,RAIPAIL通过修改字段值并进行主动交互,仅当修改值与数据长度完全一致时,才能收到目标设备的正确报文;否则,IEC服务器将不返回错误报文信息,进而表明该字段确为数据长度字段。

(3) 传送原因字段取值探测。根据初始协议逆向分析结果,收集的IEC-104样本中的传送原因字段取值为64和67,而RAIPAIL可以额外探测出新取值01。然而,因传输多数为命令,且IEC104模拟器对错误报文不返回状态,因此,推测传输原因字段取值范围暂定为01～67。

(4) 请求地址字段验证。针对初始协议逆向分析结果中的原有地址和变异地址进行验证,交互反馈报文中数据值变化均能够对应地址变化情况,表明该字段是请求地址字段。

5.2.3 MQTT协议字段验证

针对MQTT协议逆向分析结果,RAIPAIL进行多次主动式交互测试。实验结果如表4所示。

表4 MQTT字段实验结果

结合表4中的实验结果,分别从控制字段取值范围探测、数据长度字段语义验证、未知字段语义探测和长度字段语义验证等4个角度进行分析:

(1) 控制字段取值范围探测。根据初始协议逆向分析结果,收集的MQTT样本中的控制字段仅有01、02、03、04、09等5种取值,而RAIPAIL通过对控制字段进行变异,并与服务器主动交互,观察订阅者,服务器对错误报文均无响应结果,因此保持原有结果集。

(2) 数据长度字段语义验证。针对初始协议逆向分析结果中的数据长度字段进行验证,RAIPAIL通过修改字段值并进行主动交互,经转义和对比订阅者的数据流量中的数据长度字段相同,验证该字段确为数据长度字段。

(3) 未知字段语义探测。根据初始协议逆向分析结果,RAIPAIL对初始字段转义获得mqtt/test,并生成大量测试用例,通过与工控设备进行主动交互以获得反馈结果,对应字段转义为mqtt/work,进而探测该未知字段是主题名字段。

(4) 长度字段语义验证。针对初始协议逆向分析结果中的数据长度字段进行验证,RAIPAIL通过修改字段值并进行主动交互,仅当修改值与数据长度完全一致时,才能收到目标设备的正确报文;否则,MQTT服务器将不返回错误报文信息,进而表明该字段确为数据长度字段。

5.2.4 小 结

通过对Modbus、IEC104和MQTT 3种主流工控协议的报文字段进行分析,可发现工控协议通常采用小包传输,使用一个或者几个字节来标示相应的功能,并且数据包具有相对一致的结构和字段内容结构,具有相对固定的周期,以确定设备处于连接状态的时间和行为。基于工控协议这些特征,RAIPAIL不仅可以有效验证初始逆向分析结果中字段语义的正确性,还能够准确探测MQTT协议中初始协议逆向无法提取的未知字段语义。此外,RAIPAIL还进一步对字段取值范围进行探测与扩充,并彻底解决伪静态长字段问题。

5.3 协议状态机分析

由于Modbus协议没有状态,RAIPAIL仅针对IEC104和MQTT协议状态机进行分析,分别从新状态探测、新状态转化序列和新状态依赖等3个角度进行验证与探测。

5.3.1 IEC104协议状态机探测

针对IEC104协议,通过分析初始协议逆向分析结果,IEC104协议状态机主要包括4种协议状态,如表5所示。

表5 IEC104初始逆向结果状态定义

基于分析初始协议逆向推断的IEC104协议状态机,RAIPAIL对各个协议状态的转化序列进行验证与测试,并构建协议状态转化图,如图2所示。

图2 IEC 104协议状态机分析结果图

结合图2可以明显看出,RAIPAIL能够准确验证IEC104协议状态机中各种协议状态和状态转换序列,同时,还能够进一步探测出IEC104协议中的新协议状态和新状态转换序列。具体结果如表6所示。

表6 IEC104协议新状态和状态转化序列

5.3.2 MQTT协议状态机探测

针对MQTT协议,通过分析初始协议逆向分析结果,MQTT协议状态机主要包括3种协议状态,如表7所示。

表7 MQTT初始逆向结果状态定义

基于分析初始协议逆向推断的MQTT协议状态机,RAIPAIL对各个协议状态的转化序列进行验证与测试,并构建协议状态转化图,如图3所示。

图3 MQTT协议状态机分析结果图

结合图3可以明显看出,RAIPAIL能够准确验证MQTT协议状态机中各种协议状态和状态转换序列,同时,还能够进一步探测出MQTT协议中的新协议状态和新状态转换序列。具体结果如表8所示。

表8 MQTT协议状态机实验详解

5.3.3 小 结

通过对IEC104和MQTT的协议状态机进行分析,可发现工控协议状态机通常较为简单,甚至没有状态信息,但是由于工控系统的稳定性和可靠性要求,工控协议的报文覆盖率相对较低,特别是一些异常状态,导致根据流量样本逆向的状态机的构建往往只是完整状态机的子集。针对这些问题,RAIPAIL不仅可以有效地验证原有状态机的正确性,还能够基于初始逆向结果探测出新协议状态和状态转化序列。此外,RAIPAIL还实现对工控协议的控制字段依赖的主动挖掘,增强工控协议状态机的完备性。

6 结束语

笔者提出了一种基于主动交互式学习的未知工控协议逆向分析方法(RAIPAIL)。该方法根据不同协议字段,设计相应变异器以验证字段语义、扩充字段取值和异常样本类型,不仅能够有效验证未知工控协议逆向分析结果的准确性,还能够有效解决因样本多样性不足而导致的伪静态长字段问题;同时,根据初始逆向提取的协议状态机,组合多种顺序通信序列,与工控设备进行主动式交互通信,以探测新协议状态、状态转化序列、状态依赖的关系,能够进一步提高逆向分析结果的完整性。因此,RAIPAIL对需要依赖协议逆向分析的入侵检测、漏洞挖掘等网络安全技术具有极高的应用价值。然而,RAIPAIL目前仅适用于能够为第三方工具提供交互功能或模拟器的工控系统,并且RAIPAIL的验证环节目前仍需人工操作。未来将针对无法为第三方工具提供交互功能或者模拟器的工控系统的协议逆向方法进行研究,并重点针对方法的验证模块进行改进,以减少对人工专家经验的依赖。比如将探测响应报文与前期逆向结果自动化地进行比对,采用自动化显示返回报文对应的样本类型,以提高RAIPAIL的自动化程度,进而降低人工分析的难度。