组会

组会纪要

2021-06-18 组会纪要

Posted by 瞿铸枫 on June 18, 2021

DIANE: Identifying Fuzzing Triggers in Apps to Generate Under-constrained Inputs for IoT Devices

IEEE Symposium on Security and Privacy 2021

报告人：瞿铸枫

2021/6/18

BackGround

  • IoT——一大热门
  • IoT自动化漏洞挖掘——安全研究一大热门
  • 由于提取、仿真固件上的困难，往往只能实现black-box fuzzing。但是这种方法产生的往往是invalid inputs，这些非法输入会很快被IoT设备拒绝从而无法到达深度代码。
  • 另一种方法是利用配套App来生成结构良好的输入。但是现有解决方案产生的fuzzing输入受到了APP验证代码的约束

Limitations

  • 首先想获取固件就难：从设备上提取固件需要特定的方法，并且供应商们一般不会允许他们的软件对外公开
  • 解包、分析固件样本也充满挑战：固件样本可能有多种格式、并且可以在几种不同的架构上运行，这些架构通常又是undocumented。
  • 大部分设备出厂时都禁用了硬件调试功能，排除了基于动态插桩的分析技术
  • 基于上述原因，安全研究员选择黑盒方式进行IoT安全分析。但是现有的黑盒技术需要有关设备接受的数据格式的知识，而鉴于设备采用的协议的异构性且缺乏文档，这些黑盒方法难以应用

研究现状

IoTFuzzer

  • 一个观察：大多数设备都有配套的APP，其中包含了必要的生成对应设备的合法输入机制。
  • 基于这一观察，Chen等人提出了IoTFuzzer，该工具利用配套APP来Fuzz IoT设备。
  • IoTFuzzer分析配套App，检索连接app的UI与网络相关方法或数据编码方法的所有路径；然后IoTFuzzer沿这些路径对处理用户输入的第一个函数的参数进行fuzz，从而为IoT设备生成有效的fuzz input。
  • 与随机fuzz从网络上直接发送给IoT设备的数据相比，这种方法产生了更好的结果，但实际上，它是在从UI提取变量后立即变异变量，然后再执行应用程序的输入验证或数据处理。 因此，当App清洗提供的输入时，IoTFuzzer的效率将大打折扣。由此，IoTFuzzer不能生成欠约束(指不受app侧sanitization影响)但结构良好的fuzzing inputs。

image-20211116165318616

Motivation

image-20211116165339895

  • 该程序用PTZ函数向camera发送位置命令
  • PTZ调用sendMsg，该函数准备要发送的数据并保存在buffer里
  • 同时，另一个线程从同一个缓冲区读取数据，并向设备发送命令
  • PTZ会对密码字符串执行完整性检查

此示例显示了从配套应用程序生成 IoT 输入时必须面临的两个关键挑战。

  1. app与IoT设备通信使用的是结构化的数据，有可能是已知协议(比如HTTP)，也可能是厂商的私有协议。设备会立即丢弃不符合预期格式的消息，因此不会触发其代码中的深层错误。

  2. 生成正确结构化的输入很重要，但有效的方法必须避免生成受应用端验证代码约束的输入。 函数PTZ禁止密码包含字符 & 和 ‘，但是这些字符可能是触发崩溃的关键

Solutions

本文提出一种克服上述困难的方法。

关键观察结果：配套APP中存在关键函数能用来生成最优的fuzzing inputs(即valid yet under-constrained)

这些函数本文中将其称为fuzzing trigger

fuzzing trigger会在数据转换函数(如network serialization)之前，输入验证代码之后被执行。因此fuzzing trigger生成的输入不受APP侧sanitization代码的约束，同时不会因invalid format而被目标IoT设备丢弃。

根据此观察，本文设计实现DIANE，静态动态结合分析并发现安卓配套App中的fuzzing trigger，然后使用这些函数自动化fuzz IoT设备。

