802.11无线网络之WPA企业版安全攻防

一次性进群，长期免费索取教程，没有付费教程。

教程列表见微信公众号底部菜单

进微信群回复公众号：微信群；QQ群：460500587

---

微信公众号：计算机与网络安全

ID：Computer-network

大部分主要的组织将“WPA企业版”（WPA Enterprise）作为他们的无线网络的部署方案。它提供了认证上的细粒度控制（fine-grained control），这种控制可以使网络整体变得更安全。“WPA企业版”在使用EAP协议的基础上支持多种身份认证方案，这些方案中的一些方案，被认为是比其他方案更安全的认证方案。

如果您对RADIUS协议、802.1X协议和EAP协议之间交互的细节不熟悉，请参见《802.11无线网络安全基础知识》中相关的内容，文中有对这三个概念的介绍。

一、获取扩展认证协议的握手

正如“四次握手”对于攻击“Wi-Fi保护访问下的预共享密钥”认证至关重要一样，“EAP协议握手”（EAP handshake）对于攻击“WPA企业版”同样至关重要。“EAP协议握手”同样是采用“四次握手”的通信方式。在“EAP协议握手”期间，系统会告诉我们现在正在使用的“扩展认证协议”（EAP）类型，虽然这样的EAP类型取决于我们对网络的配置，但仅这个名字，就给了我们足以发动攻击的信息量了。要捕获到“EAP协议握手”的数据包，我们可以使用主动嗅探方法和被动嗅探方法中的任意一种。

1、EAP的身份响应

“扩展认证协议”的“身份响应”（Response Identity）的消息是客户端在“EAP握手”期间发送给“认证服务器”（authentication server）的第一条消息，消息中包含了客户端的用户名（见图1）。“认证服务器”通过实际的认证过程，可以确定该客户端发送的用户名是否可用。EAP的“身份响应”信息中有一个重要的特点，那就是该数据包是以明文方式表示的，易于辨认。如果您能够捕获到一次“EAP协议握手”数据包，那您就有可能从数据包中，得到这个正在请求连接的客户端的用户名。如果这身份认证与Windows操作系统的“系统用户”关联，那么您还可以看到的是该用户所关联的“域名”（domain）。

图1  EAP身份响应的消息

2、确定EAP的类型

“扩展认证协议”的类型可以通过检查“EAP握手”来确定。EAP类型定义在消息中，并且无论我们使用哪一款数据包检查工具（例如Wireshark软件），EAP的类型通常都会被自动翻译。客户端可以通过配置支持多个EAP类型，因此嗅探程序监测到客户端完整的“EAP协议握手”数据包是非常重要的，否则，如果您只是嗅探到“EAP协议握手”中的某一个数据包，则有可能会出现错误的判断。例如，您可能会注意到：某个客户端第一次使用EAP/TLS类型尝试连接，所以您理所当然地认为它们的EAP类型就是EAP/TLS了，但紧随其后的是，客户端又改用了“受保护的扩展认证协议”类型进行连接，如果成功，那客户端和AP接入点实际使用的连接类型就是“受保护的扩展认证协议”类型，而不是EAP/TLS类型。这一点很重要，因为“扩展认证协议”类型比别的类型更容易遭到攻击。一旦您确定对方使用的是EAP类型，那么您就可以发起一个攻击，该攻击指向这个EAP类型的网络，并有望拿到对该网络访问的权限。

二、EAP-MD5认证方式

“基于消息摘要第5版的扩展认证协议”（EAP-Message Digest Algorithm version 5，EAP-MD5）是一个相对简单的“扩展认证协议”认证方式，此方式正如其名称所暗示的，是通过MD5的散列处理，向客户端身份认证提供加密支持的。图2显示了整个认证过程。

图2“基于消息摘要第5版的扩展认证协议”的握手过程

客户端在“EAP协议握手”的第一次握手的数据包中，将自己的用户名写入到了“扩展认证协议”的“身份响应”消息中。接下来，Radius服务器在收到“身份响应”消息以后，将客户端发送一个包含有标识符（identifier）字段和一个16字节的“质疑”（challenge）字段的“EAP请求”（EAP Request）以完成第二步握手。然后，客户端就将其“密码”、“标识符”字段和“质疑”字段连接起来形成一个大的字符串，并将这个字符串通过MD5加密算法进行散列运算（hash）。运算结束后，客户端将运算结果发送到Radius服务器，这就是“EAP握手”中的第三次握手，服务器会用同样的散列运算算法，将同样的几个参数进行运算，然后将运算出的结果与收到客户端的这个运算结果进行比较，如果它们匹配，则用户成功认证；否则不匹配，则认证失败。无论哪种结果，服务器都会向用户发送一个认证结果，这就是“EAP协议握手”中的最后一步。“基于消息摘要第五版的扩展认证协议”是一个简单的方法，但是它存在诸多问题，特别是在无线网络上。

1、攻击EAP-MD5认证方式

在RFC 4017中详细定义了“为了在无线网络上安全使用各项操作，而对EAP算法提出必须遵守的特定要求”。然而“基于消息摘要第5版的扩展认证协议”违反了该“要求”中的大量规定，当EAP-MD5开发出来以后，并不意味着可以应用于全部无线网络中。“基于消息摘要第五版的扩展认证协议”并不容易被发现和使用，不过，如果您找到了，那说明您很幸运。“客户机-服务器”（Client-Server，C/S）模式的通信在无线网络上以明文方式进行的，所以，如果我们得到一个有效的客户端与服务端的“四次握手”，您就可以对该“四次握手”过程中所捕获的数据包发动一次针对该数据包的离线“暴力攻击”（brute-force attack）。

