Blog

1. It does not affect Access Points, unless the Access Point is in client mode (Wireless Bridge).
2. It does not affect Windows or iOS, as they don’t support the part of the handshake that allows for the rekeying vulnerability.
3. BSD/Linux/Android (it runs the Linux kernel) are affected since a majority of the AP’s on the market use these Kernels.
4. It does not affect normal day to day https surfing, as long as the remote end has implemented SSL correctly (OSCP stapling).

So, I guess the good news here is that vendor roll out should be quick. Google has known about the vulnerability for about a month and a half, so it seems interesting that they haven’t pushed an update. My very first guess is that Google views this as a low priority vulnerability, this is of course just speculation.

I do have a couple of questions. Would this include WPA2-Enterprise? If not, the quick fix would be to deploy WPA2-Enterprise and give everyone the same username/password to login to the Wi-Fi, and then begin to move towards Radius. I also wonder how easy it would be to deploy IDS for new wireless networks, since the BSSID would be the same for the rogue AP. It probably would be hard to find.

I think the most important thing to remember about this attack is that the attacker must set up there own AP so the user can access the internet, unless this AP fires up inside your own network. Internal network resources will be unavailable to the user. 

Here is the order of events for the attack:

1. Setup clone AP on the same channel.
2. Send a rekey once you see the client connect to the good AP.
3. Enable Firewall Forwarding (NAT) (This would use the attackers internet, or, if the attacker was able to plug into our network it could use our gateway)
4. Enable SSL Strip to remove SSL from non supporting sites (keep in mind a majority of sites support OSCP stapling, so it would cause the clients lots of errors).
5. Enable Wireshark to sniff and read passwords.
6. User browses to site and is able log in.

A LOT has to go right here in order for this to work.

In general with a correctly configured site the order of events would be:

1. Setup clone AP on the same channel.
2. Send a rekey once you see the client connect to the good AP.
3. Enable Firewall Forwarding (NAT) (This would use the attackers internet, or, if the attacker was able to plug into our network it could use our gateway).
4. Enable SSL Strip to remove SSL from non supporting sites (Keep in mind a majority of sites support OSCP stapling, so it would cause the clients lots of errors).
5. User browses to site and the site will not load (user cannot even force the load), because the SSL site is configured correctly.

Services such as SSH are not affected by this because of the same reason as  an SSL, however SSH doesn’t depend on stapling, so it’s secure everywhere.

Lastly, while the vulnerability is bad, I do not believe it’s a sky is falling moment. With any encryption it’s a cat/mouse game. I think to say that WPA2 encryption is broken is a little far reaching because it’s a bug. The protocol should support key changes, but not the way it’s implemented in those kernels.