百科问答小站 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




  

相关话题

  代码初学者,学到一段时间后,怎么寻找练手的项目? 
  如何看待互联网大厂程序员因厌恶编程,辞去月薪2w+的工作去当司机? 
  普通程序员用什么方法阻止别人转行抢饭碗? 
  涛思数据(TDengine)的工程师平均年龄是多少,超过35岁的程序员在纯技术驱动的公司有哪些优势? 
  如何看待程序员在 GitHub 发起抗议互联网公司实行 996 工作制网站? 
  国外的程序员是如何保养「革命的本钱」? 
  如何劝说后端开发不要拿变量命名 JSON 的key值? 
  编程领域都有哪些牛逼闪闪的「禁术」? 
  程序员的工资一直这么高吗?有没有人分析一下程序员工资在不同年代的变化及未来变化趋势? 
  刷 LeetCode 对于国内 IT 企业面试帮助大吗? 

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





© 2024-05-15 - tinynew.org. All Rights Reserved.
© 2024-05-15 - tinynew.org. 保留所有权利