老砖家深度解析WPA2安全漏洞

近期WPA2被破解的事（也就是KRACK漏洞攻击），在网上闹得沸沸扬扬，因为这个漏洞影响面实在太大，一时间人人自危，于是乎，改密码的、升级系统的、打补丁的、写攻略的等等，干啥的都有，其中当属专家最活跃，一时间，媒体、论坛上看到诸多高见，一篇又一篇KRACK漏洞攻击的技术分析文章，随便百度一下，都能发现很多大作。比如：”不用担心家里被蹭网 KRACK漏洞其实很弱鸡” ，这篇文章不知是怎地，造成这么大影响的KRACK漏洞居然说成是“其实很弱鸡”，我就呵呵了。再比如：”WiFi防线一夜被毁 究竟咋回事？”，这篇文章倒是旗帜鲜明的提出了“全世界的Wi-Fi早就不安全了”，这个认识是对的，但奈何文章并没有深入分析，更多的是在引用KRACK漏洞曝出者的论文内容，所以不能算作技术分析文章，只是一篇新闻稿罢了。还有借KRACK漏洞打广告想发危机财的，这本无可厚非，但稍微有点网络技术常识的人都知道，KRACK漏洞是Wi-Fi安全技术协议上的漏洞，这是底层的技术协议，而某某Wi-Fi管家只是一个上层应用的防御软件，防防病毒或许还行，试问如何能解决底层技术协议的问题？借此广告误导可真有些不地道了。须知中医头痛医脚的理论放在网络技术里是万万行不通的！若能解决，伪基站的问题也早就解决了，这样的文章也有很多，我就不一一列举了，大家自行百度（拜读）即可。

作为一个曾经浸淫在无线网络行业，算是从事了十六年无线网络安全技术研究的老砖家，本不想就此事发声，毕竟是曾经嘛，我已离开这个行业快2年，只能算半个业内人士了。但是看到专家们林林总总文章后，说实话，有点无法忍受，都什么啊，没有深入的技术分析，人云亦云搬运看似专业，也很热闹，但无助于问题认识正确，自然也就无法解决问题本身。于是我这个老砖家只能花些时间，通过重现KRACK漏洞攻击的过程，并结合过去的一些研究，写就这篇文章，希望能通过这些的技术理论和实践数据，深入剖析WPA2安全漏洞以及Wi-Fi安全问题背后的根源，知其然，亦能知其所以然。看完我这砖，需要点时间…….

2017年10月17日，国外社交媒体Twitter爆出一款宣判无线网络WPA2安全协议死亡的漏洞，这就让IEEE面子上有点挂不住了，因为此前IEEE一直在竭力声称和证明WAP2是安全的。比利时相关机构的安全研究人员Mathy Vanhoef（马蒂·万赫弗）发现WPA2认证与密钥协商协议存在一种“密钥重装攻击”（Key Reinstallation Attack，KRACK）漏洞，并通过专门的网站https://www.krackattacks.com详述该新型攻击，详见论文 Key Reinstallation Attacks: Forcing Nonce Reuse in WPA2。
根据Mathy Vanhoef的研究结果，几乎所有支持Wi-Fi的设备（例如运行Android, Linux, iOS, MAC OS, OS X, Windows, OpenBSD等操作系统的设备）都受此漏洞的影响，其传输的数据存在被嗅探、被篡改的风险。攻击者可获取Wi-Fi网络中的数据信息，如信用卡、邮件、账号、照片等，危害巨大。

需要注意的是，这绝非是一个工程实现上的问题，因为微软、苹果、谷歌、Linux开源社区等等这些公司和开发人员不可能同时犯一样的错误！这是Wi-Fi技术标准的问题，所以漏洞发现者Mathy Vanhoef才调侃说“所有按照Wi-Fi技术标准实现的产品都难以幸免，而有些产品未遵守Wi-Fi标准，却幸运的躲过一劫。”。

实际上，自1997年第一次有Wi-Fi安全技术以来，各种安全漏洞问题层出不穷，从最初的WEP到后来的WPA，再到曾经被IEEE宣称很安全的WPA2，一次又一次的被曝出安全漏洞，而本次的KRACK漏洞只是这众多安全漏洞中的一个，且绝不会是最后一个，Wi-Fi的安全问题之严重，可见一斑。因此比利时专家明确表示“Wi-Fi安全（WPA2）已死”。

