I have spend the last few days reading about and playing around with the various tools available for cracking WPA and here is what i came to.
Contrary to the "hype" WPA is not cracked, as WEP was.
No "fatal" design flaw has been found that can be exploited to get access to your wifi network.
The *current* and *known* (there is no way to emphasize this more) ways of getting access to WPA protected network is by the "old" way of the dictionary and/or brute force attacks and "rainbow tables".
That been send, the "weak link" in your WPA security is actual your chosen password.
If your password can be easily "guessed" (8 characters passwords with numbers (i.e bith dates) or known words like "/dev/null" :) then you might get into trouble if someone targets you.
Another thing that i realized is that by hiding your ESSID you are actually becoming an easier target to an attack.
This has to do with the fact that your ESSID is actually part of the key and the empty ESSID is on the top 10 of ESSID's people have pre-calculated rainbow tables for.
So to make your WPA wifi more secure do the following
1)Select a unique ESSID, an as attacker could not use a ready-made rainbow table, and would have to recalculate the PMK's and that can take some time, even with the help of Pyrit and some serious hardware.
2) Try to select a random password at least 20 characters long.
3) Switch to AES insted of TKIP
Monday, May 11, 2009
Friday, May 8, 2009
Getting Pyrit to work on my system and other WPA-PSK related rand
Recently i started reading about WPA-PSK security, as a client was using it, in their office, and after some discussion, wanted to see how (in)secure might be.
After some reading it looks like the best way to hack a WPA-PSK based system (for the moment) is to create a rainbow table of possible PMK's (Pairwise Master Key) and then let loose tools like cowpatty and aircrack-ng.
Basically you exchange time for space, as the same PMK can be used on any AP with same SSID.
The problem is, that a PMK requires something in the range of 16.000+ rounds of SHA-1 and this requires some really big computing power.
To give you an idea of the computing power required, my quad core@3Ghz can do about 1.2K PMK's/sec,which is not that bad, but will take weeks to go over a descent word list.
Doing some more search i found that there is a program called Pyrit, that uses the power of the GPU to do some serious PMK crunching. My "vanilla" (not over clocked) Nvidia 8800 GT does 4.800/sec while other, newer Nvidia cards can reach close to 50.000/sec PMK's
UPDATE 17/5/2009
The problem mentioned below is solved in revision 99 of Pyrit
Looks like it was a CUDA 2.2 bug
I am leaving the text for 'historical reasons' but you can safely ignore the fix
So i updated my CUDA drivers and SDK (Pyrit requires CUDA 2,2), got Pyrit from the SVN, build it and run my first benchmark, using only the CPU's.
Things were good, so i moved on to build the Nvidia CUDA module for Pyrit.
The build was ok
but when trying to run the benchmark again i got an error
For some reason the CUDA part was failing to load.
Googling about the error, i found a couple others had the same issue, so it was not just me, doing something wrong.
I emailed the author, but received no reply, so after a day started looking at the code to see where the problem comes from. Open Source rulez :)
It turned out that the module failed to load the CUDA kernel.
Pyrit "converts" the CUDA cubit module to an include file _cpyrit_cudakernel.cubin.h and then uses the CUDA API to load the kernel module.
In my case ,For some reason the _cpyrit_cudakernel.cubin.h seems to have an invalid
cuda kernel image.
So i changed the part that loads the kernel in _cpyrit_cuda.c from the include file
to
(P.S add the correct path to your cubit file)
that loads the cubit file directly.
That got the problem fixed and benchmark worked like a charm
Haven't looked at why the _cpyrit_cudakernel.cubin.h has a corrupted
kernel, will probably do so, during the weekend and post any patches to fix it.
After some reading it looks like the best way to hack a WPA-PSK based system (for the moment) is to create a rainbow table of possible PMK's (Pairwise Master Key) and then let loose tools like cowpatty and aircrack-ng.
Basically you exchange time for space, as the same PMK can be used on any AP with same SSID.
The problem is, that a PMK requires something in the range of 16.000+ rounds of SHA-1 and this requires some really big computing power.
To give you an idea of the computing power required, my quad core@3Ghz can do about 1.2K PMK's/sec,which is not that bad, but will take weeks to go over a descent word list.
Doing some more search i found that there is a program called Pyrit, that uses the power of the GPU to do some serious PMK crunching. My "vanilla" (not over clocked) Nvidia 8800 GT does 4.800/sec while other, newer Nvidia cards can reach close to 50.000/sec PMK's
UPDATE 17/5/2009
The problem mentioned below is solved in revision 99 of Pyrit
Looks like it was a CUDA 2.2 bug
I am leaving the text for 'historical reasons' but you can safely ignore the fix
So i updated my CUDA drivers and SDK (Pyrit requires CUDA 2,2), got Pyrit from the SVN, build it and run my first benchmark, using only the CPU's.
Things were good, so i moved on to build the Nvidia CUDA module for Pyrit.
The build was ok
stelios@Athena:~/pyrit/pyrit-read-only/cpyrit_cuda$ ./setup.py build
running build
running build_ext
Compiling CUDA module using nvcc 2.2, V0.2.1221...
ptxas info : Compiling entry function 'cuda_pmk_kernel'
ptxas info : Used 42 registers, 32+24 bytes smem, 12 bytes cmem[1]
Building modules...
stelios@Athena:~/pyrit/pyrit-read-only/cpyrit_cuda$ sudo ./setup.py
install
running install
running build
running build_ext
Skipping rebuild of Nvidia CUDA kernel ...
Building modules...
running install_lib
running install_egg_info
Removing /usr/lib/python2.5/site-packages/CPyrit_CUDA-0.2.3.egg-info
Writing /usr/lib/python2.5/site-packages/CPyrit_CUDA-0.2.3.egg-info
but when trying to run the benchmark again i got an error
stelios@Athena:~/pyrit/pyrit-read-only/cpyrit_cuda$ pyrit benchmark
Pyrit 0.2.3 (C) 2008, 2009 Lukas Lueg http://pyrit.googlecode.com
This code is distributed under the GNU General Public License v3
The ESSID-blobspace seems to be empty; you should create an ESSID...
Failed to load CUDA-core (CUDA_ERROR_INVALID_IMAGE).
Running benchmark for at least 60 seconds...
CPU-Core (x86_64): 302.43 PMKs/s, 99.41% occupancy
CPU-Core (x86_64): 292.03 PMKs/s, 90.08% occupancy
CPU-Core (x86_64): 300.92 PMKs/s, 87.42% occupancy
CPU-Core (x86_64): 303.17 PMKs/s, 99.17% occupancy
Benchmark done. 1198.55 PMKs/s total.
For some reason the CUDA part was failing to load.
Googling about the error, i found a couple others had the same issue, so it was not just me, doing something wrong.
I emailed the author, but received no reply, so after a day started looking at the code to see where the problem comes from. Open Source rulez :)
It turned out that the module failed to load the CUDA kernel.
Pyrit "converts" the CUDA cubit module to an include file _cpyrit_cudakernel.cubin.h and then uses the CUDA API to load the kernel module.
In my case ,For some reason the _cpyrit_cudakernel.cubin.h seems to have an invalid
cuda kernel image.
So i changed the part that loads the kernel in _cpyrit_cuda.c from the include file
ret = cuModuleLoadData(&self->mod, &__cudakernel_module);
to
ret = cuModuleLoad(&self->mod, "/your/path/to/cubitfile/_cpyrit_cudakernel.cubin");
(P.S add the correct path to your cubit file)
that loads the cubit file directly.
That got the problem fixed and benchmark worked like a charm
stelios@Athena:~/pyrit/pyrit-read-only/cpyrit_cuda$ pyrit benchmark
Pyrit 0.2.2 (C) 2008, 2009 Lukas Lueg http://pyrit.googlecode.com
This code is distributed under the GNU General Public License v3
Running benchmark for at least 60 seconds...
CUDA-Device #1 'GeForce 8800 GT': 4796.11 PMKs/s, 89.75% occupancy
CPU-Core (x86_64): 283.45 PMKs/s, 84.37% occupancy
CPU-Core (x86_64): 298.66 PMKs/s, 96.09% occupancy
CPU-Core (x86_64): 289.44 PMKs/s, 99.15% occupancy
Benchmark done. 5667.66 PMKs/s total.
Haven't looked at why the _cpyrit_cudakernel.cubin.h has a corrupted
kernel, will probably do so, during the weekend and post any patches to fix it.
Subscribe to:
Posts (Atom)