使用eapmd5pass软件破解“基于消息摘要第5版的扩展认证协议”的操作非常简单：我们指定一个捕获数据包的文件，该文件中包含MD5的“质疑”字段和“回应”字段的数据包（通过参数“-r PrettyLilPwnies.cap”来实现），再指定一个字典文件（通过参数“-w wordlist.txt”实现），然后按回车键。如果字典中包含了目标账户的密码，那么不久eapmd5pass软件将会成功地还原出这个密码。之后，使用这组账号和密码，就可以作为一个有效的用户连接到这个无线网络，并“合法”地登录。

2、保护EAP-MD5认证的安全

不幸的是，在“基于消息摘要第5版的扩展认证协议”认证方式下，某些操作方式的设计不可能实现无线网络上的安全，如“四次握手”中明文传送用户名。除此之外，还有“基于消息摘要第5版的扩展认证协议”认证中以明文方式发送“质疑”字段和“响应”字段也都是安全隐患。另外，在“基于消息摘要第5版的扩展认证协议”认证方式中，客户端和Radius服务器之间不提供相互认证的机制，所以要确保可以应对可能发生的“中间人攻击”（man-in-the-middle attack）和“AP接入点模拟攻击”（AP impersonation attack）。但在这种机制下，因为客户端和Radius服务器不能确定接收到的数据包必定是由对方直接发给的或必定不是对方直接发给的，所以要想确保能防止这两种攻击是不可能的。在一些设置中，您可能会看到同样的“质疑-响应”机制（challenge-response mechanism），该机制可以在一个如“基于隧道传输层安全的扩展认证协议”的“隧道协议”（tunneling protocol）下进行连接和通信，这可以被认为是一个安全的替代方法。不过，如果您是单独地使用“基于消息摘要第5版的扩展认证协议”认证方式，还是建议使用另外的、更安全的EAP类型。

三、EAP-GTC认证方式

“基于通用令牌卡的扩展认证协议”（EAP-GTC）是一种名叫“通用令牌卡”（Generic Token Card）的认证方式，该认证方式就是在AP接入点和客户之间共同使用某种动态生成的一次性密钥，这个一次性密钥就叫“令牌”（Token），这里的“一次性”是指每一个密钥都有“生命期”，过了这个“生命期”该密钥就作废了，进而换成另一个新的密钥，并重新开始统计这个“生命期”的有效时间。尽管市场上有许多硬件厂商都在基于这种认证方式生产产品，但是最常见的例子是“RSA SecurID”的品牌。

从概念上讲，“基于通用令牌卡的扩展认证协议”认证方式甚至比“基于消息摘要第5版的扩展认证协议”认证方式还简单。在EAP-GTC认证情况下，用户硬件的“令牌”（token）和“认证服务器”（authentication server）都共同知道一个“短生命期”（short-lived）的共享密钥（shared secret），该值其实就是“令牌”。在通信之前，客户端的用户要想证明自己拥有这个令牌，就需要把该共享密钥值发送给认证服务器。认证服务器将接到的这个值与自己事先保存的值进行比较，如果两值相同，则认证服务器就给客户发送一个“EAP-Success”的成功消息给提出认证的这处客户端用户，表示是合法用户，二者可以通信；否则就会发送“EAP-Failure”失败的消息。

1、攻击EAP-GTC认证方式

“基于通用令牌卡的扩展认证协议”认证方式同“基于消息摘要第5版的扩展认证协议”认证方式类似，但就“基于通用令牌卡的扩展认证协议”自身而言，该认证方式并不符合为802.11网络提供认证服务的认证要求，其原因是使用这一认证方式的客户端和认证服务器之间，在认证的开始阶段没有相互认证就直接通信了。相反，硬件令牌则用作认证的次要形式，而把一个用户名和密码，或加密证书作为了首要的形式。

从概念上讲，攻击“基于通用令牌卡的扩展认证协议”认证方式非常简单，只要我们拿到当前用户正在显示的“令牌”值，在该值“生命期”过期之前，向服务器进行通信的时候，将其作为自己的“令牌”即可。在模拟信号（analog）的世界里，您可以通过“肩窥”（shoulder-surfing）用户的“令牌”或直接“亲手偷”（physically stealing）过来。在数字信号的王国中，您可以更加隐密地完成这一点：创建一个“骗子”AP接入点（rogue AP），吸引拥有“令牌”的用户，并“说服”他输入正常的“令牌”值。因为该值是有时效性的，所以您要尽可能快地将该值说成是自己的“令牌”值，拿到那个真正的网络中使用。

在实际的操作中，在Wi-Fi的无线网络领域，“基于通用令牌卡的扩展认证协议”认证方式并不能作为一种完全独立的认证方式单独使用，而是作为“基于隧道传输层安全的扩展认证协议”认证方式或“受保护的扩展认证协议”认证方式中内部认证时使用的方法。因为如果不使用内部认证，那么用户将在传递他的“令牌”值的时候使用明文方式传递了。

2、保护EAP-GTC认证的安全