Contributions

  • 一个识别fuzzing trigger的方法
  • 利用trigger识别方法实现DIANE
  • 评估11个IoT设备
  • 对大部分IoT设备和配套App来说，识别并利用fuzzing trigger来生成触发bug的输入的方法是可行的

Approach

本方法前提假设：获取不到固件

本方法为静态和动态分析相结合。分为主要两步：

  • Fuzzing trigger识别
  • Fuzzing

本方法基于四种分析：

  • 静态call-graph分析
  • 网络流量分析
  • 静态数据流分析
  • 动态函数参数分析

image-20211116165758213

Fuzzing Trigger识别

直觉：在控制流中，fuzzing trigger应该处于app侧通过网络发送数据前的合法性检查逻辑和任意数据转换函数之间。

识别算法分4步：

  • sendMessage Candidate Identification
  • sendMessage Validation
  • Data-Transforming Function Identification
  • Top-Chain Functions Collection

Step 1 sendMessage Candidate Identification

本步骤识别实现发送消息给IoT设备的必要逻辑的函数，本工作将其称为sendMessage函数

App可能依靠直接调用system call的临时原生函数实现sendMessage函数。而且这些函数可能在单独的线程中执行，这增添了精确追踪App的UI和sendMessage函数间数据流的动静态分析的难度

本文主要见解是，App必须包含一个介于核心功能和外部组件之间的边界函数（即Android framework或native libraries），当执行边界函数时，一个消息会被发送给IoT设备。本文将这个边界函数视为sendMessage函数

本方法首先通过静态分析识别候选sendMessage函数。所有调用原生函数或安卓框架中实现网络I/O功能的方法均认为是候选sendMessage函数

Step 2 sendMessage Validation

本文动态执行应用程序并利用 API Hooking来验证候选的sendMessage 函数。

理论上可以：

  • 多次动态执行该函数并检查它是否每次都产生网络流量
  • 阻止应用执行该函数并检查是否仍然产生网络流量

通常这种方法会导致程序本身崩溃。

本文采用基于时间戳和机器学习的方法解决该问题。

动态hook所有候选函数并运行程序。当观察到网络活动后，登记最后执行的候选sendMessage函数。每次执行候选sendMessage函数时，会收集执行到观察到网络活动之间经过的时间。

用K-Mean算法根据观察到的间隔时间进行聚类，将候选函数分为两个集群

基本原理是引发网络活动的函数具有较小的均值和标准差，因为它们受噪声的影响较小。

Step 3 Data-transforming Function Identification

应用程序可能会在sendMessage函数前执行数据转换。一个典型的例子就是编码，比如序列化

如前所述，Fuzzing Trigger在App的控制流中位于任何数据转换函数之前。本文方法借助数据转换函数生成合法的fuzzing输入，因此要找到Fuzzing Trigger，首先需要确定应用于正在发送的数据的数据转换函数

这项任务提出了不同的挑战。

  • 首先，正在发送的数据可能包含在一个类字段中，该字段被 sendMessage 函数引用。 这个字段理论上可以设置在应用程序代码的任何地方，包括在其他线程中。
  • 此外，对于每个字段，我们需要考虑其父类，因为持有消息的变量可能会被不同的类继承。

本方法首先静态识别可能保存待发送消息的变量，以及可能在App中设置这些变量的代码位置

确定数据转换函数。执行静态过程间反向切片。

将计算出的切片划分进函数作用域（切片中属于同一函数的连续指令子序列）

对每个函数作用域进行liveness analysis：考虑函数作用域内引用的变量，并计算在函数作用域开始时存活的变量的集合以及函数作用域结束时存活的变量的集合

观察现象：数据转换函数提高了它们消耗的数据的熵

计算函数作用域开始与末尾的变量的香农熵，如果熵的变化大，则认为是经历了数据变换

Step 4 Top-Chain Functions Collection

