研究人員發現蘋果設備在PEAP認證上存在缺陷，攻擊者可強迫蘋果設備接入惡意熱點。研究人員稱，即使身份驗證服務器（RADIUS）也不能證明密碼的真實性，該錯誤依然允許攻擊者強制任何Apple設備（iOS，macOS或tvOS）與惡意接入點關聯。

初遇CVE-2019-6203

報告撰寫者dominic稱，去年我們在準備Defcon的演講時，邁克爾（另一位研究人員）和我正嘗試實施hostapd-wpe的EAP攻擊試驗。在此次攻擊中，身份驗證服務器將接受任何用戶名，之後的動作並非將證明密碼內容返回到工作站的步驟（因為它不知道密碼），而是將EAP成功消息發送回工作站。

“對於邁克爾的執著，我拒絕了很長一段時間。因為我覺得這種攻擊方案不會奏效。因為在MSCHAPv2中，驗證服務器實際上證明了密碼內容回到決策端的過程，即使不能，我認為決策段也會拒絕繼續執行，畢竟這就是保障安全的重點。”

令dominic出乎意料的是，在唯一的一次測試中hostapd-wpe的EAP攻擊試驗竟然成功了，幾乎全部接受實驗的Apple設備（iPad，iPhone，MacBook）都成功連接到惡意接入點。由於WPE是由Brad Antoniewicz編寫的，我只得向他詢問問題所在：

在這之後，dominic針對此次發現進行了大量研究，並在4月份嘗試進行了CVE-2019-6203漏洞攻擊的再現實驗。

復現Apple漏洞

復現攻擊的第一步，是找出漏洞的所在之處。通常來說，PEAP-MSCHAP v2的認證過程分為兩個階段：

1、驗證服務器身份和建立TLS隧道。服務端將向客戶端發送服務端的證書信息，通過後建立TLS隧道保護傳輸的數據。

2、在TLS隧道內通過MSCHAP v2進行雙向認證。

在Frame 4、Frame 5中，驗證者和客戶端的Response都是通過雙方的Challenge + passwordHash + Username計算得出的，並發向對方進行身份驗證。

那麼，如何復現Apple漏洞攻擊呢？

2008年，安全研究員Joshua Wright編寫了一個名為FreeRADIUS 的補丁。Wright的WPE攻擊試驗同樣使用了繞過PEAP-MSCHAP v2的方式，最終，它可以通過建立虛假PEAP-MSCHAPv2熱點得到個人用戶請求，並在第二階段獲取Challenge、NTResponse 和Username。

“與之類似的原理，同樣可以應用在此次研究中。”dominic稱，我用同樣的方式複現了PEAP認證上的漏洞攻擊CVE-2019-6203。

具體方法如下：

安裝：

hostapd-wpehttps://github.com/OpenSecurityResearch/hostapd-wpe/blob/master/hostapd-wpe.patch 這是在Kali中使用“apt-get install hostapd-wpe”完成的，以下假定該方法。

使用-e開關運行它以啟用“EAP Success”

https://github.com/OpenSecurityResearch/hostapd-wpe/blob/master/README#L135

在iOS設備上，在Wifi下，連接到“hostapd-wpe”網絡。選擇信任證書。可以使用任何憑據。

設備將連接，運行dnsmasq以分發DHCP將顯示設備獲取IP。

使用以下示例配置嘗試使用wpa_supplicant進行相同的客戶端連接將不起作用：

network = {

ssid =“hostapd-

wpe ” key_mgmt = WPA-EAP

eap = PEAP

phase2 =“auth = MSCHAPV2”

identity =“test”

password =“password”

ca_cert =“/ etc / hostapd-wpe / certs / ca.pem “

}

如此一來，將看到請求者將拒絕最終的消息驗證者並斷開連接。

修復問題及解決方案

復現試驗中，未打補丁的Apple設備跳過發送驗證器響應並且僅按照第7幀發送MSCHAPv2成功幀。這導致易受攻擊的Apple設備輕鬆在其狀態機制中跳過。隨後它會發送一個PEAP響應——hostapd-wpe向其發送EAP-Success。

dominic稱，這意味著如果Apple設備連接到未知用戶密碼的惡意AP，它不僅會獲得NetNTLMv1質詢響應，設備也將連接到網絡。由於EAP的網絡通常是企業網絡，Apple設備會認為它與之相關（沒有用戶交互），此時也可以進行響應式攻擊。

該缺陷影響2019年3月25日前的iOS、macOS、tvOS版本，包含MacBook、iPhone、iPad、Apple TV等多種蘋果設備。但令dominic感到困惑的是，已修補的設備在PEAP，MSCHAPv2和WPA2級別上表現出完全相同的行為，即設備仍然連接到網絡，在某些情況下甚至會請求DHCP。這是一個例子：

相反，Apple 在連接後使設備與網絡斷開連接。設備顯示“無法連接”錯誤，並且設備上顯示的日誌條目顯示：

Dominic解釋道，這有點像一名保安在守護一座大樓，一旦有人進去無論是誰都會被全部趕出去。雖然它具有解決問題的效果，但很讓人擔心會不會暴漏出其他危險訊號。

“然而，在測試修復後的系統時，我確實注意到一個異常值，當在設備連接但導出不同的PMK時，握手的第二個消息中由MIC證明（這就是repo中的WPA代碼所用的）出現了異常。當然，我覺得這只是一次偶然，因為PMK來自外部TLS會話並且未啟用加密綁定，這應該是沒有可能的。”

目前，Dominic仍不能確認這個問題是否真的存在，他表示會在之後的研究中用多台蘋果設備展開試驗，找出答案。

建議：

驗證在最終EAP-Success消息中發送的消息驗證器，並且不允許iOS / macOS設備連接到無法證明用戶密碼知識的惡意接入點。

可以在以下位置找到執行此驗證的wpa_supplicant示例：

https ：//w1.fi/cgit/hostap/tree/src/eap_peer/mschapv2.c#n112