abstract+introduction
背景
工控网打破了工业物联网中假定的每个系统相互分离的限制,引入的威胁。工控网中的目标主要分为两类:一类是控制控制生产过程的设备,另一类是控制这些设备的监控软件supervisory software。
问题
专注于分析针对PLC设备的supervisory software,特别是寻找其中有关协议实现的漏洞。(攻击面)
目前工作及其缺点
目前针对ICS内部的supervisory software的fuzzing工作较少,并且受限,主要是三个方面:通常是运行在windows上的闭源程序,并且体量较大,严重依赖GUI;通常作为客户端,这对于fuzzer来说不易测试;通常使用专有协议进行通信,并且协议状态是和GUI紧耦合的。
现有fuzzing工作与ICS3fuzzer特性对比图
挑战
- 闭源、体量大
- 与GUI操作紧耦合
- 私有协议
论文工作
提出了ICS3Fuzzer,ICS Supervisory Software Fuzzer,一个可移植的、模块化的,能够自动化测试supervisory software的fuzzing框架。
没有直接分析提取协议实现(因为十分困难),而是直接在同步控制GUI操作以及网络通信的情况下,直接运行和fuzz对应的supervisory software。
ICS3Fuzzer是黑盒的,通过自动化地输入专门生成地有效地输入并到达不同的协议状态,来持续地驱动整个过程。并且提出了新的fuzzy策略,倾向于更有可能发生漏洞的状态。测试目标时是结合模拟测试与实际测试的优缺点。
贡献:
- 设计实现了ICS3Fuzzer
- 提出了新的fuzzing策略
- 结果好,并开源
BACKGROUND AND MOTIVATION
ICS Architecture
典型的ICS系统由三层,分别是(1)Field Instrument Control Layer,由传感器(senior)和执行器(actuator)构成,用来进行系统的输入和输出(2)Process Control Layer,由专用嵌入式设备组成,比如PLC/RTU,用来控制实时进程(3)Supervisory Control Layer,由几个工作站组成,用来提供实时监控以及控制系统的设备。
ICS系统的几个显著的特点:
- ICS直接与物理世界进行交互,因此其中的安全问题往往会造成更大的危害。
- ICS必须可靠并且满足实时约束,必须使用实时操作系统,并且特定领域协议(domain-specific protocols)被用来在上述三层之间进行通信,并且协议往往未被加密。
- ICS的网络是air-gaped,即与外部网络隔离,因此其中往往缺少很多安全性措施。但是随着IIOT的发展,这种隔离逐渐被削弱,因此会带来很多问题。
ICS系统中supervisory software的共同特点为,都提供了用于读可操作变量、开启/停止PLC、下载固件等接口,这些功能在一个指定的信道进行通信,通信数据包含如下内容:
- 实时设备状态:sensor reading、feedback of control command exectuion、heartbeat messages
- 设备信息:device name、version、model、manufacturer
- structured data block: program blocks、memory blocks、 diagnostic files
Security Risks Exposed by Supervisory Software
生产系统种涉及OT和IT网络,supervisory software运行在OT网络种,并且OT网络与IT网络之间存在强大的隔离,但是APT攻击往往能够穿透这层隔离。
Assumption
假设攻击者已经控制了ICS北部一台主机,并且能够监控、拦截、修改ICS内部主机之间的通信,即MITM attack。
Attack Approaches and Consequences
主要通过两种方式,一种是修改报文,使得Supervisory software 崩溃,另一种是利用Supervisory software已有逻辑执行恶意命令。
DESIGN OVERVIEW
Movitating Example
下图表示的是supervisory software GX Words2和PLC之间的TCP session,在这个过程中,为了获取网络数据公开了许多input states,并且在每一个特殊的input state下,supervisory software都在等待一种特定的来自PLC 设备的报文。
我们定义一种session type作为一种functionality,双向交换报文。functionality是一种supervisory semantic,例如向PLC中下载程序、开启PLC等等。
Key observartion
- TCP session的开始往往是一种按钮操作(可理解为人工操作),有人类通过GUI界面完成。
- 在session期间,在许多情况还需要额外的按钮操作来完成交互。
- session通过周期性的交换heartbeat报文或者停止报文交换来结束此session。
New Insight
Supervisory software在不同的interaction states时往往有着不同的行为(code execution),Supervisory software的交互状态本质上是与PLC设备进行交互的特定的程序上下文;交互状态取决于几个因素,包括之前的按钮操作、之前的input states等。Supervisory software的实现与GUI接口是高度耦合的。
Challenges
- C1:Guiding the supervisory software to enter a specific input state.
每个session都涉及了许多input states,为了能够达到针对input states较好的覆盖需要克服三个困难:
首先TCP session初始化是由作为client的supervisory software发起的,因此fuzzing tool需要等待接收supervisory software发起的请求;其次为了fuzz一个特定的输入状态,我们需要使得supervisory多次到达正确的交互状态,这需要同步三种事件,GUI操作、supervisory software中的代码执行情况、设备的响应。没有设计专门的机制来自动且同步地操控GUI操作以及网络流量,很难做到这一点;还有由于状态之间复杂的依赖关系,很多情况下都需要supervisory software先到达某个特定状态,然后才能到达目标状态,然而仅仅是识别出相对完整的状态集合已经十分困难。
- C2:Fuzzing proprietary protocols with unknown message frame format and state-space.
不知道状态空间就无法探索深度的程序路径以及深度的协议状态;不知道报文格式,就无法推断出报文字段值的约束关系,无法高效地生成有意义输入。
- C3:Simulating the session of proprietary protocol.
对于每个supervisory software发出的请求,都必须对其提供一个相应的回应,因此需要模拟这个session,但是这需要针对proprietary protocols有一个全面的理解。
Solutions to Challenges
为了解决挑战C1,我们设计了一个新的控制机制,通过自动准确地同步GUI操作以及网络通信,到达任何被识别的input states。
为了解决挑战C2,采用已有工作来逆向报文的格式,并且进行差异性分析识别字段与约束;为了识别协议状态以及过滤无效状态,不参用逆向的办法,而是建立基于执行路径与对应输入的state-book;为了能够对state能够达到较好地覆盖,提出新的切换state的策略。
为了解决挑战C3,通过建立一组基于真实抓包流量建立的communication templates/patterns,进行PLC device仿真,如果匹配不到合适的回复报文,那么就采用真正的PLC device.
DETAILED DESIGN
ICS3Fuzzer的结构如下图所示,主要分为两部分Pre-processing phase和Fuzzing phase:
- Pre-processing phase
- Functionality analysis. 分析如何在fuzzing loop期间自动化地开启会话。
- Proprietary protocol analysis. 分析报文格式以及状态空间,以帮助能够选择有价值的input states和生成高效的变异数据;根据捕获的流量模拟交互报文,从而不被限制在特定的硬件中。
- Fuzzing phase:全自动的,并且由四步工作组成
- 根据从state-book,选择一个有价值的input state。
- 根据得到的协议格式信息,生成变异的输入。
- 自动化地同步控制GUI操作以及网络通信,将变异数据喂给已选择的input state。
- 监控supervisory software的status并且记录malformed input。
Functionality Analysis
此部分的目的是准备进行task/functionality的UI组件,通过网络接口进行会话。利用guiAutolit
来实现“activator”,可用来触发GUI事件,比如鼠标移动等。
具体来说,此步分为两部分:
- 获取GUI handle:可以通过控制GUI handle来写脚本控制GUI事件
- 定义操作顺序:functionality是按照特定的GUI操作顺序出发的。
最终ICS3Fuzzer可利用guiAutolit来自动化实现fuzzing。
Proprietary Protocol Analysis
Inferring Protocol Format
利用现有工具Towards automated protocol reverse engineering using semantic information
Obtaining State-Space
此步骤目的为了定义和区分session中的input state,往往一个session中包含许多input state,并且其中有许多相似且重复的input state。
区分input states的办法:
- 直接的办法:比较messages的相似性,但不准确
- 论文方法:记录在对应input state下的execution trace(我理解为程序对每个message的execution trace),即是messages的区别很小也有可能导致十分不同的execution traces。在fuzzing过程中,应该着重关注那些能够导致更多中execution trace的input state。
由于本论文具有通用性,所以不专门分析特定ICS protocol的输入状态,而是建立维护一个state-book,其中包括code execution trace以及corresponding inputs,并不需要回复输入状态的特殊语义。
具体通过DynamoRIO插桩实现trace收集,并且只record/dump在消息传输阶段的message transmission(通过hook以及track send()以及recv())。因此在state-book中的每一个input state都对应着一个tuple,包括original message,execution trace,以及index。
Device Emulation
为了不被具体的硬件限制,论文选择基于获取到的报文模拟communication。
具有两个挑战:
- 当supervisory software初始化一个request时,需要根据抓取到的报文识别出对应的response.
- 需要调整对应报文中的动态字段。
对应上述挑战的解决办法:
- 设备中的request-response一般是非常相似的,可以根据抓取的报文建立对应关系。
- 根据人工总结的经验,加上人工分析,识别定义出报文中的动态变化字段。
如果上述办法仍然不能获取对应的response,那么就需要借助于真是的PLC device。最终ICS3Fuzzer可以对每个supervisory software的request产生对用的response。
State Selection
对state-book中记录的input state中的三个属性,index、execution trace、original message,赋予权重,所以每一个input state都具有一个权重,那么权重就可以代表每一个input state的价值。
权重的考量基于三个hypotheses:
- 网络通信越深,越有可能触发bug
- 当message呗转发给software,那么越多的BB被触发,越有可能存在bug
- input越复杂,越有可能造成crash
对应上述三个hypotheses的具体做法:
- 使用index代表depth。但是同时需要注意消除具有相似的state,比如导致复的行为,具体来说即相似的报文以及程序执行路径。
- 与AFL等基于反馈的fuzzer一致
- 输入越复杂,编译越多样,就有可能触发新的执行路径,具体使用message内被定义的字段数来代表复杂度。
最终选取state depth、basic blocks count、field count来代表上述三个hypotheses,最终计算出state weight。
Input Generation
此步骤利用获取的protocol format来生成变异的输入,主要完成两个任务:
- 根据你想得到的protocol format生成输入
- 根据得到的约束关系纠正报文字段。
Data Feeding
fuzzing supervisory software需要同步网络输入以及GUI操作,此论文通过proxy机制来实现了这一目标。
包含了Dispatcher、GUI Proxy、Traffic Proxy,Dispatcher通过给traffic proxy发送command来关系network traffic,通过给GUI proxy发送command来关系GUI操作,自动化的实现了fuzzing的输入.
Crash Monitor
基于Windows EventLog Service来做。
没考虑由于程序挂起(program hang)导致的bug。
Manual Work
需要人工工作来完成预处理过程,以解决GUI操作以及protocol先验知识,主要包括四个方面:
- exploring GUI interface
- writing activators
- obtaining protocol knowledge,包括状态空间收集、报文template获取、协议格式逆向
- verifying the accuracy of the analysis.
发表评论
您还未登录,请先登录。
登录