How secure is your EAP-PEAP v0
deployment?
PEAP stands for Protected Extensible
Authentication Protocol. PEAP is one of many types of EAPs available. EAP types
are like different flavors of ice cream. You can have simple vanilla or a
complex rocky road type of EAP. The different types of EAPs provide different
levels of administration and security. Some EAPs are consider weak, like LEAP
which can be breached with Asleap.
Commonly referenced EAPs used on WiFi
networks:
EAP-PEAP
EAP-LEAP
EAP-TLS
EAP-TTLS
EAP-FAST
EAP-PEAP is the most common and
widely deployed EAP used on wireless networks world wide. It is also very
secure, if configured and deployed properly. EAP-PEAP has a few different
versions. These versions identify what type of internal authentication is
conducted AFTER the outer TLS tunnel is created. This internal tunnel is where
credentials are passed. The most commonly used EAP-PEAP type used is EAP-PEAP
v0 based on MsChapV2.
EAP-PEAP v0 - MsChapV2
EAP-PEAP v1 - GTC
EAP-PEAP v2 - TLS
The intent of this blog post is to
keep the understanding and configuration of EAP-PEAP client side simple and
easy to understand.
The reason why PEAPv0 is widely
adopted is because Microsoft was part of PEAP development. Microsoft uses their
own protocol MsChapV2 as the internal tunnel to pass credentials. The windows
wireless supplicant natively supports PEAP v0. This resulted is wide adoption.
How you configured EAP-PEAPv0 is very
important. If not properly configured you can expose yourself and your network
to a man in the middle attack. To understand this process we need to understand
some of the mechanics of PEAP.
SERVER SIDE CERTIFICATE
PEAPv0 uses a server side
certificate. The certificate is installed on the radius server. This server
side certificate is used to create the outer TLS tunnel between the client and
the radius server. This prevents prying eyes from sniffing frames to expose the
user ID and password.
When a WiFi client connects to a WLAN
configured with EAP, the radius server sends the server side certificate to the
client. The client then uses this server side certificate to hash his/her
network credentials and passes it back to the radius server. The radius server
has the private key for that server side certificate. You may recall when you
created the CSR (certificate signing request) a private key was created in that
process. The private key resides on the radius server. Think of the private key
as a secret decoder ring. After the radius server decodes the client hash, it
can send the user ID and password to AD for user authentication.
MAN IN THE MIDDLE
While there are other documented PEAP
attacks. The most realistic and real world attack is the man in the middle
attack. We just discussed how the server side certificate is used to securely
pass user IDs and passwords.
What if we compromised the users
connection by presenting our own server side certificate via a rogue access
point broadcasting your WLAN, whereby collecting the user ID and password?
Imagine for a moment…………
You work for Acme Company. Your Acme
computer is configured to a WLAN called ACME-WIRELESS-NETWORK. You connect each
and every day without fail. One day you connect and get a validate certificate
popup. You, like almost everyone else, click accept without reading the content
of the popup. What you just did was accepted a server side certificate from a
rogue radius server and you passed your user ID and password.
This article is not intended to share
all the specifics on how to set up a man in the middle attack. You’re one
google search and a FREE RADIUS setup away!
VALIDATING SERVER SIDE CERTIFICATE
It is important we validate the
server side certificate on the wireless client that connects to our enterprise
wireless network. In other words we are trusting only specific certificates
from our own radius server(s). All other request get ignored and don't get
displayed to the user as a popup to override. This is critical to prevent a man
in the middle attack.
From an enterprise perspective this
isn't a simple check box on the infrastructure and the problem goes away.
Rather its standardizing on client side configuration and ensuring this
configuration is deployed on every wireless device connecting to your network.
The other problem, wireless supplicants aren't created equally. iOS and OSX you
need to push a profile whereby validating the certificate like windows. Some
supplicants may or may not allow you to validate certificates.
HUMAN FACTOR
You need to remove the human decision making process from this security
equation. You don't want to give a user the ability to choose what certificate
they should and should not validate when connecting to your enterprise network.
WINDOWS 7 / 8.1 - APPLE iOS and OSX
Windows 7, 8.1 and Apple devices
require the user to validate a wireless network when presented with a
certificate for wireless authentication, if a wireless profile is not setup for
that WLAN. Once accepted the certificate trust is remembered in the WLAN
profile. If you delete the WLAN profile these certificate trusts also get
deleted. By manually configuration or profile pushing you can negate the certificate
trust popup.
CONFIGURE VALIDATING SERVER SIDE CERTIFICATE DETAIL
Method 1: Limit
the trusted root CAs that are available to the user
Overall, the best way to reduce these potential risks is to limit the trusted
root CAs that are permitted for PEAPv0. To do this, click to clear the check
boxes for all non-applicable CAs in the Trusted Root Certification Authorities
list. This prevents the user from trusting new root CAs, because the user is
presented with an explicit list of permitted authentication servers.
Method 2: Prevent
the user from being prompted for certificate validation
PEAPv0 configuration includes an option that prevents the user from being
prompted for certificate validation. This is the Do not prompt user to
authorize new servers or trusted root certification authorities option. By
default, this option is disabled. If you enable this option, the user is not
presented with the UI that may be difficult for the user to understand.
Therefore, the user cannot select an unapproved root certification authority.
To enable this option, follow these
steps:
1 In the Protected EAP Properties
dialog box, click to select the Validate server certificate check box.
2 Click to select the Do not prompt
user to authorize new server or trusted certification authorities check box.
3 Install the root certificate of the
server in the NTAuth store, or click to select the root certificate in Trusted
Root Certificate Authorities list.
If you cannot use this method, you
can educate users to make sure that they reject the request to authorize any
new servers or certification authority.
Method 3: Limit
authentication servers
PEAPv0 configuration lets you limit the servers that can be trusted for an
authentication. The Connect to these servers option uses a list of server
names, each separated by a semicolon, to explicitly define the servers against
which the client may authenticate. When you enable this option and use the
strict list of accepted servers, this man-in-the-middle attack is much more
difficult to execute. Or, this attack may be impossible to execute, depending
on the specific PKI structure that your organization uses.
To enable the Connect to these
servers option, follow these steps:
1 In the Protected EAP Properties dialog box, click to select the Validate
server certificate check box.
2 Click to select the Connect to
these servers check box.
3 In the Connect to these servers
box, type a list of all back-end authentication servers. Separate each server
name with a semicolon. For example, type the following for the domain acme.com
and for authentication servers auth1 and auth2:
auth1.contoso.com;auth2.contoso.com
Overview
1 - Validate Server Certificate
- Select the CA that signed your server side certificate
2 - Enter the CN name of the server
side certificate(s). If more than 1 CN is used (radius servers) separate CN
with a “;” and make sure there are spaces between CNs.
3 - Check box the Do Not Prompt user
….. This is an extra fail safe that a user won’t get the popup.
4 - Enter enable identify privacy —
Enter a value in this field. This field is presented in clear text during the
EAP-PEAP process. Make sure its not a user ID. :)
