Clients React to the WiFi Pineapple

The WiFi Pineapple is a very evil rogue access point (AP) that can quite easily trick an unsuspecting WiFi enabled device or user into connecting to itself. It does this mainly through a suite of programs called PineAP. Thanks to the makers of the WiFi Pineapple, Hak5, their website is full of Get Started tutorials and tutorials that review the basic functionality of the device. You can find most of those tutorials over at www.wifipineapple.com.

This article’s purpose is examine how different clients connect automatically to the WiFi Pineapple.

Special Snowflakes

Not all WiFi devices are created equally. 802.11 as a standard has been around for quite a while, but implementations of that standard can be different based on what the manufacturer is trying to accomplish. For instance, some WiFi devices send out probe requests to demand SSIDs by name for the purpose of connecting while others merely send out a broadcast and require surrounding APs to respond in a roll call fashion. Recently, I witnessed and Apple device that sent both at the same time.

For the most part no one cares that these differences exist. If you can turn on the Pineapple and acquire your target, then there’s no problem. The consternation occurs when you cannot convince a device to connect to the Pineapple automatically. Is it the device, is it you, or is it the circumstance?

The Problem

I use the Pineapple on a daily basis with the express aim of associating client devices without the knowledge of the owner. What’s unfortunate is that the Pineapple is not successful in all cases and when it is successful, I’m many times left in the dark about the circumstances of the success.

The Experiment

I wanted to understand why, how, and under what circumstances a device connects to the WiFi Pineapple. At my disposal are 5 mobile devices all created by different manufacturers. The following characteristics were determined to be of interest for each device:

Initial Probe Request with SSIDs & Initial Probe Request with Broadcast – When a device is searching for a wireless network, it sends out probe requests. Sometimes this probe request will contain the name of an SSID in its Preferred Network List (PNL). Other times the probe request is a broadcast asking for APs to respond with their SSID. The initial probe request refers to the first time the mobile device attempts to reach out for an access point.

Probes When Idle/Sleeping – When a mobile device is not in active use, it usually enters into an idle mode where the screen goes dark to save battery. In this state some phones send out probe requests where others do not.

Idle/Sleeping Probe Interval – The time between probes while the phone is in an idle state.

Responsive when Idle/Sleeping – Seeks to determine whether a device will respond to any attempt on the part of the Pineapple to coerce an automatic connection while the device is in an idle state.

Secondly, the pineapple has 3 options that reside in the PineAP module to ensnare an unsuspecting client. These were all be tested against each device.

Allow Associations – When activated this option will capture an incoming probe request from a client, strip out the SSID information from the request, and then pose as that SSID in the hopes of causing the client to connect.

Broadcast SSID Pool – An option that causes the Pineapple to broadcast all of the SSIDs held within its pool of collected SSIDs. This option is helpful when a client does not transmit the names of SSIDs for which it is searching. Once a client sees a name it recognizes, it may then send a probe request asking specifically for that particular SSID.

Beacon Response – Some clients need to be heavily assured that the AP it is connecting to is, in fact, the SSID it knows. Beacon response is an absolute battering ram of assurance. Once a client device sends a probe request with an SSID, the Pineapple will heavily bombard that specific device with Beacon Frames insisting it is the AP with the correct SSID for which the client is searching.

Setup

The following pieces of equipment and software were utilized for the experiment.

• Laptop with Ubuntu
• Wifi Pineapple Tetra
• Airmon-ng
• Wireshark
• An assortment of mobile devices

My wife took the mobile devices and connected each to 5 to 10 open access points at chain restaurants and big box stores around town. The Pineapple Tetra was populated with an SSID list of 179 names which included the SSIDs to which the mobile devices registered.

It is also worth noting that at no time was the Tetra connected to the Internet. Any client that connected to the Pineapple had no opportunity to reach out beyond it.

Procedures

Each device was powered up individually and put in its idle state in a low radio frequency (RF) environment. No other WiFi transmitters were present. The pineapple was not initially active in the environment.

A laptop was setup using airmon-ng and Wireshark to ascertain many of the device characteristics listed above. Responsiveness when Idle/Sleeping was not determined due to the omission of the Pineapple during this initial portion.

After the relevant data was collected via Wireshark, a WiFi Pineapple Tetra was activated with no options preconfigured. With Wireshark running, and individual device was powered and put in idle mode. Allow Associations was first tried for several minutes or several iterations of probe requests. If this effort neglected to associate the client, then Broadcast SSID Pool was activated. Finally, if these two measures did not force the client to associate, Beacon Response was activated. If a successful connection was obtained at any time, then the device was marked as being Responsiveness when Idle/Sleeping.

