EAP-TLS: Where Mac security is worse than Windows

On a recent job I was looking at a WPA2/Enterprise EAP-TLS setup deployed in a bunch of MacBooks and what I found was somewhat disappointing.

The client was using an enterprise management tool to push configuration profiles, their own root level CA and a host specific client side certificate.

On the surface everything appeared to be working just fine as far as EAP-TLS is concerned, BUT I discovered that Mac OS X completely fails to verify or enforce specific CA signatures against the server side certificate presented by the authentication server. This prompted me to look a bit deeper into this and compare it with Windows 7, which I knew had a decent set of security measures for wireless profiles.

For reference this diagram shows how a TLS session is established, shown in stream ‘2’ where the client is the Supplicant mobile station and the server is the authentication server (RADIUS or otherwise):

Source: https://upload.wikimedia.org/wikipedia/commons/6/63/8021X-Overview.png

I am not one to advocate the wonderful features of Windows seeing as there aren’t many, but credit where it is due! Here’s the specifics…

Macs

While a Mac will complain/throw up warnings if the server side certificate is not signed by a trusted CA (*any* trusted CA that is), there are still issues:

1. There was no visible way to configure a wireless network profile that would enforce a specific certificate authority to verify the server side certificate.

2. The user to import the CA into its own certificate store or the root CA store (with administrator’s credentials) from within the warning dialog. After this no more warnings are given because the server side certificate becomes trusted.

The Warning dialogue window shown upon connecting to hacker’s network:

The expanded dialogue window:

A root level CA store is a critical security asset. It is the top level of public key cryptography trust. I don’t advocate security through obscurity, but there is certainly a relationship between how critical a certain element is and how difficult it should be to make changes to it. I believe root level CAs (or the certificate store for that matter) should be made purposely difficult to modify.

3. A previously known and used wireless connection to be re-established with the same settings against an attacker’s AP (evil twin attack) with a different server side cert signed by a different CA. There will be a warning about the different CA and it must be imported before the connection works (requires admin creds) — or a mutually trusted CA must be used.

The fact here is that everything about the established connection changed from one connection to the next, which is typical in an evil twin attack except for a few superficial aspects (SSID, BSSID, etc.). Crucially the fundamental authentication elements of the profile have changed and the fact that something is detected as being untrusted in an EAP-TLS setup should prompt both the server (if it is legitimate) and the client to simply abort the association.

While at first glance this does not look particularly unreasonable, it becomes so when it happens after the host has connected before a (legitimate) wireless network using the same configuration profile on which all certificates were valid and no warnings were raised. During an evil-twin attack, the last thing a host should do is facilitate connections to WPA/Enterprise environments on which there are issues, especially if the setup is EAP-TLS which relies solely on the validity of certificate pairs!!

This image shows the rogue hacker authentication server’s certificate, imported into the user’s certificate store without requiring administrator’s credentials:

4. The client side certificate to be signed by a CA that the server cannot validate.

Admittedly it is the authentication server’s job to decide whether to trust a given client side certificate. Client and server side certificates signed by different CAs implies that they exist under different PKI trees or branches which also implies to a point that there is no single entity which controls both parts of the authentication method. However even maintaining a list of authorised self-signed client side certificate fingerprints on the server could be bypassed, if not by brute forcing. PKI’s strength derives from the ability to verify authenticity and in this case it is being thrown out the window.

It is apparent to me that the reason for this is Apple’s way of simplifying the operating system. I have discussed this matter with colleagues who suggested that Apple provides Enterprise management add-ons which could enable a level of configurability to overcome these limitations. However I have never seen them, so if you have, do give us a shout!

Windows

However, on Windows (7 at least) wireless configuration profiles can be made to enforce the following options:

1. Ensure that the server side cert is signed by a specific CA certificate.

This ensures that a client that has not been compromised will refuse to connect to *any* evil twin AP unless the server side certificate of the legitimate authentication server had been compromised (or perhaps its CA). This is the ideal situation.

The following image shows Windows’s granular CA verification enforcement and the option to prevent the station from allowing the user to authorise servers or certificates:

2. Ensure that the server side cert is signed by any root level trusted CA certificate.

This option is a bit more relaxed, all it requires is that the server side certificate is valid. It is in most aspects similar to how Mac OS X behaves when presented with an authentication server with a trusted certificate. Both allow the connection to be established but Windows’s dialog box is much more of a security warning than OS X’s. In addition, the user cannot import the certificate from this dialog.

This image shows the Windows dialog revealing that an issue was found in the authentication server’s certificate. Sadly the connection is allowed to proceed. However this dialogue box is far more effective at illustrating this is a security issue:

3. Ignore the server side certificate’s signature.

OK, this is pretty bad, not even Mac OS X allows this. Any certificate on any authentication server will do. Don’t do this. Please.

Conclusion

The fact that the client can be configured to ensure that the authentication server’s certificate is signed by a specific CA highlights how a subtle difference in the way both operating systems allow EAP-TLS wireless profiles to be configured has a significant impact in security. It makes Windows far more resilient to evil twin attacks or attacks that exploit the trust relationship between mobile stations and the authentication server.

In addition, it was found that neither Windows nor Macs store contextual information about the profiles they are setup to connect to. This is not a significant issue on Windows if the profile is strongly configured, but it would still be an important intrusion detection mechanism.

Solution

Is there one? Windows has it mostly sorted, Apple could improve Mac OS X’s wireless profile features to ensure that authentication server TLS certificates are signed by specific (pre-assigned) CAs. Also both operating systems would benefit from storing context information of previously established connections and using them as a way to detect changes that could reveal attacks. Oh and please don’t give your users local administrator’s privileges, or otherwise all the above can be turned upside down because the user (and attackers and malware) has control over the certificate store.

On the subject of Macs, only give people the access privileges that they need, that’s a basic security admin fact. That means ‘not admin’ people! Audit and review the Macs in your organisation, walk around and actually locate them, we’ve found instances where their presence wasn’t even known about. There’s a nice post about that issue here.