我们先来看看Wi-Fi安全技术发展和演进历程（摘抄自我搞无线网络安全技术时写的某篇技术分析文章）：

WEP安全协议提出于1997年，这是无线局域网标准最初使用的安全协议。其安全架构是基站对用户进行单向鉴别，采用开放式系统鉴别与共享式密钥鉴别算法，鉴别简单，易于伪造。其加密机制是64位RC4流加密算法，静态密钥，安全强度低。已于2001年被完全破解。
WPA安全协议提出于2002年，是为了缓解来自产业和用户的安全压力，而提出的针对WEP协议的软件升级方案，可通过对原有WEP设备软件升级实现，但仍存在大量安全漏洞，主要有：安全架构漏洞（基站缺乏独立身份，基站和后台传输主密钥带来安全风险并且导致扩展性差，兼容已被破解的WEP机制导致系统整体存在漏洞等）；安全协议设计不安全、缺乏健壮性（协议设计不完备，使用的杂凑算法等级低，无效帧重传导致拒绝服务攻击等）。
WPA2安全协议提出于2004年，采用了AES-128分组密码算法。但WPA2采用的身份鉴别协议和WPA相同，仍存在安全架构和安全协议设计漏洞，容易遭受漏洞攻击。
（笔者注：老砖家的预言果然应验了，WPA2遭受了KRACK漏洞攻击。^_^）

而要剖析Wi-Fi安全性为什么这么经受不住考验，就得从其安全架构入手。

图1 Wi-Fi安全架构示意

如图1所示，最初的WEP安全可以忽略不计，其架构毫无安全性可言。被轻松破解后，Wi-Fi采用了号称更加安全的IEEE 802.1x架构，可依然无法逃过被破解的命运，这是为什么呢？

众所周知，IEEE 802.1x原本是有线网络上的安全架构，Wi-Fi则是完全将其照搬到了无线局域网中。可是有物理接触的有线网络与没有物理接触仅靠电磁传播的无线网络并不一样，直接将有线网络的安全架构生搬硬套到无线网络上，本身就是有问题的。IEEE显然也意识到了这一点，可遗憾的是，他们并未从架构上寻求解决方法，而是在这个不合理的架构之上叠加了一个四步握手协议，某种程度上也是希冀着可以用这种方式弥补其架构上的缺陷。殊不知基础架构不牢靠，你把房子垒得越高，反倒越容易出问题。IEEE这种错误的思路，导致的结果就是这些年来，Wi-Fi各种安全问题层出不穷，往往都是为了解决上一个安全问题而打的补丁中，却引入新的安全问题，以本次的KRACK攻击为例，问题恰恰就出在叠加的那四步握手协议上。

图2 Wi-Fi的四步握手协议

如图2所示，KRACK攻击主要发生在认证和密钥建立阶段的四步握手过程中，通过简单的报文模拟诱使安全协议交互的一方重发密钥交互协议中的一条消息，另一方收到重发的这条消息后再次安装已安装过的密钥，安装时将IV等相关的信息重置后使用，从而导致了同一个密钥使用了相同的IV再次加密数据，最终造成数据被重放、解密甚至伪造等安全危害。该攻击不仅针对WPA2，对于WPA也同样适用，不论是采用预共享密钥机制还是采用IEEE 802.1x机制的Wi-Fi网络都受到该漏洞的影响。

下面我们就来揭开密钥重装攻击（KRACK）神秘的面纱，一窥其究竟：
密钥重装对于不同的数据机密性协议造成的危害程度不尽相同。针对AES-CCMP，攻击者可以实施重放和解密，这使得劫持TCP流并注入恶意数据变得有可能；针对WPA-TKIP和GCMP，攻击的影响更大甚至是灾难性的，不仅可以重放、解密，而且还能伪造。危害情况具体如表1所示：

