Linux-某电商网站流量劫持案例分析与思考

【前言】

　　自腾讯与京东创建了战略合做关系以后，笔者网上购物就首选京东了。某天在家里访问京东首页的时候忽然吃惊地发现浏览器忽然跳到了第三方网站再回到京东，内心第一个反应就是中木马了。

　　居然有这样的事，必定要把木马大卸八块。

　　【缘由排查】

　　首先在重现的状况下抓包，京东官网确实返回了一段Java让浏览器跳转到了yiqifa.com。

　　下图是应用层的抓包。

　　

　　服务器返回的代码致使跳转，基本能够排除本地木马，推测是网络或者服务器的问题。根据笔者的经验，这种状况很大多是链路上的流量劫持攻击。固然也不能排除京东服务器被黑的状况。

　　继续排查。应用层已经不行了，咱们要用Wireshark抓网络层的包。

　　

　　从Wireshark结果能够看到，网络上出现了两个京东的HTTP响应。第一个先到，因此浏览器执行里面的Java代码转到了yiqifa.com；第二个HTTP响应因为晚到，被系统忽略（Wireshark识别为out-of-order）。

　　两个京东的HTTP响应包，必然一真一假。快揭示真相了。

　　再来看看两个HTTP响应的IP头。

　　第一个包TTL值是252，第二个包TTL值是56，而以前TCP三次握手时京东服务器的TTL值是56，故能够判断先到的包是伪造的，真的包晚到而被系统忽略。

　　

　　

　　至此，确认是链路上的劫持。

　　更多链路劫持攻击的信息能够先看看笔者以前写的文章《链路劫持攻击一二三》。

　　【攻击方式】

　　继续分析伪造的数据包。

　　伪造包的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环境测试，就没有发现这种流量劫持现象了。

　　【攻防之道】

　　链路劫持对企业和用户都是很麻烦的，影响用户体验，还泄漏敏感信息，并且仍是分地域的，检测和防护起来也相对困难。

　　链路劫持已经被某些人运用的炉火纯青。好比近期业界发现部分区域的百度联盟广告脚本被植入恶意Java去DDoS攻击GitHub。

　　腾讯历史上也遇到过多起链路劫持攻击，目的性很强，大部分是插广告（少部分是钓鱼和挂马），攻击手法各类各样，有运营商的区域DNS劫持和链路 劫持、运营商区域DNS Server遭到缓存投毒攻击（利用CVE-2007-2926，很是经典）、开发商在路由软件中植入劫持代码、CDN与源通讯遭到ARP攻击、用户PC 本地木马。固然，这些目前都已经解决了，也在持续监测中。

　　为了对抗链路劫持，不少腾讯业务也都使用了HTTPS或者私有协议，好比QQ Web登陆、QQ邮箱、理财通、Web微信、微信公众平台等。

　　DNS劫持攻击相对容易检测和防御。

　　检测方面，用分布的点去进行DNS查询便可，发现运营商DNS结果不对就能够推进修复。腾讯在2010年起就建设了DNS劫持监控系统，有兴趣的朋友能够去读下这篇文章。

　　防御方面，一种方案是使用DNSSEC（DNS Security Extensions）；腾讯、114DNS还研发了本身的方案——HttpDNS。HttpDNS不使用DNS协议而是经过HTTP协议从 HttpDNS后端服务器获取域名对应的IP。固然，相似的思路咱们能够实现一堆了：HTTPSDNS、TCPDNS、UDPDNS、ICMPDNS……

　　

　　链路劫持相对复杂。

　　检测方面，若有客户端，能够依靠客户端进行检测；若是没有客户端，就具体状况具体分析了，能够在网页里用Java检测页面元素，甚至能够在全国重要城市租用ADSL探测。

　　另外，在机房的流量监控设备里会发现异常：好比这个案例就会出现用户接收了HTTP响应后没有回应，而后URL中又带了yiqifa.com的 关键字从新访问主页的状况；再好比某些设备的HTTP阻断会向服务器发特定的RST包（我见过发IP Id为8888的案例）。

　　防御方面，这个案例只是伪造数据包，并无实施阻断，因此只要客户端的安全软件把疑似出问题的包（一次TCP会话中TTL值相差很大或者IPId忽然跳变）拦截就能够防护。为了不误杀，能够拦截并休眠1秒，若是没有一样的数据包过来再放行。

　　有本身客户端的能够走本身的私有协议，网站类就困难一些，部署HTTPS吧。百度主页近期就使用了HTTPS，不过大部分用户仍是不习惯在浏览器里输“https://”;，因此仍是存在被劫持的风险（相似的工具备SSLStrip）。固然了，对抗也会随之升级的，好比此次发现的GMail证书伪造事件。

　　在HTTPS尚不能大规模普及的状况下，是否能够给用户或者终端软件提供一个规避链路劫持的安全服务呢？彷佛是能够的。下图是笔者构想的一个简单的经过本地代理软件加云服务的方式规避不安全ADSL链路的解决方案。

　　

　　一些浏览器的云加速也客观上实现了这个功能。对于安全性不肯定的公共WiFi，也能够用相似的方法来规避风险。

　　转自:http://security.tencent.com