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