Theme Preview

PWN华为HG8120C光猫之后

由 李晓岚 在 2016年07月04日发表

PWN华为HG8120C光猫(一)中,怀疑ONT造成了 IPv6-in-IPv4 协议高丢包率,但是无法证明。然后在PWN华为HG8120C光猫(三)中,成功在ONT上获取了root shell,可以通过 tcpdump 来抓包,来观察 IPv6-in-IPv4 协议数据包是如何在通过ONT时被丢弃的。

网络拓扑结构

+--------+         +-----+                 +---------------+
| router |-------->| ONT |------- ... ---->| tunnel server |
+--------+         +-----+                 +---------------+
192.168.1.88       192.168.1.1             74.x.x.x
2001:xxxx::2       119.x.x.x               2001:xxxx::1

其中,路由器还充当 tunnel client 的角色。ONT使用 PPPoE 拨号到ISP获取公网IP 119.x.x.x,并做NAT到内网192.168.1.0/24。

在ONT上使用 tcpdump 抓包

静态编译链接 tcpdump, 使用PWN华为HG8120C光猫(三)中获取到的root shell,运行 ./tcpdump -i any -w ipv6-drop.pcap。通过指定选项 -i any 以便抓到ONT上所有接口的数据包。同时在路由器上运行 ping6 2001:4860:4860::8888,来产生 IPv6-in-IPv4 流量。下面就是抓取到的相关数据包:

1 IP 192.168.1.88 > 74.x.x.x: IP6 2001:xxxx::2 > 2001:4860:4860::8888: ICMP6, echo request, seq 1, length 64
2 IP 119.x.x.x > 74.x.x.x: IP6 2001:xxxx::2 > 2001:4860:4860::8888: ICMP6, echo request, seq 1, length 64
3 PPPoE  [ses 0x6f29] IP 119.x.x.x > 74.x.x.x: IP6 2001:xxxx::2 > 2001:4860:4860::8888: ICMP6, echo request, seq 1, length 64
4 PPPoE  [ses 0x6f29] IP 74.x.x.x > 119.x.x.x: IP6 2001:4860:4860::8888 > 2001:xxxx::2: ICMP6, echo reply, seq 1, length 64
5 IP 74.x.x.x > 119.x.x.x: IP6 2001:4860:4860::8888 > 2001:xxxx::2: ICMP6, echo reply, seq 1, length 64
6 IP 74.x.x.x > 192.168.1.88: IP6 2001:4860:4860::8888 > 2001:xxxx::2: ICMP6, echo reply, seq 1, length 64
7 IP 74.x.x.x > 192.168.1.88: IP6 2001:4860:4860::8888 > 2001:xxxx::2: ICMP6, echo reply, seq 1, length 64
8 PPPoE  [ses 0x6f29] IP 192.168.1.88 > 74.x.x.x: IP6 2001:xxxx::2 > 2001:4860:4860::8888: ICMP6, echo request, seq 2, length 64
9 PPPoE  [ses 0x6f29] IP 192.168.1.88 > 74.x.x.x: IP6 2001:xxxx::2 > 2001:4860:4860::8888: ICMP6, echo request, seq 3, length 64

从上面抓包数据来看,只有 seq 1 的ping收到了回复,这与路由器上 ping6 的输出结果一致。与 seq 1 相关的数据包是标号1-7号。仔细分析这7个包,正常流程是这样的:

  1. 从路由器192.168.1.88出来的数据包,目的IP是tunnel server 74.x.x.x,其中封装了IPv6流量。
  2. ONT对数据包进行NAT,将源IP改成ONT PPPoE获取的公网IP。
  3. 通过PPPoE协议将数据包封装发送到光路。到此上行流量已经离开ONT。
  4. PPPoE收到从tunnel server发出的ping echo相关的数据包。
  5. 从PPPoE解包后的IP数据包,目的IP是119.x.x.x,ONT的公网IP。
  6. ONT对数据进行NAT,将目的IP改写成192.168.1.88。
  7. 数据包从ONT Lan口去到路由器。

而非正常流量8和9,直接就将流量封装在PPPoE协议中了,但没有对其中IP流量进行SNAT转换,直接使用路由器的内网IP 192.168.1.88当做源IP,这样的数据包到达ISP后会被如何处理,我想不到。但可以肯定的是,ONT是肯定收不到数据回包了。这样的异常流程,Lan的流量根本就没有到达ONT的Lan口,就被网卡驱动程序莫名其妙的封装在PPPoE协议中,直接注入到ppp网络接口中去了。这样的功能看起来像是为ISP提供IPv6支持服务的,然而ISP并未启用IPv6,驱动没有对未启用IPv6的情况进行测试,进而导致这样的问题。

解决方案

想自行修复这样的问题,在没有任何代码的情况下,完全不知道如何下手,想了几天,但毫无头绪,只能想办法绕过。ONT还有一个上网模式是桥接,使用桥接后,ONT不进行PPPoE拨号,通过路由器来拨号上网,这样ONT连ppp网络接口都没有了,那个有bug的驱动应该不会生效了吧。那就来试试吧,使用 telecomadmin 用户web登录ONT,改成桥接模式后,路由器上使用对应用户名和密码拨号后,重新测试 ping6,再也没有了丢包的情况了。

结论

从发现问题,以为是ONT丢包,到最后使用 tcpdump 确诊,发现不是丢包,而是没有正确进行NAT,顺带还PWN了ONT,最后使用桥接绕过有bug的驱动,问题总算非完美解决了。

标签:ONTPWN路由器IPv6-in-IPv4

comments powered by Disqus