萬物互聯(lián)時(shí)代，無線網(wǎng)絡(luò)全面覆蓋我們的生活，基本上各家門店都有wifi標(biāo)志，而且有的還沒有密碼，蹭WiFi似乎已成為一項(xiàng)基本“生存技能”，現(xiàn)代人的基本狀態(tài)就像下面這首打油詩一樣：

枯藤老樹昏鴉，空調(diào)Wifi西瓜

葛優(yōu)同款沙發(fā)，我就往那一趴

如果企業(yè)沒有對(duì)自家應(yīng)用做好數(shù)據(jù)防護(hù)，蹭網(wǎng)的同時(shí)，用戶個(gè)人隱私也暴露在互聯(lián)網(wǎng)中，不安全協(xié)議傳輸數(shù)據(jù)，直接導(dǎo)致用戶數(shù)據(jù)被中間人劫持獲取。

同時(shí)，流量被劫持獲取，可以直接對(duì)服務(wù)器發(fā)起攻擊，獲取服務(wù)器業(yè)務(wù)數(shù)據(jù)、用戶數(shù)據(jù)等核心資產(chǎn)信息。那么企業(yè)應(yīng)該如何去避免此類攻擊的發(fā)生呢？首先得去了解一下中間人攻擊的前因后果。

中間人攻擊的前因后果

協(xié)議先天性缺陷

（1）HTTP明文傳輸導(dǎo)致用戶信息泄露？

從攻擊的視頻中可以知道，攻擊者是實(shí)施了HTTP協(xié)議的中間人攻擊，相信每個(gè)計(jì)算機(jī)行業(yè)人員都知道，超文本傳輸協(xié)議（HTTP，HyperText TranSfer Protocol）是互聯(lián)網(wǎng)上應(yīng)用最為廣泛的一種網(wǎng)絡(luò)協(xié)議，所有的WWW文件都必須遵守這個(gè)標(biāo)準(zhǔn)，也就是說萬維網(wǎng)不得不使用這個(gè)協(xié)議，也是非常的尷尬。

從攻擊者的角度是怎么看待這個(gè)問題呢？

尋找一個(gè)采用HTTP協(xié)議傳輸數(shù)據(jù)的網(wǎng)站系統(tǒng)，這里針對(duì)用戶登錄的賬號(hào)信息進(jìn)行數(shù)據(jù)獲取，使用WireShark流量分析工具對(duì)局域網(wǎng)下的用戶HTTP數(shù)據(jù)包進(jìn)捕獲，參考下圖：

對(duì)TCP數(shù)據(jù)流進(jìn)行數(shù)據(jù)分析，可以發(fā)現(xiàn)，存在明文的用戶名uname和密碼password，參考下圖：

總結(jié)：由此可見HTTP數(shù)據(jù)流是用明文方式傳輸數(shù)據(jù)，攻擊者可以利用局域網(wǎng)抓包等手段輕易獲取用戶與服務(wù)器的交互信息。?

（2）為什么HTTP是明文傳輸？

從上一小節(jié)可以知道攻擊者抓取的HTTP數(shù)據(jù)包里面的數(shù)據(jù)是明文，為了解明文傳輸?shù)脑?#xff0c;可以先了解以下在OSI七層模型中HTTP協(xié)議工作的地方，OSI模型七個(gè)層次的功能以及協(xié)議集圖示如下：

根據(jù)OSI七層模型，可以知道HTTP協(xié)議工作在應(yīng)用層，再來看看HTTP數(shù)據(jù)包的封裝過程，發(fā)送方在客戶端頁面輸入上層數(shù)據(jù)，上層數(shù)據(jù)到傳輸層會(huì)添加TCP報(bào)頭形成數(shù)據(jù)段，再下送到網(wǎng)絡(luò)層添加IP報(bào)頭形成數(shù)據(jù)段，在繼續(xù)下送至數(shù)據(jù)鏈路層添加以太網(wǎng)首部和尾部，形成以太網(wǎng)幀，最后傳遞至物理層形成01010形式的比特流，整個(gè)過程，上層數(shù)據(jù)這一部分沒有進(jìn)行任何加密數(shù)據(jù)處理，參考下圖：

同理接收方也是如此，接受方收到二進(jìn)制比特流，通過層層上送解包，最終獲取明文的上層數(shù)據(jù)，參考下圖：

