12

One of the dangers of using WPA2-PSK is the possibility that an attacker may setup another wireless network with the same SSID and even use the same access point MAC address via MAC spoofing. The attacker then may use a deauth attack to cause an internal computer in the network to have to reauthenticate, allowing the attacker to recover enough of what he needs to eventually bruteforce his way into your wireless network.

However, I'm not sure if this attack method is mitigated when using something like WPA2-Enterprise. I'm a system administrator and it would be relatively trivial (< 1hr work) for me to setup WPA2-Enterprise with an internal RADIUS authentication server and migrate away from WPA2-PSK. However, does this mitigate the evil twin problem?

Naftuli Kay
  • 6,715
  • 9
  • 47
  • 75
  • 3
    I don't name this sort of attack **honeypot** attack. Honeypot are used to stuck the bad guys or softwares. What you want to protect you from here is named a **rogue AP**. – dan Dec 11 '13 at 22:33

2 Answers2

12

I would call this an evil twin attack. And it's not uncommon to see corporate laptops vulnerable to this.

WPA2-Enterprise supports a number of EAPs - Extensible Authentication Protocols. (Wikipedia article) The security depends on which EAP you use, and how you configure it. Some EAPs more vulnerable to an "evil twin" attack than PSK, as an attacker doesn't need to brute force the key.

Fortunately, a number of EAPs are secure against an evil twin. One approach is to use TLS internally; PEAP is a popular option that does this. To be secure against an evil twin, you must enable certificate verification and distribute the certificate to all your clients. There is no need to get such a cert issued by a root CA.

paj28
  • 32,736
  • 8
  • 92
  • 130
  • Gotcha. I'm used to the idea of running my own CA anyway, so the idea isn't too far-fetched. Great answer. Can't the attacker still attempt to stage a MITM to then be able to get access to the network? – Naftuli Kay Dec 11 '13 at 22:47
  • @NaftuliTzviKay if an attacker tries to MITM, all they will see is encrypted junk. This is because TLS uses public key crypto and prevents MITM. – paj28 Dec 11 '13 at 22:53
  • This bit of information is going to start countless questions on this site. (brace yourselves) I thought MITMs were always possible? – Naftuli Kay Dec 11 '13 at 23:22
  • @NaftuliTzviKay - TLS is designed to prevent MITM, and is thought to do this well. Practical MITM attacks against TLS have been performed, but are mostly based on getting a fraudulent certificate. As you're acting as your own CA you can control that risk yourself. – paj28 Dec 12 '13 at 01:06
  • → paj28: could you develop on "no way to get such a cert issued by a root CA"? – dan Dec 12 '13 at 11:55
  • @danielAzuelos the implementations I've seen have used self-issued certs, and I have no idea how you would apply to a root CA for such a cert (what would the CN be?) Having said that, I don't have a reference for there being "no way" to do this. If you do find a way, please let me know! – paj28 Dec 12 '13 at 17:42
  • → paj28: the key point is that this certificate won't be a "server" certificate. Moreover you won't need to make it automatically recognized by the access server. I would have said "no need to…" rather than "no way to…". – dan Dec 12 '13 at 23:07
2

You're right to say that WPA2-Enterprise doesn't in and of itself solve the honeypot problem, however you can use TLS with it, ensure that the server has a valid cert and that the client will check it before authenticating, which should address the problem.

Rory McCune
  • 60,923
  • 14
  • 136
  • 217