如果您已经部署了“受保护的扩展认证协议”认证方式或EAP-ITLS认证方式，并将“基于通用令牌卡的扩展认证协议”认证方式作为这两种方式中的次要的内部认证形式，那么在这个无线网络的上下文中，同样意味着您正在使用“基于通用令牌卡的扩展认证协议”这种认证方式。您所能做的最重要的事情，就是确保在客户端的设备上配置了“只有在隧道建立成功以后，才与服务器进行认证”的设置，并且如果隧道连接失败，则马上停止。

四、LEAP认证方式

“轻量级扩展认证协议”（Lightweight EAP，LEAP）是Cisco公司专有的EAP认证类型之一，主要是基于“Microsoft版的‘质疑响应认证协议第2版’”（Microsoft-Challenge-Handshake Authentication Protocol，MS-CHAPv2）。客户端要连接到网络，先发送它的用户名，认证服务器会返回一个8字节的“质疑”。然后，客户端会计算密码的NT散列值，然后将该值作为“种子”（seed material），并通过DES算法对“质疑”进行加密，最后将散列值和加密后的“质疑”连接在一起，一并返回给认证服务器。认证服务器在拿到连在一起的结果后，会做相同的计算，以验证结果的正确性。

表面上，“轻量级扩展认证协议”好像一个相当不错的协议。然而，其主要的缺点就是“质疑”和“响应”都是通过明文进行传送的，如果我们可以捕获到一个用户认证过程中所产生的通信数据包，那么我们就可以启动离线“暴力破解”攻击，进而破解出该用户的密码。

1、用Asleap软件攻击LEAP认证方式

“轻量级扩展认证协议”的漏洞是由Joshua Wright首次发现并展示出来。他以Asleap来命名用来展示这一漏洞的软件工具。Asleap的运行，需要先捕获一些EAP进行协议握手时的一些数据包。要完成这种捕获操作，您既可以直接使用Asleap工具本身得到，也可以通过任何其他的“嗅探器”（sniffer）得到。无论采取哪种方式，我们要做的第一件事情，就是创建一个散列字典文件（hashed dictionary file）。这个文件可以用来从任何“轻量级扩展认证协议”保护的网络中还原密码。下面创建一个散列字典文件：

该命令输出了两个文件：一个索引文件（扩展名为“.idx”）和一个散列字典文件（dict.hashed）。这个“预先计算散列字典”（precomputed hash dictionary）文件不针对特定的任何无线网络，从而只需要产生一次。当然，这样说的前提是假设该用户的密码在这个字典中，否则要么在攻击中失败，要么就是您发现有新的可能有密码后，再重新生成一次。一旦散列字典生成结束，就可以发起实际的离线“暴力破解”攻击。在下面的例子，有一个名为pcap的文件，是在采用“轻量级扩展认证协议”认证的无线网络中被嗅探程序捕获到的数据包组成的文件，假设该无线网络的密码是“qaleap”。

2、保护LEAP认证的安全

出于某种原因，如果您的无线网络上被迫使用“轻量级扩展认证协议”认证方式，并且不能升级，那您唯一可以做的事就是尝试执行严格的密码策略，否则如果您可以换成别的东西，那请马上换掉。其中，“受保护的扩展认证协议”认证方式就是一个“轻量级扩展认证协议”认证方式的很好的替代品。换成“受保护的扩展认证协议”认证方式以后，您仍然可以使用以前的用户名和密码。最后，Cisco公司的建议是所有“轻量级扩展认证协议”认证方式的设备都请替换为使用“基于安全隧道灵活认证的扩展认证协议”认证方式。

五、EAP-FAST认证方式

“基于安全隧道灵活认证的扩展认证协议”（EAP-Flexible Authentication via Secure Tunneling，EAP-FAST）认证方式也是一种EAP的认证方式，同“轻量级扩展认证协议”一样，也是由Cisco系统开发的。并且EAP-FAST很像“受保护的扩展认证协议”认证方式和“基于隧道传输层安全的扩展认证协议”认证方式。“基于安全隧道灵活认证的扩展认证协议”认证方式首先在客户端和认证服务器之间建立一个安全隧道，然后将用户认证证书经由该隧道进行传送。在“基于安全隧道灵活认证的扩展认证协议”认证中，安全隧道的创建被称为“第1阶段”（Phase 1），客户端通过隧道传输认证证书被称为“第2阶段”（Phase 2）。

“基于安全隧道灵活认证的扩展认证协议”的显著特征之一是其具有“受保护的访问认证证书”（Protected Access Credential，PAC）。PAC是一个存储在客户端系统中的文件，其中包含一个“公共密钥”（shared secret），即“PAC密钥”（PAC-Key）；一个不透明的元素，称为“PAC不透明成分”（PAC-Opaque）；以及其他信息，称为“PAC信息”（PAC-Info）。“PAC信息”中包括了认证服务器的“权威ID”（Authority Identity，A-ID）。上述信息一起随着“受保护的访问认证证书”分发到各个客户端上，完整的“‘传输层安全’握手”并不需要用于建立TLS隧道。相反，“第1阶段”所使用的处理方式是基于RFC4507中所提到的方式完成，RFC4507定义免声明的TLS会话还原。