数据转换函数通常以精确的顺序执行，以充分准备要发送到IoT设备的数据。例如，base64编码数据后，封装在HTTP请求中

本文将数据转换函数序列称为转换数据链，将该序列的第一个函数称为Top-Chain Function

如果修改Top-Chain函数F的变量最终会影响变量v的值，就说F会影响v

本步骤感兴趣的是影响sendMessage变量的Top-Chain函数

如果控制这些Top-Chain的变量，就可以控制发送到被分析物联网设备的数据。而且，这些数据既有效（即被物联网设备接受），又不受App端输入验证的影响。

构建Dominance Tree以识别Top-Chain函数。选择那些不受任何其他数据转换函数支配的数据转换函数，最后认为收集到的数据转换函数为Fuzzing Trigger

Test Generation

通过变异Fuzzing Trigger的参数生成一个测试用例

变异策略：

  • 字符串长度
  • 数值
  • 空值
  • 数组长度

Identifying Crashes

在没有对设备进行侵入性物理访问的情况下识别物联网设备基于网络的服务的所有崩溃是具有挑战性的

DIANE自动分析设备响应来识别崩溃。DIANE 首先执行应用程序的正常运行并监控设备在正常活动期间的响应方式。 然后，在fuzzing时，DIANE监视APP和设备之间的网络流量，如果满足以下任一条件，则认为输入可能会导致崩溃：

  • Connection dropped
  • HTTP Internal Server Error (500)
  • Irregular network traffic size
  • Heartbeat Monitoring

Fuzzing

最后，用另外一个智能手机作看门狗设备，从一个中立的角度监控IoT设备的状态

Experimental Evaluation

两个研究问题：

  • DIANE 是否能够有效地发现物联网设备中先前已知和先前未知的漏洞？
  • 现有的（基于应用程序或网络级别的）fuzzer可以达到类似的结果吗？

第一个问题，本文评估fuzzing trigger检测的准确性，然后对11个不同的IoT设备进行fuzz，最终在5个设备中发现了11个bug，其中9个0day漏洞，同时时间缩短了10个小时

第二个问题，本文

  • 首先将IoTFuzzer与DIANE进行比较，表明DIANE性能更优
  • 然后，通过自动化学习来衡量配套APP中执行APP端合法性验证的频率，实验表明分析的APP中有51%包含了APP端合法性验证
  • 最后将DIANE与网络级别fuzzer进行比较，表明网络级fuzzer不能发现漏洞

image-20211116170447218

Limitations and Future Work

  • 当sanity check出现在Native code、数据转换函数或直接在sendMessage函数中实现时，目前无法绕过
  • 与其他任何基于动态分析的方法一样，DIANE 的代码覆盖率有限，即它无法识别应用程序未执行的Fuzzing Trigger
  • DIANE当前无法对嵌套的JAVA对象进行Fuzz
  • 可以增强DIANE以自动发现语义漏洞。目前此功能是半自动的，因为它需要分析人员检查并于看门狗设备交互

Conclusion

  • 本文研究了 IoT 设备Fuzzer的有效性。
  • 一方面，发送到设备的随机模糊网络数据包需要了解设备接受的数据格式，当设备使用自定义固件时，这很少可用。
  • 另一方面，由于应用程序端代码的约束，利用配套移动应用程序的 UI 来生成语法正确的消息的方法是无效的。
  • 相反，本文提出了一种介于网络级和UI级之间的Fuzzing方法。该方法旨在识别Fuzzing Trigger，这是物联网配套应用程序中的部分代码，在输入验证之后和任何数据转换函数之前执行，并最大化模糊测试结果。
  • 本文中根据提出的方法实现了名为 DIANE 的工具，并在11个不同品牌的真实物联网设备上对其进行了评估。 DIANE 优于当前最先进的方法，它可以成功检测到现有Fuzzer无法触发的关键错误。
CATALOG
    FEATURED TAGS
    讨论 组会
    FRIENDS