作者：軒夏

0x00概述

---

中間人攻擊（Man-in-the-Middle Attack，簡稱“MITM攻擊”）是一種“間接”的入侵攻擊，這種攻擊模式是透過各種技術手段將受入侵者控制的一臺計算機虛擬放置在網路連線中的兩臺通訊計算機之間，這臺計算機就稱為“中間人”。透過中間人攻擊可以竊取資訊、進行篡改、欺騙等多種攻擊。

對於Android平臺上的中間人攻擊已經討論的比較多，今天來聊聊iOS平臺上的中間人攻擊，以及iOS的可信證書管理。

0x01中間人攻擊

---

在未做特殊說明的情況下，本文所有實驗環境為：

iPhone 5 + iOS 8.1.2 + 已越獄。

1.1. 中間人攻擊分級

iOS平臺上根據中間人攻擊的難度，可以將中間人攻擊分為3個等級：

1) level1:在沒用向手機中安裝攻擊者證書的情況下可以進行中間人攻擊

2) level2:在向手機中安裝攻擊者證書的情況下可以進行中間人攻擊

3) level3:在向手機中安裝攻擊者證書的情況下也不可以進行中間人攻擊

對於這三種情況，我們以一個例子分別對這三種情況進行說明。借用Owasp關於iOS https中間人演示的例子，稍做修改。正常情況下，程式啟動時如圖1，點選“Fetch Secret”程式請求server端資料並顯示，如圖2。

圖 1 啟動介面

圖 2 正常獲取資料

1.1.1. 不匯入證書可中間人

在此次連線的NSURLConnection物件的delegate類中只實現一個connection:didReceiveAuthenticationChallenge:方法，如圖3。

圖 3 連線校驗方法

設定burp suite，開啟代理，如圖4。

圖 4 burp suite設定

手機設定代理為burp suite執行pc的地址，如圖5。

圖 5 手機代理設定

執行程式，點選“Fetch Secret”，程式正常獲取到了與圖2相同的資料，burp suite也截獲了所有資訊，如圖6，中間人攻擊成功。

圖 6 burp suite截獲資料

1.1.2. 匯入證書可中間人

修改程式，在NSURLConnection物件的delegate類中實現connection:willSendRequestForAuthenticationChallenge:方法，如圖7。

圖 7 連線校驗方法

其他設定與1.1.1小節完全相同，程式發現連線異常，終止獲取資料，如圖8，burp suite也理所當然獲取資料失敗。

圖 8 獲取資料失敗

此時，向手機中安裝burp suite證書，如圖9。

圖 9 安裝burp證書

重新開啟應用，點選“Fetch Secret”，應用正常獲取資料，burp suite也截獲了全部資料，中間人攻擊成功。

1.1.3. 匯入證書不可中間人

繼續對程式進行修改，將公鑰證書放入應用中，並修改connection:didReceiveAuthenticationChallenge:方法在連線過程中獲取證書資訊，對server端證書進行強校驗，如圖10。同時，註釋掉connection:willSendRequestForAuthenticationChallenge:方法，因為如圖實現了這個方法，方法connection:didReceiveAuthenticationChallenge:將不會被呼叫。

圖 10 連線校驗方法

其他設定不變，手機中依然安裝有burp suite證書，開啟應用，點選“Fetch Secret”，應用無法正常獲取資料，如圖11，burp suite也不能截獲資料，中間人攻擊失敗。

圖 11 證書錯誤

1.2.4一些建議

一般來說，建議應用信任手機中的所有證書即可，在應用中置入公鑰證書對連線進行強校驗確實最為安全，但會引發諸多問題，如證書更新、證書過期、證書作廢等。

如果需要更新客戶端證書，都必須升級客戶端版本，而升級客戶端是一個較為漫長的過程。 例如證書被駭客竊取，需要緊急作廢證書，而許多使用者卻有沒有及時升級客戶端的習慣，這將可能導致大面積使用者使用出現網路異常的情況。就目前來看，也確實很少看到有應用將安全級別做到level3。

