2017-09-05 11:06:01
阅读：649次
点赞(0)
收藏
来源： randywestergren.com
作者：360U1210592773
译者：hacker2017
预估稿费：100RMB
投稿方式：发送邮件至linwei#360.cn，或登陆网页版在线投稿
前言
由Obihai公司出品的OBi200是一个和谷歌语音集成在一起的家庭VoIP网关。它支持大多数标准VoIP功能，并且可以与几乎任何“便携式”SIP服务集成。我今年早些时候购买了一台，作为我家里的座机（无月租），到目前为止，运转的相当不错。但在完全安装之前，我决定深入了解它的工作原理。
固件分析
我插入设备并打开了Web界面。我做的第一件事是检查刷入的固件版本：
通过上图可以看到，OBi200被刷入的固件版本是3.0.1 (Build: 4492)。通过Obihai 官网发现最新版本是3.1.1 (Build: 5463EX)，显然这是一个旧版固件。这里我并不打算马上更新到新版，我准备检查一下旧版固件是否有被修补过的漏洞。
接下来我在我在Obihai官网下载了该固件。虽然并没有找到完全一致的固件版本，但是找到了一个非常接近的版本3.0.1 (Build: 4738)。用binwalk对固件进行扫描，结果如下:
通过扫描结果可以看到，该固件包含几个Squashfs文件镜像以及一个ARM文件镜像。看来一切都有希望进行进一步探索, 因此我把他们导出到我本地文件系统里进行研究。
通过文件系统，我能够更多地了解设备的底层实现。这里查看/etc/passwd文件，内容如下：
如上所示，root账户并没有被设置密码。启动脚本/etc/rc也包含一些有趣的信息，如下:
/bin/swcfg-pw0000x3800 hostnameOBi202 #hostnameFFxAV mount-tprocproc/proc #Create/varonRAMdisk mount-tramfsnone/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-tsquashfs/dev/mtdblock7/obi #Makingthe/etcdirectorypointtoMTD4 #mount-tjffs2/dev/mtdblock4/etc-osync #Makingthe/etcdirectorypointtoMTD4 #mount-tjffs2/dev/mtdblock4/scratch-osync #gatewaybegin mount-tsysfsnone/sys mkdir/var/run/ppp-p#neededbypppd mkdir/var/log/ppp-p mkdir/var/lock#neededbywvdial #echo"********Startudev" mount-n-ttmpfs-omode=0755udev/dev cp-a-f/dev0/*/dev #It'sallovernetlinknow if[-e/proc/sys/kernel/hotplug];then echo"">/proc/sys/kernel/hotplug fi #udevd--daemon #echo"startmonitor" #udevadmmonitor-e>/dev/.udev.log& #UDEV_MONITOR_PID=$! #echo"starttrigger" #udevadmtrigger #echo"startsettle" #udevadmsettle #kill$UDEV_MONITOR_PID mount-ttmpfsnone/dev/shm-osize=512K mount-tdevptsnone/dev/pts #mknod-m644/dev/urandomc19 #chownroot/dev/urandom echo"********Startsyslogd" touch/var/log/messages syslogd #gatewayend #Startnetworkdevice cd/etc #../rc.net& ../rc.net cd/ echo"===>Obi<===" cd/obi #cd/usr/local/obi ./obi&如上文件内容所示，被注释掉的一些调试/开发信息，泄露了设备的一些调试环境。在进行初始化设置后, 脚本将目录切换到包含所有原始二进制文件的/obj/目录，并启动主obi脚本 (最终是obiapp二进制文件)。
弹出SHELL
通过搜索上面的文件名，我发现了去年有篇文章披露了Obihai公司OBi1000电话产品的一系列漏洞。由于在一个PoC中提到了obiapp二进制文件，并且在Obi200中找到了类似的URI结构，所以在两个产品中似乎有一些共同的代码。我测试了我的设备上的命令注入漏洞，并确认可以重新启动设备：
接下来，我尝试启动telnet守护程序，但是经过几次尝试，我发现端口23被设备专门阻止。我最终能够得到一个在另一个端口上运行telnetd的根shell：
其他的命令注入点
我很好奇是否还有其他类似的命令注入点，因此我决定继续深入探索一下。我用IDA反汇编了obiapp二进制文件，并找到了上述checkssid请求的关键点。在附近的地方，我发现了几个不同的请求：
然后得到其他的PoC如下:
请注意，上述第二个请求的格式略有不同，这是因为进程在把参数传递给system()函数前有解码操作。
继续Root
在新版固件中似乎修补了上面披露的漏洞 (后来我证实了), 不过我想在更新固件后继续研究，看是否能对设备进行Root。 我认为获得设备的控制台访问SHELL 是我最好的选择,因此我通过检索dmesg命令的返回数据来搜索串行接口:
如上图所示，有个串行接口/dev/ttyS0-------现在只需要在电路板上找到这个调试端口就可以了。
本文的第2部分, 我将着重于描述识别和连接主板的UART引脚，以便通过控制台来访问设备。
本文由 安全客 翻译，转载请注明“转自安全客”，并附上链接。
原文链接：https://randywestergren.com/reverse-engineering-obi200-google-voice-appliance-part-1/