连接时，认证服务器向客户端发送一个“权威ID”，然后客户端检查本地系统的A-ID，看与该A-ID是否与“受保护的访问认证证书”进行了关联。如果有一个有效的“受保护的访问认证证书”是关联的，客户端将该PAC所对应的“PAC不透明成分”回送给认证服务器。该“PAC不透明成分”是认证服务器生成的，最初，当客户端向认证服务器发送认证的时候，认证服务器在向客户端提供一个双方会话（session）的“身份证明”（identifier），“PAC不透明成分”也就是在这个期间生成的。您可以将这个“身份证明”理解成一张“门票”。一旦认证服务器能识别这个“PAC不透明成分”是有效的，那么“PAC密钥”就会被用来派生“传输层安全”的主密钥（master secret），并且这个缩短的“‘传输层安全’握手过程”（即“第1阶段”）就将告完成。

虽然“基于安全隧道灵活认证的扩展认证协议”的可支持多种“第2阶段”的协议，但是只有“Microsoft版的‘质疑响应认证协议第2版’”MS-CHAPv2和“通用令牌卡”GTC是最常用的。从EAP-FAST协议的角度看待MS-CHAPv2和GTC，就像从“受保护的扩展认证协议”PEAP和“基于隧道传输层安全的扩展认证协议”EAP-TTLS看待TLS隧道一样，“传输层安全”TLS隧道可以保护这些认证证书免受攻击。只不过TLS隧道是在“第1阶段”建立的。

向用户发布一个“受保护的访问认证证书”的过程被称为“PAC配置”（PAC provisioning），或者称为“第0阶段”（Phase 0）。即使在小规模部署中，“PAC配置”也是一项艰巨的任务。“第0阶段”所需要的不仅仅是初始化安装，而且还包括重建，所以“PAC配置”个数的添加就意味着管理费用的增加，因此通常的这种配置工作周期为一年一次。“PAC配置”可以通过“跑腿网络”（sneakernet）来引导，通过客户端的有线接口来引导，或者自动进行配置。前两个选项与传统的基于证书的EAP协议相比，确实没什么优势；然而，第三个选项是系统管理员喜欢“基于安全隧道灵活认证的扩展认证协议”的真正原因。自动的“PAC配置”只要求用户输入她的认证证书，就可以通过无线接收其“受保护的访问认证证书”。尽管自动的“PAC配置”对于网络管理员来说是一个方便的功能，但它也是的“基于安全隧道灵活认证的扩展认证协议”迅速土崩瓦解的主要原因。

1、攻击EAP-FAST认证方式

自动的“PAC配置”可以以两种形式出现：“需服务器认证”（Server-Authenticated）和“非服务器认证”（Server-Unauthen-ticated）。“需服务器认证”的“PAC设置”不太吸引人，因为作为客户端需要有服务器的认证证书才能建立“第1阶段”，这种“鸡生蛋，蛋生鸡”的逻辑在一定程度上抵消了自动“PAC配置”的初衷。“非服务器认证”的“PAC配置”则广受欢迎。它实现“第1阶段”的时候，使用一个匿名的（anonymous）“Diffie-Hellman隧道”，然后在“第2阶段”继续的时候使用“Microsoft版的‘质疑响应认证协议第2版’”（MSCHAPv2）认证证书。这样说来，其实整个协议就变成了“在‘基于安全隧道灵活认证的扩展认证协议’认证下使用‘Microsoft版的‘质疑响应认证协议第2版’协议’的认证”（即EAP-FAST-MSCHAPv2）。也正如其超长名称所暗示的一样，在“非服务器认证”的“PAC配置”下，匿名隧道并没有为用户提供“到认证服务器去认证”的能力。因此，“基于安全隧道灵活认证的扩展认证协议”的部署方法很容易受到“中间人攻击”（man-in-the-middle attack）或“AP接入点模拟攻击”（AP impersonation attack），这一点很像“受保护的扩展认证协议”PEAP和“基于隧道传输层安全的扩展认证协议”。一旦有了访问“Microsoft版的‘质疑响应认证协议第2版’”的认证证书，您就具有了发动一次“暴力攻击”的能力，并且，如果成功的话，就允许您从事“PAC配置”的处理，并且拿到一个有效的网络“受保护的访问认证证书”。

对这种攻击方式需要注意的是，为了成功地发动攻击，您必须在“PAC配置”的时候处在该无线网络中。而“处在该无线网络中”又谈何容易呀，有时还比较困难，因为客户端通常只在初次部署的时候进行大规划的批量“PAC配置”，然后偶尔再以新客户端身份加入。另外，“受保护的访问认证证书”重建的时候，也会为攻击提供了另外一次良机，但这时的攻击同样存在上面所说的这种限制。

2、保护EAP-FAST认证的安全

保护“基于安全隧道灵活认证的扩展认证协议”的安全是件非常简单的事，就像是禁止“非服务器认证”的自动“PAC配置”一样简单。然而，应当指出：一旦”非服务器认证”的自动“PAC配置”不再可用，“基于安全隧道灵活认证的扩展认证协议”所提供“对其他基于证书的EAP认证”就几乎没什么好处可言了。如果必须使用这种类型的“PAC配置”，它应该在“有限的次数内”，在“可控制的地方”再进行这样的“PAC配置”，以便降低风险。

六、EAP-TLS认证方式

“基于传输层安全的扩展认证协议”（EAP-Transport Layer Security，EAP-TLS）是第一个要求与“Wi-Fi保护访问”兼容的EAP认证方法。EAP-TLS被认为是非常安全的，主要是因为它使用了客户端和服务器证书来认证网络上的用户。然而，这同时也是其主要的缺陷。在一个任意规模的组织中，管理所有用户的证书肯定是一个让人胆寒的挑战，大多数组织根本不具备所需的PKI的水平。

