百科问答小站 logo
百科问答小站 font logo



如何看待2020 年 3 月 26 日 GitHub 疑似遭受中间人攻击? 第1页

  

user avatar   xuan-pla 网友的相关建议: 
      

现在是2020年3月27日凌晨4点23,github主站也出现了相同的问题...

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

情况

分析

因为对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端口进行了路由,而且路由到了另一个相同目标地址的主机上了。同时也可以使用 port.ping.pe/这个工具进行在线的测试:

这里虽然看不出访问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进行回复

xuanxuanblingbling.github.io




  

相关话题

  编程代码不会,无人可请教,甚至没有标准答案,该怎么办? 
  作为程序员,你有哪些正在做的个人项目? 
  为什么学习编程第一课要学习输出"hello, world"?这是谁规定的? 
  程序员用机械键盘是为了识别敲击声还是为了宏编程所带来的方便? 
  要去柬埔寨做程序员了,可靠么? 
  为什么 Windows 系统 Program Files 这个经常用来装软件的目录,名称中有个空格? 
  现在作为优质程序员的你,大二的时候都在做些什么? 
  作为阿里云的技术用户或潜在用户,你会不会因为月饼门重新考虑阿里云服务? 
  请问各位程序员,是我的思维方式有错误吗? 
  算法工程师如何应对做算法策略的不确定性;比如没效果,这时绩效怎么保证? 

前一个讨论
有消息称比亚迪将向美国好事多供应7000万个口罩,是否属实?
下一个讨论
有没有哪个演员演的角色非常符合小说里的人物形象?





© 2024-11-08 - tinynew.org. All Rights Reserved.
© 2024-11-08 - tinynew.org. 保留所有权利