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