Wpa Handshake

[vdub]

I have a problem. I setup a wrt54g router running ddwrt in my shop for pen testing.

The ssid is Linksys and its using wpa.

I am using airodump-ng and I am having a hard time capturing a handshake. I finally got it after connecting my phone to the access point but it took over 10 attempts to do it.

I have my channel set to the same as the access point and everything else looks good.

When I first started I accidentally used my normal wpa2 password and it failed to authenticate but airodump-ng claimed to have gotten that handshake. I restarted it and tried again and that’s when it took over 10 tries to get another. I tried with my phone and my wife's notebook.

The wpa password on the access point is just "password". I want to play with piping john in to airocrack-ng. However, if this was a real world test and I was deauthing to get the handshake then it would take forever.

Is there anything I might be doing wrong.

Here is what I am doing.

## change channel

iwconfig wlan0 channel 6

## then airmon-ng

airmon-ng start wlan0 6

## now I have to bring the adapter down or it doesn't work

ifconfig wlan0 down

## Then start airodump-ng

airodump-ng wlan0 -c 6 --bssid xx:xx:xx:xx:xx:xx -w ./Linksys.0

The adapter is not configured on the system. This adapter is the alfa I use on my netbook and I have it connected to my desktop just for this purpose. I have dual Ethernet adapters and have no intention on making wlan0 work as an actual connection.

Any tips would be appreciated. I read somewhere that you can force wpa in airodump but I could not figure out how.

[digip]

Few things. Connect one of your workstations or devices to the AP.

Next, open your attack machine and setup the wireless stuff. "airmon-zc start wlan0". Try the zc- vs ng just in case your card is like mine and wigs out for whatever reason with ng. Once the card is started via airmon, you should now have a wlan0 and a mon0. mon0 is what you will use for everything, since it is in monitor mode, where as wlan0, is in manage mode and only for connecting to an AP. Now that the card is in monitor mode, start airodump. "airodump-ng -c 6 -w dump mon0". That will start the mon0 nic on channel six and capture to dump.pcap, etc. In another terminal or term tab, now deauth the access point. "aireplay-ng -0 3 mon0 -e Linksys". That sends deauth packets to your AP. You should probably change the name from Linksys to something you know, so you aren't accidentally hitting neighbors in the process. You could alternatively use the AP mac address too. See documentation on aireplay for the command prefix.

Once you start deauthing airodump should show the handshake. It may take a few tries, but give some time between deauths and you should see the handshake for whatever device you currently have connected, tries to reconnect automatically. If you have the devices setup to not automatically reconnect, then that could be an issue, but most will by default. Just keep trying and you should see the handshake. Just be sure to try a few deauths and then give it some time to reconnect. If you use too many deauths or repeat too soon, you won't allow the handshake process to happen.

Once airodump sees it, then run aircrack-ng against dump.pcap and your ready to do whatever you want with the pacp file.

Edited May 8, 2012 by digip

[vdub]

I have always used the wlan{x} device rather then the mon{x} device. If you run iwconfig you can see the wlan{x} is in monitor mode. I will give it a try but I know there was a reason I never used the mon{x} device, I think it might have given me trouble in the past. Honestly I can't remember why.

For the testing I was doing I was manually reconnecting to the access point. Does deauthing give you a better chance of catching a handshake? According to the reading I did on aircrack's site they actually said you will have more luck cycling the connection yourself rather then deauthing. The problem is I was doing the attack against my Galaxy Note and if you deauth a note it just goes to 4G rather then reconnecting. It will eventually reconnect but not right away. So rather I just cycled between my test router and my home router.

I will try deauthing and see where that gets me.

Right now I need to figure out how to get john and aircrack to run on a single core with taskset. I was having problems with it earlier so I took a break from it.

[digip]

Well, in real world scenarios, you wouldn't have access to the target workstations to force them to disconnect and reconnect. Deauthing kicks them off the access point and most operating systems are set to reconnect when they loose the connection. The fact you are using a phone might not be the best test subject for this lab if its going to fail over to 4G vs reconnecting to the AP. Best setup would be a normal windows machine connected, then deauth it, and watch for it to reconnect.

