0
雷鋒網(wǎng)5月18日消息，研究人員發(fā)現(xiàn)蘋果設(shè)備在PEAP認證上存在缺陷，攻擊者可強迫蘋果設(shè)備接入惡意熱點。
研究人員稱，即使身份驗證服務(wù)器（RADIUS）也不能證明密碼的真實性，該錯誤依然允許攻擊者強制任何Apple設(shè)備（iOS，macOS或tvOS）與惡意接入點關(guān)聯(lián)。
以下是雷鋒網(wǎng)對報告內(nèi)容進行的整理：
初遇CVE-2019-6203
報告撰寫者dominic稱，去年我們在準備Defcon的演講時，邁克爾（另一位研究人員）和我正嘗試實施hostapd-wpe的EAP攻擊試驗。在此次攻擊中，身份驗證服務(wù)器將接受任何用戶名，之后的動作并非將證明密碼內(nèi)容返回到工作站的步驟（因為它不知道密碼），而是將EAP成功消息發(fā)送回工作站。
“對于邁克爾的執(zhí)著，我拒絕了很長一段時間。因為我覺得這種攻擊方案不會奏效。因為在MSCHAPv2中，驗證服務(wù)器實際上證明了密碼內(nèi)容回到?jīng)Q策端的過程，即使不能，我認為決策段也會拒絕繼續(xù)執(zhí)行，畢竟這就是保障安全的重點?！?/p>
令dominic出乎意料的是，在唯一的一次測試中hostapd-wpe的EAP攻擊試驗竟然成功了，幾乎全部接受實驗的Apple設(shè)備（iPad，iPhone，Macbook）都成功連接到惡意接入點。由于WPE是由Brad Antoniewicz編寫的，我只得向他詢問問題所在：
在這之后，dominic針對此次發(fā)現(xiàn)進行了大量研究，并在4月份嘗試進行了CVE-2019-6203漏洞攻擊的再現(xiàn)實驗。
復現(xiàn)Apple漏洞
復現(xiàn)攻擊的第一步，是找出漏洞的所在之處。通常來說，PEAP-MSCHAP v2的認證過程分為兩個階段：
1、驗證服務(wù)器身份和建立TLS隧道。服務(wù)端將向客戶端發(fā)送服務(wù)端的證書信息，通過后建立TLS隧道保護傳輸?shù)臄?shù)據(jù)。
2、在TLS隧道內(nèi)通過MSCHAP v2進行雙向認證。
在Frame 4、Frame 5中，驗證者和客戶端的Response都是通過雙方的Challenge + passwordHash + Username計算得出的，并發(fā)向?qū)Ψ竭M行身份驗證。
那么，如何復現(xiàn)Apple漏洞攻擊呢？
2008年，安全研究員Joshua Wright編寫了一個名為FreeRADIUS 的補丁。Wright的WPE攻擊試驗同樣使用了繞過PEAP-MSCHAP v2的方式，最終，它可以通過建立虛假PEAP-MSCHAPv2熱點得到個人用戶請求，并在第二階段獲取Challenge、NTResponse 和 Username。
“與之類似的原理，同樣可以應用在此次研究中?！眃ominic稱，我用同樣的方式復現(xiàn)了PEAP認證上的漏洞攻擊CVE-2019-6203。
具體方法如下：
安裝：
hostapd-wpehttps://github.com/OpenSecurityResearch/hostapd-wpe/blob/master/hostapd-wpe.patch 這是在Kali中使用“apt-get install hostapd-wpe”完成的，以下假定該方法。
使用-e開關(guān)運行它以啟用“EAP Success”
https://github.com/OpenSecurityResearch/hostapd-wpe/blob/master/README#L135
在iOS設(shè)備上，在Wifi下，連接到“hostapd-wpe”網(wǎng)絡(luò)。選擇信任證書。可以使用任何憑據(jù)。
設(shè)備將連接，運行dnsmasq以分發(fā)DHCP將顯示設(shè)備獲取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 “
}
如此一來，將看到請求者將拒絕最終的消息驗證者并斷開連接。
修復問題及解決方案
復現(xiàn)試驗中，未打補丁的Apple設(shè)備跳過發(fā)送驗證器響應并且僅按照第7幀發(fā)送MSCHAPv2成功幀。這導致易受攻擊的Apple設(shè)備輕松在其狀態(tài)機制中跳過。隨后它會發(fā)送一個PEAP響應——hostapd-wpe向其發(fā)送EAP-Success。
dominic稱，這意味著如果Apple設(shè)備連接到未知用戶密碼的惡意AP，它不僅會獲得NetNTLMv1質(zhì)詢響應，設(shè)備也將連接到網(wǎng)絡(luò)。由于EAP的網(wǎng)絡(luò)通常是企業(yè)網(wǎng)絡(luò)，Apple設(shè)備會認為它與之相關(guān)（沒有用戶交互），此時也可以進行響應式攻擊。
該缺陷影響2019年3月25日前的iOS、macOS、tvOS版本，包含MacBook、iPhone、iPad、Apple TV等多種蘋果設(shè)備。但令dominic感到困惑的是，已修補的設(shè)備在PEAP，MSCHAPv2和WPA2級別上表現(xiàn)出完全相同的行為，即設(shè)備仍然連接到網(wǎng)絡(luò)，在某些情況下甚至會請求DHCP。這是一個例子：
相反，Apple 在連接后使設(shè)備與網(wǎng)絡(luò)斷開連接。設(shè)備顯示“無法連接”錯誤，并且設(shè)備上顯示的日志條目顯示：
Dominic解釋道，這有點像一名保安在守護一座大樓，一旦有人進去無論是誰都會被全部趕出去。雖然它具有解決問題的效果，但很讓人擔心會不會暴漏出其他危險訊號。
“然而，在測試修復后的系統(tǒng)時，我確實注意到一個異常值，當在設(shè)備連接但導出不同的PMK時，握手的第二個消息中由MIC證明（這就是repo中的WPA代碼所用的）出現(xiàn)了異常。當然，我覺得這只是一次偶然，因為PMK來自外部TLS會話并且未啟用加密綁定，這應該是沒有可能的?！?/p>
目前，Dominic仍不能確認這個問題是否真的存在，他表示會在之后的研究中用多臺蘋果設(shè)備展開試驗，找出答案。
建議：
驗證在最終EAP-Success消息中發(fā)送的消息驗證器，并且不允許iOS / macOS設(shè)備連接到無法證明用戶密碼知識的惡意接入點。
可以在以下位置找到執(zhí)行此驗證的wpa_supplicant示例：
https ：//w1.fi/cgit/hostap/tree/src/eap_peer/mschapv2.c#n112
參考來源：sensepost；freebuf雷鋒網(wǎng)雷鋒網(wǎng)雷鋒網(wǎng)
雷峰網(wǎng)原創(chuàng)文章，未經(jīng)授權(quán)禁止轉(zhuǎn)載。詳情見轉(zhuǎn)載須知。
