电商网站流量劫持案例分析与思考（二）

发布时间：2022-05-14 01:59:42 作者：来源：浏览量（2174 ）

摘要：当时据我推出，应该是光面撒网，应该不是独一事件，于是就访问了下易迅、淘宝、天猫这些电商网站，结果发现易迅也受到同样的攻击。看起来这次流量劫持的目的是将电商网站流量导给返利联盟，通过返利联盟获得当前用户...

当时据我推出，应该是光面撒网，应该不是独一事件，于是就访问了下易迅、淘宝、天猫这些电商网站，结果发现易迅也受到同样的攻击。看起来这次流量劫持的目的是将电商网站流量导给返利联盟，通过返利联盟获得当前用户成交金额的返利。

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

攻击源定位

来看看当时的路由结果：

如果按初始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包。

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