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

发表于 | 分类于 |

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

情况

image

分析

因为对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

image

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

image

经过网友的提示，知道了工具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

image

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

image

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

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

image

诡异的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值：

image

如此诡异的动作应该是墙吧。数据包: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端口：

image

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

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

其他细节

参考这个回答有如下细节，记住：魔鬼隐藏在细节中

作者：某某
链接：https://www.zhihu.com/question/382702036/answer/1107409295
来源：知乎
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。

  • 只言事实，不做评论。目前已知如下几点，如有新发现或事实错误，欢迎于评论区补充。
  • 请勿擅自推测缘由访问
  • github.io 发现证书错误，server 发过来的证书为自签名证书
  • 海外服务器访问正常
  • 查看DNS解析无误忽略不信任的证书，可以返回正确结果（速度很慢，白天时而无法响应，凌晨恢复，疑服务器过载）
  • ping 与 traceroute 正常
  • 路由属于网络层，tcp 属于传输层。理论上路由与端口无关
  • http ip 访问正常（返回 404）
  • tcpping github.io:80 延迟 140ms，tcpping github.io:443 延迟 20ms
  • 中美光速延迟约 60 ms
  • 于不同地区 tcp traceroute 443 端口，在本地 isp 下一层即跳转至所谓的 github.io 服务器
  • tcp traceroute 80 端口则会经过日本 ntt 再至美国
  • 于不同地区 tcpping，大概据北京越远延迟越高（相关性较弱）
  • 在北京 tcpping 延迟低至 4 毫秒
  • 以光速计，4 毫秒延迟对应数百公里
  • 即使在国内访问，GitHub Page 的 domain fronting 功能仍然正常运转
  • 如 curl -v -k https://185.199.110.153/ -H ‘Host: www.cctv.com’
  • 以其他信道向 github.io 443 端口发送去程数据包，回程数据包无法收到
  • 同样方法向 80 端口或其他 ip 发生去程数据包，可收到回复
  • 以类似现象的 cloudflare 某节点测试，查看 cdn-cgi/trace，发现 src ip 为正确地址

友情分析