IoT 设备固件分析之网络协议 fuzz

无线安全 2019-11-09

本文作者:cq674350529(信安之路新晋作者)

通常,在对IoT设备的固件进行分析时,固件中与提供服务如HTTPTelnetRTSPUPnP等相关的二进制程序是重点分析的对象。因为一旦在这些程序中发现漏洞,其很有可能会被远程利用,进而带来严重的安全隐患。

对固件二进制程序进行分析,常见的分析方法包括模糊测试补丁比对工具静态扫描人工审计等。其中,模糊测试方法具备简单易用的特点,通常也比较有效,其在业界已被广泛使用。

下面,以某型号路由器为例,基于Boofuzz框架,介绍对常见网络协议进行fuzz的方法。

除了网络协议外,也可以采用类似的思路对其他协议如BLE、串口协议等进行fuzz。同时,该方法不仅局限于IoT设备,也可用于对常见的服务程序进行测试。

模糊测试简介

模糊测试采用黑盒测试的思想,通过构造大量的畸形数据作为应用程序的输入,来发现程序中可能存在的安全缺陷或漏洞。

img

模糊测试方法的分类有很多。根据测试用例生成方式的不同,可以分为基于变异的模糊测试和基于生成的模糊测试。根据对目标程序的理解程度,可分为黑盒模糊测试、灰盒模糊测试和白盒模糊测试。常见工具与方法的对应关系如下。

img

针对IoT设备,由于其资源受限和环境受限等特点,实际中常采用黑盒模糊测试的方式。在对网络协议进行测试时,可以将常见的网络协议分为两类:一类属于文本协议,如HTTPFTP等,这类协议的特点是其数据包内容都是可见字符;另一类为二进制协议,其特点是数据包内容大部分是不可见字符,这类协议在工控设备如PLC中比较常见,通常属于私有协议。针对文本协议,笔者常采用Sulley 框架进行测试:

https://github.com/OpenRCE/sulley

而针对二进制协议,则常采用 kitty框架进行测试:

https://github.com/cisco-sas/kitty

Sulley框架和kitty框架均能够对两类协议进行测试。

另外,在对IoT设备进行模糊测试时,需要考虑如何对设备进行监控,以判断是否出现异常。最简单的方式通过设备服务的可用性进行判断,如果设备提供的服务不可访问,表明设备可能崩溃了。但这种监控方式粒度比较粗,容易漏掉一些异常行为。另外,当设备出现异常后,还需要对环境进行恢复,以便继续进行测试。常见的方式就是重启设备。现在很多设备崩溃之后都会自动重启,如果测试目标设备没用提供这种机制,则需要采用其他方式解决。

Boofuzz框架简介

由于Sulley框架目前已经停止更新维护,而Boofuzz框架是Sulley的继承者,除了修复一些bug之外,还增加了框架的可扩展性。下面对Boofuzz框架进行简单介绍:

img

来源: Fuzzing Sucks! Introducing the sulley fuzzing framework. Pedram Amini & Aaron Portnoy. Black Hat US 2007

由上图可知,该框架主要包含四个部分:

1、数据生成:根据协议格式利用原语来构造请求

2、会话管理/驱动:将请求以图的形式链接起来形成会话,同时管理待测目标代理请求,还提供一个 web 界面用于监视和控制

3、代理:与目标进行交互以实现日志记录、对网络流量进行监控等

通常,代理是运行在目标设备上。但是,对于IoT设备而言,大部分情况下都无法在目标设备上运行代理程序。


本文由 信安之路 创作,采用 知识共享署名 3.0,可自由转载、引用,但需署名作者且注明文章出处。

楼主残忍的关闭了评论