自騰訊與京東建立了戰(zhàn)略合作關(guān)系之后，筆者網(wǎng)上購(gòu)物就首選京東了。某天在家里訪問(wèn)京東首頁(yè)的時(shí)候突然吃驚地發(fā)現(xiàn)瀏覽器突然跳到了第三方網(wǎng)站再回到京東，心里第一個(gè)反應(yīng)就是中木馬了。

竟然有這樣的事，一定要把木馬大卸八塊。

原因排查

首先在重現(xiàn)的情況下抓包，京東官網(wǎng)確實(shí)返回了一段JavaScript讓瀏覽器跳轉(zhuǎn)到了yiqifa.com。

下圖是應(yīng)用層的抓包。

服務(wù)器返回的代碼導(dǎo)致跳轉(zhuǎn)，基本可以排除本地木馬，推測(cè)是網(wǎng)絡(luò)或者服務(wù)器的問(wèn)題。根據(jù)筆者的經(jīng)驗(yàn)，這種情況很大可能是鏈路上的流量劫持攻擊。當(dāng)然也不能排除京東服務(wù)器被黑的情況。

繼續(xù)排查。應(yīng)用層已經(jīng)不行了，我們要用Wireshark抓網(wǎng)絡(luò)層的包。

從Wireshark結(jié)果可以看到，網(wǎng)絡(luò)上出現(xiàn)了兩個(gè)京東的HTTP響應(yīng)。第一個(gè)先到，所以瀏覽器執(zhí)行里面的JavaScript代碼轉(zhuǎn)到了yiqifa.com；第二個(gè)HTTP響應(yīng)由于晚到，被系統(tǒng)忽略（Wireshark識(shí)別為out-of-order）。

兩個(gè)京東的HTTP響應(yīng)包，必然一真一假。快揭示真相了。

再來(lái)看看兩個(gè)HTTP響應(yīng)的IP頭。

第一個(gè)包TTL值是252，第二個(gè)包TTL值是56，而之前TCP三次握手時(shí)京東服務(wù)器的TTL值是56，故可以判斷先到的包是偽造的，真的包晚到而被系統(tǒng)忽略。

至此，確認(rèn)是鏈路上的劫持。

攻擊方式

繼續(xù)分析偽造的數(shù)據(jù)包。

偽造包的TTL值是252，也就是說(shuō)它的原始TTL值應(yīng)該是255（大于252的系統(tǒng)默認(rèn)TTL值只能是255了，一般不會(huì)修改），也就表明攻擊者的設(shè)備離我隔了3個(gè)路由；而正常的京東網(wǎng)站的HTTP響應(yīng)TTL值是56，隔了8個(gè)路由。物理上假的設(shè)備離我近，所以偽造的HTTP響應(yīng)會(huì)先到——比較有意思的是，筆者實(shí)際監(jiān)測(cè)時(shí)候發(fā)現(xiàn)也有偽造包晚到導(dǎo)致劫持失敗的情況。

推測(cè)是一個(gè)旁路設(shè)備偵聽(tīng)所有的數(shù)據(jù)包，發(fā)現(xiàn)請(qǐng)求京東首頁(yè)的HTTP請(qǐng)求就立即返回一個(gè)定制好的HTTP響應(yīng)。大致的攻擊示意圖如下。

當(dāng)時(shí)筆者推測(cè)攻擊者在鏈路上大動(dòng)干戈應(yīng)該不會(huì)只針對(duì)一個(gè)網(wǎng)站，于是就訪問(wèn)了下易迅、淘寶、天貓這些電商網(wǎng)站，結(jié)果發(fā)現(xiàn)易迅也受到同樣的攻擊。看起來(lái)這次流量劫持的目的是將電商網(wǎng)站流量導(dǎo)給返利聯(lián)盟，通過(guò)返利聯(lián)盟獲得當(dāng)前用戶成交金額的返利。

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

攻擊源定位

來(lái)看看當(dāng)時(shí)的路由結(jié)果：

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

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

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

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

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

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

一天后得到運(yùn)營(yíng)商答復(fù)：“經(jīng)核查，深圳本地沒(méi)有進(jìn)行推送，經(jīng)網(wǎng)上查詢有木馬或病毒會(huì)導(dǎo)致此現(xiàn)象，非電信網(wǎng)內(nèi)問(wèn)題，請(qǐng)進(jìn)行殺毒后再測(cè)試，謝謝”。

不過(guò)從當(dāng)天晚上起，我再在ADSL環(huán)境測(cè)試，就沒(méi)有發(fā)現(xiàn)這種流量劫持現(xiàn)象了。

攻防之道

鏈路劫持對(duì)企業(yè)和用戶都是很麻煩的，影響用戶體驗(yàn)，還泄漏敏感信息，而且還是分地域的，檢測(cè)和防御起來(lái)也相對(duì)困難。 