从概念上讲，“基于传输层安全的扩展认证协议”EAP-TLS协议很简单。服务器向客户端发送它的证书，该证书是经过认证的，证书中包括的“公共密钥”（public key）用来加密进一步消息的。客户端将它的证书发送到认证服务器，该证书是认证服务器认证过了的。然后客户机和服务器处理生成一个“随机密钥”（random key）。在其他情况下（例如“安全套接层”（Secure Sockets Layer，SSL）），这个密钥是用来初始化一个对称加密套件（symmetric cipher suite），加密从“传输层安全”会话（TLS session）中得来数据。然而，在“基于传输层安全的扩展认证协议”中，您对使用“传输层安全”来加密这些数据并不感兴趣，这是“高级加密标准-计数器模式密码块链消息完整码协议”（Advanced Encryption Standard-Counter Mode CBC-MAC Protocol，AES/CCMP）或“临时密钥完整性协议”（Temporal Key Integrity Protocol，TKIP）的工作。相反，您可以使用通过“传输层安全”生成的随机密钥去创建“成对主密钥”。随着“EAP-Success”的成功消息，“成对主密钥”会从RADIUS认证服务器发送到AP接入点上。

1、攻击EAP-TLS认证方式

正面攻击“基于传输层安全的扩展认证协议”协议几乎是不可能的。如果EAP-TLS的漏洞突然受到了某种加密攻击，这可能意味着“传输层安全”被破解了，这比担心您的无线网络被攻击更加可怕。但这并不是说这个供应商的“基于传输层安全的扩展认证协议”没有缺陷。虽然您肯定也希望它的确没有，但正如该协议是非常强健的一样，它的确还是有缺陷的。打败“基于传输层安全的扩展认证协议”的唯一可行的方法就是窃取一个客户端的“私人密钥”（private key）。

窃取客户端的“私人密钥”可能非常困难，或者根本一点也不难。如果他的“私人密钥”保存在一个受“个人身份ID码”（Personal Identification Number）密码保护的智能卡内，那么您会有相当多的工作要做。如果“私人密钥”保存在一个用最低级别保护的Linux或Windows操作系统的硬盘中，那您可以通过一些其他手段进行攻击了，例如，偷到“私人密钥”是最直接的攻击方式。

在Linux操作系统上，从一台已成功入侵过的系统中获取“私人密钥”只是找到密钥的保存区域并将其复制出来的简单问题。而在Windows操作系统中则会有点麻烦，因为密钥通常保存在“认证证书”中。

一旦您偷到了一个“私人密钥”，并获得用户的“认证证书”，那就简单多了。因为“私人密钥”和“认证证书”的算法是公共的，所以后面的操作比较容易，下面，您就可以使用正确的“认证证书”和“私人密钥”，配置您的计算机连接到这个无线网络上。一旦你进入网络中，如果您想捕获别人的通信数据包，您可以用“ARP欺骗”（ARP-spoof）来完成，或者运行“中间人攻击”（man-in-the-middle attack）方式。不过，因为每个人都有独特的“成对主密钥”，所以如果您使用airdecap-ng，恐怕并不能轻易地解密每个人的通信数据包。

2、保护EAP-TLS认证的安全

如果您已经实施了“基于传输层安全的扩展认证协议”进行系统的认证，这至少说明您在无线网络安全方面已经做了不少处理。如果有可能，尽可能将客户端的“私人”密钥保存在智能卡上，或其他一些“防篡改的令牌”（tamper-resistant token）中。如果没有这些，那就保持经常给客户端工作站及时打补丁，并更新系统到最新版，以防止客户的“私人密钥”被窃取。

在使用“基于传输层安全的扩展认证协议”的时候，一个次要的关注点就是包含在“认证证书”中的信息和这些信息的收来发去都是自由使用的。认证证书中包含有轻度敏感信息，如员工的姓名、密钥长度和散列算法。如果您关心这个问题，您可以在一个加密的隧道中运行“基于传输层安全的扩展认证协议”，从而保护刚才提到的信息。这种技术被称为“在‘受保护的扩展认证协议’的认证中使用‘基于传输层安全的扩展认证协议’的认证”（PEAP-EAP-TLS），该技术是由Microsoft公司发明的。

七、PEAP和EAP-TTLS认证方式

在前面的例子中，我们已经看到“扩展认证协议”的方法表示很弱不禁风，因为一个攻击者可以通过离线攻击就可以观察并拿到“认证证书”。例如前面“基于消息摘要第5版的扩展认证协议”和“轻量级扩展认证协议”两个认证方式。在“基于传输层安全的扩展认证协议”中，我们也意识到了，一个使用“认证证书”的认证方法在安全方面是高效的，一旦正确的部署，就很难以破解。不过反过来，对于一个组织来说，EAP-TLS认证方式很难部署，因为想让所有用户都保护好各自的认证证书需要大量额外的维护成本。如果对一些中间数据能提供一些针对EAP-TLS的加密安全技术，那么在方便用户名和密码之间的关联上，算法是更容易让人感觉到满意的。对于这一点，PEAP和EAP-TTLS正好提供了这种将二者优点牵线搭桥，共建新认证方法的功能。

