abstract+introduction

背景

工控网打破了工业物联网中假定的每个系统相互分离的限制，引入的威胁。工控网中的目标主要分为两类：一类是控制控制生产过程的设备，另一类是控制这些设备的监控软件supervisory software。

问题

专注于分析针对PLC设备的supervisory software，特别是寻找其中有关协议实现的漏洞。（攻击面）

目前工作及其缺点

目前针对ICS内部的supervisory software的fuzzing工作较少，并且受限，主要是三个方面：通常是运行在windows上的闭源程序，并且体量较大，严重依赖GUI；通常作为客户端，这对于fuzzer来说不易测试；通常使用专有协议进行通信，并且协议状态是和GUI紧耦合的。

现有fuzzing工作与ICS3fuzzer特性对比图

挑战

1. 闭源、体量大
2. 与GUI操作紧耦合
3. 私有协议

论文工作

提出了ICS3Fuzzer，ICS Supervisory Software Fuzzer，一个可移植的、模块化的，能够自动化测试supervisory software的fuzzing框架。

没有直接分析提取协议实现（因为十分困难），而是直接在同步控制GUI操作以及网络通信的情况下，直接运行和fuzz对应的supervisory software。

ICS3Fuzzer是黑盒的，通过自动化地输入专门生成地有效地输入并到达不同的协议状态，来持续地驱动整个过程。并且提出了新的fuzzy策略，倾向于更有可能发生漏洞的状态。测试目标时是结合模拟测试与实际测试的优缺点。

贡献：

1. 设计实现了ICS3Fuzzer
2. 提出了新的fuzzing策略
3. 结果好，并开源

 

BACKGROUND AND MOTIVATION

ICS Architecture

典型的ICS系统由三层,分别是（1）Field Instrument Control Layer，由传感器（senior）和执行器（actuator）构成，用来进行系统的输入和输出（2）Process Control Layer，由专用嵌入式设备组成，比如PLC/RTU，用来控制实时进程（3）Supervisory Control Layer，由几个工作站组成，用来提供实时监控以及控制系统的设备。

ICS系统的几个显著的特点：

1. ICS直接与物理世界进行交互，因此其中的安全问题往往会造成更大的危害。
2. ICS必须可靠并且满足实时约束，必须使用实时操作系统，并且特定领域协议（domain-specific protocols）被用来在上述三层之间进行通信，并且协议往往未被加密。
3. ICS的网络是air-gaped，即与外部网络隔离，因此其中往往缺少很多安全性措施。但是随着IIOT的发展，这种隔离逐渐被削弱，因此会带来很多问题。

ICS系统中supervisory software的共同特点为，都提供了用于读可操作变量、开启/停止PLC、下载固件等接口，这些功能在一个指定的信道进行通信，通信数据包含如下内容：

1. 实时设备状态：sensor reading、feedback of control command exectuion、heartbeat messages
2. 设备信息：device name、version、model、manufacturer
3. 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

1. TCP session的开始往往是一种按钮操作（可理解为人工操作），有人类通过GUI界面完成。
2. 在session期间，在许多情况还需要额外的按钮操作来完成交互。
3. session通过周期性的交换heartbeat报文或者停止报文交换来结束此session。

New Insight

Supervisory software在不同的interaction states时往往有着不同的行为（code execution），Supervisory software的交互状态本质上是与PLC设备进行交互的特定的程序上下文；交互状态取决于几个因素，包括之前的按钮操作、之前的input states等。Supervisory software的实现与GUI接口是高度耦合的。

Challenges

1. 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先到达某个特定状态，然后才能到达目标状态，然而仅仅是识别出相对完整的状态集合已经十分困难。

1. C2：Fuzzing proprietary protocols with unknown message frame format and state-space.

不知道状态空间就无法探索深度的程序路径以及深度的协议状态；不知道报文格式，就无法推断出报文字段值的约束关系，无法高效地生成有意义输入。

1. 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：

1. Pre-processing phase
   1. Functionality analysis. 分析如何在fuzzing loop期间自动化地开启会话。
   2. Proprietary protocol analysis. 分析报文格式以及状态空间，以帮助能够选择有价值的input states和生成高效的变异数据；根据捕获的流量模拟交互报文，从而不被限制在特定的硬件中。
2. Fuzzing phase：全自动的，并且由四步工作组成
   1. 根据从state-book，选择一个有价值的input state。
   2. 根据得到的协议格式信息，生成变异的输入。
   3. 自动化地同步控制GUI操作以及网络通信，将变异数据喂给已选择的input state。
   4. 监控supervisory software的status并且记录malformed input。

Functionality Analysis

此部分的目的是准备进行task/functionality的UI组件，通过网络接口进行会话。利用guiAutolit来实现“activator”，可用来触发GUI事件，比如鼠标移动等。

具体来说，此步分为两部分：

1. 获取GUI handle：可以通过控制GUI handle来写脚本控制GUI事件
2. 定义操作顺序：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的办法：

1. 直接的办法：比较messages的相似性，但不准确
2. 论文方法：记录在对应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。

具有两个挑战：

1. 当supervisory software初始化一个request时，需要根据抓取到的报文识别出对应的response.
2. 需要调整对应报文中的动态字段。

对应上述挑战的解决办法：

1. 设备中的request-response一般是非常相似的，可以根据抓取的报文建立对应关系。
2. 根据人工总结的经验，加上人工分析，识别定义出报文中的动态变化字段。

如果上述办法仍然不能获取对应的response，那么就需要借助于真是的PLC device。最终ICS3Fuzzer可以对每个supervisory software的request产生对用的response。

State Selection

对state-book中记录的input state中的三个属性，index、execution trace、original message，赋予权重，所以每一个input state都具有一个权重，那么权重就可以代表每一个input state的价值。

权重的考量基于三个hypotheses:

1. 网络通信越深，越有可能触发bug
2. 当message呗转发给software，那么越多的BB被触发，越有可能存在bug
3. input越复杂，越有可能造成crash

对应上述三个hypotheses的具体做法：

1. 使用index代表depth。但是同时需要注意消除具有相似的state，比如导致复的行为，具体来说即相似的报文以及程序执行路径。
2. 与AFL等基于反馈的fuzzer一致
3. 输入越复杂，编译越多样，就有可能触发新的执行路径，具体使用message内被定义的字段数来代表复杂度。

最终选取state depth、basic blocks count、field count来代表上述三个hypotheses，最终计算出state weight。

Input Generation

此步骤利用获取的protocol format来生成变异的输入，主要完成两个任务：

1. 根据你想得到的protocol format生成输入
2. 根据得到的约束关系纠正报文字段。

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先验知识，主要包括四个方面：

1. exploring GUI interface
2. writing activators
3. obtaining protocol knowledge，包括状态空间收集、报文template获取、协议格式逆向
4. verifying the accuracy of the analysis.