Don't Panic! KRACK 沒你想像的那麼糟

上海交通大學密碼與計算機安全實驗室（LoCCS）軟體安全小組（GoSSIP）版權所有，轉載請與作者取得聯繫！

著名的計算機學術安全會議CCS在2017年錄用了一篇名為Key Reinstallation Attacks: Forcing Nonce Reuse in WPA2的學術論文，看起來，這和其他的上百篇同樣將要在11月1日在美國達拉斯喜來登酒店會議中心一起登場報告的論文沒有太大的差別，然而就在4天前，這篇論文的作者藉助網站KRACK Attacks: Breaking WPA2點燃了整個網路世界，我們打開的瀏覽器突然被各種勁爆的新聞標題塞滿了：「WPA2加密協議已被攻破」，「WiFi危機！」，「WiFi爆驚天漏洞」。隨之而來的是大量的安全服務商、安全解決方案商藉機狠狠地公關了一把，推出相關的安全防護產品的速度驚人。然而，我們閱讀了攻擊發現者的網站和他的論文，又把幾乎所有的新聞報道瀏覽了一遍，感覺作者有意在引起所有人的注意力，而互聯網世界又非常配合地把恐慌的氣氛推向了高潮。作為一個學術研究團隊，我們在安全危機的表象下，總是會質問這個攻擊事件本身兩個問題：KRACK攻擊的本質到底是什麼？KRACK攻擊會對什麼場景造成實質性的安全危險？如果不能精確地向公眾去解釋這兩個問題，安全研究人員和安全企業就應該反省自己的失職。很遺憾，我們完全不能認同論文作者 Mathy Vanhoef 在相關網站上寫下的相關言論的傾向：面向學術界的論文，可以最嚴謹的強迫症去研究和處理哪怕是最輕微的安全問題，因為學術研究人員會以客觀冷靜的態度來審視這些問題；而面向公眾的宣傳則需要告訴大家危害的邊界和不受影響的情況，只為了一個大新聞而宣傳，那還是too young too simple吶！

那麼，讓我們來試圖回答一下這篇論文所導引到的兩個問題：KRACK攻擊的本質到底是什麼？KRACK攻擊會對什麼場景造成實質性的安全危險？其實不論是論文還是諸多出現的分析文章，都用了冗長的篇幅去解釋這個漏洞，但是這個漏洞可以用簡單的一句話來總結：WPA協議存在一個消息重放漏洞，導致相同的密鑰（Crypto Key）被反覆使用在不同的會話（Session）上。這個攻擊也就是作者所說的Key Reinstallation Attacks，重點就在於相同的密鑰被反覆用在不同的會話上。更簡單一點，就是存在多組密文數據，被相同的加密密鑰（包括Nonce）進行了加密。這種加密模式背後所關聯的潛在安全性破壞，就是KRACK攻擊的本質危害。

那麼你可能要問，多組密文數據被相同的加密密鑰加密，存在什麼危害呢？首先我們要指出，即使在KRACK攻擊的場景下，攻擊者知道有多組密文數據被同一密鑰加密，但是他並不知道這個密鑰是什麼（特殊情況即全零密鑰後續會討論）。這裡之所以產生了問題，很大程度上是因為WPA加密協議在這裡採用的是stream cipher加密（即用一個偽隨機密鑰流逐位元組去異或明文），具體而言，攻擊的本質是通過攔截和重放一些握手關鍵數據包，使得雙方已經在使用的密鑰被重新安裝，同時伴隨著相關參數的重置，就會導致用於加密明文的密鑰流被重複使用。為說明方便，下面使用一個略不嚴謹的表達來進行闡述。

`ciphertext = plaintext xor AES(key, IV||counter)`

原本在key和iv不變的情況下，只要counter從0開始每次增加1，那麼所產生的密鑰流就不會重複，安全性沒有任何問題。但由於重新安裝密鑰後，key和iv沒有發生變化，counter卻被重置為0，這樣產生的密鑰流就會與重置前的密鑰流完全相同。而stream cipher加密恰好是不應該重用密鑰流的，如果有兩組用相同密鑰加密的密文，就可以通過互相之間異或消掉密鑰流，而如果其中一組密文對應的明文是已經為攻擊者所知的，另一組密文對應的明文就可以通過這個運算得到。

儘管如此，這種我們稱之為key reuse attack的KRACK攻擊的普遍形式，由於key reuse窗口的大小受限，以及推測明文的不確定性，其造成的影響較為有限：僅僅是密鑰流的重用導致的部分消息可被解密，重放及有條件的偽造。對於一些設備來說，其攻擊窗口很小，重複使用的密鑰流比較短，因此可以解密的數據長度受限。比如，對於一些接受重傳消息為密文的設備，可行的攻擊如下圖所示，圖中紅框中是重新安裝key前後使用了相同密鑰流的兩條消息，由於在重新安裝key之前只可能發出圖中所示的一條消息，因此可恢復的數據長度最多與此消息長度相同。