總結(jié)：HTTP雖然是應(yīng)用層的協(xié)議，但是其數(shù)據(jù)在整個(gè)數(shù)據(jù)裝包中都是處于明文狀態(tài)，只是不同層次之間進(jìn)行了包的封裝轉(zhuǎn)換，在不同層次會(huì)看到不同的數(shù)據(jù)，比如在物理層，只能看到0101010類型的二進(jìn)制比特流，但是在應(yīng)用層卻可以看到明文的數(shù)據(jù)，整個(gè)過程只是一個(gè)數(shù)據(jù)包的封裝和解包，沒有設(shè)計(jì)數(shù)據(jù)的加密和解密操作。

（3）中間人攻擊的根源是什么？

通過了解HTTP明文傳輸?shù)姆治鲞^后，結(jié)合OSI七層模型每一層的含義，參考如下：

路由器是存在于OSI七層模型的網(wǎng)絡(luò)層，也就是通常接觸最多的局域網(wǎng)，家里接入有線或者無線網(wǎng)絡(luò)都會(huì)設(shè)置路由器，用戶通過接入路由器與外界網(wǎng)絡(luò)進(jìn)行聯(lián)系。

中間人攻擊也是在這一層面實(shí)施攻擊的，這一層存在的協(xié)議參考OSI七層模型可以知道有IP，ARP，ICMP等協(xié)議。在路由器層面，也就是局域網(wǎng)內(nèi)是通過地址解析協(xié)議即ARP（AddreSS ReSolution Protocol），根據(jù)IP地址獲取物理地址進(jìn)行目標(biāo)尋址交流。大概的流程內(nèi)容如下：

• 主機(jī)發(fā)送信息時(shí)將包含目標(biāo)IP地址的ARP請(qǐng)求廣播到網(wǎng)絡(luò)上的所有主機(jī)，并接收返回消息，以此確定目標(biāo)的物理地址；

• 收到返回消息后將該IP地址和物理地址存入本機(jī)ARP緩存中并保留一定時(shí)間，下次請(qǐng)求時(shí)直接查詢ARP緩存以節(jié)約資源。

ARP協(xié)議沒有安全認(rèn)證機(jī)制，因?yàn)榫钟蚓W(wǎng)內(nèi)主機(jī)是建立在信任的基礎(chǔ)上的，所以只要主機(jī)接收到ARP應(yīng)答包，都會(huì)緩存在ARP表中，這就為ARP欺騙提供了可能。攻擊者可以發(fā)送錯(cuò)誤的IP地址MAC地址的映射關(guān)系。

ARP欺騙主機(jī)等攻擊是最常見的中間人攻擊，在同一個(gè)局域網(wǎng)中，通過將網(wǎng)卡設(shè)置為混雜模式，借助ARP欺騙實(shí)現(xiàn)中間人攻擊即可監(jiān)聽目標(biāo)設(shè)備的網(wǎng)絡(luò)通信。ARP攻擊原理如下圖：

主機(jī)A IP:192.168.1.2 MAC:02-02-02-02-02-02

主機(jī)B IP:192.168.1.3 MAC:03-03-03-03-03-03

網(wǎng)關(guān) IP:192.168.1.1 MAC:01-01-01-01-01-01

主機(jī)B為攻擊者，向被攻擊者主機(jī)A不斷發(fā)送ARP響應(yīng)數(shù)據(jù)包內(nèi)容：IP：192.168.1.1對(duì)應(yīng)MAC：03-03-03-03-03-03 向網(wǎng)關(guān)不斷發(fā)送ARP響應(yīng)包內(nèi)容：192.168.1.2對(duì)應(yīng)MAC：03-03-03-03-03-03，在局域網(wǎng)內(nèi)，廣播尋址是根據(jù)MAC地址來定位用戶地址的，所以，一旦mac地址進(jìn)行了改變，用戶地址也就進(jìn)行了改變，由于ARP會(huì)更新緩存表的特性，導(dǎo)致了攻擊者可以通過不斷發(fā)送ARP響應(yīng)包達(dá)到欺騙網(wǎng)關(guān)和被攻擊者的目的，代替用戶與網(wǎng)關(guān)進(jìn)行信息交互，同時(shí)代替網(wǎng)關(guān)與用戶聯(lián)系，進(jìn)而形成了中間人攻擊。

總結(jié)：ARP緩存接受任何時(shí)間更新成為中間人攻擊的根本原因

安全協(xié)議不安全

（1）HTTPS加密傳輸也存在信息泄漏？

開發(fā)人員針對(duì)部分不安全協(xié)議進(jìn)行了安全控制，采用HTTP+SSL的方式進(jìn)行數(shù)據(jù)傳輸，也就是我們常說的HTTPS協(xié)議。使用安全套接字層（SSL）進(jìn)行信息交換，簡(jiǎn)單來說就是HTTP的安全版，來保證傳輸?shù)臄?shù)據(jù)安全。