KRACK漏洞基于密码学的理论基础，即分组加密算法使用同一加密密钥在用于会话加密时不能使用相同的IV，若IV重用，则必然存在安全漏洞。受篇幅限制，此处不再赘述。

目前公共漏洞和披露（Common Vulnerabilities & Exposures，CVE）网站已为KRACK预留漏洞编号，包括如下列出的十种，都是基于上述原理。

l CVE-2017-13077：在四次握手中重装成对加密密钥（PTK）
l CVE-2017-13078：在四次握手中重装组密钥（GTK）
l CVE-2017-13079：在四次握手中重装完整组密钥（IGTK）
l CVE-2017-13080：在组密钥握手中重装组密钥（GTK）
l CVE-2017-13081：在组密钥握手中重装完整组密钥（IGTK）
l CVE-2017-13082：接受重新传输的快速BSS切换（FT）重新关联请求，处理的同时重装成对加密密钥（PTK-TK）
l CVE-2017-13084：在PeerKey握手中重装STK密钥
l CVE-2017-13086：在TDLS（Tunneled Direct-Link Setup，通道直接链路建立）握手中重装TDLS PeerKey（TPK）
l CVE-2017-13087：处理无线网络管理（WNM）休眠模式响应帧时重装组密钥（GTK）
l CVE-2017-13088：处理无线网络管理（WNM）休眠响应帧时重装完整组密钥（IGTK）

KRACK攻击不仅涉及Wi-Fi安全协议的四步握手（4-way Handshake），而且还涉及到其他协议组件，包括组密钥握手（GroupKey Handshake）、站间密钥握手（PeerKey Handshake）、快速切换握手（Fast BSS Transition (FT) Handshake）等几乎所有的安全协议过程，如图3红圈所标示的，导致成对传输密钥（Pairwise Transient Key，PTK）、组临时密钥（Group Temporal Key，GTK）、站间密钥STK、组播管理保护密钥（ Integrity GTK，IGTK）等都会被重装。图中的TK是指PTK、GTK和IGTK。

图3 IEEE 802.11的安全协议模块执行示意图

从图3可见，站间密钥握手协议虽然由两个子协议构成，但是SMK 握手用于协商四步握手使用的PMK，SMK并不是直接用来保护通信数据的，故不会受到KRACK攻击的影响，故KRACK对站间密钥协议的攻击也只是集中在其的第二个阶段即SMK握手之后的四步握手协议上，因第二阶段的四步握手协议用于协商和装载数据保密协议的密钥STK；快速切换握手是将四次握手协议嵌在了物理关联框架中完成的；KRACK对组密钥握手的攻击方法与对四步握手协议并无本质区别。

四步握手协议是Wi-Fi安全机制中最重要和最基础的组件，它不仅完成客户端和AP之间的认证，确保双方具有一致的成对主密钥PMK（来自于PSK或者IEEE 802.1x认证的结果），而且完成会话密钥的协商和分发，包括用于保护单播业务数据的PTK、保护广播/组播业务数据的GTK以及保护组播管理帧的IGTK等。

图4 四步握手协议示意图

在图4中，四步握手协议与会话密钥有关的简要说明如下：
（1）Client在收到Msg1 后导出PTK；
（2）AP在收到Msg2后导出PTK；
（3）客户端在收到Msg3后安装PTK/GTK/IGTK；
（4）AP在收到Msg4后安装PTK；
（5）安装之后客户端和AP分别使用该PTK/GTK/IGTK进行加解密或者完整性保护。

IEEE 802.11标准中关于Msg3的接收和重发处理，定义见其的12.7.6.4和Fig.13-17对应的描述，为方便阅读，对标准中相关部分截图见图5和图6。

图5 客户端对Msg3的接收处理

图6 客户端状态机中Msg3消息重发的接收处理

