HTTPS中間人攻擊實踐（原理·實踐）

 

前言

很早之前看過HTTPS的介紹，並瞭解過TLS的相關細節，也相信使用HTTPS是相對安全可靠的。直到前段時間在驗證https代理通道鏈接時，搭建了MITM環境，才發現事實並非我想的那樣。因爲部分應用開發者忽視證書的校驗，或者對非法證書處理不當，讓咱們的網絡會話幾乎暴露在攻擊者面前。

下文會向你們展現的對IOS系統上2款常見的應用（知乎，360瀏覽器）進行MITM攻擊，獲取或篡改用戶數據。

基本介紹

中間人攻擊的基本介紹可能看這裏（ https://zh.wikipedia.org/wiki/中間人攻擊）。大體是說一種在網絡中劫持會話的攻擊方案，若是隻監聽流量稱之爲被動網絡攻擊（passive network attack），如何攻擊者主動修改數據流稱之爲主動網絡攻擊（active network attack）。

好在20幾年前Https就出現了，在保證會話安全的同時也能很好的抵禦中間人攻擊（不過飄逸的應用開發者們老是能不經意的忽視這種保護）

網上對中間人攻擊的介紹還算多，不過具體到實踐的就相對要少不少（這裏是指針對https的中間人攻擊實踐）

 

 

上圖簡單的表述了中間人攻擊的主要過程（上部爲正常https流量，下部爲被劫持的https流量），後面咱們能夠對着這個圖來實施咱們本身的中間人攻擊。

準備中間人攻擊

須要提早準備些簡單常見工具：

1：Fiddler （注意雖然Fiddler抓取HTTPS報文的實際原理就是MITM，不過這裏固然不是用Fiddler實施中間人攻擊。由於Fiddler是自動完成的，也沒有實踐的意義，而且Fiddler須要被攻擊者本身提早導入並信任根證書）

2：一個已經申請SSL證書的域名 （須要域名也意味着還須要一臺代理該域名的nginx服務器，這裏之因此選擇一個真實的域名主要是爲儘量了還原現實的場景，若是您沒有域名也能夠用ip代替，不過證書仍是要提早準備好）

這裏用的是一個合法簽發的DV證書（網上其實能夠很容易找到免費的證書），通常瀏覽器或客戶端校驗證書時，都會先檢查證書是不是「受信任的根證書頒發機構」頒發，再檢查SSL證書中的證書吊銷列表，再檢查檢查此SSL證書是否過時，再檢查SSL證書的網站的域名是否與當前訪問域名一致。若是使用一個合法簽發的證書實際上能夠經過大部分校驗。

 

HTTPS 會話的發起是須要先創建SSL通道的。

咱們藉助Fiddler將全部HTTPS的流量引導到咱們本身的服務器【lulianqi.com】

引導流量須要使用到FreeHttp插件（ http://www.javashuo.com/article/p-dflfncnc-nc.html能夠在這裏下載該插件），插件安裝好後直接按下面截圖配置便可（FreeHttp自己具有強大的自定義報文篡改能力，若是有興趣能夠在前面連接處查看詳細內容）。

如上圖打開Fiddler進入FreeHttp插件頁籤，添加一個請求修改規則，點擊肯定，將規則添加到規則列表並勾選該規則，將其置爲可用。（若是您沒有域名也能夠用ip來代替，將http://lulianqi.com:443換成http://您服務器的ip:443便可）（注意圖中紅色線框標記的地方，如以上設置啓用規則）

這裏簡單說明下使用代理的HTTPS請求會利用Connect請求創建SSL通道，咱們修改Connect鏈接目標便可（由於這個時候SSL通道尚未創建，目標地址仍是明文，咱們能夠直接修改，這樣操做能夠模擬網絡中存在的攻擊）

 

FreeHttp默認跳過connect tunnels，因此這裏咱們須要在設置項裏設置is skip connect tunnels 爲否（按圖中提示操做便可）

 

而後是Fiddler本身的設置

如上圖，在Options中配置僅捕獲Connects，上面也有提到實際上咱們不須要Fiddler進行中間人攻擊，因此不用解密，也不用在客戶端導入證書

 

最後咱們須要配置咱們的服務器【lulianqi.com】上的nginx （固然，在這以前您的nginx須要在服務器上先安裝並配置好網絡）

