IOTFUZZER:Discovering Memory Corruptions in IoT Through App-based Fuzzing

摘要

目前针对IoT设备的安全分析工作都是基于固件来展开的，这样就需要解决如何获取固件以及如何分析固件的问题。

考虑到设备以及架构的多样性，作者借助IoT设备的移动端App设计了一个黑盒模糊测试工具来避开这类问题以分析IoT设备上的内存错误漏洞。

作者设计并实现了IOTFUZZER并测试了17个不同的IoT设备，最终发现15个内存错误漏洞，其中包括了8个未知的漏洞。

1.简介

物联网攻击的一个重要目标是设备固件中的实现缺陷（或安全漏洞）。系统地检测这些缺陷需要解决一些挑战。最主要的一个问题是固件获取的困难，因为许多供应商没有公开他们的固件映像。而且越来越多的厂商禁用调试端口，无法通过调试端口获取。

对于IoT设备来说，用户所在移动端设备上安装的操作App可以提供许多丰富的交互信息，那么可以利用它们可以发送测试数据。这样可以明显降低在分析漏洞时逆向可执行文件的困难度和工作量。 因此，作者设计一个基于移动应用程序的模糊测试框架。

作者提出了一个新型自动黑盒Fuzz测试框架——IOTFUZZER，旨在监测物联网设备中的内存损坏漏洞

工作目的

• 仅Fuzz测试，结果用于指导后续的安全分析，找出漏洞的根源。

基于APP分析的Fuzz测试框架

• 大多数IOT设备带有官方APP
• APP中包含丰富的命令（种子）消息，URL和加密/解密信息
• 轻量级，无需复杂的逆向和协议分析

主要优点

• 无需获取IOT设备固件镜像
• 无需逆向分析
• 无需知道协议具体内容

2.背景

IOT通信模型

• 手机客户端直接与IOT设备进行通信
• 使用供应商提供网络云服务进行通信
• 云服务器与设备之间通信
  

（手动/自动）分析固件的障碍

• 固件获取
• 固件解压
• 可执行分析

挑战

• Mutating fields in networking messages

识别协议中的哪些数据是可以被用来修改为mutation的，通用协议较为方便，难点在于私有协议

• Handling encrypted messages

有些协议的字段甚至全部协议本身是加密的，所以需要以相同的方式加密的包含数据(Mutated)的协议消息。

• Monitoring crashes

还需要监控设备的状态，因为IoT设备大多没有显示器，需要使用一种不接触设备为前提的方法检测设备是否Crash。

解决方法

• Mutating protocol fields at data sources

针对未知协议的逆向比较花费精力，所以作者选择在数据源处对协议中所使用的数据进行修改。作者使用了数据流分析，这里数据源其实就是Source

• Reusing cryptographic functions at runtime

因为修改了Source，所以对于加密函数不需要重新实现，只要重用即可，作者使用了Xposed hook这些函数

• Detecting liveness with heartbeat mechanism.

发送心跳包以检测状态

3.实现

A. UI Analysis

UI分析的目的是识别出与网络消息发送相关的事件以便于后续数据流分析和fuzz。

首先使用Androguard构建CFG，对于隐式的控制流转换(例如thread.start和thread.run的回调)使用EdgeMiner分析并添加到CFG上，以分析出那些操作会触发网络消息事件

然后使用Monkeyrunner构建出什么样的UI触发顺序可以触发相应的网络事件，例如，先点击Text框，然后输入数据点击发送Button以发送消息。

B. Data-flow Analysis

为了识别那些数据与要发送到IoT设备的消息内容（例如，字符串常量，系统API的返回值等）从选定元素中跟踪数据流以确定影响某些消息字段的内容。 然后，这些数据会被改变字段的内容以进行fuzz。使用TainDroid实现

Taint Sources：system APIs;UI Input

Taint Propagation：修改传播规则，可以保存任意数量的污点tag

Taint Sinks：networking APIs; encryption functions

启发式选择包含算术和按位运算的函数作为加密相关函数

C. Runtime Mutation

优势： 1. 协议字段可以在加密或者编码之前修改 2. 未知协议也在不逆向协议细节的情况下fuzz

使用xposed在数据流分析出sink为目标sinks的source生成处进行hook并修改其值。

Fuzzing Scheduling

并不是全部修改所有的source，因为这样更容易触发设备的异常导致粒度不够细。

Fuzzing Policy

更改字符串的长度以实现栈溢出或堆溢出和越界

修改int、double、float值以测试堆栈溢出和数组越界

修改数据类型或者未初始化的变量提供空值以测试misinterpretation或者未初始化漏洞

D. Response Monitoring

用心跳包检测设备的状态以判断是否发生了Crash

• Expected Response：not interested
• Unexpected Response：untreated errors
• No Response：Dos or dead loops
• Disconnection：Crash

4.讨论与限制

局限性

• 测试范围

移动应用程序提供了便于设备管理的主要数据输入渠道，可以尝试使用其他数据通道（如传感器或调试端口）。

• 连接模式

目前仅通过Wi-Fi连接的设备，日后可扩展到其他通信模式，如蓝牙，Zigbee。

• 结果判断

IOTFUZZER无法直接生成内存损坏类型和根本原因，在黑盒测试中，最终的漏洞确认通常需要进行一些手动操作。

• 结果的准确性

存在大量误报。

在某些情况下，内存损坏不会导致崩溃。