Fixing the PEAP MitM through correct config

Back in 2008 Brad Antoniewicz and Josh Wright presented a talk at Shmoocon titled, PEAP: Pwned Extensible Authentication Protocol.  I blogged about it at the time here and here is Brad’s blog post from then.

At the time, I realized that our wireless client configuration instructions allowed man in the middle.   I’ve been trying to get this fixed for four years, and I finally got success this week!

The original config is below:   You’ll note that validate “user certificate is not checked”

By doing this, the client will connect to anything with a certificate!   It would be really easy to do what Josh and Brad talk about and set up a fake Access Point and Radius server.   The client would give their credentials to the attacker who would then log into the network.   The client could either than be allowed to stay connected and man in the middled, or drop their connection.  The client would be non-the-wiser.   They’d just try again and this time get in on the real access point.

I figured what needed to happen was get the public key for the certificate used in PEAP.   I started on the Wireless Control Server which is the wrong place to be.

Next, I looked at the client help file and found that for EAP-GTC, it is mandatory to list the server name in the “connect only to these servers” field.   But you need to know the CN or the SAN to do that.

So I found out the server name is our ACS server not the Wireless Control Server.   I got what we thought was the root certificate, and I tried to connect.   It didn’t work, but this time I was prompted to  accept a new certificate.   Apparently if I’d selected any of the root certificates, I would have been prompted to add the real one, but because none were selected the connection failed.

So we set up a profile set to validate certificates, and connect only to our ACS server.   We deployed the public key of the root server of the internal CA that issued our certificate, and configured the client to only trust that CA for this wireless connection.   Lastly we checked “do not prompt user to authorize new server”

If you don’t check “do not prompt user to authorize new servers”, if the user were man in the middled they would be prompted to accept the certificate.   Users always accept security warnings and continue so they can do their work.   So it is best to take the choice out of their hands.   The security goes hand in hand.   By only trusting certificates issued from my internal CA, it is unlikely they would have a certificate that could be accepted by the end user anyway.

That should have been fixed much sooner.   Once we answered the right questions of the right people, it turned out to be an easy fix.   It is quite common for companies to turn off certificate validation in their wireless setup rather than fixing the cause of problems.   This opens companies to man in the middle attacks.   Just because it is only open to people who can drive near your facility doesn’t mean it isn’t a big big problem.