Karma Jasager wpa

[Kafoowe]

So this is how one person explains how this works.

What your phone actually does is walk around shouting out "Is Cost Coffee WiFi here?!?!" or "Is Starbucks WiFi here?!?!" and so on for all the networks in your remembered list. Once it finds a network that it remembers it will connect to it and stop worrying about finding another until you're disconnected. Whilst this is fine in most normal circumstances, an access point will respond with "No I'm not Costa Coffee, I'm Dave's WiFi", the Jasager firmware running on the Pineapple is different. The WiFi Pineapple will actually respond with "Of course I'm Costa Coffee, please connect to me..." and at that point your phone happily believes what it's been told and connects to the "Costa Coffee" WiFi.

So here's my question. If the original coffee shop "Costa coffee wifi" was wpa encrypted and it's the only wifi access point on this person phone, who obviously has the wpa code on his phone. Can pineapple still connect to him even though the phone is looking for "Costa coffee wife" wpa vs "Costa coffee wifi" unlocked

[Skinny]

Thanks for bringing up the question. You shouldn't be able to cause a client to connect to the pineapple if that client is looking for SSIDs that have a WPA2 key associated with them.

After your question, I ran this test on two devices: a Nexus 7 tablet and a laptop running Ubuntu. I had both devices connect to an access point requiring a WPA2 password. I then powered down the access point. I booted the pineapple and only had the SSID of the previous access point available in the PineAP module. The pineapple only beckoned out the SSID of the previous access point. Neither device would automatically connect. I was pleasantly surprised this was the case but then thought about the nature of WPA2.

For WPA2 a four way handshake is needed. During this process both client and AP are trying to prove their legitimacy to each other. It follows then that the pineapple might not be successful in the case you stated.

However, my test was a sample set of 2. I believe any device that is implementing decent WiFi security measures would follow suit but it would be interesting to see if there are any exceptions out there. I'll probably be testing Windows based systems later.

This piece of knowledge is going to make me cut my SSID pool down. If APs / SSIDs requiring WPA2 aren't going to help me snag client devices, I might as well cut them from the pool.

[rpcodes]

I ran a similar set of tests about a month ago, maybe more by now, Win7, Android, and Ubuntu Linux clients. On the Tetra, but same software (Karma, etc). I think that to accept a client that is looking for a WPA access point, pineapple would need some way to respond with the correct handshake (using tools like airng and the like maybe?)

In other words its not enough to reply "Yes I am the WPA AP you want", like it does with Open networks and Karma

Iirc WPA is like:

Client sends some handshake info

AP replies with its handshake info

Everything matches then client connects; otherwise, no dice.

I'm thinking, is it possible to set up pineapple something like this:

1. listen for and collect the clients handshake / request to connect

2. send to a server to crack / brute force / etc the password, again i think air-ng or something may have this capability?

3. once cracked, send handshake reply to pineapple

4. broadcast the handshake reply, so now client thinks pineapple is its desired WPA2 AP

I have not investigated the sort of computational power it would take for a "simple" WPA2 password crack, this is just an idealized flow. Any WPA2 experts - Am I on the right track at least?

I second your notion of trimming your pool size. I wonder, does pineapple interface allow us to filter out WPA protected ARPs somehow? I will have to look again for this, curious...

[Mr-Protocol]

A simpler flow would be:

• Sniff the handshake
• Send to cloud cracking
• Use the key and setup to be in access point mode and broadcast the network
• Deauth all clients on the "real" WPA AP to force a connection on yours.

[rpcodes]

Mr-Protocol thanks for the input. I think your steps are the same as mine just written in simpler language. And you also add the deauth step, yes, I agree.

I was looking for a no hands solution, so your step 3, can that be automated somehow do you know? Similar to how karma broadcasts beacons, I'd ultimately like to broadcast WPA APs the same way.

I also found on forums this which is basically step 1

https://forums.hak5.org/index.php?/topic/38180-howto-capture-wpa-handshake-wifi-pineapple-nano/

So for the WPA experts - what do we use to actually generate the AP side handshake? i.e. what are our cracking tools

[Mr-Protocol]

You wouldn't just generate a handshake since every handshake is different. You would just set it up to be an access point requiring the previously cracked password.

I'm sure it could be automated with some custom scripting. Anything is possible.

[b0N3z]

So would a xxx-guest wifi that has a webui login like say comcast, does that produce a 4 way handshake like if id login to my my regular wifi and put a password in on the device itself? Im going to test this later today unless for some reason somebody has already tried this.

EDIT:  I have actually got a client to connect with an SSID that was password protected.  It was my roomates Iphone6 on the old ssid i had configured to my wifi router.  I had changed the name and password and he still had the old network saved in his phone.  He came home as I had PineAP going for testing on my laptop and needless to say i couldnt get the laptop at that time but he connected right away.  My macbook will warn me if I go from an ssid that has a psk to an ssid w/out a psk (if the ssid is exactly the same) 

Edited May 16, 2016 by b0N3z

[Forkish]

Is there is a way to use Occupineapple and broadcast the the ssid as protected and then capture the attempted handshake with tcpdump or ngrep?

[Mr-Protocol]

8 hours ago, Spoonish said:

Is there is a way to use Occupineapple and broadcast the the ssid as protected and then capture the attempted handshake with tcpdump or ngrep?

No because Occupineapple only broadcasts beacons. Also all handshakes are unique.

[Forkish]

5 hours ago, Mr-Protocol said:

No because Occupineapple only broadcasts beacons. Also all handshakes are unique.

Ah, thank you for the clarification.  I wish I knew the in's and the out's of network systems.  I can tell you how to achieve the optimal contrast to the bokeh for any shot with a SLR but understanding what syn+ack headings in relation to packet files and protocols is still moving sand with a pitchfork.  I want to ask, "Doesn't the probing client send out the password first to see if the AP will accept it?" Which is where I came from asking about Occupineapple;  But I have a feeling that there is a system in place that causes both AP and probing client to meet in the middle and that system obfuscates or tests the password sort of like an encrypted mediator, never to see my interface.  ..maybe? 

Edited May 19, 2016 by Spoonish

[Mr-Protocol]

Here is some reading:

https://en.wikipedia.org/wiki/Beacon_frame

https://en.wikipedia.org/wiki/Wired_Equivalent_Privacy

https://en.wikipedia.org/wiki/Wi-Fi_Protected_Access