研究人員發現蘋果裝置在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
來源:雷鋒網
更多資訊:「淨網2019」4萬餘條公民資訊被竊取,懷化公安跨省抓獲黑客
CEO透露:Coinbase現管理著10億美元的加密貨幣資產