“受保护的扩展认证协议”（Protected EAP，PEAP）和“基于隧道传输层安全的扩展认证协议”（EPA-Tunneled Transport Layer Security，EAP-TTLS）是目前Wi-Fi无线网络中，在基于EAP认证的各种认证算法方式中，拥有最大量、最新安装量的两种认证方式。尽管二者使用了不同的技术，但它们的操作风格却十分相似。下面我们一起来了解这些内容。

无论是“受保护的扩展认证协议”，还是“基于隧道传输层安全的扩展认证协议”，都首先在客户端和认证服务器之间建立一个TLS隧道，并通过这个隧道提供相互认证，然后，通过采用不太安全的“内部认证协议”（inner authentication protocol）经由隧道传送“认证证书”。这条隧道的“内部认证协议”之所以被认为是不太安全的，是因为最初的设计认为在隧道内的网络上实施嗅探是不太可行的，一旦他们处于隧道之中，不太安全的身份认证机制则会被隧道本身的安全机制所保护，这种保护给它一个附加级别的保护以避免“侦听攻击”（eavesdropping attacks）。

例如，我们可以想象一下，如果弱“轻量级扩展认证协议”协议的“质疑”和“响应”等信息是通过加密信道进行发送和接收的，那么考虑一下会发生什么？这时攻击者将不能够收集发动“字典攻击”所需要的数据，那么“轻量级扩展认证协议”将变成一个非常安全的身份认证方法。事实上，许多“受保护的扩展认证协议”和“基于隧道传输层安全的扩展认证协议”两个认证方式，在部署的时候，都使用了与“轻量级扩展认证协议”相似的“内部认证协议”。

此外，“传输层安全”隧道不仅是提供了对内部认证证书的保护，而且也为客户端提供了确保认证服务器的身份的能力。这样就实现了可以安全地相互认证的想法，作为客户端通过一个可信任的认证机构的认证服务器来验证“传输层安全”证书认证。

对于“传输层安全”隧道来说，“外部”（其实就是隧道本身）提供了基本的保护，“内部”但以安全的认证，所以“内部”就算我们姑且认为是“潜在的薄弱”，我们也要先将“外部”瓦解后再考虑这些事。下面的攻击主要集中在如何颠覆这条隧道的问题上。

攻击PEAP认证方式和EAP-TTLS认证方式

“受保护的扩展认证协议”和“基于隧道传输层安全的扩展认证协议”纯粹依靠“传输层安全”隧道，为它的用户的“认证证书”提供一种安全可靠的运输，我们自然会将隧道作为我们的攻击目标。问题是，“传输层安全”在绝大多数情况下是安全的，虽然的确存在一些攻击方式，但它们通常非常难以实现，或者是需要在特定的条件下成功地登录到在现实环境中，才有获得成功的可能性。因此，如果“传输层安全”本身在协议上不存在“设计”漏洞，我们就不得不在其程序的“实现方式”（implementation）上找找有没有漏洞可钻。比如我们希望我们的目标网络有配置上的错误；不要焦急，真的有网络管理员无知地帮助我们。

果然，一个意外之喜被发现，在“受保护的扩展认证协议”和“基于隧道传输层安全的扩展认证协议”的配置中，一个客户端上出现了一个常识性错误。该配置跳过客户端上的证书认证操作。以这种方式配置客户端，这个客户端就会潜在的容易受到“AP接入点模拟攻击”（AP impersonation attack）和“中间人攻击”（man-in-the-middle attack）。

想象一下，我们盯上了一个“受保护的扩展认证协议”或“基于隧道传输层安全的扩展认证协议”认证的无线网络。我们配置一个新的AP接入点，该AP接入点与那个我们要“取而代之”的合法AP接入点具有相同的“服务集标识”，并且我们的AP接入点可以向客户端提供更好的服务网络信号强度。这无疑会吸引客户端前来连接。当客户端与我们连接的时候，我们就“偷梁换柱”地将接收到EAP消息通过我们的RADIUS服务器进行传输，但在这个传输中，终止“传输层安全”隧道，并且接受客户的“内部认证协议”。通过这种方式，我们就已经击败了“传输层安全”隧道。

Hostapd程序是一款可以在正常802.11卡之外，创建一个AP接入点的软件，最新版本的hostapd程序，程序内部还内置了一个独立的RADIUS服务器。这大大简化了冒充一个合法“WPA企业模式”认证的部署过程。这个软件逻辑的设计动机毫无疑问，就是专门针对上面这种攻击而定的。这些AP接入点可以完成一定级别上基于EAP等多数认证方法，并且由于软件内置RADIUS服务器的功能，所以也不再需要外部的RADIUS服务器，另一个好处是，像我们这样的黑客也不再需要建立一个完整的RADIUS服务器了。

Hostapd的无线Pwnage版本：hostapd-wpe。几年前Joshua Wright和Brad Antoniewicz共同开发了一个开源RADIUS服务器的修改版，名叫FreeRADIUS。在这个版本中，FreeRADIUS-WPE是Hostapd的无线Pwnage版本，该版本最适合接收由客户端发送给它的任何认证证书，一旦将认证证书中的密码还原成明文以后，黑客就会重新使用这些密码。这些补丁和技术已加入到hostapd的内置RADIUS服务器中了，所以这个项目的后续开发人员就将其命名为hostapd-wpe。

Hostapd-wpe提供许多攻击功能，且并没有指定必须是与“Wi-Fi保护访问”认证相关的认证方式。例如作为客户端版本的“OpenSSL心脏之血攻击”（OpenSSL Heartbleed attack），以及最新版的Karma“骗子”AP接入迭代技术（iteration of the"Karma"rogue-AP technique）。

