2020年3月26日国内HTTPS访问GithubPage劫持事件分析

我猜这么诡异的动作，应该是墙，然后用iptables尝试复现了劫持的情景

情况

• Github pages 的 HTTPS 是不是出问题了？
• 如何看待2020 年 3 月 26 日 GitHub 疑似遭受中间人攻击？
• 如何看待GitHub pages在20年3月26日被大范围中间人攻击还留下了QQ号？

分析

因为对DNS不是很懂，根据网友的信息，这次事件跟DNS应该没啥关系，所以相信以下4个ip地址是正确的：

github.io.		3600	IN	A	185.199.108.153
github.io.		3600	IN	A	185.199.111.153
github.io.		3600	IN	A	185.199.109.153
github.io.		3600	IN	A	185.199.110.153

尝试ping以下自己的站点，TTL为51，比较稳定：

➜  ~ ping xuanxuanblingbling.github.io
PING xuanxuanblingbling.github.io (185.199.108.153): 56 data bytes
64 bytes from 185.199.108.153: icmp_seq=0 ttl=51 time=104.540 ms
64 bytes from 185.199.108.153: icmp_seq=1 ttl=51 time=98.988 ms
64 bytes from 185.199.108.153: icmp_seq=2 ttl=51 time=98.148 ms
64 bytes from 185.199.108.153: icmp_seq=3 ttl=51 time=104.147 ms
^C
--- xuanxuanblingbling.github.io ping statistics ---

用curl访问目标站点80端口： curl http://xuanxuanblingbling.github.io/ ，TTL也为51

但是如果访问目标站点443端口，无论是通过浏览器访问还是curl后跟https，SYN的ACK回复的TTL均为57：

经过网友的提示，知道了工具mtr，全称my traceroute，在mac和zsh的环境下会有一点环境变量的问题： Mac 下使用 MTR 路由工具 ，使用如下命令：

➜  sudo mtr xuanxuanblingbling.github.io
➜  sudo mtr xuanxuanblingbling.github.io --tcp -P 80
➜  sudo mtr xuanxuanblingbling.github.io --tcp -P 443

可以看到ICMP的ping包和访问tcp80的包到达目的地都是14跳，而访问tcp443的包到达目的地的包都是8跳，57-51=14-8=6。所以可以看出，访问同一个ip地址的不同的端口的包，在219.158.105.237后分道扬镳了。这个地址能被这个 工具 找到的原因是，这个工具可以发送TTL依次递增的TCP包，常用的traceroute只能发送TTL依次递增的ICMP包。

路由属于网络层，tcp 属于传输层。理论上路由与端口无关。不过，若将这个结果看做路由，这里就是针对TCP443端口进行了路由，而且路由到了另一个相同目标地址的主机上了。同时也可以使用 http://port.ping.pe/ 这个工具进行在线的测试：

• http://port.ping.pe/xuanxuanblingbling.github.io:80
• http://port.ping.pe/xuanxuanblingbling.github.io:443

这里虽然看不出访问80与访问443的路径差异，但是可以看出443端口在某些网络上压根就连不上：

诡异的TTL

所以可以看出icmp和tcp80的包都应该是到达了真正的github的服务器并且得到了响应，那么访问tcp443的数据包，到底是谁回复的呢？我们通过curl请求一个包仔细分析，有意思了：

curl https://xuanxuanblingbling.github.io/

总共是12个包：

1. TCP握手，3个
2. client server各自hello和ACK，4个
3. client发不认识的CA并且RST，2个
4. server回以上的ACK，3个

server总共回了6个包，这6个包里有4个不一样的ttl值：

如此诡异的动作应该是墙吧。数据包: 2020-03-27-github-io-443.pcapng

复现

中间人也好，TCP阻断也好。这些词都没有说明，我现在访问的目标ip真的是 185.199.108.153 ，在wireshark中看到的回包中的IP也是 185.199.108.153 。但我们知道这个回包并不是真正的 185.199.108.153 回复的，也就是说有人伪造了回包中的源IP。这个技术怎么实现呢？其实用iptables就能实现，首先在虚拟机的ubuntu进行如下配置，注意这里的ens33是网卡名，每个主机不同：

sysctl -w net.ipv4.ip_forward=1 # 开启路由器转发
sudo iptables -F -t nat         # 清空nat表
sudo iptables -t nat -L         # 查看nat表
sudo iptables -t nat -A PREROUTING -i ens33 -p tcp --dport 443 -j REDIRECT --to-port 8080 # 使用PREROUTING链将所有发往tcp443的包转发到本地8080端口
echo "hello xuanxuan" | nc -l 8080 # 在本地8080端口监听

然后在另一台windows虚拟机中安装好nc，并且把网关配置成ubuntu的ip地址，然后通过nc访问目标的443端口：

发现这个数据包： 2020-03-27-iptables-443.pcapng 的确是源IP被伪造了，而且我并没有在任何一张网卡上设置IP地址为： 185.199.108.153 ，所以这个回复hello xuanxuan的数据包的源IP是iptables自己填写的，即iptables本身就能实现源地址伪造的功能。所以如果在骨干路由器的节点上进行了类似的操作就可以达到这次的效果，不过可以看出我们这里模拟的TTL还是规律的，至于现实中为什么会出现TTL如此诡异的情况？后面到底还做了什么手脚？我不知道。有的网友说用了BGP FlowSpec这个技术，我也不是很懂。不过我认为技术上是：

1. 针对不同端口进行了类似路由的处理
2. 且伪造了源IP进行回复