个人用户在接入Wi-Fi网络的时候，只需要找到SSID然后输入密码就好了。但对于企业用户，这个过程充满了危机。今天要介绍给你的这篇WiSec 2023最佳论文奖得主——The Devil is in the Details: Hidden Problems of Client-Side Enterprise Wi-Fi Configurators就揭示了企业Wi-Fi认证中的种种细节导致的安全问题。
对于企业Wi-Fi接入，其实反而是在高校的大学生会更为熟悉？这种由IEEE 802.1X standard来规定的认证，通常需要先建立一个TLS连接，然后再由用户输入身份凭据完成认证。攻击者一般会利用Evil Twin攻击（也就是新建一个SSID同名、但是信号更好的Wi-Fi网络来进行钓鱼）来盗取敏感登录凭据。在这种背景下，本文作者对常用的一些企业Wi-Fi网络认证的configurator（怎么翻译呢？配置器？）进行了安全审计，发现了大量细节上的缺陷，让用户面临诸多安全威胁。下面我们来看看具体的问题。
首先作者分析的是Android 12开始使用的TOFU configurator，这个TOFU不是豆腐，是“首次使用信任”也就是“trust on first use”的意思。Google在Android官方文档里面是这么介绍TOFU的：
与只需要密码的个人网络相比，企业网络使用公钥基础设施（PKI）身份验证，这需要客户端预先安装证书。在 Android 11 或更低版本中，用户可以在网络设置中为服务器 CA 证书选择不验证选项，从而绕过服务器端证书的验证。但是，为了加强安全性并遵守 WPA R2 规范，Android 12 引入了对企业网络进行服务器证书验证的要求。这一附加要求为用户制造了障碍，因为他们需要为此类网络安装 CA 证书。 TOFU 为用户提供了一种通过简单地接受其根 CA 来连接到基于 PKI 的企业网络的方法。
对于运行 Android 13 或更高版本的设备，Android 支持首次使用信任 (TOFU) 身份验证方法 ( RFC7435 )，该方法允许用户通过安装服务器使用的根 CA 并将其域名设置为一个企业网络来信任企业 (EAP) 网络保存的网络。 TOFU 允许设备在用户首次连接到企业网络时获取未经身份验证的公钥，并保留该密钥以供后续连接使用。
https://source.android.google.cn/docs/core/connect/wifi-tofu?hl=zh-cn
然而这个TOFU是块“豆腐渣”，它的问题包括：
-
客户端（Wi-Fi接入方）先把用户凭据发出去了，才验证服务端（Wi-Fi提供方）的身份……
-
显示信息莫名其妙：如下图所示，当configurator开始认证的时候，首先会弹出来一个对话框，告诉客户端即将连接的Wi-Fi网络的提供方的一些信息。然而，然而，这个地方看起来显示的是证书信息，实际上显示的是这个证书的签发CA的信息，而不是证书本身的owner的信息……
-
更糟糕的是，configurator在显示这些信息的时候，根本不去验证这个证书的合法性，也就是说下面这些信息可能都是伪造的（里面也许就放了个自签名的公钥信息）……
-
configurator不会保存（假）证书信息，每次重新连接后，上次使用的证书（指纹）信息就被遗忘了，这样每次连接的时候，使用的证书都不同，configurator也不会提示用户……
-
攻击者还可以通过多次（实际观察下来也就是4次，如下面的状态机转换图so’si）拒绝服务攻击，让已经连接的Wi-Fi网络断开，然后重新回到上面那个“连接确认”的UI。
看完了Android的“豆腐渣”configurator，我们再看看其他一些第三方的configurator有没有问题。作者接下来关注的是eduroam CAT这个第三方的开源configurator，通过分析代码，作者发现，eduroam CAT configurator在连接的时候，对于服务端的名字校验有个非常大的bug：究其原因，eduroam CAT configurator使用了Android API level 18引入、然而已经在API level 23之后被废弃的setSubjectMatch方法，来从配置文件中读取允许连接的服务器域名。这个方法的问题在于，如果配置文件中指定的不是一个服务器名而是一组（multiple server names，例如zar.tugraz.at, zar1.tu-graz.ac.at, zar1.tugraz.at, zar2.tu-graz.ac.at, zar2.tugraz.at等），它会取一个公共的后缀（在这个例子中就是.at），那么攻击者只需要注册一个xxx.at域名，就可以混进去了……
对于另一个开源configurator——geteduroam来说，在处理多服务器名的配置文件时同样会有问题。特别地，如果配置文件中多个服务器名的类型不一样（比如一个是域名，另一个是IP地址），或者都是域名，但是属于不同的top-level domain也就是TLD不同，geteduroam configurator就会返回一个空的公共后缀……这样攻击者就可以随便申请一个证书，然后用来冒充Wi-Fi提供方啦。
作者当然也分析了商业的configurator，在一个名为SecureW2 JoinNow的商业configurator中，作者着重分析了这个APP使用的profile文件。作者广泛收集了470多个profile文件，很有意思的是，它们覆盖了不仅Android平台还有Windows和iOS平台。作者逐个仔细分析了这些（厂商签名过的）profile文件，发现其中有一些的enableServerValidation竟然是设置为false，也就是说，客户端看到这个属性值之后就不去校验服务器的身份了（这让人想起来了当年Android APP里面泛滥成灾的忽略TLS证书校验的问题）。实际上，这个问题的根本原因，编辑部今天早上刚刚遇到过：因为Windows 7、Android 10及更早的系统中没有安装最新的Let’s Encrypt证书的根证书，导致很多古老但是仍然在使用的计算机无法通过HTTPS访问相关网站，因而很多时候只能回退到不安全的HTTP协议。估计是出于同样的原因，这里出现了enableServerValidation设置为false的情况。当然，这个属性即使设置为false，也还是要看操作系统的约束。如果新版本的Android和Windows就会无视这个false，而macOS则会让用户来决定（假定被攻击了）是否要接受有问题的证书。
除了这个问题，SecureW2 JoinNow的Windows客户端还有一些奇怪的问题，它只会使用TLS_RSA_WITH_3DES_EDE_CBC_SHA或者TLS_RSA_WITH_AES_128_CBC_SHA这两种密码学套件，非常不安全对吧？！简直是后门！
总之，和上周推荐的“大破Office签名”一样，这篇论文的研究非常扎实，是我们喜欢的安全研究论文风格，强力推荐给大家！
论文：https://www.hugohue.com/src/wisec23-configurator-flaws-wu.pdf
原文始发于微信公众号（安全研究GoSSIP）：G.O.S.S.I.P 阅读推荐 2023-06-12 企业Wi-Fi认证危机