安装hostapd-wpe程序是一个简单的过程。

（1）首先，该程序的正常使用，有一些必须预先安装的程序，所以在正式安装之前，先要在Linux操作系统上安装这些可能漏装的先决条件。

（2）然后，下载hostapd程序和hostapd-wpe补丁程序的源代码，并在这两个程序的下载网站上查找这两个软件的版本信息。

（3）现在，应用hostapd-wpe补丁，并在整个工程中编译连接一下。

（4）最后，运行一个脚本文件，该脚本文件包含由hostapd-wpe自动生成的一些“自签名证书”（self-signed certificate）。

八、运行恶意RADIUS服务器

在下面的内容中，我们会举例说明一个攻击过程。在这个攻击中，有两个客户端已经被配置为连接到一个与“WPA2企业模式”模式下的网络上，通过“受保护的扩展认证协议”和“Microsoft版的‘质疑响应认证协议第2版’”两个认证方式，并且这两个客户端都已暴露在恶意的RADIUS服务器之中。在下面的这个例子中，我们将模拟攻击虚构的企业网络解决方案，该解决方案命名为“虚构方案”（Foray Solution）。

我们的目标是当遇到下列情况时，确定我们应该采取的行为，以及终端用户可以识别出来的可能的警报：

在一个网络中，突然出现了一个相同的“服务集标识”，对客户来说，以前使用的“Wi-Fi保护访问版本2”认证突然换成了“Wi-Fi保护访问版本1”认证，这会发生什么？

当之前一直用来建立“传输层安全”通道的认证突然无法在信任的证书颁发机构进行验证了，这时的客户端会怎么做？

如果RADIUS认证服务器返回了认证成功的消息，客户端是继续与认证服务器的其他操作？还是盲目地直接进行关联操作？

除此之外，为了后面还有人接着上当，客户端应该信任的证书会做成如图3所示的样子。

图3  客户端应该信任的证书

在开始使用hostapd-wpe软件之前，我们需要修改该程序的配置文件hostapd-wpe.conf。因为我们是在无线接口上运行的，所以我们将接口设置为wlan0，并且禁用（disable）掉“驱动程序默认是有线”的那一行。在这个文件中，由当前位置稍微向后移动，我们还会看到有很多与802.11相关的选项，我们还可以将所有的这些802.11的选项都设置为“允许”（enable）。最后，我们找“WPA的版本”这一项，将其值改为“2”以上。更改完成之后的hostapd-wpe.conf文件，看起来应该像下面这样（粗体部分表示修改后的内容）。

为了让这些修改生效，我们可以启动服务器。

1、诱骗Windows 客户端到“骗子”AP接入点上

在AP接入点运行起来以后，我们就可以看到连接这个网络的Windows客户端，还可以调查一下他们所使用的Windows版本是多少。记住，在这种情况下，客户端已被配置修改为连接到ForayCorporateNetwork这个无线网络上，我们就是要看看当有“骗子”AP接入点故意设置使用相同的“服务集标识”可用的时候，这些客户端是如何表现的。

首先，Windows客户端会比较这两个“WPA企业模式”认证网络所宣称的版本号。如果前面对配置文件修改正确（就是配置文件hostapd-wpe.conf中“wpa=2”的那一行），那么Windows客户端上所做的检测通信，并且没有也没向客户端通知什么信息。如果我们在我们的“骗子”AP接入点中的配置有错误，那么该客户端用户将看到如图4所示的警告信息。

图4  警告信息

一旦Windows客户端执行完WPA认证时的版本比较后，下一步就是验证在“传输层安全”隧道另一端的”认证证书”是否有效。在Windows默认设置下，如果“认证证书”验证失败，那么该Windows用户客户端将不被允许连接到该无线网络上。由于该客户端以前是成功地连接到过这个网络的，所以这系统会提示是否要“删除网络连接”（forget the network），如图5所示。

图5  系统提示是否删除网络连接

这对于攻击者是不利的，因为Windows还没有给我们送来缓存中的“认证证书”。幸运的是，这个配置是由管理员才能进行配置的，所以在没有有效的服务器“认证证书”的前提下，仍然有相当数量的部署“受保护的扩展认证协议”。

一旦“外部”的“受保护的扩展认证协议”隧道已经建立，Windows将会执行一个“Microsoft版的‘质疑响应认证协议第2版’”认证，以便与我们的服务器进行数据交换。这时，Windows允许我们针对以后的“认证证书”发起“字典攻击”。当Windows客户端用户连接的时候，在hostapd-wpe的窗口中，将显示类似于下面的窗口的内容。

我们可以借助于这些值，尝试在离线状态下进行“暴力破解”。但在不久的将来，客户希望我们能够通过对我们自己的认证。因为没有该用户的密码（这时，我们还没有到退出的时候），所以我们也不能认证我们自己。这也就是为什么在后面紧随就是用户的“认证证书”，我们可以从日志文件中，看到下面的输出内容：

由于缺少相互的认证，所以这也是Windows系统中客户端的窗口显示连接断开的主要原因。走到这一步，现在Windows用户也不知道什么地方出了差错，他同样还是会看到之前出现过的那个“无法连接到该网络”（Can’t connect to this network）对话框。