如上圖咱們直接在nginx中添加一個server用於劫持會話（咱們本身的域名要解析過來），證書使用的是lulianqi.com的一個dv證書。

這個nginx實際是就是中間人了，如今咱們的中間人僅僅劫持流量（即被動網絡攻擊），但一旦流量到了咱們的服務器並且SSL通道是與咱們的服務器創建的，即表示咱們能夠任意的處理這些流量，隨時均可以進行主動網絡攻擊。

 

實施中間人攻擊

全部準備工做作完了咱們就能夠看下中間人攻擊的效果了

 

TLS對中間人攻擊的抵禦

固然正常狀況下，咱們的網絡安全確定不會這麼脆弱，因此暫時咱們在下面看到的是在一切正常的狀況下，看瀏覽器是如何藉助HTTPS（LTS）抵禦中間人攻擊的

用瀏覽器訪問https://www.baidu.com

得利於TLS證書體系，雖然咱們能發起中間人攻擊，不過瀏覽器察覺到了證書的異常（這個時候就怕你點繼續瀏覽）

瀏覽器如何知道當前通道存在風險的，瀏覽器一開始就知道本身須要鏈接的主機是www.baidu.com，咱們雖然經過網絡劫持的方式讓瀏覽器覺得咱們的中間人服務器就是www.baidu.com，不過咱們的中間人服務器卻沒有www.baidu.com的證書，因此咱們依然使用了lulianqi.com的證書，前面咱們也提到過了瀏覽器等客戶端會檢查「受信任的根證書頒發機構」，證書吊銷列表，SSL證書是否過時，證書籤發的域名。最後瀏覽器發現咱們證書籤發的域名不是www.baidu.com，天然就知道了當前網絡的風險，而後中止發送真實業務請求，並向用戶提示或詢問。

（證書的校驗有賴於CA，而CA通常都是比較權威的組織機構，咱們選擇信任他們)

 

若是用戶執意訪問，就會出現如上圖證書提示的錯誤，但一樣意味着您可能正處於攻擊下（事實上的確如此）

而後咱們我服務器就完美的劫持了用戶的會話，全部信息都暴露了（因此遇到這樣的提示仍是不要點確認比較好）

 補充說明下上圖及下文中相似的圖片都是中間人服務器nginx的訪問日誌，若是日誌中出現相應請求報文，即表示中間人攻擊實施成功。

 

這裏順便看下Chrome的表現

Chrome明顯對HSTS處理更爲出色。由於對於已經開啓嚴格安全傳輸HSTS的www.baidu.com，瀏覽器發現證書錯誤後，Chrome的作法是直接禁止訪問，而Edge依然能夠經過詢問的方式繼續訪問

 

上面的實例演示了中間人攻擊發起的基本過程，及瀏覽器是如何經過證書體系來抵禦中間人攻擊的。（HTTPS對中間人攻擊的抵禦）

還有一點須要說明上文及下文提到的流量或對話都是指HTTPS，若是您使用的是http那麼風險隨時都在。

 

 

沒法抵禦中間人攻擊的實例（知乎，360瀏覽器）

現實中咱們被手機陪伴的時間明顯更多，咱們下面來看下手機上移動應用是否能抵禦這種中間人攻擊。

許多應用使用HTTPS與後端進行通訊，這種作法在系統程序，網站及移動應用中很是常見。不幸的是，應用開發者每每沒有正確的對證書進行校驗，這樣系統實際對攻擊者敞開了懷抱。

QA流程應該包括證書校驗方面的測試。

 

首先咱們將手機連上Fiddler代理（注意這裏咱們不須要讓手機安裝或信任任何第三方證書）

咱們嘗試着如平常生活同樣使用手機（注意這裏測試使用的都是IOS上APP）

 

 

 

 

大部分應用出現了沒法訪問，彈出式安全提示等反應

不過不幸的是仍然有一些應用無視了證書的保護，直接與危險的中間人服務器創建了鏈接，並向用戶正常的顯示了頁面等數據。

下面列幾個表明性強的APP進行說明 （這裏不是特地選擇這些APP，只是我手機中正好安裝有，並且我的認爲這些APP你們也比較經常使用）

 

1：知乎 （IOS版 4.34.1（1228） ）

 

 

 