從攻擊者的角度是怎么看待這個(gè)問題呢？

可以通過實(shí)驗(yàn)來看結(jié)果，選擇QQ郵箱登錄網(wǎng)站，該網(wǎng)站使用HTTPS，使用WireShark抓包查看TCP數(shù)據(jù)量

追蹤TCP數(shù)據(jù)流，數(shù)據(jù)全是亂碼，無法識(shí)別數(shù)據(jù)，很明顯數(shù)據(jù)已經(jīng)被加密了，通過抓包并沒有獲取用戶信息。

到這里一定會(huì)存在一個(gè)疑問，如果我的App與服務(wù)器全部采用HTTPS通信不就沒有中間人攻擊的問題了嗎？

事實(shí)上如果用自己偽造的CA證書去加解密數(shù)據(jù)包，一樣可以獲取到敏感信息，大致攻擊思路：攻擊者在設(shè)備上導(dǎo)入并信任自己的CA證書，然后利用該證書進(jìn)行數(shù)據(jù)的加密和解密，在這個(gè)過程中，明文信息已經(jīng)被暴露在攻擊者面前。

比如這里，將CA證書導(dǎo)入設(shè)備讓其信任，使用工具抓包，能夠清晰看見HTTPS數(shù)據(jù)包的信息。同樣是qq郵箱登錄的數(shù)據(jù)，區(qū)別就在于使用工具之前我讓設(shè)備信任了自己的CA證書。當(dāng)然這里并沒有抓到明文密碼，這是由于qq郵箱還有其他數(shù)據(jù)安全加密設(shè)置，參考下圖：

總結(jié)：HTTPS證書信任機(jī)制出現(xiàn)問題，還是可以進(jìn)行中間人攻擊截取用戶明文的數(shù)據(jù)流量。

（2）HTTPS為什么存在安全風(fēng)險(xiǎn)？

從上一節(jié)可以了解到，HTTPS加密協(xié)議也是存在中間人攻擊的，為了解攻擊的原理，我們可以先來看一看HTTPS的握手過程。這里以支付寶為例，利用WireShark獲取支付寶的HTTPS數(shù)據(jù)流量進(jìn)行分析

客戶端發(fā)送Client Hello請(qǐng)求建立HTTPS鏈接，服務(wù)器返回Server Hello回應(yīng)客戶端接收到請(qǐng)求，并下發(fā)HTTPS證書給客戶進(jìn)行驗(yàn)證，客戶端驗(yàn)證通過，發(fā)送對(duì)稱加密密鑰，進(jìn)行數(shù)據(jù)交換。能夠非常直觀的看出握手流程，簡(jiǎn)單的HTTPS實(shí)現(xiàn)圖

如果客戶端未嚴(yán)格校驗(yàn)證書或者忽略了域名校驗(yàn)，攻擊者可以通過對(duì)客戶端進(jìn)行操作，從而繞過客戶端的弱校驗(yàn)，達(dá)到欺騙服務(wù)器，進(jìn)行中間人攻擊的目的。簡(jiǎn)單例舉了HTTPS存在的問題

• 忽略SSL證書校驗(yàn)

• 忽略域名校驗(yàn)

• 證書信息泄漏?

情況一、信任任何證書。出現(xiàn)這種情況的原因很有可能是使用的開源通信庫存在缺陷，還有就是開發(fā)人員在開發(fā)過程中未連接生產(chǎn)環(huán)境的服務(wù)器，為解決認(rèn)證過程中證書報(bào)錯(cuò)的問題只能暫時(shí)修改代碼使其APP信任任意證書，而在上線前未對(duì)此代碼進(jìn)行處理。通過對(duì)APP進(jìn)行逆向分析，可以在客戶端代碼中發(fā)現(xiàn)存在開發(fā)人員忽略證書認(rèn)證的代碼片段

該段代碼重寫了谷歌原有X509Certificate[]的校驗(yàn)方式，進(jìn)行了覆蓋，卻沒有添加自己的證書校驗(yàn)代碼，導(dǎo)致證書校驗(yàn)的代碼為空，攻擊者可以使用任意證書進(jìn)行流量劫持，這里利用了工具自簽名一個(gè)證書，即可進(jìn)行HTTPS證書校驗(yàn)繞過，參考下圖：

