Theme Preview

PWN华为HG8120C光猫(一)

由 李晓岚 在 2016年05月01日发表

几星期前,家里网络更换了光猫(ONT),由HG8120R换成了HG8120C,均系华为生产,ISP提供。事后发现原来完美工作的IPv6-in-IPv4 tunnel丢包严重,达到90%以上。由于ONT是唯一变更了的设备,所以可以几乎100%确认是新的ONT HG8120C造成的丢包。于是在过去的几个星期里,PWN新ONT设备便成了我闲暇时光的主要工作,最终成功pwned,获取了root shell。

起因

更换设备后,很快发现访问IPv6出现困难,完全不能打开网页,马上使用ping6进行诊断,得到了如下很有规律的结果:

    leexiaolan@localhost $ ping6 2001:4860:4860::8888
    PING 2001:4860:4860::8888(2001:4860:4860::8888) 56 data bytes
    64 bytes from 2001:4860:4860::8888: icmp_seq=1 ttl=56 time=416 ms
    64 bytes from 2001:4860:4860::8888: icmp_seq=17 ttl=56 time=419 ms
    64 bytes from 2001:4860:4860::8888: icmp_seq=33 ttl=56 time=415 ms
    64 bytes from 2001:4860:4860::8888: icmp_seq=49 ttl=56 time=423 ms
    64 bytes from 2001:4860:4860::8888: icmp_seq=65 ttl=56 time=427 ms
    64 bytes from 2001:4860:4860::8888: icmp_seq=80 ttl=56 time=426 ms
    64 bytes from 2001:4860:4860::8888: icmp_seq=96 ttl=56 time=358 ms
    ^C
    --- 2001:4860:4860::8888 ping statistics ---
    97 packets transmitted, 7 received, 92% packet loss, time 96013ms
    rtt min/avg/max/mdev = 358.180/412.373/427.908/22.604 ms

从结果来看,链路中某个设备,每16个数据包会丢掉其中的15个,仅有一个通过,丢包率高达15/16=93.75%。得到这样的结果,考虑到tunnel server在香港,第一反应这个丢包的设备是GFW。于是换国内某云服务商的机器做tunnel server测试,ping6的目标地址就是tunnel server自身的IPv6地址,也得到了类似结果,所以,GFW的嫌疑洗清了。

猜测

这时,刚换的ONT设备的嫌疑就陡然上升了。使用设备提供的useradmin登录ONT的web管理页面,可以看到新ONT可以提供IPv6连接,但是没有启用,也无法手动配置。而IPv6这个功能在老ONT上是没有的,这进一步加大了新ONT丢弃IPv6包的嫌疑。但由于老ONT HG8120R已经被ISP回收,无法置换回去测试,所以还不能100%确定就是ONT设备丢包。即便ONT是我已知的链路中唯一更换的设备,但无法确定ISP的局端设备是否发生变化,所以需要更强的证据来佐证是新ONT丢的包。如果可以抓取到ONT光口发出去的数据包,就能……,很不幸手上没有这样的设备,买个这样的设备估计也不会很便宜。所以,剩下唯一的途径就从ONT下手,在ONT内部抓取数据包。

之前老的ONT已经PWNED,知道设备运行Linux kernel,Hisilicon(其母公司是华为)的ARM CPU。要在这样的设备上抓包,需要两个条件:一是抓包软件,二是root shell。第一个条件容易满足,交叉编译ARM处理器的tcpdump即可,我之前已经为HG8120R静态链接编译了tcpdump,应该可以直接使用,就差root shell了。

UART

以往的经验告诉我,这样的设备都有一个UART debug port,焊上对应信号线,root shell马上就有了,就像给机柜中的服务器插上显示器和键盘。只是这种方法需要拆开设备外壳包装,在电路板上找到对应针脚。一番观察之后,确定HG8120C外壳只用一颗螺丝和机壳周围一圈多个卡口固定。尽量不弄坏卡口,同时也保护好外观,小心翼翼地拆开机器外壳,取出电路板,马上就发现下图的五个针脚焊盘J4:

HG8120C UART pin

针脚定义与Practical Reverse Engineering Part 1 - Hunting for Debug Ports中相同,唯一例外就是上图中红框标注的两个电阻R231和R232缺失,而这两个电阻刚好是1和5脚,也就是Rx和Tx与电路连接的唯一通路,焊上两个100欧电阻或直接将TTL线焊接在中间两个焊点上即可。

