亲历的一次某电商网站链路劫持分析

       故事的起因是昨天早上业务部门有同事反应唯品会的网站上不去，这不是重点，重点是这其中有业务部门领导！！！ 

      先来看下现象，访问http://www.vip.com有的时候可以访问，大多数时候跳转到了另一个域名http://click.linktech.cn/m=vipshop&a=A100211728&l=99999&l_cd1=0&l_cd2=1&tu=http%3A%2F%2Fwww.vip.com， 然后我们的上网行为管理软件将这个域名给拦截掉了，出现了下面的图片。

      

这个时候领导在第一时间机智的对我们说：可能被链路劫持了，让我们进一步查一下。于是我用工具看了一下访问时候的瀑布图，发现确实是被跳转到了另一个域名，然后去get了一个广告的页面，如下：

      

 正常的瀑布图如下：

        

为了进一步确认是被劫持了还是网站自身的跳转需求，我们进一步抓包进行了确认。可以看出来在正常的TCP三次握手后，我正常的去get了www.vip.com。

       

然而这个时候服务器给我回的包里面出现了一个location的字段，让我跳转去一个新的URL，这个url也正是上面被我们上网行为管理拦截的URL。

      

受之前这篇文章的启发http://www.freebuf.com/vuls/62561.html,继续追查TTL以及Identification的值，发现和TCP三次握手时候确实不一致，TCP握手时候的TTL返回值是50，而这个包里是112，Identification值为0。基本可以确定是这个是一个伪造的数据包了。

TCP三次握手时的TTL值：

       

       但是和那篇文章不一样的是，他在收到一个伪造包后，又收到了一个真实服务器的回包，但真实数据包由于重复被drop掉了，而我经过反复抓包以及非常细致的查看了所有的数据包，并没有发现真实服务器的回包。反而是接下来我自己PC发出了一个莫名其妙的RST ACK的包，因此我猜测，很可能是这台窃听服务器，同时向我和服务器发出了RST的包，这时我会回一个RST ACK，并且也就不会收到真实服务器的回包了，如果真是这样的话应该可以讲的通了。   

       为了进一步确定窃听设备的所在位置，我对www.vip.com进行了trace和ping，发现从trace的结果看是经过16跳，而ping的结果是返回值为50。

      这时候我产生了迟疑，因为如果真实的服务器默认的初始TTL是64的话，经过16跳不可能是返回值是50啊。这时候我注意到这个域名解析的cname是网宿CDN加速的域名，于是我找到了网宿的朋友帮忙让他们查一下这台服务器的初始TTL值，经过他们确定确实是64，而返回值为什么是50不是48，我猜测可能是非对称路由的原因吧，但是不管怎么样返回值为112的这个数据包一定时伪造的了。而112这个数值也是巧的很，如果他服务器初始的TTL是默认的128的话，128-112正好等于16跳。所以现在就只有两个可能，一是这个窃听服务器和真实服务器就在同一个IDC里面，二就是窃听者的TTL没有设置为初始值给我们排查问题进行犯罪行为进行演示。

      为了进一步对节点位置精确判断，我使用模拟发包软件去模拟发http包，由于这类窃听行为一般都是基于包的，不是基于状态的，所以当窃听服务器收到http包后会给与响应，通过模拟报文中的初始TTL值的逐渐增加是可以精确判断出位置所在的。但是不知道是不是我构造的http包有问题，还是这个窃听服务器更加狡猾（窃听到有TCP握手后才会给与响应），我经过多次尝试，从TTL值为1到16，始终都没有得到响应。至此排查陷入了瓶颈，为了尽快解决问题，我暂时停住了研究的步伐，去和唯品会以及运营商进行沟通。

       首先我先联系了唯品会的客服，然后安排了一位唯品会的IT人员和我沟通，但是这位IT人员不仅技术水平有限而且态度也不好，讲了半天也不知道我说的意思，最后他找到网宿的人，网宿告诉他是运营商劫持了，让我自己去找运营商。我说，你们上海地区有线通就这么一个CDN节点，肯定有很多人都被劫持了，会严重影响你们的用户体验，希望你们自己重视并和运营商沟通，结果他仍然不以为然。过了一会该公司客服又电话我说，原因查出来了，是我们自己原因，我擦，这种业余以及不负责任的态度让我对该电商直接路人转黑。

      为了解决问题，我只能自己去找有线通，目前资料已经提交有线通客户经理，等待有线通答复，本文也暂时告一段落，未来待续。本次对链路劫持的分析，虽然没有彻底找到劫持设备位置，但是从数据包的分析中还是收获不少经验，关于模拟http包的问题，哪位大神如果搞过的话，可以指点一下，非常感谢。