電商網站流量劫持案例分析與思考（二）

• 作者：新網
• 來源：新網
• 瀏覽：100
• 2018-03-16 17:35:39

當時據我推出，應該是光面撒網，應該不是獨一事件，于是就訪問了下易迅、淘寶、天貓這些電商網站，結果發現易迅也受到同樣的攻擊。看起來這次流量劫持的目的是將電商網站流量導給返利聯盟，通過返利聯盟獲得當前用戶成交金額的返利。

當時據我推出，應該是光面撒網，應該不是獨一事件，于是就訪問了下易迅、淘寶、天貓這些電商網站，結果發現易迅也受到同樣的攻擊。看起來這次流量劫持的目的是將電商網站流量導給返利聯盟，通過返利聯盟獲得當前用戶成交金額的返利。

基本確認運營商有問題，但是無法確認是運營商官方故意的還是遭到黑客攻擊或者是內部人士偷偷搞的。

攻擊源定位

來看看當時的路由結果：

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

有了充分證據，于是整理了一個圖文并茂的文檔通過騰訊安全應急響應中心向深圳電信報障。