连接,上电,启动

焊接好三根信号线,和电脑上使用的USB转串口设备连接,剩下就只用确定几个协议参数了。多数情况下除了波特率,其它参数都是默认值。波特率通常也都是使用那几个知名的速率,挨个试一遍就可以找到了。我运气很好,第一次试用115200便对了,上电启动设备,屏幕上很快就滚过下面这些信息:

    leexiaolan@localhost $ sudo screen /dev/ttyUSB0 115200

    HuaWei StartCode 2012.02 (R15C10 Apr 03 2015 - 01:24:45)

    NAND:  NAND FLASH Enter Low Driver Mode
    Nand(Hardware): 128 MiB
    startcode select the uboot to load
    the high RAM is :8080103c
    startcode uboot boot count:71872272
    use the main slave_param area from flash, the RAM data is not OK!!!
    Use the UbootA to load first
    Use the UbootA to load success

    U-Boot 2010.03 (R15C10 Jun 29 2015 - 17:21:21)

    DRAM:  128 MB
    Boot From NAND flash
    Chip Type is SD5116H
    ...
    waitForPADO: wait for PADO on wan3 10 sec.
    profile close core dump
    Press any key to get started

    telnet port:23
    Open device /dev/pts/2 OK!
    Entering character mode
    Escape character is '^]'.

    Welcome Visiting Huawei Home Gateway
    Copyright by Huawei Technologies Co., Ltd.

    Login:

提示输入用户名,尝试常见的几个用户名密码组合,最后用户名root,密码admin成功登录了。

    Login:root
    Password:
    WAP>

得到了WAP>提示符,输入shelldebugshell等命令都提示命令不存在。

    WAP>shell
    ERROR::Command is not existed

    WAP>debugshell
    ERROR::Command is not existed

Google一番后,原来是需要先使用su进入特权模式,再使用shell命令。

    WAP>su
    success!
    SU_WAP>shell

    BusyBox v1.18.4 (2015-06-27 14:02:58 CST) built-in shell (ash)
    Enter 'help' for a list of built-in commands.

    profile close core dump
    WAP(Dopra Linux) #

嗯,看到熟悉的BusyBox了,心中一阵喜悦。可惜这段喜悦没能延续很长时间,尝试输入两个命令后就彻底绝望了。

    WAP(Dopra Linux) # ls
    /bin/sh: wap.ls: not found
    WAP(Dopra Linux) # ps
    ERROR::Command is not existed

    WAP(Dopra Linux) # help
    ERROR::Command is not existed

    WAP(Dopra Linux) # ?
    boardtype.sh
    clcmcheck.sh
    customize.sh
    EquipMode.sh
    exit
    getcustominfo.sh
    getcustomize.sh
    ifconfig
    iwconfig
    ...

BusyBox是假的,还是只能执行几个有限的命令。失望之余,只能寄希望于看能不能在这三个WAP>SU_WAP>WAP(Dopra Linux) #提示符下找到任何一个可以利用的命令,于是开始了一个无聊的循环,一个命令一个命令的尝试,了解其作用,最后得出令人心塞的结论:全军覆没,没有一个可以用于执行任意代码。

如何继续

到目前为止,厂商的安全措施做得还不错,还没有发现明显可以利用的漏洞。那么,下一步该如何进行呢?仔细思考了一会,大概还有如下几个途径:

  1. 使用jTAG直接读写Flash。这种方法的不方便在于,需要处理系统本身的文件系统数据结构以及uboot对数据的校验等信息。另外,jTAG针脚比UART多,电路板上也没有明显标记,在没有CPU的数据手册情况下,很难确定针脚定义。
  2. 使用Flash编程器在线或焊下芯片离线读写Flash。这种操作Flash的方式更困难,还需要考虑Flash的OOB数据
  3. 如何中断uboot,得到uboot cli,从而修改Flash或从网络加载kernel等。
  4. 找Web管理页面或命令行参数注入漏洞。
  5. 修改firmware升级包,WAP>提示符下使用load pack升级。
  6. 厂商隐藏的其它后门。

可能还存在某些目前还未想到的方法。总之,可以尝试的方法还很多,肯定能找到行之有效方法。下篇再继续我们的PWN HG8120C之旅。

标签:ONTARM安全漏洞路由器固件PWN

comments powered by Disqus