IOTFUZZER: Discovering Memory Corruptions in IoT Through App-based Fuzzing
随着越来越多的物联网设备进入消费市场，迫切需要在攻击者之前检测其安全漏洞。现有的基于二进制分析的方法仅适用于固件，除了那些配备有用于从设备中提取代码的特殊工具的固件之外，这种方法很难访问。为了应对物联网安全分析中的这一挑战，本文中提出了一个新颖的自动模糊测试框架，称为IOTFUZZER，旨在发现物联网设备中的内存损坏漏洞而无需访问其固件映像。关键思想是基于以下观察：大多数IoT设备通过其官方移动应用程序进行控制，并且此类应用程序通常包含有关其与设备进行通信的协议的丰富信息。因此，通过识别和重用程序专用逻辑（例如，加密）来改变测试用例（尤其是消息字段），我们能够有效地探测IoT目标，而无需依赖于有关其协议规范的任何知识。研究中，作者实施了IOTFUZZER并评估了17种运行在不同协议上的实际IoT设备，并且该方法成功地识别了15个内存损坏漏洞（包括8个以前未知的漏洞）。
INTRODUCTION
首先介绍了物联网设备的发展情况，并考虑到松散的安全保护和大量的漏洞带来的安全隐患，给网络犯罪分子带来可乘之机。
物联网攻击的一个重要目标是设备固件中的安全漏洞。系统检测这些漏洞需要解决一些挑战：
1、固件获取困难
许多供应商未公开提供其固件映像；从主板上转储映像需要已启用的调试端口的支持，许多物联网设备由于其简单性不存在这些调试端口。
2、压缩格式的多样性
所获得的固件如何解压缩？
在对从固件中提取的文件进行安全性分析时，主要挑战来自各种底层架构（内存布局，指令集等）。
1、现有技术主要依赖于某些体系结构的仿真，但是NVRAM参数不可用会导致在模拟器中运行的程序崩溃；
2、利用符号执行来分析固件也需要考虑到架构问题。
Our Approach. 与传统的嵌入式设备不同，大多数物联网设备由用户通过移动应用程序控制。此类IoT应用程序旨在充当其设备的电话侧控制面板，因此携带有关该设备的丰富信息，尤其是与其固件进行通讯的方式。此类信息的示例包括应用程序中嵌入的命令（种子）消息，URL和加密/解密方案。IOTFUZZER，是一种自动的黑盒模糊测试框架，专门用于检测IoT固件中的内存损坏漏洞。 IOTFUZZER的独特之处在于，它可以运行协议指导的模糊测试，并利用物联网应用程序携带的信息，而无需对协议进行逆向工程或从应用程序中显式恢复此类知识。取而代之的是，它执行动态分析以识别在应用程序内部形成的将传递给目标设备的消息内容，并在运行时自动更改这些内容，以便使用应用程序的程序逻辑来生成有意义的测试用例，以测试目标固件。这种方法不仅轻量级，避免了繁重的协议分析，而且可靠，即使在存在密码保护（加密，身份验证等）的情况下，也能够生成有效的测试有效负载。
IOTFUZZER 通过由测试用例触发的崩溃来报告问题的存在，用于指导后续安全分析以找出漏洞的根本原因。
Contributions.
1、无需获取固件的模糊测试框架IOTFUZZER，用于IoT设备的安全性分析。 通过利用官方移动应用程序所携带的信息及其程序逻辑，可以自动检测IoT设备中的内存损坏漏洞，而无需直接访问固件。
2、开发了一套新技术来实施自动的黑盒IoT模糊器，其中包括无需协议规范的协议引导模糊测试，用于消息生成和传递的上下文内加密和联网功能重播以及用于远程监控目标IoT设备状态的轻量级机制。
3、作者实施了IOTFUZZER的功能齐全的原型，并对17个现实世界的IoT设备进行了评估，发现了15个对安全至关重要的内存漏洞，其中有8个从未报告过。
BACKGROUND
A. Typical IoT Communication Architecture
典型的物联网智能设备通常配备有许多用于外部信息收集的传感器，以及用于数据传输的无线连接模块。相应的智能手机应用程序作为控制节点，与物联网设备配对后可以向物联网设备发送控制命令，以更改系统设置或获取运行状态数据。设备和应用之间的通信模式可以是直接连接（例如Wi-Fi，蓝牙和ZigBee），也可以是通过无线路由器的委托连接（即连接到同一Wi-Fi网络）。另外，一些供应商提供了额外的云服务来支持远程设备管理和数据存储。在这种云辅助架构中，设备或IoT应用程序将通过Internet连接到云服务器。本文将重点放在通过Wi-Fi实现通用性的本地连接模式（直接连接和委托连接）上。
B. Obstacles in Firmware Analysis
物联网设备通常运行固件来提供系统控制、状态监视、数据收集等功能。固件通常是高度定制的，以适应具有有限计算和内存资源的硬件芯片。由于其封闭的资源和架构多样性，执行固件变得极具挑战性甚至需要大量的人工分析。以下为分析固件的挑战：
1、固件获取
一方面许多供应商并未明确为用户在线提供映像；另一方面，硬件黑客尝试使用调试端口（例如JTAG接口）转储固件映像或导出控制台。但是，越来越多的制造商倾向于在交付产品之前禁用调试端口，以防止基于硬件的破解。
2、固件解包
获得固件映像后，下一步就是解压缩提取包含的文件。固件格式的多样性以及固件映像被压缩、加密也会带来阻碍。
3、可执行分析
对从固件映像中提取的文件进行安全性分析，主要困难在于未统一的基础架构。
Our Approach.
物联网应用可以用作测试封闭源IoT设备的客户端，它是发送测试消息的节点。这样的设计避免了在发现新漏洞时逆向工程二进制可执行文件的困难和繁琐的工作。
C. Challenges in IOTFUZZER Design
IOTFUZZER 是一个自动的协议指导的模糊测试框架，可以将探测消息发送到IoT设备以触发内存损坏漏洞。基于没有针对物联网设备的流行且占主导地位的协议标准这一事实，物联网供应商倾向于设计定制的数据格式和协议、使用非标准的加密功能来加密消息。因此，为了从物联网应用程序生成协议指导和加密一致性消息，需要遵循相应设备的协议格式和加密方案。
Challenges.
1、更改网络消息中的字段。
需要自动识别和模糊未知协议的协议字段。
2、处理加密的消息。
需要一种轻巧灵活的解决方案来重用应用程序中的消息加密功能。
3、监控崩溃。
需要设计一种有效的机制来远程自动监视设备状态。
Solutions.
1、更改数据源处的协议字段。
可以在协议消息源处对协议消息中使用的数据进行突变，遵循原始程序逻辑，这些突变的字符串最终将成为协议字段。
2、在运行时重用加密功能。
由于从一开始就修改了数据源，因此正常的程序执行将有助于完成消息加密过程并生成准备发送的消息，因此无需重新实现完整的加密逻辑。
3、通过心跳机制检测活力。
尽管无法在本地监视正在运行的设备的状态，但可以通过发送心跳消息来推断程序或系统是否处于活动状态。心跳消息可以是任何查询设备状态的消息。
D. Scope and Assumptions
1、被测物联网设备可以由相应的移动应用程序进行配置和控制。
2、通信渠道需要基于Wi-Fi。
3、Android平台。
DETAILED DESIGN
IOTFUZZER 分为两个阶段：应用程序分析阶段和模糊测试阶段。
1、应用程序分析阶段
将物联网应用程序作为输入，分析 UI 以进行网络事件触发，并跟踪与应用程序协议相关领域的传播。完成这些步骤后，IOTFUZZER记录了所有协议字段以及相应功能。
2、模糊测试阶段
使用IoT应用程序的动态工具来改变感兴趣的协议字段，并动态监视IoT设备的崩溃。最后，IOTFUZZER输出警报（即崩溃消息），指示潜在的内存损坏。
有四个主要步骤来模糊IoT设备：
1、UI分析
分析IoT应用程序的代码并发现所有将导致网络消息发送的UI组件，用以通过驱动相应的UI控件触发消息发送事件。
2、数据流分析
为了识别其值与要发送到IoT设备的消息内容相关的程序元素，跟踪数据从一组选定的元素中发现确实影响某些消息字段的流，使用这些程序元素来突变字段的内容，以模糊设备。利用数据流分析来确定如何命令IoT应用程序生成有意义的测试输出以用于模糊其远程目标。
3、运行时突变
根据定义的模糊策略，一旦识别出协议字段，IOTFUZZER便会在其第一个使用位置对原始字段进行突变。然后，物联网应用将遵循其正常执行逻辑来计算和构建消息，并将其与变异数据一起发送到物联网设备。
4、响应监视
远程监视IoT设备的运行状态并捕获触发的崩溃。对于基于TCP的通信，IoT应用程序和IoT设备之间的连接被中断很容易检测，对于基于UDP的通信，使用心跳机制来检测在不确定的时间发生的崩溃。
A. UI Analysis
在准备协议字段识别和突变时，我们只需要关注触发网络消息传递的事件。 因此，UI分析的目标是确定最终导致消息传递的UI元素。
一个典型的IoT应用程序的工作方式如下：当输入文本框时，单击UI上的按钮，或进入另一个Activity，事件处理程序将被调用以处理事件； 之后，在事件处理功能中，将创建一个后台线程来构建输出消息并操作加密/解密和网络功能。
为了确定触发网络消息的UI组件，执行静态分析以将不同活动中的UI元素与目标网络API相关联。
构建调用路径。首先使用 Androguard 构建应用程序的调用图。从目标网络通信API开始构造UI事件处理程序的后向代码路径。 但是，由于存在隐式的控制流转换，例如 thread.start 和 thread.run 的回调关系以及其他事件驱动的调用，因此还需找到这些隐式边缘，可以通过 EdgeMiner 获得。代码路径的接收器是一组最终发送网络消息事件处理程序。
Activity转移图构造。为了到达某些Activity并在模糊期间触发网络发送事件，需要构造Activity转移图。首先使用 Monkeyrunner 通过基于事件执行顺序的简单策略与每个Activity中的UI元素进行交互；之后获得一系列UI事件以及如何触发它们的顺序；记录将当前Activity转换为另一Activity的事件，对于每个Activity中的事件，根据构造的调用路径筛选出不会导致网络发送API的事件；最后使用记录的UI事件构造Activity转换图，其节点是具有触发消息发送API的事件（或事件序列）的Activity，而边缘是创建或恢复Activity的事件（或事件序列）。
B. Data-flow Analysis
在执行过程中改变协议字段需要首先识别协议字段并记录将协议字段作为参数的函数。 鉴于IoT应用程序中的命令消息通常是由硬编码字符串、用户输入或系统API构成，使用动态污点跟踪和 TaintDroid 的改进版本来进行识别。
1、专注于突变未编码的原始数据，不会将污点传播到加密函数。执行加密函数识别，除了作为标准网络发送API的参数的接收器之外，还将污点接收器设置为那些加密函数的参数。
2、仅在Dalvik VM中以可变级别记录污点传播流，未深入到本机系统库级别（由于TaintDroid的限制）。
1、污染源。
分析的污点包括物联网应用中的所有字符串（例如关键字和定界符）、消息中经常使用的系统API、来自UI的用户输入。
2、污染传播。
修改传播规则，扩大更多的污点来源。使用字典来存储 taint 标签。每当创建新标签时，都会将其添加到字典中并跟踪此标签的依赖性。
3、污水池。
污点是确定的网络API和加密函数使用的数据。如果网络消息中没有加密，则污染点将是那些标准的网络API。是否使用加密函数可以通过下所述的加密函数识别来识别。
加密函数识别：
密码算法通常包含算术和按位运算。首先，选择包含算术和按位运算的函数，然后记录消息发送事件的执行轨迹找到候选加密函数。
C. Runtime Mutation
通过污点跟踪可以识别协议字段以及它们通过的相应功能。 动态地钩挂记录的函数，并在运行时更改协议字段参数以生成探测消息，这样的设计带来两个好处：
（1）在对协议字段进行编码或加密之前可以对其进行模糊处理；
（2）无需协议逆向工程就可以模糊未知协议字段。
在应用执行期间，已标记的变量将传递给一组函数，在数据流分析中只需要记录第一个传递的函数及其调用上下文，因为第一个函数的突变足以更改后续程序逻辑中标记变量的值。大多数协议字段都是在代码中定义的硬编码字符串，并且开发人员很少清理传递的参数，执行重复数据删除并获得这些记录功能的唯一集合，并使用 Xposed 框架动态地挂钩。传递给钩子函数的原始值可以用突变值代替。
当一个钩子函数改变了字段时，不知道协议字段是否已经被模糊化。为了安排模糊处理的过程，我们使用算法将突变分配给功能参数。突变的分配在触发每个事件处理程序之前进行。
对于每条消息，我们都希望随机选择要突变的字段子集，而不是对所有字段进行突变（因为设备容易拒绝所有字段都发生了突变的消息）。首先从所有挂钩函数中提取参数集P；然后随机生成总突变量s，它是小于c（消息M中已标识字段的数量）的正整数（这样的要求是通过将每次执行的突变数限制为少于消息字段的数量，来减少对所有字段进行突变的机会）；最后为等式t1 + t2 +··+ tn = s（t和s为整数）计算了一组有效解，其中tx是分配给参数字段px的突变量。该方程的解不是唯一的，只是随机选择一个有效的组。由于实时数量的调用函数在运行时不可用，因此选择一个随机有效组是一种无偏的解决方案。该策略可以灵活适用于不同的情况，例如强调某些功能或协议字段的突变时间。
一般来说，模糊策略主要有两种类型：基于生成的模糊和基于变异的模糊。前者需要理解协议格式，并从头开始生成带有结构信息的输入，以避免被直接拒绝。后者仅使用类型信息来更改现有的种子输入。由于协议字段的运行时突变本质上是输入结构感知的，因此可以通过对字段采用以下启发式突变规则来实现带有结构和类型信息的模糊策略：
（1）更改用于基于堆栈或基于堆的溢出和越界访问的字符串的长度。
（2）更改整数，双精度或浮点值以进行整数溢出和越界访问。
（3）更改类型，提供空值以错误解释值和未初始化的变量漏洞。
D. Response Monitoring
当目标物联网设备已收到模糊测试消息时，需要知道它是否触发了任何异常行为（例如系统崩溃）。
可能的响应可分为以下几类：
（1）预期响应。在这种情况下，探测消息将由IoT设备正确处理，并且不会发生任何异常。
（2）意外响应。探测消息超出了程序的预期逻辑（例如，达到了输入参数的边界），并触发了未处理的错误。
（3）没有回应。当对某个探测消息没有响应时，它可能触发DoS漏洞，或者只是在本地处理的错误而没有答复，或者以死循环运行。
（4）断开连接。对于像TCP这样的面向连接的通信协议，当探测消息触发系统崩溃时，网络连接将被中断。
基于以上列出的四种类型的响应，针对物联网设备与物联网应用之间的不同传输层通信使用了针对性的故障检测机制。对于基于TCP的连接，只是通过查看连接状态来推断系统是否崩溃。对于基于UDP的连接，如果程序或系统崩溃，则不会有任何响应发送回IoT应用程序。
为了区分这两种情况，使用心跳插入机制。
首先从IoT应用程序中提取心跳消息，该消息用于检测设备是否处于活动状态。心跳消息的提取基于对网络功能的分析以及在有或没有用户与配对的应用程序交互的情况下通过网络流量进行的差异分析。然后在模糊测试期间，每隔十个插入一个心跳消息以探测是否有活动。
IMPLEMENTATION AND EVALUATION
介绍IOTFUZZER的原型实现并分析评估结果。
A.实现细节
1、共计大约9,100条Java代码行和1,400条Python代码行；
2、在IOTFUZZER中集成开源项目（例如Xposed和TaintDroid）；
应用程序分析阶段：
3、使用 Androguard，EdgeMiner 和 Monkeyrunner 实现调用路径的构建和自动 Activity 转换；
4、依靠Xposed模块和Monkeyrunner触发网络事件以进行污点分析和后续的消息传递操作。Xposed提供了挂钩和替换功能；
5、扩展TaintDroid的污染源和污染跟踪策略来实现污染跟踪；
6、污点跟踪的输出写入配置文件中
模糊测试阶段：
7、通过在应用执行过程中在Xposed中创建分析线程来实现核心功能（计划，突变和崩溃监控）；
8、预装了配置文件以提供目标功能的信息。
注意，分析线程旨在通过为每个挂钩函数分配突变配额来安排模糊测试，并且该突变仍在应用的原始线程中执行。某些确认的崩溃是由相同种子消息的变异消息（具有微小差异）触发的（不同实例，但可能触发相同的错误），因此，记录每个种子消息和变异消息对的关系可以对崩溃消息进行分类。当获得一组由IOTFUZZER生成的崩溃消息时，可以将它们与相应的种子消息进行比较，以找到突变的字段并进一步确认固件映像中的漏洞。
B.实验设置
所有选择设备都可以通过官方IoT移动应用程序通过本地Wi-Fi网络进行操作。
对通信协议和数据传输格式没有限制。
Intel Core i7四核×2.81 GHz CPU和8 G RAM的Ubuntu 14.04 PC
Google的Nexus 4上运行污点跟踪
将正在测试的IoT设备配置为完全控制的本地Wi-Fi网络设置，避免了无关的流量和不必要的防火墙封装干扰。
设备初始化后，将这些设备与智能手机上安装的相应物联网应用程序配对，智能手机连接到相同的无线局域网。
C.有效性
使用IOTFUZZER（每个设备设置为运行24小时）对17个IoT设备执行模糊测试，发现9个设备中有15个严重漏洞（内存损坏），包括5个基于堆栈的缓冲区溢出，2个基于堆的缓冲区溢出，4个空指针取消引用和4个崩溃。
D.效率
IOTFUZZER在测试时间和测试用例数量上通常都超过了流行的开源模糊测试，仅用52.79小时就识别了15个内存损坏，总共有184159条模糊信息。
DISCUSSION AND LIMITATIONS
测试范围。
尽管IOTFUZZER获得了较高的规范覆盖率（用于协议），但固件的代码覆盖率和攻击面的覆盖率却受到限制。
主要焦点是从移动应用程序的数据输入通道自动识别内存损坏。为了检测（利用）此类内存漏洞，IOTFUZZER（攻击者）必须以调试（恶意）意图输入实际数据。
对于现代物联网设备，移动应用程序提供了主要的数据输入通道，以方便设备管理。尽管攻击者可能会利用其他数据通道，例如传感器或调试端口，但由于物理访问的要求，利用的门槛很高，这使得攻击很难在实践中成功。
连接模式。
在IOTFUZZER的当前实施中，仅关注与Wi-Fi连接到移动应用程序的设备。
结果判断。
IOTFUZZER无法直接生成内存损坏类型和根本原因。IOTFUZZER的设计目标是自动生成漏洞警报（即崩溃消息），以帮助安全分析人员轻松地定位和确认固件的根本原因。
结果准确性。
对于误报，IOTFUZZER报告的某些崩溃消息源自不可避免的和不可预测的网络错误，尤其是对于基于TCP的连接。如果IOTFUZZER在子进程中发生并由相应的父进程正确处理，则可能会丢失某些崩溃。线程崩溃将始终影响整个进程并导致进程崩溃，因为线程没有自己的地址空间。同样，在某些情况下，内存损坏也不会导致崩溃。例如，缓冲区溢出导致损坏的局部变量，并且不会损坏堆栈帧或返回地址。
CONCLUSION
介绍了第一个物联网模糊测试框架IOTFUZZER，它利用官方的移动应用程序来检测相应物联网设备的内存损坏。 为了进行有效的安全测试，开发了一套新颖的技术，包括用于消息生成和传递的上下文内加密和网络功能重播，没有协议规范的协议字段的运行时变异，以及用于检测系统崩溃的轻量级监视机制。 通过在真实环境中进行实验，使用IOTFUZZER成功识别了17个IoT设备中的15个内存安全漏洞。