Using Pineapple to Spoof WPA2 Encrpted APs

[Skinny]

I had a unique experience today targeting a mobile device. The Pineapple was setup with all the options running on PineAP. The mobile device beaconed out an SSID that happened to be the SSID of an AP that has WPA2 encryption.

The Pineapple then very dutifully captured the SSID and replayed it. To my utter surprise the mobile device connected to the Pineapple. This unique association was verified with 2 other pieces of equipment to make sure we were seeing things correctly.

In general, this doesn't happen, at least, this is the first time I've seen it happen. The WPA2 4-way handshake process is there to ensure that both the client and the AP mutually recognize each other. The process is just as much to show the client that the AP is the correct AP as much as it is for the AP to find out if the client is a legitimate client.

I've heard @Darren Kitchen and @Sebkinne say on several videos that WiFi can be implemented differently from vendor to vendor; it was just interesting to see that in action today. Just know that some devices will respond positively to the Pineapple even if the SSID you are spoofing normally uses WPA2. It's always worth a shot. You might get lucky.

Edited September 17, 2016 by Skinny

[Foxtrot]

A packet capture of this behaviour would be incredibly interesting. What device was this? 

[artuk]

Thanks for this info, very interesting, will definately do some testing

[Skinny]

6 hours ago, Foxtrot said:

A packet capture of this behaviour would be incredibly interesting. What device was this? 

I plan on taking a capture as I have a small window of opportunity with the device, however sadly I can't reveal what the device is. Which also means I can't give out the pcap, but I will let everyone know in general terms what is happening in the packet capture. Sorry, but its the best I can do in this situation.

[Skinny]

Just a follow up on this. It turns out that the device in question had a profile pushed to it that made it aware of the WPA2 encrypted AP, but that push never gave the device any credentials to authenticate with the AP. So as far as the device knew, it thought that SSID was genuinely an open access point to begin with. Once I gave the device the opportunity to connect with the same SSID, it grabbed it right away. 

After looking at the packet capture, this explanation totally lines up with what I was seeing. The device never attempted the four-way handshake. It went straight into open authentication.

The Moral of the Story: If your company controls mobile devices from a cloud based system and they push preferred network lists to the mobile devices with the name of secure APs, they also need to give those phones the credentials for those APs for mutual, secure authentication. Otherwise the device may assume the APs on the list are open and will fall for a tricky pineapple.