The Great Cannon缺陷探究之TTL篇

  前不久,The Great Cannon向Github发动了一轮DDoS攻击。攻击方式为一种中间人攻击,The Great Cannon劫持了用户和百度某服务器之间的通信,使得用户发出的请求并没有到达百度某服务器,而是直接返回给用户构造好的恶意Js脚本。用户浏览器加载恶意Js后,便会每隔两秒向Github发送一次请求。攻击流程大致如下图:

image001

图1

  更多具体的攻击细节可参阅“参考资料”中的文章。
  这篇文章中(http://www.freebuf.com/news/special/63148.html)说明了发现The Great Cannon的方法及原理,即因为返回包中的TTL(time-to-live,所有网络中的数据包中都用这个字段来表示数据包经过了几跳。每一次路由器将一个数据包发出去的时候,就会将这个字段减一。当这个字段为零的时候,数据包将会被丢弃。以防止路由器无限制发送数据包造成死循环)值发生了改变,从而判定攻击方法为中间人劫持,以及更进一步的确定了The Great Cannon的位置。image002

图2

  正是因为上图中后面几个返回包的TTL值变得与之前不一致,从而暴露了返回包已经被修改。

image003

图3

  由图3可知,一旦The Great Cannon的初始TTL值X不等于64-A,用户收到的返回包就会出现TTL值不一致的情况。TTL值发生变化的原因,做如下推测:
image004

图4

  由于每个用户所处的位置不同,到达The Great Cannon经过的路由跳数也不同,所以The Great Cannon并不知道用户和The Great Cannon之间的距离,为了使得每一个用户都能收到返回包,所以将TTL值统一设为一个较大的值。
  这样一来,用户一旦发现收到的返回包中的TTL值被修改为非正常的值,就暴露了返回包已经被劫持。继续深入研究返回包的内容之后,便可了解攻击方式及攻击手段,甚至能猜测The Great Cannon的情况。为了改进The Great Cannon,可以参考如下方法:
  正如图3中所示,要做到TTL值前后一致,应该使得X=64-A。A为The Great Cannon到百度某服务器之间的距离,并且是可知的。又可以确定百度某服务器发出的返回包的初始TTL值为64。从而可以很容易的确定X的值。之后便以这个值作为The Great Cannon发出数据包的初始TTL值来向用户发送数据包。这样一来,在用户端,就好像返回包是真正从百度某服务器发来的一样,从而做到了对攻击方式的隐藏。

参考资料:
http://www.freebuf.com/news/62288.html
http://www.freebuf.com/news/special/63148.html
http://www.freebuf.com/articles/network/65839.html
http://www.freebuf.com/news/63676.html
http://www.freebuf.com/news/63632.html

发表评论

电子邮件地址不会被公开。 必填项已用*标注