这四条消息中都携带Key Replay Counter字段，该字段作为消息计数器，用于收发双方消息的匹配，标准中定义该字段是严格递增使用的。正确的流程中Msg1和Msg2中使用Key Replay Counter的值为r；Msg3和Msg4中使用Key Replay Counter为r+1。对Key Replay Counter的定义指出，AP每次加1使用，客户端每次将收到的有效的交互消息中的Key Replay Counter的值作为自己的Key Replay Counter。同时标准中还定义了，客户端对每次收到的Msg3，如果Key Replay Counter字段的值已经使用过（小于或等于当前Key Replay Counter）就悄悄地丢弃该消息（也就是不做任何处理）。因此，如果正常的Msg4丢失，如图7中红字体所标示的，那么AP就需要重发Msg3，此时为了保证客户端接收并处理重发的消息，根据图5和图6的表述即可得知AP必须对Key Replay Counter加1后使用，也就是AP会重发Msg3，且是重新组包，其中的Key Replay Counter就使用了r+2，因此客户端就会完整地按照接收一个新的Msg3的消息处理过程进行处理，据图5可知客户端每收到Msg3就安装一次密钥，并重置加密使用的关键参数包括IV等，因此客户端收到重传的Msg3就重新安装了已安装的密钥（密钥还是同一个密钥，IV相关的信息等也再次重置），见图7。

图7 Msg4丢失时Msg3的重发示意图

可见，KRACK攻击在 Msg4 由于背景噪声而丢失的时候会自发地出现，也就是说接受明文重传 Msg3 的Client，可能会在没有攻击者存在的情况下重用IV。此时攻击者就可以通过一些手段迫使AP收不到Msg4而重发Msg3，从而造成KRACK攻击。

客户端在发出Msg4即打开802.1x端口后，有的仅接收密文的四步握手消息，有的还允许接收明文的四步握手消息，下面分两种情况详述攻击过程：

1、明文重传Msg3的攻击方法

图8 明文重传Msg3的攻击示意图

如果客户端即受害者在加载完会话密钥之后，依旧接受以明文方式重传 Msg3，密钥重装攻击就很简单，如图8所示。首先，攻击者会使用基于频段的中间人攻击，因此可以控制握手包。阶段1中，攻击者阻止AP接收Msg4；阶段2中，受害者在发送 Msg4 之后会装载 PTK 以及 GTK/IGTK 密钥，并打开IEEE 802.1x端口，开始正常传输数据；阶段3中，AP会因为没有收到 Msg4 而重传 Msg3，攻击者可以转发重传 Msg3 给受害者，导致它重新装载 PTK 和 GTK/IGTK，并重置数据保密协议使用的IV和重传计数器等，此时，当受害者传输它下一个数据帧时，数据保密协议就会使用旧的IV，见阶段5。这意味着攻击者可以在转发重传 Msg3 给受害者前等待任意的时间，即可控制一定数量的会被重用的IV。

阶段4的目标是完成 AP部分的握手。因为受害者已经加载了 PTK，这意味着它的下一个 Msg4 是被加密的，在AP还未加载 PTK 时，它通常会拒绝已加密的Msg4，因此，IEEE 802.11标准里定义了 AP需要接受具有任意重传计数器的四次握手包（见其12.7.6.5的描述，为方便阅读，对标准中相关部分截图见图9），而不仅仅是最后一个，即接收Msg4的时候，AP验证 Key Replay Counter字段值在当前四次握手过程中是否使用过，也就是说，AP接受之前曾发送给Client消息中使用过且还未被Client发送回来的重传计数器。此时AP 会接受旧的未加密的Msg4，就是重传计数器为r+1的那条消息。总之，AP会装载 PTK等，打开 802.1x 端口，开始发送加密的数据帧给 Client。

图9 AP对Msg4消息的接收处理

虽然图9只示意了 Client 发送IV的重用情况，其实KRACK攻击允许重放数据帧。Client在阶段3中重装 GTK 之后，AP通过广播或多播重传的数据是可以被重放的。这是因为在重装密钥的时候，重传计数器也被重置了。特别是对于密钥更新即四步握手更新执行的情况下，无论单播还是多播都更容易实现重放攻击。