If you are doing all of this manually, set up airodump ahead of time to write to the dump file, while listening on the same channel as your AP, then let all of your devices connect. They should still see the handshake without a deauth, so long as the capture process was setup before they connected. In most cases, you can just leave your machine running airodump, and you should eventually see handshakes for multiple routers in your area as they neighbors connect to their own routers using WPA. Deauthing just helps speed up the process if you see someone connected and need to capture the handshake for specific routers, like on a pentest against a companies wifi.

[vdub]

Right now I need to figure out how to get john and aircrack to run on a single core with taskset. I was having problems with it earlier so I took a break from it.

FYI aircrack-ng -p {number of cores}

This is how you limit the number of cores aircrack uses. taskset doesn't work on aircrack. At least now I can use my system while it runs and my temperature will not reach over 70c. I have a quad core AMD FX @ 4Ghz and earlier with all 4 cores going at 100% after an hour the CPU was at 72c and the system was barely responsive. I have a new way to burn in CPU's, lol.

Well, in real world scenarios, you wouldn't have access to the target workstations to force them to disconnect and reconnect. Deauthing kicks them off the access point and most operating systems are set to reconnect when they loose the connection. The fact you are using a phone might not be the best test subject for this lab if its going to fail over to 4G vs reconnecting to the AP. Best setup would be a normal windows machine connected, then deauth it, and watch for it to reconnect.

If you are doing all of this manually, set up airodump ahead of time to write to the dump file, while listening on the same channel as your AP, then let all of your devices connect. They should still see the handshake without a deauth, so long as the capture process was setup before they connected. In most cases, you can just leave your machine running airodump, and you should eventually see handshakes for multiple routers in your area as they neighbors connect to their own routers using WPA. Deauthing just helps speed up the process if you see someone connected and need to capture the handshake for specific routers, like on a pentest against a companies wifi.

Your right, if I am going to set this up in the lab it might as well be as realistic as possible so I should be deathing anyway. The problem I have had is I have been using mdk3 for the deathing because aircrack has a bug that makes it hard to stay on a static channel. However, mdk3 works just as well, you just have to add hwaddr's to a black list and run mdk3 against it. Not that big of a deal. Honestly I think its better in some cases.

[digip]

mdk3 runs deauths non stop though, doesn't it? if it does, you will not see the handshake, it will never let the blacklisted devices reconnect. aireplay works fine for deauthing so long as your card is supported, and if you set airodump to capture on a specific channel you should be fine ("airodump-ng -c 6 -w dump mon0" where -c 6 is channel six). airmon-ng has been known to be buggy, but I haven't had any issues with the rest of the suite, including airmon-zc.

[vdub]

mdk3 runs deauths non stop though, doesn't it? if it does, you will not see the handshake, it will never let the blacklisted devices reconnect. aireplay works fine for deauthing so long as your card is supported, and if you set airodump to capture on a specific channel you should be fine ("airodump-ng -c 6 -w dump mon0" where -c 6 is channel six). airmon-ng has been known to be buggy, but I haven't had any issues with the rest of the suite, including airmon-zc.

Yeah your right, I didn’t think about that. mdk3 does run non stop. I will have to play with aireplay again and see if I can get it to work this time. I think the problem was airdump would work on a static channel but aireplay would not. I will play around with it and see what happens. I think when I was researching the problem last time I found a patch for aireplay but it was easier just using mdk3 then patching aircrack.

[digip]

aireplay, will follow whatever channel airdump is on. It doesn't really care about channels, it only cares about targets, either via SSID or MAC addresses and desitnation based. I generally just do SSID, so long as I am close enough to my router. Further way targets, use the ap mac and workstation mac in the syntax. See airplay for details, but it works so long as you aren't too far to see the handshakes.

Edited May 8, 2012 by digip

[vdub]

aireplay, will follow whatever channel airdump is on. It doesn't really care about channels, it only cares about targets, either via SSID or MAC addresses and desitnation based. I generally just do SSID, so long as I am close enough to my router. Further way targets, use the ap mac and workstation mac in the syntax. See airplay for details, but it works so long as you aren't too far to see the handshakes.

