朱 珠,傅 曉,王志堅
(河海大學 計算機與信息學院,南京 211100)
當下,Android系統(tǒng)已成為國內(nèi)智能移動終端設(shè)備使用最多的操作系統(tǒng):到2016年末為止,中國移動手機用戶已突破13億人[1]。僅在2016年一年,中國智能手機出貨量即達到5.22億部[2],其中,使用Android操作系統(tǒng)的設(shè)備占中國全部智能設(shè)備比例為83.2%,處于絕對主流地位[3]。
由于眾所周知的因素,國內(nèi)Android用戶無法通過Google Play市場獲取應(yīng)用程序,因此,第三方應(yīng)用市場和應(yīng)用程序開發(fā)者自行提供的下載地址成為Android應(yīng)用程序分發(fā)、下載的重要渠道。由于第三方應(yīng)用市場及應(yīng)用程序開發(fā)者自身較低的安全意識,上述Android應(yīng)用程序下載渠道也成為惡意攻擊者的攻擊目標,其中,下載劫持(Download Hijacking)是最常見的攻擊手段之一。
下載劫持屬于典型的中間人攻擊(Man-In-The-Middle Attack):攻擊者在用戶與目標服務(wù)器之間的鏈路上部署旁路設(shè)備(By-pass Equipment)用以監(jiān)聽用戶下載報文;當捕獲用戶向特定服務(wù)器請求下載Android應(yīng)用程序的報文時,旁路設(shè)備便冒充目標服務(wù)器向用戶發(fā)送虛假應(yīng)答,將用戶請求重定向到攻擊者指定的地址。中間人攻擊是一種常見的網(wǎng)絡(luò)攻擊行為,使用范圍廣泛,極具破壞力,也以其他多種形式出現(xiàn),從會話劫持、瀏覽器劫持到網(wǎng)站掛馬(Drive-by download)。
在會話劫持中,攻擊者攔截并接管用戶和主機之間建立的合法會話,可以訪問任何需要身份驗證的資源[4],此時攻擊者已經(jīng)得到了合法的會話ID,可以使用該合法會話ID直接登錄,在會話ID沒有被泄露的情況下,該攻擊者便擁有了合法用戶的身份。如今,會話劫持可以通過使用單點登錄(Single Sign On)技術(shù)輕松檢測到[5]。一旦會話被攻擊者劫持,受害者可以立即發(fā)現(xiàn)并采取措施產(chǎn)生新的會話。
在瀏覽器劫持中,用戶并不是感染常規(guī)的惡意軟件,而是當連接到惡意或受到攻擊的網(wǎng)站時,前端語言(如JavaScript)允許用戶的瀏覽器執(zhí)行惡意活動。實際上,攻擊者通常是在瀏覽器的允許操作范圍內(nèi)進行活動的,系統(tǒng)默認其行為是合法的,因此,即使是最新的殺毒軟件也無法察覺此劫持。目前這種劫持可以通過部署在用戶網(wǎng)頁瀏覽器的某種檢測器來檢測[6],即根據(jù)瀏覽器行為的上下文關(guān)聯(lián)性,通過對瀏覽器的正常模式和被劫持模式的狀態(tài)訓練,設(shè)計的一種能夠發(fā)現(xiàn)并終止瀏覽器可疑行為的檢測器。
網(wǎng)站掛馬(Drive-by download)攻擊比上述兩種劫持更常見。當互聯(lián)網(wǎng)用戶訪問惡意網(wǎng)頁時,惡意網(wǎng)站服務(wù)器將包含木馬的HTML文檔傳遞給用戶的計算機系統(tǒng),惡意內(nèi)容利用用戶計算機系統(tǒng)上的漏洞,執(zhí)行攻擊者提供的惡意代碼以及安裝惡意軟件。網(wǎng)站掛馬的檢測是一個熱門的研究領(lǐng)域,包括利用數(shù)據(jù)挖掘技術(shù)對網(wǎng)頁惡意內(nèi)容進行惡意或良性分類。其中有一種異常檢測,就是在加載網(wǎng)頁時監(jiān)視用戶計算機系統(tǒng)的異常變化[7]。
Android應(yīng)用程序包下載劫持則包含了以上所有劫持的特點。通常情況下,發(fā)布者(一般是第三方應(yīng)用市場及應(yīng)用程序開發(fā)者)使用超文本傳輸協(xié)議(Hyper Text Transfer Protocol, HTTP)發(fā)布Android應(yīng)用程序安裝包的統(tǒng)一資源定位符(University Resource Locator,URL)地址,用戶通過瀏覽器或其他下載工具請求該地址上的資源。當用戶瀏覽器發(fā)出的HTTP請求(可能是GET方法,也可能是POST方法)被攻擊者部署的旁路設(shè)備發(fā)覺并攔截,便會收到一個旁路設(shè)備偽造的HTTP暫時性轉(zhuǎn)移(302 Temporarily Moved)響應(yīng),將用戶請求重定向到一個攻擊者指定的地址,再次發(fā)出下載請求(通常指定惡意應(yīng)用程序包)。該過程中,就應(yīng)用層方面而言,存在HTTP會話被劫持;就下載方法方面而言,存在用戶的瀏覽器被劫持;就結(jié)果方面而言,惡意應(yīng)用程序被隱蔽強迫下載。所以可以說,Android應(yīng)用程序包下載劫持是一種涉及了多種劫持的多功能劫持,跟之前所有的劫持攻擊相比,更加復(fù)雜和難以檢測。
上述方法可以將用戶下載的安裝包替換為任意數(shù)據(jù),故存在一定的危害性,但是,由于發(fā)布者的資源并未真正被用戶下載,發(fā)布者通過Web流量分析(Traffic Analytic)可以輕易地判斷出自身是否受到下載劫持攻擊:頁面訪問量(Page View,PV)相對于獨立訪問者(Unique Visitor,UV)的不正常降低,是受到下載劫持的顯著特征之一。
為了與本文中將要研究的對象進行區(qū)分,將上述傳統(tǒng)的下載劫持稱為常規(guī)下載劫持(Regular Download Hijacking);與常規(guī)下載劫持不同,隱蔽下載劫持(Stealth Download Hijacking)無法通過發(fā)布者自身進行的Web流量分析進行發(fā)現(xiàn),除非用戶發(fā)現(xiàn)受到劫持攻擊并報告給發(fā)布者,否則該攻擊行為對發(fā)布者完全隱蔽。
圖1 下載劫持攻擊中各報文時序關(guān)系
以往,認為隱蔽下載劫持技術(shù)屬于高級網(wǎng)絡(luò)武器(Advanced Cyber Weapon,ACW)的一部分,一般被高級持續(xù)性威脅(Advanced Persistent Threat, APT)應(yīng)用于針對特定高價值目標的網(wǎng)絡(luò)攻擊中,普通用戶難以接觸到該類攻擊,但是,在2017年年初,發(fā)現(xiàn)該技術(shù)被應(yīng)用于針對普通電信用戶的大規(guī)模下載劫持攻擊。該事件與2017年4月Shadow Brokers竊取NSA下屬Equation Group的網(wǎng)絡(luò)武器庫類似,標志著流入民間的ACW開始被應(yīng)用于針對一般人群的大規(guī)模網(wǎng)絡(luò)攻擊,同時APT的行動模式也從早期的黑客行動主義逐漸染上鮮明的功利指向性色彩。
2017年初,江蘇省內(nèi)某互聯(lián)網(wǎng)服務(wù)提供商(Internet Service Provider, ISP)光纖寬帶接入用戶在上網(wǎng)時發(fā)現(xiàn),從Android應(yīng)用程序開發(fā)者網(wǎng)站以及第三方應(yīng)用市場下載的.apk(Android Package)格式安裝包被替換為360手機助手、PP助手、豌豆莢等與用戶所下載應(yīng)用無關(guān)的第三方應(yīng)用安裝包。用戶向該ISP客服反映后,被告知出現(xiàn)此現(xiàn)象的原因是受到病毒和木馬攻擊,建議用戶安裝360殺毒軟件。
在注意到這一問題之后,聯(lián)系了部分被替換安裝包的應(yīng)用程序開發(fā)者,通過網(wǎng)站W(wǎng)eb流量分析發(fā)現(xiàn),相關(guān)省份與ISP的PV及UV均未出現(xiàn)異常降低的情況。這一表現(xiàn)明顯與以往下載劫持攻擊的模式不相匹配,因此嘗試通過實驗證明攻擊行為的存在。
為了避免干擾,在全新的虛擬機VMware環(huán)境下,安裝了 Windows 7 sp1旗艦版操作系統(tǒng),其中瀏覽器選擇的是Internet Explorer 11,通過江蘇省某ISP光纖寬帶以太網(wǎng)點對點協(xié)議(Point to Point Protocol over Ethernet,PPPoE)虛擬撥號接入互聯(lián)網(wǎng)。根據(jù)用戶反饋信息,使用瀏覽器直接下載www.91vst.com首頁提供的CIBN微視聽應(yīng)用下載鏈接,該鏈接指向位于江蘇省泰州市的內(nèi)容分發(fā)網(wǎng)絡(luò)(Content Delivery Network, CDN)節(jié)點,該節(jié)點地址為58.222.18.2。重復(fù)該操作3次。
下載開始后,瀏覽器收到的響應(yīng)流來自于115.231.86.9或115.231.86.10,該地址位于浙江省義烏市,且內(nèi)容并非CIBN微視聽應(yīng)用安裝包,其內(nèi)容依次是360手機助手、PP助手、豌豆莢。
圖2 被替換的安裝包
然后,在虛擬機操作系統(tǒng)中通過設(shè)置虛擬私有網(wǎng)絡(luò)(Virtual Private Network,VPN)代理服務(wù)器下載該鏈接,上述現(xiàn)象沒有發(fā)生,瀏覽器收到的響應(yīng)流來自58.222.18.2,確為CIBN微視聽應(yīng)用。
通過上述比較實驗,在排除病毒、木馬等干擾因素之后,可以初步確定,在該ISP接入網(wǎng)絡(luò)與該CDN節(jié)點之間存在下載劫持攻擊。
為了確定攻擊者利用何種漏洞在發(fā)布者網(wǎng)站與用戶之間實現(xiàn)了隱蔽下載劫持,在測試環(huán)境中安裝Wireshark和WinPcap進行網(wǎng)絡(luò)抓包分析。
用戶點擊下載鏈接之后,瀏覽器向服務(wù)器58.222.18.2發(fā)出HTTP請求報文,記為Request0,Request0的HTTP頭部如下所示:
GET/vst/apk/updateDownload/Z2J9KVYTBJCFLYYQEWTX.apk HTTP/1.1〗r〗n
Accept: text/html, application/xhtml+xml, */*〗r〗n
Referer: http://www.91vst.com/〗r〗n
…
隨后,瀏覽器收到來自服務(wù)器58.222.18.2的HTTP響應(yīng)報文,記為Response1,Response1的HTTP頭部如下所示:
HTTP/1.1 302 Moved Temporarily〗r〗n
Content-Type: text/html〗r〗n
Location: http://115.231.86.10:9780/L06/W_D_J.apk〗r〗n
…
可以看出,該報文為HTTP暫時性轉(zhuǎn)移(302 Temporarily Moved)響應(yīng),內(nèi)容是通知瀏覽器Request0所請求的資源已暫時轉(zhuǎn)移,應(yīng)重新請求http://115.231.86.10:9780/L06/W_D_J.apk上的資源。Response1的Time to live值為113,事先已經(jīng)知道服務(wù)器58.222.18.2正常響應(yīng)的Time to live為56,故可以判斷Response1為攻擊者部署的旁路設(shè)備偽造的HTTP響應(yīng)。測試環(huán)境中,瀏覽器收到Response1之后,轉(zhuǎn)而請求地址http://115.231.86.10:9780/L06/W_D_J.apk上的資源,向服務(wù)器115.231.86.10發(fā)出HTTP請求報文,記為Request1,Request1的HTTP頭部如下所示:
GET /L06/W_D_J.apk HTTP/1.1〗r〗n
Accept: text/html, application/xhtml+xml, */*〗r〗n
Referer: http://www.91vst.com/〗r〗n
…
服務(wù)器115.231.86.10響應(yīng)Request1之后,此時瀏覽器所下載的安裝包已被替換為豌豆莢。
至此為止,攻擊者的劫持手法與常規(guī)下載劫持完全一致:通過偽造來源地址,冒充發(fā)布者網(wǎng)站向用戶瀏覽器返回偽造的HTTP暫時性轉(zhuǎn)移報文,將瀏覽器請求重定向到服務(wù)器115.231.86.10,下載指定服務(wù)器路徑上的安裝包。問題在于,在這一過程中,用戶并未下載服務(wù)器58.222.18.2上的資源,但是CDN節(jié)點,即服務(wù)器58.222.18.2的統(tǒng)計數(shù)據(jù)上,卻顯示了用戶進行了一次正常下載。這意味著,若不在用戶端進行抓包分析,發(fā)布者無法憑借在服務(wù)器端統(tǒng)計信息分析出自身是否受到了下載劫持攻擊。這種攻擊模式具有隱蔽下載劫持的鮮明特征,與以往所接觸的下載劫持攻擊具有顯著的差異。
因此,將報文分析的范圍從原先的HTTP報文,擴大到全部TCP/IP(Transmission Control Protocol/Internet Protocol)報文。
Request0的TCP/IP頭部如下所示:
Internet Protocol Version 4, Src: 192.168.1.110, Dst: 58.222.18.2
Transmission Control Protocol, Src Port: 3771, Dst Port: 80, Seq: 1, Ack: 1, Len: 344
Response1的TCP/IP頭部如下所示:
Internet Protocol Version 4, Src: 58.222.18.2, Dst: 192.168.1.110
Transmission Control Protocol, Src Port: 80, Dst Port: 3771, Seq: 1, Ack: 1, Len: 129
Request1的TCP/IP頭部如下所示:
Internet Protocol Version 4, Src: 192.168.1.110, Dst: 58.222.18.2
Transmission Control Protocol, Src Port: 3772, Dst Port: 9780, Seq: 1, Ack: 1, Len: 306
可以看出,Request0、Response1、Request1的TCP/IP頭部序列號(Sequence number, Seq)和確認號(Acknowledgment number, Ack)均為1,這意味著上述請求與響應(yīng)報文在發(fā)送過程中都各自創(chuàng)建了一個新的TCP會話連接,而不是在同一個TCP會話連接中[8];并且,服務(wù)器和客戶端也都正確處理了對方的請求和響應(yīng),這是由HTTP的無狀態(tài)性質(zhì)所決定的[9]。
在HTTP中,所有客戶端與服務(wù)器之間的請求與響應(yīng)都是無狀態(tài)、無連接的,這意味著服務(wù)器的每一次響應(yīng)不需要與客戶端的上一個請求在上下文上語義相關(guān)。HTTP的這一特性是為了在請求與響應(yīng)過程中,服務(wù)器與客戶端之間可以不保持活動連接,而是重新發(fā)起TCP會話連接,從而節(jié)省服務(wù)器資源。
以Request0為例,該請求報文TCP頭部中Seq為1,段長度(segment Length, Len)為344,則在同一個TCP會話連接中,服務(wù)器響應(yīng)報文Response1的TCP頭部中,Seq應(yīng)為1,與請求報文在同一序列中;Ack應(yīng)為345,由請求報文的Seq加上Len得出。而實際上,Response1并未遵守這一規(guī)則,客戶端瀏覽器依然認為Response1是服務(wù)器對Request0的應(yīng)答響應(yīng)。
通過搜索TCP/IP報文發(fā)現(xiàn),在Request0和Response1報文之間,確實存在一個TCP/IP報文,其Seq為1,Ack為345。將該報文記為Response0,其TCP/IP頭部如下所示:
Internet Protocol Version 4, Src: 58.222.18.2, Dst: 192.168.1.110
Transmission Control Protocol, Src Port: 80, Dst Port: 3771, Seq: 1, Ack: 345, Len: 0
從以上內(nèi)容可以看出,Response0僅存在頭部信息,其段長度為0,內(nèi)容為空。
而在Respons1和Request1報文之間,也存在一個TCP/IP報文,與Response0具有相同的Seq和Ack值。將該報文記為Response2,其TCP/IP頭部如下所示:
Internet Protocol Version 4, Src: 58.222.18.2, Dst: 192.168.1.110
Transmission Control Protocol, Src Port: 80, Dst Port: 3771, Seq: 1, Ack: 345, Len: 1412
由于Response2和Response0報文的TCP/IP頭部具有相同的Seq和Ack,故在測試環(huán)境的TCP堆棧中,后到達的Response2被當作TCP序列錯誤(TCP Out-Of-Order)報文而舍棄。
圖3 報文Response2的內(nèi)容
分辨出報文Response0和Response2哪一個是真正的響應(yīng)報文并不是很復(fù)雜。將Response2中正文內(nèi)容的十六進制轉(zhuǎn)換為文本形式,可以看到Response2包含了HTTP響應(yīng)的首部,內(nèi)容類型為Android包,長度為26 615 091字節(jié)。在時間軸上搜索了所有的包,發(fā)現(xiàn)了一系列跟隨著Respnose2的HTTP 延續(xù)包。將它們合并起來,便得到了真正想要下載的Android包的一個副本。而Response0雖然與Response2有相同的Seq和Ack,但它的實體內(nèi)容項卻是空的。
通過分析Response2報文內(nèi)容,發(fā)現(xiàn)該報文正是來自服務(wù)器58.222.18.2的CIBN微視聽應(yīng)用安裝包。
如上文所述,劫持的攻擊機制已經(jīng)很明確了。服務(wù)器58.222.18.2將數(shù)據(jù)串傳輸?shù)紿TTP響應(yīng)中,把Request0所請求的Android包的完整副本發(fā)送給瀏覽器。由于MTU(最大傳輸單元)的限制,HTTP響應(yīng)在通過網(wǎng)關(guān)時被分成多個包。而第一個包(即Response2)包含的首部信息對瀏覽器決定如何處理該報文有著至關(guān)重要的作用。檢測到該信息,旁路設(shè)備便發(fā)送一個偽裝的響應(yīng)報文Response0欺騙瀏覽器丟棄真實的響應(yīng)報文Response2,Response0便占用了Response2的Req和Ack。一旦Response2被瀏覽器丟棄,其所有跟進的延續(xù)包到達瀏覽器都會變成無效。
在一次正常下載過程中,用戶瀏覽器發(fā)出下載請求Request0,發(fā)布者服務(wù)器對此請求進行響應(yīng),用戶瀏覽器收到該響應(yīng)Response2后,完成下載過程。
而在隱蔽下載劫持過程中,攻擊者部署的旁路設(shè)備在監(jiān)聽到下載請求Request0之后,偽裝成發(fā)布者服務(wù)器,發(fā)出虛假的響應(yīng)Response0和Response1。
其中,Response0的Len為0,內(nèi)容為空;其TCP/IP頭部的Seq為1,Ack為Response0的Seq加上Len。Response0的目的在于,占用發(fā)布者服務(wù)器對Request0的真實響應(yīng)報文Response2的Ack,使Response2在到達用戶瀏覽器之后,因為Seq和Ack被Response0占用而被當作TCP序列錯誤報文舍棄。在這一過程中,由于服務(wù)器實際上正常響應(yīng)了Request0,只是在Response2到達用戶瀏覽器之后才被舍棄,故仍然統(tǒng)計為一次正常下載。
Response1是一個HTTP暫時性轉(zhuǎn)移響應(yīng),目的則是將用戶瀏覽器的請求Request0重定向到攻擊者指定的URL,使瀏覽器重新發(fā)出請求Request1,轉(zhuǎn)而下載攻擊者指定URL上的安裝包,從而完成整個下載劫持過程。
圖4 隱蔽下載劫持攻擊中各報文時序關(guān)系
攻擊者能夠成功實施隱蔽下載劫持的充分條件是,旁路設(shè)備偽造的響應(yīng)報文Response0和Response1先于服務(wù)器真實響應(yīng)報文Response2到達用戶端:若Response2先于Response0到達,則后到達的Response0會被當作TCP序列錯誤而舍棄,用戶開始正常下載未被劫持的資源。因此,攻擊者部署的旁路設(shè)備與用戶端之間的距離必定小于服務(wù)器到用戶端的距離,這一點可以通過響應(yīng)報文Response1的TTL(Time To Live)值進行證明:服務(wù)器正常響應(yīng)報文的TTL為56,而偽造的響應(yīng)報文為113??紤]到旁路設(shè)備有可能進行了TTL欺騙(TTL Spoofing),113不是其真實值,TTL的高低不一定反映設(shè)備間的路由跳數(shù)或距離,因此難以通過TTL和Tracert命令確定旁路設(shè)備的地址(實際上,由于ISP在主干網(wǎng)上限制了ICMP協(xié)議端口,未能通過該方法確定TTL為113的設(shè)備地址)。
但是,可以確定的一點是,旁路設(shè)備的偽造響應(yīng)報文總是在時序上早于真實響應(yīng)報文。
如上文所述,攻擊者利用了HTTP的無連接特性,通過偽造響應(yīng)報文,在不中斷服務(wù)器正常響應(yīng)的情況下,率先占用真實的響應(yīng)報文的TCP序列,使真實報文被瀏覽器端錯誤舍棄;同時,通過偽造重定向使瀏覽器轉(zhuǎn)而請求攻擊者指定的資源。
該漏洞存在于HTTP協(xié)議層,理論上影響所有基于該協(xié)議下載的資源。通過實驗發(fā)現(xiàn),攻擊者僅劫持HTTP GET請求路徑中包含“.apk”關(guān)鍵字的下載內(nèi)容,這意味著攻擊者最初的目標很可能是安裝Android操作系統(tǒng)的智能設(shè)備,因為以該關(guān)鍵字為后綴名的文件均為Android應(yīng)用程序安裝包(Android Package Kit,MIME類型為application/vnd.android.package-archive)[10],但是在測試中,Android、Windows以及Ubuntu、Debian等操作系統(tǒng)無一例外地受到影響,本文認為這是由于攻擊者未能正確識別用戶瀏覽器的User Agent值所導(dǎo)致的[11],攻擊者可能僅想劫持安裝Android操作系統(tǒng)的智能設(shè)備的下載請求,但是由于技術(shù)缺陷未能實現(xiàn)HTTP請求頭部中User-Agent字段的判斷。
iOS和macOS等操作系統(tǒng)的用戶不是該攻擊者的目標,因為安裝了這些操作系統(tǒng)的設(shè)備默認不允許從第三方發(fā)布者下載和安裝應(yīng)用程序安裝包,而從Apple Store下載的安裝包不受該漏洞影響。
在江蘇省內(nèi),使用HTTP提供下載的Android應(yīng)用程序安裝包均受到了此漏洞的影響,包括開發(fā)者網(wǎng)站和第三方應(yīng)用市場。部分具有應(yīng)用內(nèi)更新功能(又稱Hot swapping,熱更新[12])的Android應(yīng)用程序也受到了該漏洞的影響,原因是在更新過程中使用了HTTP,被中間設(shè)備視同單獨的一次HTTP下載請求而進行劫持。
至2016年末,江蘇省內(nèi)互聯(lián)網(wǎng)寬帶接入用戶數(shù)為2 877.2萬戶[13],其中該ISP光纖寬帶接入用戶數(shù)超過1 000萬戶[14],據(jù)此估計,此次受該下載劫持攻擊的用戶數(shù)不少于1 000萬戶。按平均每個用戶每天5次下載計算,攻擊者單日劫持下載量即可突破5 000萬次。按照50元/萬次下載計算(安卓應(yīng)用程序推廣平均價格),攻擊者單日獲利即可超過25萬元。
在實驗中,發(fā)現(xiàn)攻擊者的一般攻擊模式是,將用戶下載的安裝包隨機替換為豌豆莢、360手機助手、PP助手等。這一模式似乎是由旁路設(shè)備根據(jù)115.231.86.9和115.231.86.10的負載均衡情況即時進行調(diào)整,然而,在這一模式之外,也發(fā)現(xiàn)了更為特殊的攻擊模式:
蘇寧易購網(wǎng)站及其應(yīng)用程序安裝包(m.suning.com)受到了此次下載劫持攻擊的影響,與其他應(yīng)用不同的是,蘇寧易購安裝包總是被攻擊者替換為手機京東。該情況是在其他測試用例中從來沒有發(fā)生過的。
有理由相信,攻擊者具備了識別用戶下載請求中的地址,并根據(jù)地址預(yù)設(shè)重定向目標的能力。據(jù)此判斷,攻擊者已具備能力對于不同網(wǎng)站、地址上的應(yīng)用程序安裝包,分別設(shè)定具體的劫持規(guī)則。這一模式的目的很可能是為了從被劫持應(yīng)用開發(fā)者的競爭對手中獲取商業(yè)報酬。
圖5 受到劫持的蘇寧易購安裝包
如上文所述,攻擊者通過部署旁路設(shè)備向用戶發(fā)送虛假的響應(yīng)報文Response0和Response1來實現(xiàn)隱蔽劫持。如果路由端或客戶端能對上述兩個響應(yīng)報文進行過濾,便可預(yù)防攻擊者利用該漏洞進行攻擊。
經(jīng)測試,部署防火墻和入侵檢測系統(tǒng)(Intrusion Detection Systems, IDS)無法過濾Response0和Response1,因為這兩個包并沒有非法的信息結(jié)構(gòu)。
響應(yīng)報文Response0的目的在于占用真實的響應(yīng)報文的Seq和Ack值,故攻擊者未對其內(nèi)容進行填充,其僅有頭部信息,沒有內(nèi)容信息,段長度為0(Len=0)。將符合上述特征的報文進行過濾后,即可正常下載所請求的安裝包,但是并非所有段長度為0的TCP包都是虛假報文。在建立一個TCP會話時,通信雙方會發(fā)送三個報文段,這三個報文段中的Len均為0,但是其Ack和Seq的值都不會超過1。因此,設(shè)置這樣一個規(guī)則來過濾Response0:如果某個TCP包的Len是0,Ack或Seq中的任何一個大于1,便認為該包無效。但是這個規(guī)則也會發(fā)生誤判:當關(guān)閉一個TCP會話時,依舊需要發(fā)送一些報文段來進行會話釋放,此時的Seq值無法滿足不超過1。因此將此規(guī)則添加到防火墻或IDS中會使會話中的計算機無法及時斷開連接直到超時,白白浪費了資源。
一旦Response0被過濾了,Response2就可以被用戶瀏覽器接受,即可以對需要的應(yīng)用程序包進行下載,但問題還沒有完全解決:點擊下載鏈接時,會有兩個應(yīng)用程序包被下載下來,其中一個是用戶請求的應(yīng)用程序,另一個是隨機選擇的115.231.86.9或115.231.86.10上的應(yīng)用程序包。為了解決這個問題,需要對Response1進行過濾。
響應(yīng)報文Response1是用于將用戶請求重定向到攻擊者指定的地址。在實驗中,已知目標地址為115.231.86.9和115.231.86.10,故只需將頭部包含上述兩個地址的響應(yīng)報文過濾掉,即可對Response1進行屏蔽。
在安裝了Linux系統(tǒng)的終端或軟路由中,可以通過配置iptables/netfilter對該漏洞進行預(yù)防。而在安裝了其他操作系統(tǒng)的設(shè)備上,則需要通過安裝第三方模塊或應(yīng)用程序來實現(xiàn)相同的效果。本文在一些基于Linux操作系統(tǒng)(如Debian,Ubuntu和CentOS)的設(shè)備上測試了上述兩條規(guī)則,都有很好的運行效果。
為了有效預(yù)防Android應(yīng)用下載劫持所引發(fā)的風險,可以從分布式檢測、集中分析以及主動預(yù)防等方面從根源上阻止此類劫持攻擊。
MITM設(shè)備可能部署于網(wǎng)絡(luò)的任何一個節(jié)點,僅依靠部分用戶自行檢測難以有效地發(fā)現(xiàn)。由于下載劫持可被APK安裝包的HTTP下載請求觸發(fā),故而可以在整個Internet中部署大量分布式節(jié)點,模擬用戶行為發(fā)送下載請求,并對響應(yīng)報文進行檢查。如果響應(yīng)報文符合下載劫持攻擊的特征,則可認為該節(jié)點與服務(wù)器之間的鏈路存在MITM設(shè)備。節(jié)點將相關(guān)信息上傳至數(shù)據(jù)中心進行下一步分析。
數(shù)據(jù)中心在搜集到一定數(shù)量的攻擊信息后,通過數(shù)據(jù)挖掘和在線實時分析,統(tǒng)計受劫持用戶范圍、攻擊者所在位置、線路、網(wǎng)絡(luò)地址、受影響站點等,形成劫持特征庫并實時向運營商、站點、用戶、行政主管部門和執(zhí)法單位公布。
受影響用戶根據(jù)特征庫主動將相關(guān)劫持站點加入黑名單,并更新防火墻策略過濾惡意報文;受影響站點根據(jù)特征庫適時調(diào)整加密策略,避免使用HTTP明文進行安裝包發(fā)布及應(yīng)用內(nèi)更新;運營商根據(jù)特征庫及時開展內(nèi)部審計工作,清查涉及流量劫持等灰色產(chǎn)業(yè)鏈的內(nèi)部機構(gòu)及人員。
除了上述技術(shù)手段,社會各界也應(yīng)該意識到,打擊下載劫持不僅僅要通過技術(shù)手段,更需要通過行政管理手段和法律手段。通過建立檢測、分析、預(yù)防的全過程控制措施,將用戶、運營商、站點、行政主管部門及執(zhí)法單位緊密聯(lián)系起來,廣泛參與其中。只有使社會各界意識到下載劫持的危害性,才能夠?qū)ο嚓P(guān)灰色產(chǎn)業(yè)從業(yè)人員形成威懾,從而杜絕此類違法行為。
本文通過案例分析,提出了一種針對Android應(yīng)用程序安裝包的隱蔽下載劫持攻擊漏洞。對于該漏洞的形成原理、利用機制、攻擊者模式、預(yù)防方法等問題,本文進行了分析與研究,期望能夠給之后的國內(nèi)外網(wǎng)絡(luò)安全研究人員提供研究數(shù)據(jù)與參考資料。
該漏洞相較以往傳統(tǒng)下載劫持漏洞,無法通過服務(wù)器端流量分析進行發(fā)現(xiàn),具有較強的隱蔽性和危害性。利用該漏洞的攻擊者具有利益指向性明確、手法隱蔽、背景深厚等特征,符合對于APT的一般性描述[15],應(yīng)及早引起運營商內(nèi)控部門、通信主管部門以及網(wǎng)絡(luò)執(zhí)法部門的警惕。
[4] ORIYANO S P. CEH v9: Certified Ethical Hacker Version 9 Study Guide [M]. Hoboken, NJ: John Wiley and Sons, 2016: 331.
[5] ARMANDO A, CARBONE R, COMPAGNA L, et al. An authentication flaw in browser-based single sign-on protocols: impact and remediations [J]. Computers and Security, 2013, 33(4): 41-58.
[6] MNICA D, RIBEIRO C. An IDS for browser hijacking [EB/OL]. [2018- 01- 07]. http://www.thinkmind.org/download.php?articleid=securware_2015_6_10_30083.
[7] van LE L, WELCH I, GAO X, et al. Anatomy of drive-by download attack [C]// AISC ’13: Proceedings of the 11th Australasian Information Security Conference. Darlinghurst, Australia: Australian Computer Society, 2013, 138: 49-58.
[8] POSTEL J. RFC 793—transmission control protocol [S/OL]. [2018- 01- 07]. http://www.faqs.org/rfcs/rfc793.html.
[9] FIELDING R, GETTYS J, MOGUL J, et al. RFC 2616: hypertext transfer protocol [J]. Computer Science and Communications Dictionary, 1999, 7(9): 3969-3973.
[10] YANG A, STEELE S, FREED N. RFC 6532: Internationalized email headers [S/OL]. [2018- 01- 08]. https://datatracker.ietf.org/doc/rfc6532/?include_text=1.
[11] FIELDING E R, RESCHKE E J. RFC 7231: HyperText Transfer Protocol (HTTP/1.1): semantics and content [S/OL]. [2018- 01- 08]. https://tools.ietf.org/html/rfc7231.
[12] HENNESSY J L, PATTERSON D A. Computer Architecture: A Quantitative Approach [M]. San Francisco, CA: Morgan Kaufmann, 2003: 707.
[13] 江蘇省通信管理局.江蘇省信息通信業(yè)二〇一七年年度滾動發(fā)展計劃[EB/OL]. [2018- 01- 18]. http://www.jsca.gov.cn:8080/pub/jstx/jstxglj/201711/t20171113_46662.html.(Jiangsu Communications Administration. Annual rolling development plan of information and communications industry in Jiangsu in 2017 [EB/OL]. [2018- 01- 18]. http://www.jsca.gov.cn:8080/pub/jstx/jstxglj/201711/t20171113_46662.html.)
[14] 朱秀霞.江蘇電信光網(wǎng)用戶數(shù)居全國各省之首[N].新華日報, 2015- 12- 15.(ZHU X X. Jiangsu Telecom optical network user number ranking first in the country’s provinces [N]. Xinhua News, 2015- 12- 15.)
[15] LACEY D. Advanced Persistent Threats: How to Manage the Risk to Your Business [M]. [S.l.]: Information Systems Audit and Control Association, 2013: 11-13.