如果您无意中把一个Windows客户端骗到您的“WPA1企业”认证的无线网络中，而他这个客户端的本意是想加入“WPA2企业”认证的无线网络，然后，您在“内部”认证方法中证明自己本身也失败了，那Windows会将这种行为视为是一种攻击，Windows会强行删除该无线网络的配置文件。所以这是一定要引起用户和管理员的注意的。当您让hostapd-wpe工作的时候，如果要冒充“Wi-Fi保护访问版本2”认证的无线网络，那么一定要确保在配置文件hostapd-wpe.conf中的“WPA的版本号”设置为“2”。

尽管很不幸，我们没能让Windows客户端加入到我们的网络中，但是我们已找到我们所想要的东西：那就是用户的“认证证书”。通过这个散列后的认证证书，我们可以通过Asleap程序加载一个离线的“密码猜测攻击”（password-guessing attack）。

通过结合保存在hostapd-wpe日志文件中的Windows客户端用户的用户名，我们可以使用下列“认证证书”入侵到这个网络“johnny_c/turn_down_for_what！”中去。

2、诱骗OS X 10.9.4客户端到“骗子”AP接入点上

到目前为止，我们已经看到了Windows客户端在面对“骗子”RADIUS认证服务器的时候是如何表现的。下面我们通过比较的方式看看Mac的OS X客户端在遇到同样情况时的表现。

首先，让我们看看在“Wi-Fi保护访问”提供了不正确的版本的情况下，Mac的OS X上会发生什么。类似于Windows，用户收到警告提示（见图6）。

图6  OS X系统上出现的警告提示

这比我们在Windows上所看到提示信息更具体，但对于大多数非专业的终端用户来说，这么专业的提示信息也会让他们无所适从。那么，当Mac的OS X客户端接收到一个以前信任的“传输层安全”隧道“不信任的认证证书”（untrusted certificace）的时候，会发生什么呢？

图7中的错误提示信息，对于一个普通的无线终端用户来说，肯定很难理解，试想一下，如果“认证证书”上实际上写的是关于目标主机上的一些情况，而不是像图7所写的那种“‘鬼鬼祟祟的皮特斯阴谋’服务器证书”（即图中“Sneaky Petes Shady Server Certificate！”），那大家可以想象一下，会有多少人单击“继续”（即图中“Continue”）按钮，来进行继续的认证。

图7  错误提示信息

假如用户无视上述警告，而单击了“继续”按钮，那么他将被提示需要输入“用户名”和“密码”。正如在Windows显示的一样，这些“认证证书上”将被用于在“Microsoft版的‘质疑响应认证协议第2版’”认证中，用于“内部”的认证方法：

如果我们通过asleap软件运行这些结果，我们就会得出如前面Windows实例中的结论，即结果同样是“johnny_c/turn_down_for_what！？”。

获取Mac上OS X用户的“认证证书”同样有趣，从hostapd-wpe程序的日志文件中，我们就可以注意到客户端并没有断开。看来，OS X的现代版本并不通过“内部”隧道完成相互的“认证证书”。我们不仅得到该用户的“认证证书”，而且我们现在非常适合执行各种“客户端攻击”（client-side attack），终于，其中一个客户端可以让我们在其机器上拥有执行代码的权力。

3、保护PEAP和EAP/TTLS认证的安全

要防止这类“受保护的扩展认证协议”和“基于隧道传输层安全的扩展认证协议”认证方式的攻击，最关键的点就是要确保您网络中客户端的有效“认证证书”。如果某客户端的认证证书检查失败，那么客户端的设备将永远无法连接到这个无线网络上。

很多人想知道，为什么“连接到失败的证书认证网络”是软件的一个选择项。您可以参考Windows上的“受保护的扩展认证协议”配置属性，为什么它甚至会建立不进行验证的客户端呢？正如许多安全问题一样，答案就是：这涉及金钱或时间。

对于一个需要验证认证证书的客户端来说，要安装本地组织的“证书颁发机构”（Certificate Authority，CA），需要有根认证证书（root certificate）的权限，这个配置操作做起来可能很麻烦，另外，网络上一个“知名的‘证书颁发机构’”（well-known CA）要想发布证书，那么这个网络也需要认证证书，并且这种“知名的‘证书颁发机构’”是需要花钱买的。因此无论是在当地组织的“证书颁发机构”根证书安装，还是“知名的‘证书颁发机构’”发布证书，都是出力不讨好的事。相反，允许用户不做证书认证，则可以避免管理员买认证证书，也可以避免只是为了个无线访问而专门配备一个自己公司的证书认证服务器。

九、结语

本文涵盖了针对“Wi-Fi保护访问”认证的几种已知的攻击方式。“Wi-Fi保护访问”所提供增强的安全性大大优于其前身（“有线等效保密协议”），不过，这些改进也抬高了“Wi-Fi保护访问”认证系统的价格，这是由这些新的802.11协议所涉及的复杂性越来越高所导致的。幸运的是，这种复杂性对于最终用户来说是透明的（hidden），在任何现代的操作系统连接到一个“Wi-Fi保护访问”保护的网络和连接到一个“有线等效保密协议”保护的网络一样简单。然而，在幕后，在密钥的选择上，在协议的漏洞攻击上，在无线网络客户端的配置缺陷上，攻击者也有过几次良好的，可以充分利用认证算法弱点的机会，进而获得对网络的“非认证的”访问。

微信公众号：计算机与网络安全

ID：Computer-network

【推荐书籍】