Wireless Encryption

[digininja]

Seeing as people keep asking various questions about the Pineapple and encryption I thought I'd do a quick write up on how wifi encryption works. I'm not going to go into technical detail just cover the basics but hopefully it will answer the questions we keep getting asked.

Association

The first thing a client does when it wants to talk to an AP is to associate. It does this by asking to AP if it can associate. The AP will check things like MAC address filtering and other stuff and say either yes or no.

There is no proving anything at this point, no challenges etc.

If the association is allowed then they move on to the next stage, if it isn't allowed then the association fails and the client is disconnected.

Authentication

For our purposes there are three types of authentication, none, WEP and WPA-PSK.

none - No authentication happens and the client is allowed on to the network. This is the way open networks work and the way the Pineapple works by default

WEP - The AP sends a challenge to the client, the client manipulates the challenge using the key and sends it back to the AP. The AP checks the generated value and if it matches the client is authenticated. Both parties can then use the key to encrypt traffic and communicate securely. The key is never sent in the open, just the response to the challenge. This is why we can't capture the key which is a common question we get asked.

Authentication is one way, the client authenticates to the AP but the AP isn't authenticated back to the client.

As far as the Pineapple is concerned we can send the challenge and accept any response the client sends to authenticate the client but we would then be stuck without the key to encrypt/decrypt the traffic so we couldn't actually talk to the client.

Very dumbed down but cracking the key is done by capturing a lot of traffic then brute forcing the key that is used to encrypt the traffic.

WPA-PSK - The AP sends a challenge to the client, the client manipulates it and sends it back to the AP along with a challenge of its own. The AP manipulates the challenge and sends that back to the client. This is called the four way handshake as 4 packets are sent during the communication.

Authentication is mutual, the AP authenticates the client and vice-versa.

As with WEP, the key is not sent in the air so it can't be captured.

Cracking the PSK is done by capturing the 4 way handshake, in reality most of the time all you need is the first two packets, the challenge that is sent to the client and the reply from the client to the AP. You then fire the cracker off against those two packets.

What you should note here is that the key you are cracking is the key the client is using as you have the client challenge and the response it generated.

If the client doesn't know the PSK then the response it generates isn't accepted by the AP and the authentication fails, the client is disassociated.

If the AP doesn't know the PSK then it can accept the response from the client but it can't generate a valid response to send to the client so the client will abort the authentication process. This means we can't fake the authentication process.

As I said a the start, this isn't designed to be a technical description of how it all works. If you want full technical details I highly recommend you watch the Security Tube WiFi Megaprimer . I know a lot about wifi but I learnt things from it so it is definitely worth watching.

[Anavrin]

As far as the Pineapple is concerned we can send the challenge and accept any response the client sends to authenticate the client but we would then be stuck without the key to encrypt/decrypt the traffic so we couldn't actually talk to the client.

May be a dumb question, but couldn't we conduct a bruteforce / dictionary attack with that?

I mean we made the challenge, so we know the paintext of the encrypted challenge response.

Wouldn't it be possible to retrieve the key by taking the plaintext, encrypting it with a bunch of keys listed in a dictionary and compare it to the challenge response?

It sure not as convenient as classical WEP cracking, although more convenient than WPA cracking since you don't need the client to explicitly (re)connect to the target AP.

Edited January 17, 2013 by Anavrin

[digininja]

Yes

Cracking the PSK is done by capturing the 4 way handshake, in reality most of the time all you need is the first two packets, the challenge that is sent to the client and the reply from the client to the AP. You then fire the cracker off against those two packets.

What you should note here is that the key you are cracking is the key the client is using as you have the client challenge and the response it generated.

[Anavrin]

I was talking about WEP keys, not WPA, I though my quote from your post would've been self-explanatory, oh well...

Let me re-phrase my question;

If we force a station to try and authenticate with us via Karma or something,

we send him a challenge, the station encrypt it with the WEP keys,

we then try to decrypt the ciphertext with a dictionnary file until the result equals the plaintext challenge which we already know since we created it.

I was asking if this concept was somewhat practicable, or is there some hidden trickery that would prevent this attack.

It is less convenient than AP-targeted WEP cracking, but it would be a very effective and decentralized way to mass harvest a lot potential weak WEP keys for multiple AP, 4-ways handshake style, but better.

Edited January 17, 2013 by Anavrin

[digininja]

It might work but would be very slow if it did. With the normal WEP attack you are using ARP requests to generate network traffic which is a response to your action and is at the speed of the network device. With the authentication you are limited by the speed the client attempts to re-authenticate which isn't that fast, maybe an attempt a second compared to the thousands of packets per second for traditional WEP attacks.

I've also noticed a lot of clients give up trying to authenticate after a number of attempts, they go into a suspend type state for a while. That would limit the packet capture even more.

So, a vague possibility of it working but not really practical.