当前位置:安全客 >> 知识详情

【技术分享】逆向集成在谷歌语音程序中的OBi200固件: 第一部分

2017-09-05 11:06:01 阅读:7404次 收藏 来源: randywestergren.com 作者:360U1210592773

http://p1.qhimg.com/t012170f7f0fd15ea96.png

译者:hacker2017

预估稿费:100RMB

投稿方式:发送邮件至linwei#360.cn,或登陆网页版在线投稿


前言


由Obihai公司出品的OBi200是一个和谷歌语音集成在一起的家庭VoIP网关。它支持大多数标准VoIP功能,并且可以与几乎任何“便携式”SIP服务集成。我今年早些时候购买了一台,作为我家里的座机(无月租),到目前为止,运转的相当不错。但在完全安装之前,我决定深入了解它的工作原理。

http://p8.qhimg.com/t0190ba9db4ce70cd40.png


固件分析


我插入设备并打开了Web界面。我做的第一件事是检查刷入的固件版本:

http://p8.qhimg.com/t01e0f8c1b08b4dcbe4.png

通过上图可以看到,OBi200被刷入的固件版本是3.0.1 (Build: 4492)。通过Obihai 官网发现最新版本是3.1.1 (Build: 5463EX),显然这是一个旧版固件。这里我并不打算马上更新到新版,我准备检查一下旧版固件是否有被修补过的漏洞。

接下来我在我在Obihai官网下载了该固件。虽然并没有找到完全一致的固件版本,但是找到了一个非常接近的版本3.0.1 (Build: 4738)。用binwalk对固件进行扫描,结果如下:

http://p1.qhimg.com/t0162a3588f03127703.png

通过扫描结果可以看到,该固件包含几个Squashfs文件镜像以及一个ARM文件镜像。看来一切都有希望进行进一步探索, 因此我把他们导出到我本地文件系统里进行研究。

http://p1.qhimg.com/t01db46907b6dffb371.png

通过文件系统,我能够更多地了解设备的底层实现。这里查看/etc/passwd文件,内容如下:

http://p4.qhimg.com/t01f66c30b97c18beb1.png

如上所示,root账户并没有被设置密码。启动脚本/etc/rc也包含一些有趣的信息,如下:

/bin/swcfg -pw 0 0 0 0x3800
hostname OBi202
#hostname FFxAV
mount -t proc proc /proc
# Create /var on RAM disk
mount -t ramfs none /var
mkdir /var/lib
mkdir /var/run
mkdir /var/log
mkdir /var/ppp
mkdir /var/tmp
cp -p /etc/ppp.ori/* /var/ppp
touch /var/tmp/resolv.conf
# 
#mount -t squashfs /dev/mtdblock7 /obi
# Making the /etc directory point to MTD4
# mount -t jffs2 /dev/mtdblock4 /etc -o sync
# Making the /etc directory point to MTD4
# mount -t jffs2 /dev/mtdblock4 /scratch -o sync
 
# gateway begin
mount -t sysfs none /sys
 
mkdir /var/run/ppp -p # needed by pppd
mkdir /var/log/ppp -p
mkdir /var/lock # needed by wvdial
 
#echo "******** Start udev"
mount -n -t tmpfs -o mode=0755 udev /dev
cp -a -f /dev0/* /dev
# It's all over netlink now
if [ -e /proc/sys/kernel/hotplug ]; then
echo "" > /proc/sys/kernel/hotplug
fi
#udevd --daemon
#echo "start monitor"
#udevadm monitor -e >/dev/.udev.log &
#UDEV_MONITOR_PID=$!
#echo "start trigger"
#udevadm trigger
#echo "start settle"
#udevadm settle
#kill $UDEV_MONITOR_PID
 
mount -t tmpfs none /dev/shm -o size=512K
mount -t devpts none /dev/pts
 
#mknod -m 644 /dev/urandom c 1 9
#chown root /dev/urandom
 
echo "******** Start syslogd"
touch /var/log/messages
syslogd
 
# gateway end
 
# Start network device
cd /etc
#. ./rc.net &
. ./rc.net
cd /
 
echo "===> Obi <==="
cd /obi
#cd /usr/local/obi
./obi &

如上文件内容所示,被注释掉的一些调试/开发信息,泄露了设备的一些调试环境。在进行初始化设置后, 脚本将目录切换到包含所有原始二进制文件的/obj/目录,并启动主obi脚本 (最终是obiapp二进制文件)。

http://p4.qhimg.com/t014f67ff261965b018.png


弹出SHELL


通过搜索上面的文件名,我发现了去年有篇文章披露了Obihai公司OBi1000电话产品的一系列漏洞。由于在一个PoC中提到了obiapp二进制文件,并且在Obi200中找到了类似的URI结构,所以在两个产品中似乎有一些共同的代码。我测试了我的设备上的命令注入漏洞,并确认可以重新启动设备:

http://p2.qhimg.com/t01fd7cd35d34de7145.png

接下来,我尝试启动telnet守护程序,但是经过几次尝试,我发现端口23被设备专门阻止。我最终能够得到一个在另一个端口上运行telnetd的根shell:

 http://p5.qhimg.com/t0125c1749727e68fe9.png

http://p2.qhimg.com/t0133daff7313a7a446.png


其他的命令注入点


我很好奇是否还有其他类似的命令注入点,因此我决定继续深入探索一下。我用IDA反汇编了obiapp二进制文件,并找到了上述checkssid请求的关键点。在附近的地方,我发现了几个不同的请求:

http://p7.qhimg.com/t012ba1806827cd2d71.png

然后得到其他的PoC如下:

http://p6.qhimg.com/t010c29e1767dd4ced5.png

http://p3.qhimg.com/t0173f80136ea5f7f03.png

请注意,上述第二个请求的格式略有不同,这是因为进程在把参数传递给system()函数前有解码操作。


继续Root


在新版固件中似乎修补了上面披露的漏洞 (后来我证实了), 不过我想在更新固件后继续研究,看是否能对设备进行Root。 我认为获得设备的控制台访问SHELL 是我最好的选择,因此我通过检索dmesg命令的返回数据来搜索串行接口:

http://p8.qhimg.com/t01f05f5893c191882e.png

如上图所示,有个串行接口/dev/ttyS0-------现在只需要在电路板上找到这个调试端口就可以了。

http://p1.qhimg.com/t016b3490eaaa0274c2.png

本文的第2部分, 我将着重于描述识别和连接主板的UART引脚,以便通过控制台来访问设备。


本文由 安全客 翻译,转载请注明“转自安全客”,并附上链接。
原文链接:https://randywestergren.com/reverse-engineering-obi200-google-voice-appliance-part-1/

参与讨论,请先 | 注册 | 匿名评论
发布
用户评论
无任何评论