流量劫持攻擊之鏈路劫持剖析
0x00 前言
鏈路劫持屬于流量劫持攻擊的一種，在電商領域較為常見，網絡上也有不少案例。本文作者將會結合公司實際發(fā)生的案例來簡要剖析鏈路劫持有關技術。由于作者水平有限，見解淺顯在所難免，望大牛勿噴，如有描述不當之處望各路看官批評指正。
0x01 劫持案例分析
案例現(xiàn)象描述：
有用戶反饋訪問公司部分業(yè)務的URL時被重定向至公司其他業(yè)務的URL，導致用戶無法請求所需的服務，嚴重影響了用戶體驗以及用戶利益。我們第一時間通過遠控的方式復現(xiàn)了上述現(xiàn)象，并及時抓取了相關數(shù)據(jù)包以供分析，當然前期也采取了用戶電腦殺毒、開發(fā)者工具分析等方式排除了用戶端個人原因的可能性。從圖1來看，初步判斷是運營商某員工所為，意欲通過流量重定向來獲取非法的流量分成，啥意思呢，被劫持的該業(yè)務的流量要經過聯(lián)盟的該賬戶spm，使得公司再付費給聯(lián)盟，歸根結底還是為了盈利。
圖1
案例問題追蹤：
通過分析抓取的樣本數(shù)據(jù)發(fā)現(xiàn)，數(shù)據(jù)包在傳輸過程中出現(xiàn)異常TTL，目標機的正常TTL為51如圖2。
圖2
這里出現(xiàn)異常TTL值116和114，并且兩個包的ID(Identification)值相同，均為25576，如圖3和圖4，明顯是偽造的包。
圖3
圖4
另外服務器banner信息也發(fā)現(xiàn)了異常情況，公司提供的Server是Tengine的，網站編寫語言是Asp.Net的，在響應頭中應該能看到，而異常響應頭部無此信息，如圖5所示：
圖5
綜上判斷，中間鏈路發(fā)生了劫持。劫持者應該是利用在運營商內部的便利條件，在網關路由器上添加嗅探程序，嗅探明文HTTP請求數(shù)據(jù)包，拿到要劫持的數(shù)據(jù)包之后，馬上給請求者返回HTTP response(302 到其他 url)，導致用戶無法訪問正常URL。
劫持意圖分析：
通過tcp流跟蹤，發(fā)現(xiàn)劫持行為指向了一個spm=s-32528773787910-pe-f-801.psy_**2的聯(lián)盟賬戶，如圖6、圖7所示，目的在于通過付費流量來獲取利潤，這也驗證了剛開始的初步判斷。
spm可以理解為跟蹤引導成交效果數(shù)據(jù)的解決方案，可以用來評估某一個站點上某一頻道的訪問和點擊效果，以及后續(xù)引導和成交情況。
圖6
圖7
劫持影響：
用戶無法正常訪問所需業(yè)務，且致公司流量及利益損失。
解決措施：
簡單粗暴的應對措施：封賬號，相關部門投訴，當然投訴的效果不能抱太大希望。
鏈路劫持其他案例
京東：http://www.freebuf.com/vuls/62561.html
唯品會：http://www.jianshu.com/p/0397a89057a9
Github：http://www.360doc.com/content/16/0208/02/6427260_533236263.shtml
新浪：WooYun: 新浪博客疑似被流量劫持攻擊Github(目標紐約時報和某墻倉庫) ">WooYun: 新浪博客疑似被流量劫持攻擊Github(目標紐約時報和某墻倉庫)
搜狐：WooYun: 搜狐視頻疑似流量劫持攻擊Github "> WooYun: 搜狐視頻疑似流量劫持攻擊Github
百度：http://cn.nytimes.com/china/20150331/c31hack/(需翻墻)
0x02 鏈路劫持概述
鏈路層劫持是指第三方(可能是運營商、黑客)通過在用戶至服務器之間，植入惡意設備或者控制網絡設備的手段，偵聽或篡改用戶和服務器之間的數(shù)據(jù)，達到竊取用戶重要數(shù)據(jù)(包括用戶密碼，用戶身份數(shù)據(jù)等等)的目的。鏈路層劫持最明顯的危害就是帳號、密碼被竊取。最常見的就是某些設備實現(xiàn)的對非法站點的訪問攔截，以及一些地區(qū)運營商的網頁植入廣告行為。
鏈路劫持的原理就是運營商(也可能是黑客)在用戶訪問網站的時候進行竊聽，獲取用戶訪問的目的ip后，然后以這個ip為source-ip冒充網站給用戶響應，通常響應中會插入一段JS代碼，這段代碼可能會讓用戶去get一些非真實網站資源，最終可能造成真實頁面被插入廣告，被蒙層，甚至整頁面被替換，嚴重影響用戶體驗以及企業(yè)形象。由于鏈路劫持可能通常發(fā)生在last-mile，而last-mile被運營商牢牢控住，所以這對監(jiān)測以及解決問題帶來了巨大的挑戰(zhàn)。劫持原理大概如圖8所示。
圖8
目前發(fā)現(xiàn)的TCP鏈路劫持攻擊一般有兩種形式：中斷訪問型(分為單向發(fā)包和雙向發(fā)包)和替換頁面型。
中斷訪問型常見于阻止用戶訪問某些網站，如某些設備禁止用戶訪問某些站點、某地運營商的禁止ADSL多終端上網功能。其原理就是偽造服務端給用戶發(fā)RST包阻止TCP連接的建立(單向發(fā)包)。某些設備做得比較狠，在冒充服務端給用戶發(fā)RST包的同時也冒充用戶給服務端發(fā)RST包(雙向發(fā)包)。
替換頁面型常見于運營商植入廣告，也有篡改正常網頁進行SEO、騙流量的。最惡劣的莫過于釣魚，如2011年出現(xiàn)過的Gmail釣魚事件以及一些不為人知的釣魚事件。原理也簡單，就是在一個HTTP請求后偽造服務端的HTTP響應給客戶端。
0x03 鏈路劫持判斷依據(jù)
TTL：表現(xiàn)為TCP 報的 TTL 不一致甚至抖動很大。一種情況是跟正常包的ttl相差明顯，就像以上本案例中的那樣;另一種情況是通過ttl來判斷操作系統(tǒng)類型，進而間接判斷數(shù)據(jù)包是否有異常。
Identification：出現(xiàn)不符合 RFC 標準的情況。對于給定地址和協(xié)議的ip包來說，它的identification應該是公差為1的單調遞增數(shù)列。每一個IP封包都有一個16位的唯一識別碼｡當程序產生的數(shù)據(jù)要通過網絡傳送時都會被拆散成封包形式發(fā)送，當封包要進行重組的時候這個ID就是依據(jù)了｡標識字段唯一地標識主機發(fā)送的每一份數(shù)據(jù)報｡通常每發(fā)送一份消息它的值就會加1｡
Banner信息：與已知信息矛盾，如本案例中。
TTL：TTL是 Time To Live的縮寫，該字段指定IP包被路由器丟棄之前允許通過的最大網段數(shù)量。TTL是IPv4包頭的一個8 bit字段。
雖然TTL從字面上翻譯，是可以存活的時間，但實際上TTL是IP數(shù)據(jù)包在計算機網絡中可以轉發(fā)的最大跳數(shù)。TTL字段由IP數(shù)據(jù)包的發(fā)送者設置，在IP數(shù)據(jù)包從源到目的的整個轉發(fā)路徑上，每經過一個路由器，路由器都會修改這個TTL字段值，具體的做法是把該TTL的值減1，然后再將IP包轉發(fā)出去。如果在IP包到達目的IP之前，TTL減少為0，路由器將會丟棄收到的TTL=0的IP包并向IP包的發(fā)送者發(fā)送 ICMP time exceeded消息。
TTL的主要作用是避免IP包在網絡中的無限循環(huán)和收發(fā)，節(jié)省了網絡資源，并能使IP包的發(fā)送者能收到告警消息。
- //IP部首定義
- typedef struct _ip_hdr
- {
- unsigned char version : 4; //版本
- unsigned char ihl : 4; //首部長度
- unsigned char tos; //服務類型
- unsigned short tot_len; //總長度
- unsigned short id; //標志
- unsigned short frag_off; //分片偏移
- unsigned char ttl; //生存時間
- unsigned char protocol; //協(xié)議
- unsigned short chk_sum; //檢驗和
- in_addr src_addr; //源IP地址
- in_addr dst_addr; //目的IP地址
- }ip_hdr;
不同的操作系統(tǒng)環(huán)境TTL值一般是固定的一個數(shù)，常見的是16的倍數(shù)，然后每經過一個節(jié)點減1。一般來說服務器不會修改默認的TTL值，例如Linux默認的TTL為64，Windows默認的TTL為128。
下面是默認操作系統(tǒng)的TTL：
WINDOWS NT/2000 TTL：128 WINDOWS 95/98 TTL：32 UNIX TTL：255 LINUX TTL：64 WIN7 TTL：64
0x04 解決方案
(1)HTTPS
https是目前應對鏈路劫持用的較多的解決方案。https是加密協(xié)議，我們隨便抓個http包，發(fā)現(xiàn)http包里面的所有東西都是明文的，這樣就會被監(jiān)聽，而https協(xié)議是加密的。
但是光加密還不夠，因為只是application data被加密了，網絡層的信息都沒有被加密，邪惡勢力依然可以用數(shù)據(jù)包的目的ip作為源ip響應用戶。https還有另一大特點是要驗證數(shù)字證書，為了確?？蛻舳嗽L問的網站是經過CA驗證的可信任的網站。所以這就幾乎徹底杜絕了鏈路劫持的可能。
但是https也不是如此完美，雖然https解決了諸多安全問題，但是對性能也有著比較大的影響。一是用戶要從http跳轉到https，并且要多幾次 TLS的握手，這會消耗一定的時間;二是服務器的壓力也會增加。除此之外如果使用全站的https，所有頁面里面的嵌入資源都要改成https，APP的程序也要進行相應的修改，CDN的所有節(jié)點也必須都支持https并且導入證書。所以全站https并不是一件容易的事情，國外的Google、 Facebook、Twitter早已支持全站https，但目前國內大多數(shù)公司都沒有采用全站https的方式。全站https應該是未來互聯(lián)網的趨勢，關于全站https請參考資料【5】，這里不詳細闡述了。
(2)加強監(jiān)控與檢測
目前網上也有一些鏈路劫持檢測方法，如使用libpcap判斷鏈路層劫持，其原理是在鏈路層劫持的設備缺少仿造協(xié)議頭中ttl值的程序(或者說，偽造流量要優(yōu)先真實流量到達客戶電腦，所以沒有機會去偽造ttl值)。電腦每收到一個數(shù)據(jù)包，便交給程序，如果判斷某一IP地址流量的ttl值與該IP前一次流量的ttl值不同且相差5以上，便判定此次流量為在鏈路層中偽造的。有關代碼請參考【6】。
(3)其他/產品
目前騰訊做的比較領先，有鏈路劫持檢測的相關發(fā)明專利。
0x05總結
鏈路層劫持較為底層，而且很多涉及運營商行為，所以不可能從根本上來防止(或者找到運營商，或者抓住黑客，當然運營商你是戰(zhàn)勝不了的你懂得)。個人認為應對鏈路劫持一般可以考慮幾個維度：業(yè)務層面、技術層面。所有的安全都是為業(yè)務服務的，在確保業(yè)務的前提下，做好安全防護措施。最重要的是技術層面加強有效檢測、監(jiān)控，包括對有關攻擊技術的研究、對日志流量等數(shù)據(jù)的分析。當然，對企業(yè)來講，我們只能夠盡量做好自身，對于我們不可控的因素往往無能為力?？傊瑥V域網一點都不安全，所以敏感信息傳輸一定要加密，還要高強度加密。
就到這里，請各位看官批評指正。
0x06 參考文獻
【1】：http://security.tencent.com/index.php/blog/msg/10
【2】：http://www.freebuf.com/vuls/62561.html
【3】：http://drops.wooyun.org/tips/11682
【4】：http://drops.wooyun.org/tips/127
【5】：http://blog.jobbole.com/78042/
【6】：http://3.1415926.science/%E7%BC%96%E7%A8%8B%E7%AE%97%E6%B3%95/2015/08/02/libpcap%E6%A3%80%E6%B5%8B%E9%93%BE%E8%B7%AF%E5%B1%82%E5%8A%AB%E6%8C%81/