情況二、信任證書管理機(jī)構(gòu)（CA）頒發(fā)的證書。這種情況的APP可以信任任何CA頒發(fā)的證書，據(jù)說這類的證書只需50美元就能買到。此類問題出在AFNetworking 2.5.2及之前的版本，也就是說如果某APP使用了此版本的開源通信庫，在不安全Wifi網(wǎng)絡(luò)中的黑客、VPN網(wǎng)絡(luò)中的職工或者國(guó)家支持的黑客，只要使用CA頒發(fā)的證書就可以對(duì)該APP的HTTPS加密數(shù)據(jù)進(jìn)行監(jiān)聽或者篡改，在源代碼中發(fā)現(xiàn)配置代碼片段：

該段代碼一個(gè)重要的配置ALLOW_ALL_HOSTNAME_VERIFIER,使其信任官方的CA證書，無論是頒發(fā)給誰的，只要是官方的證書，都可以信任，從而導(dǎo)致驗(yàn)證失敗。

情況三、信任合法證書。這種情況的APP只信任對(duì)自己而言合法的證書，首先我們看一下SSL認(rèn)證的原理的前三步：1、客戶端向服務(wù)器傳送客戶端SSL協(xié)議的版本號(hào)，加密算法的種類，產(chǎn)生的隨機(jī)數(shù)，以及其他服務(wù)器和客戶端之間通訊所需要的各種信息。2、服務(wù)器向客戶端傳送SSL協(xié)議的版本號(hào)，加密算法的種類，隨機(jī)數(shù)以及其他相關(guān)信息，同時(shí)服務(wù)器還將向客戶端傳送自己的證書。3、客戶端利用服務(wù)端傳過來的信息驗(yàn)證服務(wù)器的合法性，服務(wù)器的合法性包括：證書是否過期，發(fā)行服務(wù)器證書的CA是否可靠，發(fā)行者證書的公鑰能否正確解開服務(wù)器證書的“發(fā)行者的數(shù)字簽名”，服務(wù)器證書上的域名是否和服務(wù)器的實(shí)際域名相匹配。如果合法性驗(yàn)證沒有通過，通訊將斷開；如果合法性驗(yàn)證通過，將繼續(xù)進(jìn)行下一步。那么如何讓APP信任非法的證書呢，看上文說到的3步，我們只需要做到在合法性驗(yàn)證的時(shí)候能夠欺騙APP，通訊就不會(huì)中斷。在手機(jī)本地添加一個(gè)信任證書，APP在本地驗(yàn)證的時(shí)候，由于手機(jī)信任該證書，APP默認(rèn)也信任該證書，達(dá)到欺騙APP的目的。

情況四、這種情況是采用了服務(wù)器和客戶端雙向認(rèn)證的措施，即客戶端在確認(rèn)服務(wù)器是否合法之后，服務(wù)器也要確認(rèn)客戶端是否是合法的（服務(wù)器要求客戶發(fā)送客戶自己的證書。收到后，服務(wù)器驗(yàn)證客戶的證書，如果沒有通過驗(yàn)證，拒絕連接；如果通過驗(yàn)證，服務(wù)器獲得用戶的公鑰）。正是這個(gè)原因，我們?cè)跍y(cè)試APP時(shí)會(huì)發(fā)現(xiàn)盡管我們信任了burp或者fiddler的證書，可是在進(jìn)行登錄操作時(shí)APP依然會(huì)顯示網(wǎng)絡(luò)連接錯(cuò)誤，此時(shí)服務(wù)端已經(jīng)知道客戶端可能是非法的，然后拒絕連接。如果你是開發(fā)人員，想分析HTTPS流量也很簡(jiǎn)單：使用burp導(dǎo)入客戶端證書，此時(shí)burp就可以與服務(wù)器正常的建立連接，你也可以正常的截取到數(shù)據(jù)包了，只要獲取到證書以及密鑰，即可進(jìn)行數(shù)據(jù)獲取。APP開發(fā)時(shí)，在本地實(shí)現(xiàn)證書導(dǎo)入，應(yīng)用于HTTPS雙向校驗(yàn)傳輸證書的密鑰可以在本地獲取，參考實(shí)現(xiàn)代碼片段

分析上例代碼可以發(fā)現(xiàn)，應(yīng)用于證書client.p12的密鑰，猜測(cè)在he.b()/he.a()函數(shù)中會(huì)進(jìn)行一個(gè)處理，利用hook技術(shù)，對(duì)函數(shù)內(nèi)容進(jìn)行hook，即可獲取字符串信息，該信息包括了密鑰和其他的數(shù)據(jù)，利用獲取的密鑰和本地保存的client.p12證書，即可模擬開發(fā)人員進(jìn)行HTTPS雙向驗(yàn)證，截取用戶明文信息。

