Sunday, February 19, 2012

WPA cracking tips and tricks

WPA cracking is at the same time easy and hard to crack. It is quite easy because all you need is getting the handshake (with WEP, you need a lot of data frames). It is hard because getting the handshake can be tricky and also because cracking can take a lot of time (due to passphrase length, 8 to 63 characters).

Important notes:
  • Never forget to read the documentation in the wiki
  • Don't hack AP you don't own or if you don't have the permission to do it.


There are several things to consider when getting the handshake:
  • You need to be somehow close to both the AP and the client. If you only have the client, you should use airbase-ng to get the client to connect to you.
  • If RXQ is below 70 then there is a good chance you'll get a partial handshake which will be unusable.
  • You MUST be on the same channel as the AP (in airodump-ng, you will see RXQ column when on a fixed channel)
  • It is not necessary to keep deauthenticating the client, once or twice should be more than enough. And let the client reconnect in order to get the handshake. Each aireplay-ng tells you it sent deauthentication, it sent 128 or 256 deauth frames.
 If you still don't get the handshake after reading the wiki and those tips, then you might want to have a look at WPA Packet Capture Explained tutorial in the wiki to help understand what's going on.

Tip: It is always a good idea to clean up the capture to include one beacon the handshake before cracking it or submitting it to an online cracking service. The reason is that YOU select the handshake to crack and don't let the tool on those services to select the handshake (that might be the wrong one).

It might sound funny but it is true, there is 0% chances to crack it if the passphrase is not in the dictionary (and 100% when it is in the dictionary). So what you want to do is profiling your victim when cracking the handshake to include words/phrases related to it. You can also find a few tools on backtrack such as John The Ripper that will help you mangle the dictionary and "add" new words.
If you need to generate phrases such as number, check out 'crunch'.
Note that aircrack-ng doesn't mangle the wordlist and doesn't do any permutation, it just tries each passphrase against the handshake. And in case you want to be able to 'pause' the cracking, use John The Ripper to output to stdout and pipe the results to aircrack-ng (using -w -).
GPU cracking makes cracking much faster. One of the best solution for that is oclHashcat-plus (and it is much faster than pyrit).

Now that you've cracked the handshake, you might want to verify it. People have been trying to connect to the AP but it is the wrong way of checking since there are a lot of variables involved (such as distance, mac filtering, bad drivers, etc) that will prevent you to connect even if the passphrase is valid.
So what you have to do is using airdecap-ng.
With WPA, since what you get with the handshake is a session key for a specific device, you can only decrypt the traffic after the handshake for that device. Don't be fooled by airdecap-ng giving 0 frames decrypted when there are a few data frames encrypted with WPA, there might not be any traffic from that device after the handshake. Hence why it is very important to be able to understand a capture file.

Saturday, February 11, 2012

Aircrack-ng on phones (Android, iPhone and others)

I've often seen questions like "How can I get Aircrack-ng on my iPhone/Android/Symbian/[ADD YOUR OS]?". Let me clarify the status for phones.

In order to have Aircrack-ng running on the phone, there are several requirements:

  1. Being able to cross compile (because the CPU on your phone has a different architecture than the one on your computer). So if you cannot find a cross compiler for that specific platform, forget it.
  2. A wireless card. Most phones have one these days, so that's easy.
  3. If your phone is Linux based, you will also need to be able to be 'root' to run the commands.
  4. The driver must allow monitor mode. That's usually where almost all phones fail because only a few have that. Sometimes the card doesn't have a stable monitor mode. The reason behind it is that it must be low power (and cheap to manufacture) so the chipset (and its firmware) is very limited.

To give you a quick answer, only one phone meets all the requirements with its internal card: the Nokia N900 (it needs the 'power' kernel available in the extra-devel repositories). While doing monitor mode/injection, the battery last about 4h.

  • iOS devices: Forget it because it is never going to happen, Apple is consumer oriented and doesn't really care about the computer security industry. Plus,  iOS is too closed source and AFAIK the chipset is not capable of proper monitor mode. You could argue that it is available via Cydia. It's true but you don't have any monitor mode capabilities, so it doesn't worth it (also don't bother sending me Cydia bug reports, I don't read them).
  • Android: Forget it with the internal card. However, it will be possible with an external USB card. Dragorn, the author of Kismet Wireless is working on it.
  • Other OS: Forget it (for the same reasons as Apple).