作者:
an0nym0u5
·
2016/03/14 14:29
0x00 前言
鏈路劫持屬於流量劫持攻擊的一種,在電商領域較為常見,網路上也有不少案例。本文作者將會結合公司實際發生的案例來簡要剖析鏈路劫持有關技術。由於作者水平有限,見解淺顯在所難免,望大牛勿噴,如有描述不當之處望各路看官批評指正。
0x01 劫持案例分析
案例現象描述:
有使用者反饋訪問公司部分業務的URL時被重定向至公司其他業務的URL,導致使用者無法請求所需的服務,嚴重影響了使用者體驗以及使用者利益。我們第一時間透過遠控的方式復現了上述現象,並及時抓取了相關資料包以供分析,當然前期也採取了使用者電腦防毒、開發者工具分析等方式排除了使用者端個人原因的可能性。從圖1來看,初步判斷是運營商某員工所為,意欲透過流量重定向來獲取非法的流量分成,啥意思呢,被劫持的該業務的流量要經過聯盟的該賬戶spm,使得公司再付費給聯盟,歸根結底還是為了盈利。
圖1
案例問題追蹤:
透過分析抓取的樣本資料發現,資料包在傳輸過程中出現異常TTL,目標機的正常TTL為51如圖2。
圖2
這裡出現異常TTL值116和114,並且兩個包的ID(Identification)值相同,均為25576,如圖3和圖4,明顯是偽造的包。
圖3
圖4
另外伺服器banner資訊也發現了異常情況,公司提供的Server是Tengine的,網站編寫語言是Asp.Net的,在響應頭中應該能看到,而異常響應頭部無此資訊,如圖5所示:
圖5
綜上判斷,中間鏈路發生了劫持。劫持者應該是利用在運營商內部的便利條件,在閘道器路由器上新增嗅探程式,嗅探明文HTTP請求資料包,拿到要劫持的資料包之後,馬上給請求者返回HTTP response(302 到其他 url),導致使用者無法訪問正常URL。
劫持意圖分析:
透過tcp流跟蹤,發現劫持行為指向了一個spm=s-32528773787910-pe-f-801.psy_**2的聯盟賬戶,如圖6、圖7所示,目的在於透過付費流量來獲取利潤,這也驗證了剛開始的初步判斷。
spm可以理解為跟蹤引導成交效果資料的解決方案,可以用來評估某一個站點上某一頻道的訪問和點選效果,以及後續引導和成交情況。
圖6
圖7
劫持影響:
使用者無法正常訪問所需業務,且致公司流量及利益損失。
解決措施:
簡單粗暴的應對措施:封賬號,相關部門投訴,當然投訴的效果不能抱太大希望。
鏈路劫持其他案例
0x02 鏈路劫持概述
鏈路層劫持是指第三方(可能是運營商、駭客)透過在使用者至伺服器之間,植入惡意裝置或者控制網路裝置的手段,偵聽或篡改使用者和伺服器之間的資料,達到竊取使用者重要資料(包括使用者密碼,使用者身份資料等等)的目的。鏈路層劫持最明顯的危害就是帳號、密碼被竊取。最常見的就是某些裝置實現的對非法站點的訪問攔截,以及一些地區運營商的網頁植入廣告行為。
鏈路劫持的原理就是運營商(也可能是駭客)在使用者訪問網站的時候進行竊聽,獲取使用者訪問的目的ip後,然後以這個ip為source-ip冒充網站給使用者響應,通常響應中會插入一段JS程式碼,這段程式碼可能會讓使用者去get一些非真實網站資源,最終可能造成真實頁面被插入廣告,被蒙層,甚至整頁面被替換,嚴重影響使用者體驗以及企業形象。由於鏈路劫持可能通常發生在last-mile,而last-mile被運營商牢牢控住,所以這對監測以及解決問題帶來了巨大的挑戰。劫持原理大概如圖8所示。
圖8
目前發現的TCP鏈路劫持攻擊一般有兩種形式:中斷訪問型(分為單向發包和雙向發包)和替換頁面型。
中斷訪問型常見於阻止使用者訪問某些網站,如某些裝置禁止使用者訪問某些站點、某地運營商的禁止ADSL多終端上網功能。其原理就是偽造服務端給使用者發RST包阻止TCP連線的建立(單向發包)。某些裝置做得比較狠,在冒充服務端給使用者發RST包的同時也冒充使用者給服務端發RST包(雙向發包)。
替換頁面型常見於運營商植入廣告,也有篡改正常網頁進行SEO、騙流量的。最惡劣的莫過於釣魚,如2011年出現過的Gmail釣魚事件以及一些不為人知的釣魚事件。原理也簡單,就是在一個HTTP請求後偽造服務端的HTTP響應給客戶端。
0x03 鏈路劫持判斷依據
- TTL:表現為TCP 報的 TTL 不一致甚至抖動很大。一種情況是跟正常包的ttl相差明顯,就像以上本案例中的那樣;另一種情況是透過ttl來判斷作業系統型別,進而間接判斷資料包是否有異常。
- Identification:出現不符合 RFC 標準的情況。對於給定地址和協議的ip包來說,它的identification應該是公差為1的單調遞增數列。每一個IP封包都有一個16位的唯一識別碼。當程式產生的資料要透過網路傳送時都會被拆散成封包形式傳送,當封包要進行重組的時候這個ID就是依據了。標識欄位唯一地標識主機傳送的每一份資料包。通常每傳送一份訊息它的值就會加1。
- Banner資訊:與已知資訊矛盾,如本案例中。
TTL:TTL是 Time To Live的縮寫,該欄位指定IP包被路由器丟棄之前允許透過的最大網段數量。TTL是IPv4包頭的一個8 bit欄位。
雖然TTL從字面上翻譯,是可以存活的時間,但實際上TTL是IP資料包在計算機網路中可以轉發的最大跳數。TTL欄位由IP資料包的傳送者設定,在IP資料包從源到目的的整個轉發路徑上,每經過一個路由器,路由器都會修改這個TTL欄位值,具體的做法是把該TTL的值減1,然後再將IP包轉發出去。如果在IP包到達目的IP之前,TTL減少為0,路由器將會丟棄收到的TTL=0的IP包並向IP包的傳送者傳送 ICMP time exceeded訊息。
TTL的主要作用是避免IP包在網路中的無限迴圈和收發,節省了網路資源,並能使IP包的傳送者能收到告警訊息。
#!cpp
//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; //協議
unsigned short chk_sum; //檢驗和
in_addr src_addr; //源IP地址
in_addr dst_addr; //目的IP地址
}ip_hdr;
不同的作業系統環境TTL值一般是固定的一個數,常見的是16的倍數,然後每經過一個節點減1。一般來說伺服器不會修改預設的TTL值,例如Linux預設的TTL為64,Windows預設的TTL為128。
下面是預設作業系統的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是加密協議,我們隨便抓個http包,發現http包裡面的所有東西都是明文的,這樣就會被監聽,而https協議是加密的。
但是光加密還不夠,因為只是application data被加密了,網路層的資訊都沒有被加密,邪惡勢力依然可以用資料包的目的ip作為源ip響應使用者。https還有另一大特點是要驗證數字證照,為了確保客戶端訪問的網站是經過CA驗證的可信任的網站。所以這就幾乎徹底杜絕了鏈路劫持的可能。
但是https也不是如此完美,雖然https解決了諸多安全問題,但是對效能也有著比較大的影響。一是使用者要從http跳轉到https,並且要多幾次 TLS的握手,這會消耗一定的時間;二是伺服器的壓力也會增加。除此之外如果使用全站的https,所有頁面裡面的嵌入資源都要改成https,APP的程式也要進行相應的修改,CDN的所有節點也必須都支援https並且匯入證照。所以全站https並不是一件容易的事情,國外的Google、 Facebook、Twitter早已支援全站https,但目前國內大多數公司都沒有采用全站https的方式。全站https應該是未來網際網路的趨勢,關於全站https請參考資料【5】,這裡不詳細闡述了。
(2)加強監控與檢測
目前網上也有一些鏈路劫持檢測方法,如使用libpcap判斷鏈路層劫持,其原理是在鏈路層劫持的裝置缺少仿造協議頭中ttl值的程式(或者說,偽造流量要優先真實流量到達客戶電腦,所以沒有機會去偽造ttl值)。電腦每收到一個資料包,便交給程式,如果判斷某一IP地址流量的ttl值與該IP前一次流量的ttl值不同且相差5以上,便判定此次流量為在鏈路層中偽造的。有關程式碼請參考【6】。
(3)其他/產品
目前騰訊做的比較領先,有鏈路劫持檢測的相關發明專利。
0x05總結
鏈路層劫持較為底層,而且很多涉及運營商行為,所以不可能從根本上來防止(或者找到運營商,或者抓住駭客,當然運營商你是戰勝不了的你懂得)。個人認為應對鏈路劫持一般可以考慮幾個維度:業務層面、技術層面。所有的安全都是為業務服務的,在確保業務的前提下,做好安全防護措施。最重要的是技術層面加強有效檢測、監控,包括對有關攻擊技術的研究、對日誌流量等資料的分析。當然,對企業來講,我們只能夠儘量做好自身,對於我們不可控的因素往往無能為力。總之,廣域網一點都不安全,所以敏感資訊傳輸一定要加密,還要高強度加密。
就到這裡,請各位看官批評指正。
0x06 參考文獻
本文章來源於烏雲知識庫,此映象為了方便大家學習研究,文章版權歸烏雲知識庫!