能夠清楚看到知乎是徹底無視了證書不匹配的錯誤，與沒有受到MITM時表現是同樣的，正常訪問，正常提交數據。但事實倒是全部流量都是經過中間人服務器轉發到知乎的，中間服務器解密了全部流量，而且能夠對其進行篡改。更糟的是這一切發生的時候，用戶是徹底不知情的。簡單的說就是當您在使用知乎APP瀏覽或發帖時，網絡節點中的任何別有用心的人都是能夠獲取您在瀏覽的內容，並對其進行修改。（這樣的描述一點都不誇張，後面會說明實際MITM中，也不會須要您的手機提早鏈接Fiddler代理，有許多可行且更隱祕的方式能夠將流量引入中間人服務器。若是應用不能識別到分享，就會跟上面描述的狀況同樣）

 2：360瀏覽器（IOS版本360瀏覽器 4.0.10）

其實某款特定APP因爲自身安全問題不能抵禦MITM，最多也只會影響到本身的APP及本身的用戶，不過瀏覽器若是出現這種問題就會對使用者全部瀏覽的網站都有影響

特別是以安全爲一大賣點的360，其自家瀏覽器的安全策略讓人沒法理解

 

 

 

 

 

 

上面的截圖來自使用360瀏覽器分別瀏覽baidu及apple的狀況，能夠看到使用360手機瀏覽器瀏覽網頁（開啓https的網站），在受到MITM時只有一個不起眼的變化，那個本來應該是綠色的小盾牌變成了灰色，而且沒有向用戶進行任何詢問，直接就創建了不安全的SSL通道，後面的狀況就很驚悚了，全部使用360手機瀏覽器瀏覽的內容所有被中間人服務器劫持。

一開始本身也並不相信360手機瀏覽器會直接無視證書錯誤，不向用戶詢問。特地找了另外一臺沒有安裝過360手機瀏覽器的手機（iphone6），在AppStore裏下載了新版本的360手機瀏覽器測試，結果是同樣的，除了那個不起眼的灰色小盾牌徹底無視了證書域名不匹配的錯誤。（順便提一下上面的知乎也同樣，都用新手機測試過，的確有安全問題）

 

3：其餘APP

固然我在本身手機了不僅發現上面2款APP存在上面的問題，還有許多APP存在相似的問題，包括個別金融類應用，還有部分APP部分模塊的流量存在被劫持的風險。這裏也就不一一列出。

經過上面的實踐能夠看出咱們平時使用的網絡並不安全，部分開發者忽視證書校驗，或對證書異常處理不當，致使原本十分有效LTS失去本來的防護能力。

 

 

改進

仍是強調下，我的對於上面提到的2款App（知乎，360瀏覽器）並無惡意，只是藉此說明下當前網絡大環境下確實存在的一些安全風險。

也但願2款APP的相關開發者看到後，能夠及時改進，爲用戶提供更安全的使用環境。

 

以上實踐測試環境（你們能夠此從新上面的效果）

手機：iphone6（10.3.3） ，iphone6s （11.3.1），iphone8 plus（11.2.1）    

服務器：CentOS （7.3） nginx （1.10.3） 

以上測試的2款應用均是蘋果版本的APP

知乎 （4.34.1）

360手機瀏覽器（4.0.10）

 

上述中間人攻擊實踐中使用到了Fiddler及FreeHttp插件僅是爲了方便控制及調試中間人攻擊的狀態，實際操做中並不須要Fiddler，也就是說你的手機不須要鏈接任何代理，由於每每流量的劫持發生在更隱蔽的網絡節點中，如鏈路中的網絡設備徹底能夠在無感的狀況下將通過本身的流量先轉發到中間人服務器,或者這種劫持也可能由DNS解析引發，您能夠嘗試修改host文件模擬dns劫持將目標域名指向中間人服務器一樣能夠獲得上面的結果。

事實上ARP欺騙，WPAD劫持，DNS劫持，BGP路由劫持，都會爲這種中間人攻擊創造條件（做爲網絡設備的控制者實施起來就更容易了，因此不要鏈接不認識的wifi熱點，固然對於網絡運營商咱們也只能選擇相信）

開發者只要正確的在所在平臺的底層TLS庫中開啓證書校驗，並對異常證書作合理處理，HTTPS仍是相對安全的。

 

以上內容僅作交流，請勿用於實際網絡攻擊。