In previous posts (The Wireless Attack Toolkit and What’s Trending For Hackers) I highlighted some common wireless security attacks. If you believe your corporate network has some additional security on top of it, well, this post is aimed directly at you.
Modern wireless security protocols have evolved a great deal since their inception with WEP (wired equivalent protections) and WPA (Wireless Protected Access). Now we have a bevy of wireless security protocols for corporate use and pretty good security for home users, all based off of WPA version 2. In this blog post, we’ll tackle the corporate side’s most typical implementation of WPA2 — PEAP (PEAP stands for Protected Extensible Authentication Protocol).
WPA2 PEAP is a wireless security protocol that implements 802.1X network access control mechanisms — you can’t connect to the network without an authorized username and password. Usernames and passwords are stored and checked by another portion of the corporate network, the Active Directory server (or any other LDAP server that you use if you’re not a Windows shop). This authentication actually uses the same pieces and parts as an HTTPS session to send your passwords and establish an encrypted tunnel. Pretty neat, right?
The problem that exists within this security protocol is in the implementation of the wireless standard and in the per-company implementation of the network.
Accepts all connections:
Some PEAP implementations apparently lack the ability to check that the encrypted tunnel is to a legitimate computer. So what happens when this is the case? Take some time to review how the “Evil Twin” attack is performed: I create a wireless network with the same name and characteristics as your intended network and I walk around outside your building advertising this network to any and everyone that will connect with me. Eventually someone tries to connect and establish an encrypted tunnel with me.
When they do this, I hand them an encryption certificate for their session that I control. If they are unable to verify the certificate is correct either because they have nothing to compare it to (no certificate installed) or they are unable to (the implementation doesn’t support certificate checking) then they will accept my certificate as valid and I’ll be able to witness their username and hashed password being transmitted! It happens that Active Directory tends to use a very weak cryptographic hash which can be cracked in under 24 hours for $100 using cloud-based services.
Now, not only is the client under my control and subject to a variety of attacks and sniffing, but I also have a way to sign into the corporate VPN for $100 because a certificate wasn’t deployed or checked.
Locking it down:
To get to the wireless settings, it’s somewhat circuitous.
If you don’t have a WPA2-Enterprise network, use this : Click on Network and Sharing Center > Set Up A New Connection > Manually Connect > Create a new network called ‘test’ and select WPA2-Enterprise from the security settings. Create the network and then click “Change connection settings” > click the security Tab > Settings
To properly secure an implementation, you could create your own CA, deploy the root cert to all machines, and then use the root CA to sign the radius server’s certificates. Then you can modify the settings for each client’s wireless setup to verify the cert. This is a bit overkill unless you need to have your own root CA (for stuff like monitoring SSL connections for malware, 802.1x, ect…) or you already have one.
If you want a more light-weight solution, you can get a certificate issued from a already-trusted Root CA for your radius server’s name (provided you have a valid domain and TLD that the certificate authority can issue a cert for). Then you can deploy this certificate on the radius server. Then configure your clients to validate the certificate against the certificate authority and put in the name of the radius server. The image below from the University of Texas Dallas does it right:
They could go one step further (if this is a machine that the users do not have local admin on) and check the “Do not prompt user to authorize new servers or trusted certification authorities” box for additional security that won’t let users click through security prompts.
In closing, PEAP is actually secure when you deploy it correctly — with certificates created and deployed by your Public Key Infrastructure. Create your own root certificate for your network, add it to the certificate store in your device, and then enable certificate checking with that certificate authority. Prevent users from adding servers to the certificate authority list as well if possible. Then enable this across all phones, laptops, and tablets.
For more info on setting up an Active Directory PKI see : http://technet.microsoft.com/en-us/library/cc772393(v=ws.10).aspx