Mk Iii Not Pulling Very Many Guests In

[01:B1:70:FF]

Hello, everyone!

I've been working with my Pineapple, and have a few questions. But first, here's what I have for a setup:

Hardware: Fon 2100

Firmware: Mark III, version 2.1.2

Host: Laptop running BackTrack 5 R1

Network:

eth0: 172.16.42.42

Wlan0: Alfa AWUS 036H in monitor mode

wlan1: Onboard atheros chipset connecting to internet, we'll say 192.168.1.x

Pineapple address: 172.16.42.1

I've flashed a fresh firmware on it, and the only changes I've made since then are:

Changed the root password, of course

Changed the SSID in the wireless config

The pineapple pings ok. In fact, the pineapple "pineapples" ok, meaning I can get 'guests' on it. It just doesn't fill up with 'guests' like the screenshots Darren posts.

I was in a target-rich environment last week, and could only get about a dozen guests, even with the help of some deauth fun via airdrop-ng on my Alfa. Looking at what airodump-ng said was around me indicated that I had somewhere around 10 times that amount of machines that could have potentially been "pineappled".

I've also done a fair amount of work in a 'test' environment, where I try my hand at getting my tablet and phone to "climb aboard" the pineapple. I see that they are on the local wifi, so I run airdrop for a little bit. I can see on the devices that both of them are getting deauth'ed ok. When I let them try and reconnect, I have pretty good luck getting my tablet to associate with the pineapple, but my phone (an HTC Rezound) will not associate with the pineapple at all. Looking at the karma log file, here's what I see:

KARMA CTRL_IFACE Requested ESSID is TCwifi

KARMA: Probe Request from <phone MAC> for SSID <ssid>

KARMA ssid malloc'd so free it

With the tablet, I will see that set of logs several times, and then eventually see the mgmt::auth line along with the other lines that log the association with the pineapple. But I never see an auth or association for my phone. And not just my phone, the vast majority of the "buddies" I could have made were showing the same thing. I saw a lot of different MAC addresses show those three log lines of the probe request, but for whatever reason, they never went ahead and tried to associate with the pineapple. I should note that both the phone and the tablet indicated a stronger signal from the pineapple than from the wifi they requested association to.

I'm just running karma on the pineapple, and leaving the other work to BackTrack, be it deauth, packet capture, etc.

I plan to be in another target-rich environment in a few days, and hope to have a much better run at "helping" guests with their connection to the internet.

Any suggestions on what I could be doing better, or other log files I need to look in (filename and location), or even how to understand better what these log messages mean in karma.log?

Thank you very much for any help with this.

[telot]

It sounds like you're doing everything right Mr. MAC address (I don't want to type all that out this early in the morning lol). I'd say you're getting everyone you can get - could you try and use airodump-ng on your alfa to monitor the probe requests of the potential victims you're not getting and see if any of the ssid's they probe for seem like they would be open (no authentication) ssid's (such as att_wifi, petes_free_coffee_shop_wifi, etc)? You say you got a dozen victims karma'd - thats pretty dang good! Whats the ratio of victims karma'd/not karma'd? Keep in mind Darren's list of victims were from walking throughout an entire airport terminal - he didn't have all those victims connected simultaneously at the same time. Theres a physical issue of wireless range and how many people can possibly be sitting on a laptop in that range.

The other potential factor here is wireless n vs b - some tests are required to confirm this, but I have a hunch that some OS's put a higher priority on connections to wireless A/N hotspots (open or otherwise) over anything B/G - again, I have zero data to confirm this, its just a hunch.

As for the HTC Rezound, Android treats probes requests/responses quite differently than other mobile OS (namely iOS) - its really rather picky when it comes to open auth. For instance, it will try its hardest to get back to its last known bssid before sending out probe requests looking for another one it has saved, and always puts a priority on secured wifi over open (because android is awesome I suspect).

Hope this helps you out - and if anyone has hard data on the N vs B/G, I'd love to see it!

telot

[01:B1:70:FF]

Thanks for the reply, Telot!

In looking further at the files I saved and parsed from that day, I saw, from one of my pineapple sessions, 12 unique MACs that were listed in mgmt::auth lines in the karma.log file, but I had only 5 clients listed in my dhcp.leases file. In contrast, in parsing out MACs for probe requests in the karma.log file, I came up with 44 unique MACs.

Airodump-ng had well over a hundred client MACs listed in some of the recorded scans, though I think I saw some data there that didn't look quite so reliable. Obvious MACs that wouldn't count would include 00:00:00:00:00:00, and it looked like some were very similar in their info. Counting the airodump log I saved that had the nearest time stamp to the dhcp.leases and karma.log files, I counted 85 total clients, and 38 clients who looked like they were probing for open networks. Of course, the larger portion of those were looking for the local wifi essid. Fortunately, that was an open network.

I used an app on my tablet called Fing, and did periodic ping sweeps of the subnet we were on via the local wifi. By the end of the day, I had collected 123 unique IP/MACs, though some could have been in completely different sections of the site than my pineapple could see.

As to the phone, that does help explain some of what I was seeing, because when I watched my phone try and re-associate, it seemed to insist on the same BSSID it had previously associated with. On the other hand, my tablet is an HP Touchpad running CyanogenMod 9 Alpha (ICS), and I have a pretty good track record of getting it pineappled with a little coaxing from airdrop-ng.

I wish I was better at reading the 'story' from karma.log. For instance, is it saying something bad about what happened in a probe request when it says KARMA ssid malloc'd so free it? I'd like to figure out better what is happening when I see things like a bunch of probe requests before I ever see an auth and association.

Also, I'd appreciate knowing better what's happening that makes the pineapple only work with clients trying to associate with open networks. I've read this other places in the forums, and was a bit confused. I thought Jasager would say yes to most any probe request and invite them in. Is it that the client sees the connection going open when it expected some encryption or security, and decides not to trust it?

By the way, in case you're interested, the name basically is "1 bit off" spelled as the last part of a MAC address, so you can call me 1 bit, or whatever. Mr. MAC works, too!

Thanks again for the response and additional information.