软件漏洞和对应的利用程序现在已经非常常见了。幸运的是近几年对于漏洞的响应速度和补丁的更新时间也有了显著提高。但是在嵌入式设备的领域，由于固件升级需要用户下载一个新的固件包，然后升级设备才能解决存在的问题，所以嵌入式设备通常都是使用了比较老的操作系统和软件，没有及时更新到安全的新版本。

但是由于嵌入式设备为了省电的原因通常都是使用RISC架构的CPU，比如ARM和MIPS。而目前的大部分exploit都是针对X86的，针对RISC的POC相对较少也导致嵌入式设备的安全没有得到足够的重视。

本篇博客介绍将一个已知的x86的exploit修改成适用于mips架构的过程。分析对象为netgear WNR2200路由器。

固件分析

为了寻找合适的exploit，需要先对固件进行分析。从网上可以下载到
(version 1.0.1.96) 版本的固件，解压之后发现是个img后缀的文件。使用binwalk进行分析如下：

DECIMAL       HEXADECIMAL     DESCRIPTION
--------------------------------------------------------------------------------
192           0xC0            Squashfs filesystem, big endian,
version 3.0, size: 6033818 bytes,{jump-to-offset:6033818}{file-size:6033818}
1379 inodes, blocksize: 65536 bytes, created: Thu Mar 26 03:33:52 2015
336044        0x520AC         LZMA compressed data, properties:
0x5D, dictionary size: 8388608 bytes, uncompressed size: 2740358 bytes

根据分析结果，binwalk识别出在这个文件中包含一个squashFS格式的文件系统。使用unsquashfs工具进行分析。命令为
“unsquashfs –s”

Reading a different endian SQUASHFS filesystem on C0.squashfs
Found a valid big endian SQUASHFS 3:0 superblock on C0.squashfs.
Creation or last append time Thu Mar 26 03:33:52 2015
Filesystem size 5892.40 Kbytes (5.75 Mbytes)
Block size 65536
Filesystem is not exportable via NFS
Inodes are compressed
Data is compressed
Fragments are compressed
Always_use_fragments option is not specified
Check data is not present in the filesystem
Duplicates are removed
Number of fragments 101
Number of inodes 1379
Number of uids 1
Number of gids 0

这也确认了固件文件中确实存在一个有效的SquashFS格式的文件系统。然后尝试进行解压，程序报错。

Reading a different endian SQUASHFS filesystem on C0.squashfs
Parallel unsquashfs: Using 8 processors
gzip uncompress failed with error code -3
read_block: failed to read block @0x5c0f6d
read_fragment_table: failed to read fragment table block
FATAL ERROR:failed to read fragment table

通过对这个错误信息进行调查分析，得知可能是使用了非标准的squashfs进行的压缩。我下载了最新版的SquashFS工具，重新进行编译。但是还是解压失败。更进一步的分析发现Firmware Mod Kit这个工具可能可以解压这个固件，虽然FMK这个工具好久不更新了。最后使用FMK的unsquashfs_all脚本，成功解压了固件。程序识别出，固件使用的squashfs版本为"./src/squashfs-3.0/mksquashfs-lzma”。

解压之后发现是一个基于OpenWRT的linux系统。老的Netgear路由器通过发送一个特定的包可以打开telent，具体的技术分析参考。连上telnet之后可以获得OpenWRT的版本为Kamikaze。

BusyBox v1.4.2 (2013-12-23 15:48:24 CST) Built-in shell (ash)
Enter 'help' for a list of built-in commands.

 _______                     ________        __ 
|       |.-----.-----.-----.|  |  |  |.----.|  |_ 
|   -   ||  _  |  -__|     ||  |  |  ||   _||   _| 
|_______||   __|_____|__|__||________||__|  |____|
         |__| W I R E L E S S   F R E E D O M
KAMIKAZE (7.09)
-----------------------------------
 - 10 oz Vodka       Shake well with ice and strain
 - 10 oz Triple sec  mixture into 10 shot glasses.
 - 10 oz lime juice  Salute!