此外，即使重複使用的密鑰流較長，受解密原理的影響，能解密出的消息內容仍舊有很大不確定性。如上所述，解密消息依靠的是使用了重複的密鑰流，也就是說攻擊者看到的兩段密文c1，c2都是由同一密鑰流加密，那麼就會有c1 xor c2 = p1 xor p2，在已知c1和c2的情況下，確定p1和p2各自準確的內容，還需要一些工作。上圖中的情況屬於較為簡單的一類，p1（也就是Msg4（r+2））是可以確定其大部分內容的，這樣就可以比較容易地得出p2（也就是客戶端發送的Data）中相應長度的內容。而對於其他p1和p2都無已知信息的情況下，恢復p1和p2是比較困難的。而且，由於在這種攻擊場景下，攻擊者只能對client或者AP某一端（根據論文中提到的兩種不同的攻擊模型）發出的加密數據包產生威脅，而對沒有產生key reuse的另一端是無法構成任何威脅的，這就限制了攻擊者只能在通訊的最初階段動一些手腳，而無法對稍微複雜的協議的後續數據進行攻擊，例如一個HTTP通訊，還沒有進入到TCP握手階段，key reuse attack已經無法生效了，更不要提威脅後續的實質內容。

KRACK攻擊中真正造成較為嚴重後果的，是一種可被稱為 zero key attack 的特殊攻擊形式（也是作者在其給出的DEMO中利用的攻擊），這種攻擊利用了Linux上wpa_supplicant版本為2.4、2.5、2.6的wifi客戶端（包括Android 6.0及以上版本和Android Wear 2.0等安卓設備）上的一個代碼實現的問題。由於編程安全實踐要求程序在初始化密鑰後，會將之前包含密鑰材料的緩衝區內存清零，可是當發生重放攻擊後，程序並沒有「記住」自己已經將密鑰材料緩衝區清零了，又回頭去讀取了那一塊內存區域，這時候密鑰一定是由全零的數據衍生而來，也就是說，攻擊者可以完全預測之後wifi加密數據包所使用的密鑰，那麼設備發給wifi的所有數據包都可以被解密，進而導致一個AP替換的攻擊。由於這是一種代碼實現和協議問題結合導致的安全漏洞，因此在Windows、iOS等諸多平台上隨著實現不同，這類攻擊並沒有辦法生效。

特別值得指出的是，即使存在這樣一種特殊情況，KRACK攻擊也無法威脅端到端加密（TLS協議等用於安全通訊的加密），而demo中所演示的原本的https通信被替換為http通信，則是因為挑選的演示網站http://match.com本身配置存在問題，沒有做好抵抗sslstrip攻擊的防護，而實際上正確配置的TLS站點，即使zero key attack也是無法完成攻擊的（再次感嘆下作者的用心良苦！！！）

總結一下，KRACK攻擊是針對WPA協議中非常短暫的連接協商部分的攻擊，在普遍情況下，對後續的通訊的影響有限，而且這種攻擊完全無法推導出wifi密碼，也不能獲取到會話密鑰，更不能利用此攻擊偽造已經建立了信任的兩方（AP和客戶端）中的任意一方。KRCAK攻擊所聲稱的可以竊取敏感信息，諸如信用卡號、密碼、聊天消息、郵箱、照片等，其需要的滿足條件包括：

* 客戶端版本是Linux wpa_supplicant v2.4, v2.5, v2.6，也就是Android版本是6.0及以上，以及Android Wear 2.0的設備。（只有以上設備在重新安裝後key會被置為全零）

* 包含敏感信息（如信用卡號、密碼、聊天消息、郵箱、照片等）的網路請求，沒有被安全保護，如直接使用http發送（這種情況無需krack攻擊，只要在網路鏈路的其他節點，就可以直接看到明文）、使用可被strip為http的https發送（同樣攻擊者可以無需在客戶端與Wifi間的鏈路上進行，而可以在網路鏈路的其他節點進行strip攻擊）

最後，作為安全學術研究人員，我們希望安全學術研究、安全學術會議在保持對現實系統一絲不苟、不放過一點點可能威脅的同時，也能夠對公眾更多地發出Dont Panic的聲明。沒有絕對安全的系統，我們的目標是讓系統更安全的同時，也讓大家能更有安全感^_^

推薦閱讀：