还有一种针对明文Msg3重传的攻击如图10所示，其中Client中的认证、密钥协商等由主CPU软件完成，数据加密由硬件即网卡NIC完成。阶段1中，首先让Client和AP交换Msg1和Msg2，然后阻塞第一个Msg3 ，使其不立即转发给Client，而是等着AP重传第二个Msg3；阶段2中，攻击着接连发送两个Msg3给Client，实现数据保密协议的无线网卡还没有装载 PTK，于是就将收到的两个明文包按顺序转发给主CPU；阶段3中，实现四次握手协议的CPU 接收了第一个Msg3，并且让无线网卡装载PTK；阶段4中，CPU 对从接收序列里得到的第二个 Msg3会正常处理，并响应发出Msg4，因为网卡已经装载了 PTK，因此这个Msg4会是在IV为x（某个值，可能已经发送过其他数据）的情况下加密传输的，在这之后，CPU再次让无线网卡装载 PTK，同时无线网卡也会重置与 PTK 相关的IV和重传计数器等，这意味着下一个数据帧会重用IV为1到x。

图10 明文重传Msg3的第二种攻击示意图

2、加密重传Msg3的攻击方法

图11 密文重传Msg3的攻击示意图

阶段1，攻击者让受害者和AP进行一个初始的四次握手，并且在握手成功之后，初始化执行PTK的重装；阶段2，攻击者没有立刻转发第一个Msg3，而是等待 AP 重传Msg3，然后将这两个Msg3按顺序一起发送给受害者，网卡会使用当前的PTK来解密这两个信息，然后将它们转发到CPU的接收序列；阶段3中，CPU会处理第一个Msg3，让网卡装载新的PTK；阶段4中，CPU会从接收序列取出第二个Msg3，当 PTK 被装载的时候，Msg4会通过新的PTK和IV为 1 来加密并发送，在这之后，CPU会让网卡重装 PTK，并且重置 IV和重传计数器等，最终，受害者发送的下一个数据帧就会使用新的PTK和IV为1 来加密。

这里要特别指出的是，KRACK对于四次握手的攻击还发现了一种更为惊悚的漏洞，即四步握手Msg3重传引起PTK/GTK/IGTK重新安装时，客户端会重装一个全零加密密钥。Mathy Vanhoef认为，该漏洞是由 Wi-Fi安全技术标准引起的，该标准建议在安装了TK （指PTK/GTK/IGTK）之后，从内存清除它。KRACK导致全零密钥的安装，则意味着数据通信的安全性丧失殆尽，WAP/WPA2的安全机制将形同虚设。

在Mathy Vanhoef公布的演示信息中有一段视频，向大家展示了如何进行一次完整的攻击过程，其核心就在于“重新安装现已清除的加密密钥，有效地安装了一个全零的密钥。”。

现在，我们就从工程实现角度来深入分析一下那些按照Wi-Fi标准实现的产品是否存在这样的行为：

首先我们进行代码侧分析，先弄清楚其逻辑以及密钥重装过程。为此我特意下载了Linux系统中的wpa.c文件进行详细阅读，发现了其中关键代码实现过程。

图12 Wi-Fi安全协议实现代码片段（一）

图12表示了wpa_supplicant_process_3_of_4函数中调用wpa_supplicant_install_ptk函数的代码片段。STA接收并处理第3帧，在调用wpa_supplicant_send_4_of_4函数发送第4帧后，调用wpa_supplicant_install_ptk函数安装PTK。

图13 Wi-Fi安全协议实现代码片段（二）

图13为wpa_supplicant_install_ptk函数的代码片段。wpa_supplicant_install_ptk函数中，当安装完PTK后，调用如下代码将PTK的缓冲区清0。

/* TK is not needed anymore in supplicant */

os_memset(sm->ptk.tk, 0, WPA_TK_MAX_LEN);

从代码侧看，确实是存在问题的，但是为了严谨起见还是要进行更深入的分析，拿到与之呼应的证据才行。

为了验证这一情况笔者搭建了一套WIFI接入点环境。一台无线路由器、一台安卓6.0+内核的手机作为客户端。两者进行正常的接入动作，在此过程中进行抓包，确实看到了四步握手的报文，如图14所示：

图14 Wi-Fi四步握手协议过程抓包

图14是使用wireshark打开的，EAPOL类型的数据，即四次握手的数据包。笔者特意使AP不断进行第三包的重传过程，所以会看到很多EAPOL的报文。通过抓包分析确实看到了四步握手过程，但是通过包分析并不能证明是否进行了全0密钥的安装。