The problem I had was aireplay would not run. It would give me an error saying its stuck on channel -1 and exit.

Right now I am trying different drivers for the rtl8187 to see if I can make it perform better. I have been really disappointed with its performance. It maxes out at under 1mb during downloads. I am experimenting with drivers in backtrack to see if I can get it working better. I just tried the compact-wireless drivers and I am topping off at 130K/s which is typical. I think maybe this Alfa AWUS036H just sucks. I here everyone recommending it but I also see pages and pages on Google of it getting horrible performance.

[digip]

apt-get update, apt-get upgrade, apt-get dist-upgrade and then try airmon-zc start wlan0 vs airmon-ng. The use mon0 for all of the commands for airmodump and aireplay and you should be good to go.

[vdub]

apt-get update, apt-get upgrade, apt-get dist-upgrade and then try airmon-zc start wlan0 vs airmon-ng. The use mon0 for all of the commands for airmodump and aireplay and you should be good to go.

I'm using openSUSE, not ubuntu. So its zypper not apt-get and I am currently running 12.1.

I will give that a shot.

Another quick question.

The handshake that I was able to get has been running for almost 17 hours. How long should the paraphrase "password" take to get? Is 17 hours excessive or normal?

Edit: I also have aircrack limited to a single core, but its a 4Ghz core. I know that might make a difference.

Edited May 8, 2012 by vdub

[digip]

I am experimenting with drivers in backtrack to see if I can get it working better.

I was assuming you had problems with BackTrack, not OpenSUSE.

The handshake that I was able to get has been running for almost 17 hours. How long should the paraphrase "password" take to get? Is 17 hours excessive or normal?

The handshake, is NEVER the plain text passphrase. Its a hash of the SSID+Passphease that is used as a checksum to verify identity of the user trying to authenticate. It in itself can't be used to authenticate, and can only be brute forced to check for the plain text of the original password/passphrase. If you feed aircrack a wordlist with your password in it, with each password on a line of its own, it should find it right away(so long as its not millions of lines long and at the end of the wordlist).

[vdub]

I was assuming you had problems with BackTrack, not OpenSUSE.

The handshake, is NEVER the plain text passphrase. Its a hash of the SSID+Passphease that is used as a checksum to verify identity of the user trying to authenticate. It in itself can't be used to authenticate, and can only be brute forced to check for the plain text of the original password/passphrase. If you feed aircrack a wordlist with your password in it, with each password on a line of its own, it should find it right away(so long as its not millions of lines long and at the end of the wordlist).

I am piping john though aircrack so the word list is getting generated in real time.

[digip]

I am piping john though aircrack so the word list is getting generated in real time.

Probably easier, to just use "aircrack -w wordlist.txt dump.pcap" and be done with it. If you are brute forcing it on the fly, will take forever, especially if its starting with chacters udner 8, since wpa is 8 or more, you would be wasting huge amount of time.

Unless you are doing CUDA based cracking, john is not going to speed up the process, especially if the word is in a text file for testing the process it coudl easily find it with a dictionary attack much quicker. If you want raw power, use oclhashcat website, convert your pcap to hccap and then run in oclhashcat+ gui to brute force. Still takes a long time, but its way faster than CPU cracking. You just need a GPU with capable drivers.

[vdub]

Probably easier, to just use "aircrack -w wordlist.txt dump.pcap" and be done with it. If you are brute forcing it on the fly, will take forever, especially if its starting with chacters udner 8, since wpa is 8 or more, you would be wasting huge amount of time.

Unless you are doing CUDA based cracking, john is not going to speed up the process, especially if the word is in a text file for testing the process it coudl easily find it with a dictionary attack much quicker. If you want raw power, use oclhashcat website, convert your pcap to hccap and then run in oclhashcat+ gui to brute force. Still takes a long time, but its way faster than CPU cracking. You just need a GPU with capable drivers.

My system has a 7900GT in it right now. I have been thinking about upgrading to a 9000 series so I can use cuda. As of right now I don't think anything will take the 7900 for granted.