0x02可信證書管理

---

上一章節中談到向手機中匯入可信證書的問題，小生在編寫一個iOS工具的時候無意發現iOS證書管理的一個有趣的地方。透過“Settings”->“General”->“Profiles”可以檢視當前裝置信任的證書列表，但這個列表就真的是裝置信任的證書列表嗎？

2.1奇葩的中間人攻擊情形

按照上一章節建議，將應用防中間人級別設定為level2，即應用信任當前裝置上的所有證書，如果要使用burp suite對該應用進行中間人攻擊，需要向裝置中安裝burp的證書，而目前裝置上的信任證書如圖12所示，裝置上只有一個用於連線公司內網的員工證書。

圖 12 證書列表

在這樣的情況下，burp suite應該不能獲取到應用的通訊內容，而結果如何了。為了排除結果受到iOS系統在https通訊時的10分鐘快取機制，先對裝置進行重啟或靜置10分鐘；啟動應用進行通訊，發現應用正常獲取到了與圖2所示相同的資料，而burp suite也成功截獲了與圖6所示相同的通訊內容。這是什麼鬼……

2.2 TrustStore.sqlite3

iOS系統下有一個有一個sqlite3檔案，其絕對路徑為：

“/private/var/Keychains/TrustStore.sqlite3”

該檔案中儲存的才是當前裝置真正信任的證書列表，而透過“Settings”->“General”->“Profiles”檢視到的證書列表與該檔案中儲存的證書列表可以不同步，如果我們手動對該sqlite3檔案進行更改，就能讓手機實際的可信證書列表與在“Profiles”中看到的完全不一樣。小生寫了一個工具，對該sqlite3檔案進行管理，檢視該檔案中的儲存，如圖13。

圖 13 證書列表

其中，ID為0的證書是圖12中看到的用於連線公司內網的員工證書；ID為1的證書為burp suite證書，而這張證書沒有在“Profiles”中顯示。這就是導致能中間人的原因。

我們刪除掉該sqlite3檔案中的ID為1的證書，如圖14，並對裝置進行重啟或靜置10分鐘，再進行2.1章節中的實驗。

圖 14 刪除burp證書

開啟應用，點選“Fetch Secret”，應用報錯，如圖15。

圖 15 證書錯誤

如果重新將burp suite證書手動插入TrustStore.sqlite3檔案中，如圖16，並對裝置進行重啟或靜置10分鐘，再進行2.1章節中的實驗，發現中間人攻擊成功。而本文中對TrustStore.sqlite3檔案的所有手動操作，都不會影響到“Profiles”中的任何顯示，“Profiles”始終只顯示一張員工證書。

圖 16 插入證書

2.3不顯示證書的中間人攻擊（越獄後環境）

根據2.1和2.2小節的描述，如果攻擊者透過越獄外掛、甚至是透過某些猥瑣手段逃過App Store檢查的惡意應用，對已越獄的iphone手機上的檔案“/private/var/Keychains/TrustStore.sqlite3”進行修改，向其中插入了一張攻擊者證書，例如burp suite證書，攻擊者就可以在受害者的閘道器上神不知鬼不覺的進行中間人攻擊（當然level3安全級別下的應用是沒門的），受害者完全不知情，因為受害者透過“Settings”->“General”->“Profiles”檢視可信證書的時候，不會發現任何異常，即可以在不顯示證書的情況下竊取受害者資料、進行篡改等。

所以，對於已越獄的手機，不要以為“Settings”->“General”->“Profiles”下沒有安裝一些奇奇怪怪的證書就高枕無憂了。

0x03小節

---

iOS系統的中間人攻擊方法與防範措施，總結在在0x01章節中，小生認為普通應用只需要信任當前裝置上的所有可信證書即可。關於iOS系統的可信證書列表，越獄過的朋友還是去檢查下“/private/var/Keychains/TrustStore.sqlite3”檔案中是否有“Profiles”中未顯示或顯示不對等的情況。