为了捕捉全0密钥的安装过程，笔者决定用内存分析的方式来分析这一台安卓手机客户端，以便拿到真实准确的密钥信息。

将手机与电脑连接以便进行调试，通过内存分析手段即可观测密钥的变化过程，分析环境如下：

图15 内存分析环境

我们还是进行上述步骤，重复的使第三包进行重传，经过试验并调试内存信息，我们最终找到了全0密钥安装最直接的证据：

图16 内存分析数据

如上述二图所示，我们可以看到。客户端第一次接收第三包时，确实是安装了一个随机出来的密钥，但是在收到重传指令之后，系统会将密钥内存清零，然后再去被清零区域取值进行安装。与我们最初的分析结果完全一致！

至此，关于Wi-Fi安全问题以及KRACK漏洞攻击就分析完了。

后记：

原本是想就此截稿，奈何笔者还是忍不住想说一说另一个无线局域网安全技术（没错，就是中国提出的WAPI技术），毕竟那十六年可不仅仅是在研究了Wi-Fi安全技术，对于WAPI安全技术也研究颇多。说实话，技术上WAPI的确比Wi-Fi安全多了，可惜产业中至关重要的资源（比如芯片、驱动、操作系统等）都没掌握在中国人手里，以至于咱们空有WAPI这么好的技术，却硬生生被别人利用产业资源的垄断优势排挤得举步维艰，可笑的是某些人还在那说风凉话，认为国外的月亮就一定比国内的圆！不知道在经历了这些年Wi-Fi种种安全问题之后，这些人是否还是觉得国外的月亮圆？

好了，我就不感慨了，直接说经过仔细分析得出的结论： KRACK攻击对WAPI是无效的！

为什么这么说呢？先来看看WAPI安全技术的架构，如下图所示：

图17 WAPI安全技术架构

大家都知道，WAPI是我国自主提出的无线局域网安全技术，也是全球唯二的无线局域网安全技术之一（另一个就是Wi-Fi安全技术）。不同于Wi-Fi安全技术在有缺陷的架构之上不断的修修补补，WAPI安全技术从设计之初就采用了先进的三元对等安全架构，直接实现了AP和客户端之间的对等双向认证，并且从WAPI技术标准中也可以看出，技术人员在协议设计过程中已经考虑到了种种可能面临的安全威胁，其中就包括密钥重装这类攻击方式，并有针对性的在WAPI相关技术标准中做了明确的规定，例如在WAPI安全协议交互的过程中采用了具有鲁棒性的处理方式，对于重发的消息，接收端会根据需要选择丢弃或者响应，即使选择响应，也仅仅是将之前发出的消息原样重发，仅此而已，绝不会重新执行一遍密钥安装的动作，这样KRACK攻击的前提就无法成立，后续的攻击也就无从谈起了。

写在最后：

虽说安全这东西，你不吃点亏就不会知道它的好！但是老砖家在此还是提醒大家，趁着还没吃大亏，重视一下无线网络的安全问题吧！毕竟亡羊补牢，你再怎么补，损失的羊终归是回不来了！

 

主要参考文献
[1] Mathy Vanhoef, Key Reinstallation Attacks: Forcing Nonce Reuse in WPA2, https://www.krackattacks.com.

[2] IEEE Std 802.11. 2016. Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Spec.

[3] IEEE Std 802.11ac. 2013. Amendment 4: Enhancements for Very High Throughput for Operation in Bands below 6 GHz.

[4] IEEE Std 802.11ad. 2012. Amendment 3: Enhancements for Very High Throughput in the 60 GHz Band.

[5] IEEE Std 802.11i. 2004. Amendment 6: Medium Access Control (MAC) Security Enhancements.

[6] IEEE Std 802.11r. 2008. Amendment 2: Fast Basic Service Set (BSS) Transition.

[7] GB 15629.11-2003/XG1-2006，信息技术系统间远程通信和信息交换局域网和城域网特定要求第11部分：无线局域网媒体访问控制和物理层规范 第1号修改单。

[8] CBWIPS/Z 008-2008，WAPI密钥管理实施指南。