【攻击方式】

继续分析伪造的数据包。

伪造包的TTL值是252，也就是说它的原始TTL值应该是255(大于252的系统默认TTL值只能是255了，一般不会修改)，也就表明攻击者的设备离 我隔了3个路由；而正常的京东网站的HTTP响应TTL值是56，隔了8个路由。物理上假的设备离我近，所以伪造的HTTP响应会先到——比较有意思的 是，笔者实际监测时候发现也有伪造包晚到导致劫持失败的情况。

推测是一个旁路设备侦听所有的数据包，发现请求京东首页的HTTP请求就立即返回一个定制好的HTTP响应。大致的攻击示意图如下。

 

当时笔者推测攻击者在链路上大动干戈应该不会只针对一个网站，于是就访问了下易迅、淘宝、天猫这些电商网站，结果发现易迅也受到同样的攻击。看起来这次流量劫持的目的是将电商网站流量导给返利联盟，通过返利联盟获得当前用户成交金额的返利。

基本确认运营商有问题，但是无法确认是运营商官方故意的还是遭到黑客攻击或者是内部人士偷偷搞的。

　　【攻击源定位】

来看看当时的路由结果：

 

如果按初始TTL值为255来算，HTTP包到达本机后为252，推算出经过了3(255-252)个路由，出问题的地方就在第4个路由附近，也就是这里的119.145.220.86(属于深圳电信)。

当然了，虽然基本可以确认是第四个路由附近的问题(笔者连续几天抓包，伪造的HTTP响应包TTL值一直是252)，但是不排除设备故意构造一个初始TTL值(比如设置为254)来增加追查难度，为了严谨的治学态度及避免被攻击者迷惑，所以证据要坐实了。

定位比较简单，既然攻击设备是旁路侦听数据包，可以推测它是基于包而非状态的，我们构造被侦听的数据包(也就是直接发出访问京东首页的HTTP请求TCP包，不需要三次握手)多次发送，TTL值从1开始递增，精确地传递数据包到每一个路径上，直到出现伪造响应——没有问题的位置是不会有响应的，第一个出现 伪造响应的位置就是出问题的位置。

这个时候就需要一个数据包构造工具了，基于Python的Scapy或者Windows下的XCAP都行。

于是一路发过去，TTL值等于4的时候伪造的响应包出现了——确认就是第四跳路由出问题了，同时119.145.55.14回复了Time-to-live Exceeded的ICMP包。

 

　　【问题处理】

有了充分证据，于是整理了一个图文并茂的文档通过腾讯安全应急响应中心向深圳电信报障。

一天后得到运营商答复：“经核查，深圳本地没有进行推送，经网上查询有木马或病毒会导致此现象，非电信网内问题，请进行杀毒后再测试，谢谢”。运营商还附送了这则2013年的新闻：《淘宝易迅纷纷遭木马劫持，电脑管家独家首发专杀工具》。

不过从当天晚上起，我再在ADSL环境测试，就没有发现这种流量劫持现象了。

(责任编辑：安博涛)