---------------------------------------------------
root@WNR2200:/#

其他的版本信息

很幸运，samba和linux kernel的版本都很低，更容易找到相对应的漏洞利用。

虚拟机运行samba进程

现在我们有了整个解压之后的虚拟机固件，第一步是想在qemu虚拟机中运行起来，当然我们选择只是虚拟运行samba进程。

首先需要安装qemu-static相关的程序。然后把“qemu-mips-static”复制到固件的根目录，之后使用chroot切换到固件的根目录执行。命令如下：

    “sudo chroot . ./qemu-mips-static -g 5656 ./usr/sbin/smbd -i -d 10 > fileout.txt”

具体解释一下这个命令：

1，chroot到固件的目录下，这样samba就可以认为固件目录是文件根目录。可以加载相关的lib库文件。

2，使用qemu虚拟运行samba。g参数是开启gdb调试，监听在5656端口。

3，d参数是设置调试模式为最高10。这样可以输出更多的调试信息。

4，重定向输出信息到文件里，方便后期查看。

运行这个文件的时候，会遇到一些问题。提示samba找不到smb.conf文件。在正常运行的路由器里查看，在/tmp目录有一些配置文件，但是在解压出来的固件里这个目录是空白的。可见这些文件是系统启动的时候，动态创建的。所以我们需要手动创建这些缺失的文件。

主要涉及到以下文件：

/etc/init.d/samba 这个文件会动态创建所需要的目录，复制配置到/tmp目录。然后执行下面的2个程序。

/usr/sbin/update_user 一个bash脚本。在/tmp/passwd文件中写入用户信息。

/usr/sbin/update_smb 一个二进制文件。更新tmp目录下的smb.conf配置信息。

bash脚本中的命令，可以手动一条条的执行。二进制文件使用 qemu-mips-static 模拟执行。最后检查/etc/目录中的相关软链接是否正确指向到了正确的文件。这时最开始的命令就可以正确执行了。

寻找漏洞

对应的samba版本的源代码可以在这里下载 。通过查找对应版本存在的CVE发现一个典型的堆溢出漏洞。这个数据中有一个数值用来分配缓冲区，然后程序利用第二个数值来解组数据，写进缓冲区。如果第一个数值小于第二个数值就会导致堆溢出漏洞。

这个漏洞的编号是CVE-2007-2446。samba使用一个自定义的堆分配器talloc。talloc使用树形结构分配内存。在树形结构的任何一个节点都可以释放这个和他的子节点。为了实现这个特性，talloc实现了一个自定义的释放程序，他的指针保存在堆的元数据上，可以通过溢出覆盖。当一个chunk被释放的时候，通过覆盖堆的元数据可以实现任意代码执行。

已经有个x86的metasploit利用模块。这会对我们想在MIPS目标上实现漏洞利用有比较大的帮助。

动态调试

现在我们已经已经可以用qemu虚拟机运行samba程序。使用IDA加载samba二进制文件，然后使用debugger模块可以进行远程调试。

一开始调试我们就遇到了一个问题。IDA直接展示了进程的整个内存空间的扁平视图，但是IDA并没有正确识别出我们的二进制文件中的起始位置。这导致在内存视图中所有的符号都没有关联到正确的位置，甚至IDA都无法识别哪些区域是数据哪些区域是代码。在这样的环境中调试是比较困难的，因为我们无法再感兴趣的函数上断点，也无法知道当前运行的是哪个函数。下图展示了IDA加载了进程之后的内存布局

我一开始推测IDA停在的这个初始的点是在smbd的二进制程序中。但是通过比较smbd的main函数和二进制文件的入口点发现都不是。在这个断点处选取一些指令进行搜索，在smbd中却没有找到对应的结果。这让我觉得这段代码可能并不在smbd中。

[招生]科锐逆向工程师培训(2025年3月11日实地，远程教学同时开班, 第52期)！