[vdub]

Woohoo, it finally finished

Aircrack-ng 1.1

[20:13:10] 81000004 keys tested (1141.89 k/s)

KEY FOUND! [ password ]

Edited May 9, 2012 by vdub

[Pwnd2Pwnr]

Classic Threads still teaching... love it....

[Infiltrator]

Woohoo, it finally finished

Aircrack-ng 1.1

[20:13:10] 81000004 keys tested (1141.89 k/s)

KEY FOUND! [ password ]

WoW, it took you 20:13:10 to crack the key. On my wireless, I also setup the pass-phrase to password, and it only took 3 seconds to find the key.

Where did you download the dictionary file from?

Edited October 8, 2012 by Infiltrator

[Ottawa_Chap]

This is interesting, as when I brute forced my capture using the dual 1.1 CPU in my HP 2510p laptop, I had a password of a 10digit phone # and a dictionary of all the phone numbers for my area code. I recall that crack taking ~1 day. Still have yet to try a crack with my 8400GS video card. Heck, not even sure if it's possible?

[Pwnd2Pwnr]

(Can't wait to build my tower at tax time) :)

[kthx]

This is interesting, as when I brute forced my capture using the dual 1.1 CPU in my HP 2510p laptop, I had a password of a 10digit phone # and a dictionary of all the phone numbers for my area code. I recall that crack taking ~1 day. Still have yet to try a crack with my 8400GS video card. Heck, not even sure if it's possible?

Yes, I find _LOTS_ of people will use a phone number as a password... Why would you brute 0000000000 to 9999999999? Of course it takes long...

HERE is a TIP on cracking a password that is a phone number:

Write down each area code that is common in your area (for me its 905, 416, 647, 289). You will open one "crunch" and "aircrack-ng for each area code. Example:

/pentest/passwords/crunch/crunch 10 10 "0123456789" -s 9050000000 -e 9060000000 -u | aircrack-ng -p 6 -b 68:15:90:43:10:62 -w - -l KEY_dlink_KEY dlink_dump-01.cap

/pentest/passwords/crunch/crunch 10 10 "0123456789" -s 4160000000 -e 4170000000 -u | aircrack-ng -p 6 -b 68:15:90:43:10:62 -w - -l KEY_dlink_KEY dlink_dump-01.cap

/pentest/passwords/crunch/crunch 10 10 "0123456789" -s 6470000000 -e 6480000000 -u | aircrack-ng -p 6 -b 68:15:90:43:10:62 -w - -l KEY_dlink_KEY dlink_dump-01.cap

/pentest/passwords/crunch/crunch 10 10 "0123456789" -s 2890000000 -e 2900000000 -u | aircrack-ng -p 6 -b 68:15:90:43:10:62 -w - -l KEY_dlink_KEY dlink_dump-01.cap

Each one of those will brute EVERY phone number within that area code, and it takes me around 30 mins (I have a AMD PHENOM XII 6 core processor). I don't see why anyone would brute 0000000000 - 9999999999 or even use a dictionary of phone numbers.... Pointless and WAY tooo long...

HERE is a TIP on cracking AlphaNumeric Pass:

The first command will make sure it has a different letter/number each char space. Ex. the next line will not try "aaaaa" but will try "ababab" -- it will not allow a duplicate char beside the current char.

/pentest/passwords/crunch/crunch 5 10 "abcdefghijklmnopqrstuvwxyz" -d 1@ -u | aircrack-ng -p 6 -b 68:15:90:43:10:62 -w - -l KEY_BELL617_KEY BELL617_dump-01.cap

The second command will make sure it has no more than two chars in a row. Ex. the next line will try "aabcd" but will NOT try "ababab" -- it will not allow a duplicate char beside the current char.

/pentest/passwords/crunch/crunch 5 10 "abcdefghijklmnopqrstuvwxyz" -d 2@ -u | aircrack-ng -p 6 -b 68:15:90:43:10:62 -w - -l KEY_BELL617_KEY BELL617_dump-01.cap

off to hack ;)