無線網路 KRACK 攻擊的作者 Mathy Vanhoef 揭露了影響各種無線設備的 12 個漏洞的資訊。 已發現的問題以代碼名稱 FragAttacks 呈現，涵蓋了幾乎所有正在使用的無線卡和存取點 - 在測試的 75 台裝置中，每個裝置都至少容易受到其中一種所提出的攻擊方法的影響。
問題分為兩類：3個漏洞直接在Wi-Fi標準中辨識出來，涵蓋所有支援目前IEEE 802.11標準的設備（問題自1997年就開始追蹤）。 9 個漏洞與無線堆疊特定實作中的錯誤和缺陷有關。 主要危險是第二類，因為組織對標準缺陷的攻擊需要有特定的設定或受害者執行某些操作。 無論使用何種協定來確保 Wi-Fi 安全，所有漏洞都會發生，包括使用 WPA3 時。
大多數已識別的攻擊方法允許攻擊者在受保護的網路中替換 L2 幀，從而可以侵入受害者的流量。 最現實的攻擊場景是欺騙 DNS 回應以將使用者引導至攻擊者的主機。 還給出了使用漏洞繞過無線路由器上的位址轉換器並組織對本地網路上的裝置的直接存取或忽略防火牆限制的範例。 此漏洞的第二部分與碎片幀的處理相關，使得提取有關無線網路流量的資料並攔截未經加密傳輸的用戶資料成為可能。
研究人員準備了一個演示，展示如何利用漏洞攔截透過未加密的 HTTP 存取網站時傳輸的密碼，以及如何攻擊透過 Wi-Fi 控制的智慧插座，並以此為跳板繼續攻擊本地網路上未更新且存在未修正漏洞的裝置上（例如，可以透過NAT 穿越攻擊內部網路上裝有Windows 7 的未更新電腦）。
要利用這些漏洞，攻擊者必須位於目標無線設備的範圍內，才能向受害者發送一組特製的訊框。 這些問題會影響用戶端裝置和無線卡，以及存取點和 Wi-Fi 路由器。 一般來說，將 HTTPS 與使用 DNS over TLS 或 DNS over HTTPS 加密 DNS 流量結合使用就足以作為解決方法。 使用 VPN 也適合進行保護。
最危險的是無線設備實作中的四個漏洞，這些漏洞允許簡單的方法實現對其未加密幀的替換：
- 漏洞 CVE-2020-26140 和 CVE-2020-26143 允許 Linux、Windows 和 FreeBSD 上的某些存取點和無線卡上的幀填充。
- 漏洞 VE-2020-26145 允許在 macOS、iOS 以及 FreeBSD 和 NetBSD 上將廣播未加密片段作為完整幀進行處理。
- 漏洞 CVE-2020-26144 允許在華為 Y6、Nexus 5X、FreeBSD 和 LANCOM AP 中使用 EtherType EAPOL 處理未加密的重組 A-MSDU 訊框。
實作中的其他漏洞主要與處理碎片幀時遇到的問題有關：
- CVE-2020-26139：允許重新導向未經驗證的傳送者傳送的 EAPOL 標誌的訊框（影響 2/4 可信任存取點以及基於 NetBSD 和 FreeBSD 的解決方案）。
- CVE-2020-26146：允許在不檢查序號順序的情況下重新組裝加密片段。
- CVE-2020-26147：允許重新組裝混合的加密和未加密片段。
- CVE-2020-26142：允許將分段幀視為完整幀（影響 OpenBSD 和 ESP12-F 無線模組）。
- CVE-2020-26141：碎片幀缺少 TKIP MIC 檢查。
規範問題：
- CVE-2020-24588 - 對聚合訊框的攻擊（WPA、WPA2、WPA3 和 WEP 中的 A-MSDU 訊框中的「已聚合」標誌不受保護，可以被攻擊者取代）。 使用的攻擊範例是將使用者重新導向到惡意 DNS 伺服器或 NAT 遍歷。
- CVE-2020-245870 是一種金鑰混合攻擊（允許重新組裝使用 WPA、WPA2、WPA3 和 WEP 中的不同金鑰加密的片段）。 該攻擊可以讓你確定客戶端發送的數據，例如透過HTTP存取時確定Cookie的內容。
- CVE-2020-24586 是對片段快取的攻擊（涵蓋 WPA、WPA2、WPA3 和 WEP 的標準並未要求在新連接到網路後刪除已駐留在快取中的片段）。 允許您確定客戶端發送的資料並替換您的資料。
為了測試您的裝置對問題的敏感程度，我們準備了一個特殊的工具包和一個用於創建可啟動 USB 驅動器的現成的 Live 映像。 在 Linux 上，問題出現在 mac80211 無線網狀網路、各個無線驅動程式以及無線卡片上載入的韌體中。 為了消除這些漏洞，我們提出了一組涵蓋 mac80211 堆疊和 ath10k/ath11k 驅動程式的修補程式。 某些裝置（例如 Intel 無線卡）需要額外的韌體更新。
典型裝置測試：
Linux與Windows下無線網卡的測試：
FreeBSD和NetBSD中無線卡的測試：
製造商在 9 個月前就收到了有關問題的通知。 如此長的禁運期是由於 ICASI 和 Wi-Fi 聯盟組織協調一致地準備更新以及延遲準備變更規範。 最初計劃於 9 月 19 日披露信息，但在比較風險後，考慮到變更的非同小可性，決定再推遲兩個月發布，以便有更多時間準備補丁以及因 COVID-XNUMX 大流行而產生的困難。
值得注意的是，儘管有禁令，微軟還是在 XNUMX 月的 Windows 更新中提前修復了一些漏洞。 資訊揭露被推遲到原定日期前一周，並且微軟沒有時間或不想對準備發布的計劃更新進行更改，這對其他系統的用戶造成了威脅，因為攻擊者可以獲得有關通過對更新內容進行逆向工程來修復漏洞。
來源： opennet.ru