All your credentials are belong to us: On Insecure WPA2-Enterprise Configurations
Man Hong Hue; Joyanta Debnath; Kin Man Leung; Li Li; Mohsen Minaei; M. Hammad Mazhar; Kailiang Xian; Endadul Hoque; Omar Chowdhury; Sze Yiu Chau
The 28th ACM Conference on Computer and Communications Security (CCS 2021) 
About this page
This page serves as an extended discussion on the work, All your credentials are belong to us: On Insecure WPA2-Enterprise Configurations, which is included in The 28th ACM Conference on Computer and Communications Security (CCS 2021). In the following, we dissect specifically the vendor (negative) responses to the bug reports that we had filed. The reports span from system UI design weaknesses to vulnerable setting for trusting certificates. While we believe the issues would harm users achieving secure connection with WPA2-Enterprise, the vendors do not treat them as security issues. The reports were dismissed and no fixes were promised. Thus, we hope this page would help the public to understand the issues that we found, and how to avoid them under certain situations.
About this paper
abstract
In this paper, we perform the first multifaceted measurement study to investigate the widespread insecure practices employed by tertiary education institutes (TEIs) around the globe when offering WPA2-Enterprise Wi-Fi services. The security of such services critically hinges on two aspects: (1) the connection configuration on the client-side; and (2) the TLS setup on the authentication servers. Weaknesses in either can leave users susceptible to credential theft. Typically, TEIs prescribe to their users either manual instructions or pre-configured profiles (e.g., eduroam CAT). For studying the security of configurations, we present a framework in which each configuration is mapped to an abstract security label drawn from a strict partially ordered set. We first used this framework to evaluate the configurations supported by the user interfaces (UIs) of mainstream operating systems (OSs), and discovered many design weaknesses. We then considered 7045 TEIs in 54 countries/regions, and collected 7275 configuration instructions from 2061 TEIs. Our analysis showed that majority of these instructions lead to insecure configurations, and nearly 86% of those TEIs can suffer from credential thefts on at least one OS. We also analyzed a large corpus of pre-configured eduroam CAT profiles and discovered several misconfiguration issues that can negatively impact security. Finally, we evaluated the TLS parameters used by authentication servers of thousands of TEIs and discovered perilous practices, such as the use of expired certificates, deprecated versions of TLS, weak signature algorithms, and suspected cases of private key reuse among TEIs. Our long list of findings have been responsibly disclosed to the relevant stakeholders, many of which have already been positively acknowledged.
OS weaknesses
Overview Table
| OS | Issues | Implications | Vendor Responses |
|---|---|---|---|
| Android 7+ | Server name becomes optional when a specific CA is chosen as the trust anchor. | Possibility of insecure configurations if commercial CAs are used as trust anchor. | Acknowledged [CVE-2020-27055] |
| Chrome OS | The UI lacks an input box for specifying the correct server name of the certificate. | Configurations vulnerable to ET attacks if commercial CAs are used as the trust anchor. | Acknowledged |
| Chrome OS | Domain name checking (possible only via profiles) uses a substring matching logic. | Attackers can easily obtain attack certificates which satisfy the name checking condition. | Acknowledged [CVE-2021-37964] |
| Chrome OS | Inconsistent default setting for CA certificate depending on the UI entry points. | Potential confusion and misconfiguration for users who do not understand the subtleties. | Acknowledged [CVE-2021-21212] |
| Chrome OS | The UI shows “Do not check” after importing a profile with multiple CA certificates. | Gives a misleading perception that the configuration is not validating the server certificate. | Acknowledged |
| Windows 10 | The short timeout hinders manual checking of the certificate thumbprint. | Frustrating the users into continuing the connection without checking the thumbprint. | Dismissed |
| Windows 10 | The certificate thumbprint is the SHA1 hash digest of the certificate. | Resourceful attackers can compute and leverage hash collision for impersonation attacks. | Dismissed |
| iOS | The UI marks any server certificate as "Not Trusted" with a red-colored warning text. | Confusing the users into blindly trusting any server certificates. | Dismissed |
| macOS | Self-signed CA certificates in a pre-configured profile given full trusts after import. | Installing profiles can open doors to many other attacks, e.g., MITM against HTTPS & IPSec. | Dismissed |
macOS
Issue
Self-signed CA certificates in a pre-configured profile given full trusts after import.
Expected behavior
CA certificates imported through the installation of a Wi-Fi configuration profile should only be trusted for the purpose of authenticating enterprise Wi-Fi, that is, "Extensible Authentication (EAP)", but not the other purposes such as SSL, IPSec, and software update.
Implication
The system by default grants full trusts on self-signed root CA certificates embedded in Wi-Fi configuration profiles, which can have devastating effect on the user's overall security. For example, imagine a scenario where a user went to a cafe and is trying to use the Wi-Fi there. The cafe owner can take advantage of this elevation of trust by asking the user to install a Wi-Fi configuration profile (in order to access the Wi-Fi there), and then use this to inject a trusted CA certificate on the user's macOS. The cafe owner can then use that to break many security protocols, for example IPSec and TLS, and potentially perform malicious software updates as well. We did an experiment on this and were able to perform HTTPS interception against browsers like Safari and Firefox, using an intercepting appliance with the CA certificate injected through a Wi-Fi configuration profile on a test machine. We don't see any legitimate reasons to why self-signed certificates imported through Wi-Fi configuration profiles should be given full trusts to all the other purposes beyond EAP. Based on our testing, unlike macOS, iOS does not by default grant full trust to certificates imported through Wi-Fi configuration profiles.
Demo
We demonstrate the feasibility of HTTPS interception by loading a pre-configured profile to a macbook with the use of MITM proxy. First, the macbook is connected to the network that MITM proxy controls. Next, the macOS gives full trusts, including for the use of SSL, to the self-signed CA certificates embedded in the configuration profile when the system imports it. When the user browsers any websites using for example Firefox/Safari, the MITM proxy is able to intercept the HTTPS traffic; meanwhile, it is also capable of manupulating the content. As shown in the demo video, the wording of Apple is changed to Google.
Vendor's response
For the issue you reported about full trust given to a self-signed CA certificate, we determined there is not a security risk to users, but we have forwarded this along to the appropriate team to review for future potential enhancements.
Takeaway
If you are asked to import a configuration profile, you should check if the CA certificates are fully trusted. And importantly, do not heedlessly install a profile.
iOS
Issue
The UI marks any server certificate as "Not Trusted" with a red-colored warning text.
Expected behavior
The textual description on iOS and macOS for indicating the validity of the certificates should be consistent, so that it can properly assist users to make a decision on whether to trust the certificate or not.
Implication
The indicator on iOS regarding the validity of the certificates is always "Not Trusted" in red, even if the same certificate is shown as valid on macOS. Due to this discrepancy, the users are not able to manually validate the server certificate (and hence the authenticity of the server) through the UI, unless they are also given the SHA256 fingerprint of the certificate from IT support, which rarely happens. In other words, users are likely to just blindly click trust the certificate, and as such they can fall victim to credential thefts (e.g. by performing user authentication with an Evil Twin of the real enterprise network).
Demo
We tested on both iOS and macOS to show the UI discrepancy between them. The following images show whilst macOS indicates the same certificate as valid, iOS marks it as Not Trusted.
Vendor's response
After further review, we have one question. Regarding the issue you mentioned "iOS marking valid certs as 'Not Trusted'", did you notice any cases where an invalid certificate is marked as trusted? If so, please provide additional information about this so we can investigate as a security issue.
...
Thank you for confirming you were unable to display in the UI an invalid certificate showing as "Trusted". This example does not pose a risk to our customers. Due to this, we are not tracking any issues from this report which have security impact. We are, however, investigating possible future UI changes to help users. Since there are no security implications, we will no longer provide updates on this issue.
In your future research, if you determine there is a case where a certificate's trust status is shown in a way with possible security implications, please do not hesitate to send the example to us for investigation.
Takeaway
There is no way to differentiate a forged certificate from the real one with the information given by the simplified UI on iOS (as one should know that the hostname, e.g., wireless.ust.hk and the issuer name, e.g., Thawte RSA CA 2018 can be easily given to an invalid certificate). Hence, you should ask the institution authority for the information of the legitimate certificate, i.e., the SHA-256 fingerprint of the certificate, then try to match it with the one hidden by More Details on iOS.
Windows 10
Issue I
Hiding the crucial details of the server certificate (i.e. fingerprint/thumbprint) by default, which are required to validate the identity of the authentication server.
Implication
This could lead the users simply connect to any rogue Wi-Fi network without clicking "Show certificate details".
Issue II
After clicking "Show certificate details", the shown "Server thumbprint" is a SHA-1 digest.
Implication
Given that an identical-prefix collision of SHA-1 can be found at the scale of hundred-thousand USD [shattered.io], checking only the SHA-1 fingerprint is not strong enough as a means for validating the identity of the connecting server.
Issue III
The short timeout hinders manual checking of the certificate thumbprint.
Implication
The timeout of 20 seconds, even after After "Show certificate details" is clicked. It may not be enough to perform a complete manual validation of the certificate thumbprint. This timeout behavior would encourage the users just click "Connect" instead.
Vendor's response
Thank you for contacting the Microsoft Security Response Center (MSRC). What you're reporting appears to be a product suggestion, but does not meet the definition of a security vulnerability. WPA2 and Wi-Fi connectivity cannot be exploited remotely by an attacker in the scenario you presented, but the features you mention would assist a user in validating the access point they connect to.
Takeaway
One can only inspect the SHA-1 fingerprint of the certificate to obtain partial guarantees of the authenticity of the server.
Disclosure to the affected TEIs
Summary
After we inspected the publicly available WPA2-Enterprise configuration instructions, we had contacted 1732 tertiary education institutes (TEIs) which prescribed insecure instructions applicable to at least one OS. Subsequently, a very few number of schools actively acknowledged our reports and updated the instructions according to our suggestions. The major reaction from the school admins perhaps unfortunately is ignoring our report or even cast doubts on our findings. Thus, we hope taking this chance to resolve their concerns here.
Quotes of IT admins / Security analysts
-
Closing this ticket, I feel that this is spam or some sort of phishing attempt. This is unsolicited information possibly from our public setup information. Our wireless infrastructure is protected by our NAC and various security controls.
-
Your request to IT Services has been closed. Resolution Details:spam
Discussion among IT departments found online
- Interesting one here. I deleted all the points of the lack of security in each's configuration and link to file. Really nothing new, but is this person really associated with University of Iowa and Syracuse? Is he trying to establish trust with the University? [source]
Response
The reporting emails that we had sent are tailor-made for each school. They describe specific issues mapping to each specific insecure configuration. They are neither spam nor phishing emails. The information and the suggestion document in the email are all legitimate. It would be great if they are useful to build a more secure campus environment by setting up secure WPA2-Enterprise configurations.
Contact
Hugo Hue, The Chinese University of Hong Kong, hugohue [at] link.cuhk.edu.hk