兩者代碼片段分別如下

總結(jié)：HTTPS安全協(xié)議不安全，主要還是在設(shè)計(jì)階段選擇了單向校驗(yàn)，在加上后期沒有進(jìn)行嚴(yán)格的證書校驗(yàn)，導(dǎo)致HTTPS證書驗(yàn)證被繞過，其次就是采用了雙向校驗(yàn)，但是本地校驗(yàn)的代碼沒有進(jìn)行安全保護(hù)，攻擊者通過動(dòng)態(tài)HOOK，也是可以獲取CA證書以及其密鑰信息。

（3）HTTPS中間人攻擊的危害？

HTTPS雖然也存在中間人攻擊，但是和ARP局域網(wǎng)攻擊又存在很大的差別，參考下圖：

ARP欺騙，數(shù)據(jù)信息攻擊獲取范圍是介于路由器和用戶手機(jī)之間，也就是OSI模型的數(shù)據(jù)鏈路層，路由器和用戶手機(jī)之間傳輸?shù)男畔⒍伎赡鼙还粽呓厝?#xff0c;通過中間人攻擊獲取在同一局域網(wǎng)下所有用戶的數(shù)據(jù)流量

SSL欺騙，SSL是位于OSI模型的傳輸層和應(yīng)用層之間，可以通過繞過APP本地校驗(yàn)機(jī)制實(shí)現(xiàn)在傳輸層和應(yīng)用層之間的數(shù)據(jù)傳輸（數(shù)據(jù)到達(dá)應(yīng)用層，也就是給用戶的展示界面是明文的）截取，從而獲取明文數(shù)據(jù)，或者是HTTPS相關(guān)的密鑰信息。僅存在用戶自己手機(jī)內(nèi)部，只能獲取攻擊者本身操作的賬戶流量信息

總結(jié)：就攻擊范圍來講，在客戶端的攻擊HTTPS攻擊是影響面比較窄，但就針對(duì)服務(wù)端的攻擊影響來看，兩者是一致的，都可以操作服務(wù)端數(shù)據(jù)，獲取服務(wù)端信息，都能危及服務(wù)器安全。

幾維安全解決方案

應(yīng)對(duì)傳輸協(xié)議缺陷，流量被劫持的安全風(fēng)險(xiǎn)，幾維安全建議以協(xié)議安全，數(shù)據(jù)安全，應(yīng)用代碼安全為目標(biāo)來應(yīng)對(duì)中間人攻擊。

首先對(duì)客戶端APP的可執(zhí)行文件DEX、SO、Mach-O被破解的風(fēng)險(xiǎn)，幾維安全采用源代碼保護(hù)技術(shù)，對(duì)DEX文件進(jìn)行JAVA2C，將JAVA代碼下沉至Native層，并在該層對(duì)轉(zhuǎn)化后的偽C代碼進(jìn)行強(qiáng)度最高的虛擬化處理，對(duì)SO和Mach-O文件采用源代碼編譯的方式，直接把C/C++/Object-C/Swift工程項(xiàng)目編譯成KiwiVM虛擬化后的結(jié)果，保障客戶的不被攻擊者逆向破解。

其次對(duì)在終端設(shè)備運(yùn)行的客戶端運(yùn)行時(shí)會(huì)在內(nèi)存中傳遞重要的數(shù)據(jù)，通過接入幾維安全防御安全SDK，可以對(duì)手機(jī)環(huán)境，進(jìn)程防護(hù)，代碼注入等方面進(jìn)行全面的檢測(cè)和防護(hù)，保證本地內(nèi)存數(shù)據(jù)不遭受惡意篡改。

同時(shí)，針對(duì)通道存在的明文傳輸和協(xié)議破解偽造風(fēng)險(xiǎn)，幾維安全提供結(jié)合代碼虛擬化技術(shù)和白盒技術(shù)研發(fā)的白盒密鑰SDK。利用SDK對(duì)傳輸?shù)臄?shù)據(jù)和存儲(chǔ)的數(shù)據(jù)進(jìn)行高強(qiáng)度的加密，且提供動(dòng)態(tài)加密、數(shù)據(jù)完整性校驗(yàn)等功能，支持多種對(duì)稱加密、非對(duì)稱加密和哈希算法，嚴(yán)格保障了數(shù)據(jù)的完整性和保密性。

?

轉(zhuǎn)載于:https://www.cnblogs.com/ydaq/p/11120308.html

總結(jié)

以上是生活随笔為你收集整理的传输协议不安全，数据泄露谁之过？——流量劫持技术分析的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。