鏈路劫持已經(jīng)被某些人運(yùn)用的爐火純青。比如近期業(yè)界發(fā)現(xiàn)部分區(qū)域的百度聯(lián)盟廣告腳本被植入惡意JavaScript去DDoS攻擊GitHub。

騰訊歷史上也遇到過(guò)多起鏈路劫持攻擊，目的性很強(qiáng)，大部分是插廣告（少部分是釣魚(yú)和掛馬），攻擊手法各種各樣，有運(yùn)營(yíng)商的區(qū)域DNS劫持和鏈路劫持、運(yùn)營(yíng)商區(qū)域DNS Server遭到緩存投毒攻擊（利用CVE-2007-2926，非常經(jīng)典）、開(kāi)發(fā)商在路由軟件中植入劫持代碼、CDN與源通信遭到ARP攻擊、用戶PC本地木馬。當(dāng)然，這些目前都已經(jīng)解決了，也在持續(xù)監(jiān)測(cè)中。   

為了對(duì)抗鏈路劫持，很多騰訊業(yè)務(wù)也都使用了HTTPS或者私有協(xié)議，比如QQ Web登錄、QQ郵箱、理財(cái)通、Web微信、微信公眾平臺(tái)等。

DNS劫持攻擊相對(duì)容易檢測(cè)和防護(hù)。

檢測(cè)方面，用分布的點(diǎn)去進(jìn)行DNS查詢即可，發(fā)現(xiàn)運(yùn)營(yíng)商DNS結(jié)果不對(duì)就可以推動(dòng)修復(fù)。

防護(hù)方面，一種方案是使用DNSSEC（DNS Security Extensions）；騰訊、114DNS還研發(fā)了自己的方案——HttpDNS。HttpDNS不使用DNS協(xié)議而是通過(guò)HTTP協(xié)議從HttpDNS后端服務(wù)器獲取域名對(duì)應(yīng)的IP。當(dāng)然，類(lèi)似的思路我們可以實(shí)現(xiàn)一堆了：HTTPSDNS、TCPDNS、UDPDNS、ICMPDNS……

鏈路劫持相對(duì)復(fù)雜。    

檢測(cè)方面，如有客戶端，可以依靠客戶端進(jìn)行檢測(cè)；如果沒(méi)有客戶端，就具體情況具體分析了，可以在網(wǎng)頁(yè)里用JavaScript檢測(cè)頁(yè)面元素，甚至可以在全國(guó)重要城市租用ADSL探測(cè)。

另外，在機(jī)房的流量監(jiān)控設(shè)備里會(huì)發(fā)現(xiàn)異常：比如這個(gè)案例就會(huì)出現(xiàn)用戶接收了HTTP響應(yīng)后沒(méi)有回應(yīng)，然后URL中又帶了yiqifa.com的關(guān)鍵字重新訪問(wèn)主頁(yè)的情況；再比如某些設(shè)備的HTTP阻斷會(huì)向服務(wù)器發(fā)特定的RST包（我見(jiàn)過(guò)發(fā)IP Id為8888的案例）。

防護(hù)方面，這個(gè)案例只是偽造數(shù)據(jù)包，并沒(méi)有實(shí)施阻斷，所以只要客戶端的安全軟件把疑似出問(wèn)題的包（一次TCP會(huì)話中TTL值相差很大或者IPId突然跳變）攔截就可以防御。為了避免誤殺，可以攔截并休眠1秒，如果沒(méi)有同樣的數(shù)據(jù)包過(guò)來(lái)再放行。

有自己客戶端的可以走自己的私有協(xié)議，網(wǎng)站類(lèi)就困難一些，部署HTTPS吧。百度主頁(yè)近期就使用了HTTPS，不過(guò)大部分用戶還是不習(xí)慣在瀏覽器里輸“https://”，所以還是存在被劫持的風(fēng)險(xiǎn)（類(lèi)似的工具有SSLStrip）。當(dāng)然了，對(duì)抗也會(huì)隨之升級(jí)的，比如這次發(fā)現(xiàn)的GMail證書(shū)偽造事件。    

在HTTPS尚不能大規(guī)模普及的情況下，是否可以給用戶或者終端軟件提供一個(gè)規(guī)避鏈路劫持的安全服務(wù)呢？似乎是可以的。下圖是筆者構(gòu)想的一個(gè)簡(jiǎn)單的通過(guò)本地代理軟件加云服務(wù)的方式規(guī)避不安全ADSL鏈路的解決方案。

一些瀏覽器的云加速也客觀上實(shí)現(xiàn)了這個(gè)功能。對(duì)于安全性不確定的公共WiFi，也可以用類(lèi)似的方法來(lái)規(guī)避風(fēng)險(xiǎn)。

后記

希望本文對(duì)你有幫助。