After connection attempts were made with the mobile device in idle mode, it was then put in a more active mode (i.e. opening the device to its main home screen) and kept alive. The Pineapple was placed back in its initial state and the tests were conducted again in order to ascertain if the phone could be persuaded to connect to the Pineapple at all.

Results

All results can be found on the spreadsheet at the following link:

https://docs.google.com/spreadsheets/d/1VO0VSm6n79BndK2KMqmokSVlPaOMQQAH0vkEyQRZIxY/edit?usp=sharing

This is a living document and will continue to grow as I come across more devices.

Below are the 5 mobile devices tested for this article but subsequent devices will go straight to the spreadsheet indicated above.

Alcatel Onetouch A463BG

[twocol_one]

OS/Software:

Initial Probe Request w/ SSIDs:

Initial Probe Request w/ Broadcast:

Probes When Idle/Sleeping:

Idle/Sleeping Probe Interval:

Responsive when Idle/Sleeping:

Allow Associations Required:

Beacon Response Required:

Broadcast Pool Required:

Successful Connection in Idle/Sleeping:

Successful Connection in Active Use:[/twocol_one]

[twocol_one_last]

Andriod 4.4.2

No

Yes

See Note

213s-223s

See Note

Yes

Yes

Yes

Yes

Yes[/twocol_one_last]

*Note: After being idle for about 10 minutes the device ceases to send out probes. Connection is possible in idle if done within first 10 minutes of idleness.

Kindle Fire 5th Gen

[twocol_one]

OS/Software:

Initial Probe Request w/ SSIDs:

Initial Probe Request w/ Broadcast:

Probes When Idle/Sleeping:

Idle/Sleeping Probe Interval:

Responsive when Idle/Sleeping:

Allow Associations Required:

Beacon Response Required:

Broadcast Pool Required:

Successful Connection in Idle/Sleeping:

Successful Connection in Active Use:[/twocol_one]

[twocol_one_last]

Fire OS 5.3.1.0

No

Yes

Yes

300s

No

Yes

Yes

Yes

No

Yes[/twocol_one_last]

LG Electronics LG306G

[twocol_one]

OS/Software:

Initial Probe Request w/ SSIDs:

Initial Probe Request w/ Broadcast:

Probes When Idle/Sleeping:

Idle/Sleeping Probe Interval:

Responsive when Idle/Sleeping:

Allow Associations Required:

Beacon Response Required:

Broadcast Pool Required:

Successful Connection in Idle/Sleeping:

Successful Connection in Active Use:[/twocol_one]

[twocol_one_last]

306G10c

No

Yes

No

N/A

No

Yes

Yes

Yes

No

No/Yes (See Note)[/twocol_one_last]

*Note: Did not want to connect of it’s own accord. Had to manually cycle wireless capability for device to connect automatically and this doesn’t always work. I guess that’s what you get for $9.00 on Amazon.

Motorola Moto E

[twocol_one]

OS/Software:

Initial Probe Request w/ SSIDs:

Initial Probe Request w/ Broadcast:

Probes When Idle/Sleeping:

Idle/Sleeping Probe Interval:

Responsive when Idle/Sleeping:

Allow Associations Required:

Beacon Response Required:

Broadcast Pool Required:

Successful Connection in Idle/Sleeping:

Successful Connection in Active Use:[/twocol_one]

[twocol_one_last]

Android 4.4.4

Yes

Yes

Yes

15s-45s

Yes

Yes

No

No

Yes

Yes[/twocol_one_last]

Samsung SCH-S738C

[twocol_one]

OS/Software:

Initial Probe Request w/ SSIDs:

Initial Probe Request w/ Broadcast:

Probes When Idle/Sleeping:

Idle/Sleeping Probe Interval:

Responsive when Idle/Sleeping:

Allow Associations Required:

Beacon Response Required:

Broadcast Pool Required:

Successful Connection in Idle/Sleeping:

Successful Connection in Active Use:[/twocol_one]

[twocol_one_last]

Android 4.0.4

No

Yes

Yes

281s-2914s

No

Yes

No

Yes

No

Yes[/twocol_one_last]

Remember to Check Back

This experiment will continue. If you want to have the latest information then remember to check the spreadsheet here. Just after the experiments above were conducted, an iPhone 6 came into my possession. It’s already listed on the spreadsheet.