在过去的几年中，针对IoT安全研究的一个大热主题是如何动态分析IoT固件（比如使用模拟执行的方法）。在今年的USENIX Security会议上，来自波士顿大学的研究人员进一步细化了这个方向，他们在名为 FirmSolo: Enabling dynamic analysis of binary Linux-based IoT kernel modules 的论文中介绍了一种能够对IoT固件里（私有）的Linux Loadable Kernel Module（LKM）进行动态分析的方法。
在这篇论文中，作者设计了名为FirmSolo的系统，这套系统的新颖之处在于，它利用了名为Kernel Configuration Reverse Engineering（K.C.R.E）这么一项技术，生成了各种不同的内核编译版本，这些根据不同的特定参数编译出的内核，能够对应地加载现实中已经编译过、缺乏源代码的LKM二进制代码，这样就可以动态分析这些LKM啦！
作者指出，之所以需要K.C.R.E来生成不同的内核编译版本，是因为现实中搜集的LKM并不是随便找一个内核就能加载成功的。要成功加载一个特定的LKM，首先需要内核的版本是这个LKM指定的，其次需要给这个LKM提供所有它需要的外部符号（外部函数），最后还要保证LKM中需要的特定数据结构类型在内核中被正确定义。下图是FirmSolo解决这些挑战的工作流程：
FirmSolo首先会分析搜集到的LKM二进制代码（.ko文件），从中搜集到LKM运行所需要的内核版本、符号信息和数据结构类型信息，然后就进入到K.C.R.E流程，构建所需要的内核编译版本。这里面比较有意思的地方在于，有时候如果不仔细考虑编译的参数，编译出来的内核版本可能在一些数据结构的类型声明上有细微差别。例如下图中这个struct net，在不同的编译选项下结构是不同的，如果LKM需要的类型和内核编译版本实际定义的类型只是名字相同，类型上不一致（也就是对象的内存布局有差异），那么在动态分析时肯定会崩溃。
解决这些问题之后，FirmSolo就可以大显身手了，不过我们觉得作者给这个系统起名叫做FirmSolo并不是很合适，因为作者实际上并没有用它来solo，而是结合了TriforceAFL和Firmadyne两个之前的固件分析系统一起使用。TriforceAFL是著名的安全审计团队NCC Group在2017年开发的一个基于AFL/QEMU的kernel fuzzer，而Firmadyne是本文作者之一的Manuel Egele在2016年参与的NDSS论文 Towards Automated Dynamic Analysis for Linux-based Embedded Firmware 中介绍的分析系统。作者用FirmSolo编译了1470不同的firmware固件，能够用这些固件动态加载他们收集到的56688个不同的LKM中的36178个（64%，见下表）
当然，FirmSolo也不完美，针对LKM的分析，还是很容易失败的，特别是一些符号，不管你怎么编译就是构建不出来（可能是因为私有代码？）
在FirmSolo和TriforceAFL的结合实验中，TriforceAFL成功分析了75个LKM二进制代码，并发现了19个此前未发现的bug，影响了10款现实世界的IoT设备。而在FirmSolo和Firmadyne的结合实验中，作者在15款固件中发现了NetUSB.ko这个闭源的LKM中的漏洞，在84款固件中发现了此前由TriforceAFL分析发现的漏洞。
在附录中还有一个比较有意思的内容，介绍了FirmSolo如何解决内核版本中定义的数据结构和LKM中需要的数据结构类型不一致问题的细节，感兴趣的读者可以看看：
论文：https://www.usenix.org/system/files/sec23summer_190-angelakopoulos-prepub.pdf
原文始发于微信公众号（安全研究GoSSIP）：G.O.S.S.I.P 阅读推荐 2023-01-09 FirmSolo
- 左青龙
- 微信扫一扫
-
- 右白虎
- 微信扫一扫
-
评论