基于Docker的固件模拟
概述
目前的设备模拟都需要用户人工操作,没有一个直接可用的方案,难度大成本高耗时长。而且在各大漏洞靶场中都没有集成,如:Vulfocus 开源靶场,等。本文主要讲述如何在 Docker
中搭建 Qemu
进行 system-mode
模式的固件模拟,实现易于分发开箱即用的硬件模拟环境。要是有需完善地方,请读者留言共同促进改善之。
背景
由于工作内容是物联网安全方向,通常需要购买设备进行分析,但是目前多数的设备漏洞分析只需要有固件,然后将相关程序运行即可。目前网络上通常使用 Qemu
进行固件模拟,其他的就是 Qemu
和其他环境功能 (如:nvram
)的包装器如:firmadyne
、Firmware Analysis Toolkit
、ARM-X
固件仿真框架等。
上述列举的固件模拟工具,都需要用户安装好以后,再传输固件文件系统进行模拟固件服务运行。但是,通常固件模拟总有一些小细节的错误导致失败,而且类似固件模拟成功的文章作者有可能会忽略一些细致点,导致用户找不出问题点,模拟失败。因此一直在想,要是能够将模拟成功的固件环境打包成镜像,用户获取镜像后直接运行镜像就可以获取到固件漏洞点,直接省略了繁杂的固件搭建过程。
要实现这种“开箱即用”,直接想到的便是 Docker
,它作为可直接打包其中的应用以及依赖包到一个可移植的容器,完全符合这种需求。网上查了查,现有的 Docker
中集成 Qemu
进行的固件模拟仅仅是利用 user-mode
模式(可执行二进制文件仿真,即开启固件中的单一服务)进行模拟应用运行,很多的服务的依赖包需要在system-mode
模式(固件全局仿真)下才能运行成功。
搭建过程
初步设想需解决点
根据通常 Docker 搭建Web等应用漏洞靶场的思路,即在启动 Docker 后直接访问漏洞点就可以像真正环境中一样利用。推理到固件靶场:
Docker
中需具备:模拟固件的框架,能够外部访问漏洞点,固件文件系统内部能访问外网(也就是漏洞能实际利用了),这就造成了:网络上已经有了 Docker
镜像进行 user-mode
模式的固件模拟,但是没有 system-mode
模式,可能就是因为涉及到 Qemu
中的端口转发出来及网络等因素。
需要解决:
Qemu
中模拟漏洞时,如果漏洞是通过端口进行利用的,怎样将端口转发到Docker
Qemu
能访问外网Qemu
中的服务怎么随着Docker
启动而启动,即:像 Web类的靶场,直接Docker
启动就可以将漏洞环境运行起来
搭建过程划分及流程框架图
搭建过程分为如下几步
MIPS 框架搭建--实现外网访问--端口映射
Qemu
服务随Docker
启动而启动(额外:
Qemu
同步实时更新Docker
中的文件)
本文模拟的环境案例
HG532
,CVE-2017-17215
,知识储备章节有写漏洞信息及利用脚本漏洞产生点于组件服务端口 37215 ,从数据包中获取部分信息来进行代码执行
HG532 固件文件系统类型是 mips 32位的,且格式为大端 MSB。
PoC 内容如下:
逻辑框架 Docker - Qemu - system-mode 模式的固件模拟流程图
0x01 MIPS 框架搭建--实现外网访问--端口映射
Docker version 19.03.2
中Ubuntu 18.04.4
系统 ,安装qemu-system-mips
apt-get update && apt-get install -y qemu -system-mips && apt-get clean
Qemu
使用的基础框架:https://people.debian.org/~aurel32/qemu/mips/此处映射了
Qemu
中的两个端口22、37215 qemu-system-mips -M malta -kernel vmlinux-3.2.0-4-4kc-malta -hda debian_wheezy_mips_standard.qcow2 -append "root=/dev/sda1 rw console=tty0" -device e1000,netdev=net0 -netdev user,id=net0,hostfwd=tcp::5535-:22,hostfwd=tcp::37215-:37215 -nographic
某些固件服务修改网络配置
将固件文件系统传入 Qemu
模拟环境中,尝试运行其中的 mic
服务,会发现在终端运行的 mic
进程退不出来,也就是无法掌控终端了;
在 mic
服务启动的过程中发现网络有修改,也就是意味着ip被修改了,那么转发的端口不能使用了。
使用定时任务修改网络配置
定时任务实现:修改 /etc/crontab
文件,必须要按照格式填写
0x02 固件文件系统的服务自启
解决问题: Qemu
服务随 Docker
启动而启动
启动项加入过程:
0x03 Qemu
同步实时更新 Docker
中的文件
Qemu
同步实时更新 Docker
中的文件有个小需求需要用户攻陷设备后获取 flag,也就是需要 Qemu
同步实时更新 Docker
中的 /tmp/flag
文件
解决:只要将 /tmp
目录挂载到 Qemu
中就行,使用 fat:/tmp
Qemu
中执行,加入自启动项实现:
知识储备
储备1: 端口转发
Qemu
中说明文档:https://wiki.archlinux.org/index.php?title= Qemu
储备2: Qemu联网方式
Qemu
中说明文档:https://wiki.archlinux.org/index.php?title= Qemu
储备3: Qemu 挂载 Docker中的目录
Qemu
中说明文档:https://wiki.archlinux.org/index.php?title= Qemu
挂载主机分区
储备4: Qemu的必备知识点
一篇文章有介绍 Qemu
,如下截图其中的一部分内容,详细可参考:
https://nosec.org/home/detail/4213.html
储备5: 本文涉及到的Docker知识点
网络配置使用的命令,如:
ip router
在自动运行
Docker
中Qemu
中固件文件系统中的服务成功之前,想过要是Docker
能保存当前的运行状态多方便,研究如下:Docker save
与Docker export
save 镜像,不是当前运行的而是原本的,当前运行的镜像不会保存。 export 容器,会保存,但是只是文件。Docker
镜像修改保存新镜像,docker commit
从容器中创建一个新镜像-a :提交的镜像作者
-m :提交时的说明文字
docker commit [OPTIONS] CONTAINER [REPOSITORY[:TAG]] docker commit -m="qemu-system-mips_HG532" -a="m2ayill" 553c8ce8df01 mips_huawei_hg532_success_fat_flag:v2
Dockerfile
的编写FROM
:先从本地查找镜像,若无,再从网上获取镜像FROM mips_huawei_hg532_success:latest
MAINTAINER
:描述镜像的创建者MAINTAINER m2ayill
ADD
:在执行 <源文件> 为 tar 压缩文件的话,压缩格式为 gzip, bzip2 以及 xz 的情况下,会自动复制并解压到 <目标路径>,描述镜像的创建者,先从本地查找镜像ADD <源路径1> <目标路径>
RUN
:执行后面的命令行命令RUN <命令行命令>
ENTRYPOINT
:类似于 CMD 指令,但其不会被 docker run 的命令行参数指定的指令所覆盖ENTRYPOINT ["/start.sh"]
在创建镜像时,本人使用了RUN,直接在创建过程中运行了命令 mic 导致直接卡顿,创建不了了,看完本文内容就知道。EXPOSE
:声明端口EXPOSE <端口1>
搭建中的踩坑点
0x01_1 端口转发
搭建过程中虽然进行端口转发使用的是 hostfwd ,但是初步想法有过:要实现外部访问 Docker
的端口, Docker
内部得有端口能访问,所以有两种方法实现(其实也是根据 Qemu
中的网络模式划分的):
将桥接或虚拟网卡
tap
的端口转发到Docker
内部端口Qemu
直接将端口映射到Docker
内部端口
根据知识储备1可知:user网络模式
可以实现端口转发到 Docker
,最主要的是可以访问外网,类似于 nat。
这里使用的是 user网络模式
,( 有兴趣的人,:) 可以试试 tap ,Qemu
说明文档中有写转发过程)
0x01_2 hostfwd的转发端口
刚开始尝试时,ssh转发到
Docker
的 5535 端口成功,但是 37215 死活不行,而且本文使用的案例是我使用的第二个案例,第一个案例是雄迈的 telnet 后门漏洞,其中 9527 端口也是转不出来,
设想,是不是
hostfwd
只能转发一个端口 案例推翻假设:尝试了cc8160
(第三个案例)启动的是 80 端口和 22 端口,两个端口都能使用后来一步步回想做了哪些操作:
5535 是在没有运行mic
之前,连接成功;
在运行 mic
后,5535 端口也不能使用了;
查看 mic
服务启动过程,发现 mic
服务在运行时将网络环境修改了
hostfwd
转发的端口是只要Qemu
内部有相应的端口,就可以通过hostfwd
设定的端口转发出来,也就是说,内部的服务可以在Qemu
运行后启动:
设想,ssh 端口是开机自启的,当初还以为只能是系统内部已经启动的端口才能够转出来,而运行
Qemu
后自行启动的端口无法转出 案例推翻假设:将 ssh 端口关闭后,Qemu
转发到Docker
的端口无法使用 ssh 登录了,重新启动 ssh 服务,又可以使用了
与搭建无关的:
通过
Qemu
转发到Docker
的端口,5535、37215等,其实本地是在类似监听的状态,也就是说 telnet 5535 等端口,都是属于通的状态,无法通过 telnet 来判断是否Qemu
内部的服务已经启动
0x02 “定时任务”历程
解决办法设想过如下:
放入后台,将终端释放出来,没有
nohub
命令,只能通过&
或者ctrl+z
使用
ubuntu
虚拟机+Qemu
实现的ctrl+z
放入后台,bg 的结果是 doing,&结果总是 stopped使用
Docker
+Qemu
,两种方法总是 stopped
使用 ssh 登录后的终端运行
mic
服务
案例推翻:使用 ssh 运行的 mic
服务,由于运行中断,导致运行不起来
定时任务编写过程:
/var/log/cron
crontab -e
,crontab
查看内容添加上了crontab file
,crontab
查看内容添加上了权限问题
重启服务
/etc/init.d/cron restart
无意中全局搜索
crontab
,/etc/crontab
符合平常设定定时任务的格式类型,当时脑子也呆了,下意识的直接按照文件原本的格式填写了,(第二天重新设置定时任务,死活不成功,重新走了一下流程,最终发现的原因是,/etc/crontab
填写的内容是复制过来的,没有按照原文格式写:( )
0x03 模拟攻击
到此为止,定时任务设定好,先实现: Qemu
服务手动运行起来利用转发端口到 Docker
,外部能够漏洞利用成功,手动运行mic
服务,结果:访问 ssh 成功、poc 攻击不成
分析原因( 因为过程繁琐没有在Docker中测试,使用单独的Ubuntu 虚拟机+ Qemu ):
查看 poc 在
mic
中的运行过程,尝试修改命令为date
,执行成功ssh 登录,执行 wget 有报错信息,什么都不说了,得按照格式来:
wget -g ip -l 保存路径
(-P 端口,-r 路径)
0x04 “服务自启”历程
手动运行固件服务成功后,就要解决问题: Qemu
服务随 Docker
启动而启动
当时想的很复杂, Qemu
中的固件文件系统中的服务加入启动项,涉及到两个系统,怎么实现
走了一下流程:
chroot /root/squashfs-root/ bin/sh
,进入固件shell中mic
,运行服务
尝试
chroot /root/squashfs-root/ mic
,可以运行
那就方便处理了,只要将chroot /root/squashfs-root/ mic
在启动 Qemu
时,服务同时运行起来就行,两种方法:
加入启动项
定时任务(想到的第一个办法就是定时任务,没有尝试,原因如下,其实挺后悔的,要不然早弄完了:)
设想,定时任务几乎都是随着mic服务运行后执行的,也就是在
Qemu
登录后,没有尝试登录前看看能不能执行;(为什么说Qemu
登录,在下面有写)验证:在后面通过自启项目
mic
运行后,会在Qemu
启动的过程中卡住,但是定时任务还是执行了,说明在未登录之前定时任务是可以执行的)
启动脚本第一版
尝试:
/etc/profile.d/mic_open
,只能在Qemu
登录用户后启动;/etc/init.d/mic_open
、 rd0-6 目录下都添加,不行;将脚本转成服务,加入自启项目;
使用命令加入自启项目,
update-rc.d mic_open defaults 99
,发现启动脚本有问题,根据报错信息,有了如下的第二版脚本,再次使用update-rc.d mic_open defaults 99
,加入自启项目成功。 mic_open内容如下: #!/bin/sh ### BEGIN INIT INFO # Provides: http://aaa.com # Required-Start: $local_fs $network # Required-Stop: $local_fs # Default-Start: 2 3 4 5 # Default-Stop: 0 1 6 # Short-Desc ription: mic service # Desc ription: mic service daemon ### END INIT INFO chroot /root/squashfs-root/ mic
0x05 实现“外网访问”历程
起初不知道 user模式可直接访问外网,而且 ping 执行过不能 ping 通,而且平常使用的是 tap
然后弯路开始了,其实一般都是使用 tap ,这种方法是好的,估计可以执行,在搭建 Qemu
框架就把tap设置好,然后可以访问外网,也能访问 Docker
网络,然后进行 Docker
内部的端口转发(使用 tap 不能用 hostfwd )
环境:基于(完成 Qemu
框架+定时任务修改网络+自启动服务)的 Docker
中
方式:使用的是通过 br 给 tap 设置外网访问
弯路1: Docker
禁用eth0,这网络就访问不了了, Docker
中好多没有安装,很不方便(dhclient br0
,没有 dhclient
命令),想着br设置一下就行了,就仿照 eth0 的设置成了静态,不行,
解决:网上搜了一会儿,用了 ip router
,仿照正常的eth0设置,通过 ip router add
添加 br
弯路2: 设置好了tap0,使用tap0启动 Qemu
,平常需要登录进 Qemu
修改下网络才可以使用,结果由于自启服务.mic
,在 Qemu
启动过程中直接卡顿了,ssh 也不知道 ip 不能登录
解决:网上搜了:-net tap
与 -netdi v user
,才了解到:user 网络模式
,可以联网是类似 nat
不能通过 ping
命令访问外网。
也就是无形当中,网络 已经是好的,可以访问外网。
到目前为止, Docker
实现固件模拟漏洞环境成功。
未完待续
目前已将该 Docker
的固件漏洞环境镜像上传到Vulfocus
:https://hub.docker.com/r/vulfocus/hg532-cve-2017-17215,直接拉取镜像可启动固件漏洞环境,启动 Qemu
过程需要 4-5 分钟。希望读者阅读完本文,能将更多的环境集成到 Vulfocus
。
拓展
本文使用案例的是 mips 框架,同样是适用于其他环境如:ARM、i386 等。拓展开来,Docker目前不能搭建 Windows 漏洞环境,有这种需求的可以借助本文方法实现:Docker-Qemu-Windows。
最后更新于