電商網(wǎng)站流量劫持案例分析與思考（二）

• 作者：新網(wǎng)
• 來源：新網(wǎng)
• 瀏覽：100
• 2018-03-16 17:35:39

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

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

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

攻擊源定位

來看看當時的路由結果：

如果按初始TTL值為255來算，HTTP包到達本機后為252，推算出經(jīng)過了3(255-252)個路由，出問題的地方就在第4個路由附近，也就是這里的119.145.220.86(屬于深圳電信)。

當然了，雖然基本可以確認是第四個路由附近的問題(筆者連續(xù)幾天抓包，偽造的HTTP響應包TTL值一直是252)，但是不排除設備故意構造一個初始TTL值(比如設置為254)來增加追查難度，為了嚴謹?shù)闹螌W態(tài)度及避免被攻擊者迷惑，所以證據(jù)要坐實了。

定位比較簡單，既然攻擊設備是旁路偵聽數(shù)據(jù)包，可以推測它是基于包而非狀態(tài)的，我們構造被偵聽的數(shù)據(jù)包(也就是直接發(fā)出訪問京東首頁的HTTP請求TCP包，不需要三次握手)多次發(fā)送，TTL值從1開始遞增，精確地傳遞數(shù)據(jù)包到每一個路徑上，直到出現(xiàn)偽造響應——沒有問題的位置是不會有響應的，第一個出現(xiàn)偽造響應的位置就是出問題的位置。

這個時候就需要一個數(shù)據(jù)包構造工具了，基于Python的Scapy或者Windows下的XCAP都行。

于是一路發(fā)過去，TTL值等于4的時候偽造的響應包出現(xiàn)了——確認就是第四跳路由出問題了，同時119.145.55.14回復了Time-to-live Exceeded的ICMP包。

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