hashcat Forum
Using WPA2 DK PSK (derrived Key) instead of 4Way Handshake - Printable Version

+- hashcat Forum (https://hashcat.net/forum)
+-- Forum: Deprecated; Previous versions (https://hashcat.net/forum/forum-29.html)
+--- Forum: Old oclHashcat Support (https://hashcat.net/forum/forum-38.html)
+--- Thread: Using WPA2 DK PSK (derrived Key) instead of 4Way Handshake (/thread-3652.html)

Using WPA2 DK PSK (derrived Key) instead of 4Way Handshake - TrX - 09-03-2014

Hi All,

I'm trying to audit WPA2 keys set on a number of branch location sites automatically. The controllers don't keep the plaintext, only the PSK (PBKDF2 derived key) from the following process:

DK = PBKDF2(Passphrase,SSID,SSID.length,2096,256).

There doesn't appear to be a way of feeding this data into oclHashcat ... to my mind the ability to crack this has to be supported due to the existing WPA2 support?

I guess as a workaround, would it be possible to use this data to create a 'fake' 4 way handshake capture, allowing (in a rather backwards) way to achieve this?

Would be interested to know if theres something more complex I haven't considered going on here between the two formats, or if this functionality could be easily supported? A lot of WLAN controllers store the passphrase in this way in on-disk configs and backups etc.

Regards,
TrX

RE: Using WPA2 DK PSK (derrived Key) instead of 4Way Handshake - undeath - 09-03-2014

PBKDF2(Passphrase,SSID,SSID.length,2096,256)

This does not describe anything. PBKDF2 needs a hashing algorithm. To answer your question: hashcat has no generic handler for PBKDF2.

RE: Using WPA2 DK PSK (derrived Key) instead of 4Way Handshake - TrX - 09-03-2014

undeath, you're right, apologies.

What I was trying to say is it's stored as a WPA2 PSK, so the underlying hash function is HMAC-SHA1.

I'm trying to understand why there is no PBKDF2 handler for this, is there more complexity than i've considered to the implementation that just makes it unfeasible? or is it just a feature that never made the cut?

Either way, I'm trying to follow the RFC's for the four way handshake to understand if, armed with the hash already, I could create a four way handshake capture which hashcat would be happy with. Can you think of any reason this wouldn't be physically possible?

TrX

RE: Using WPA2 DK PSK (derrived Key) instead of 4Way Handshake - coolbry95 - 09-03-2014

So are you just trying to crack the WPA2 password? If so then just capture the four way handshake and do the pcap to hccap. Then you run hashcat on the hccap.

RE: Using WPA2 DK PSK (derrived Key) instead of 4Way Handshake - magnum - 09-04-2014

(09-03-2014, 01:46 AM)TrX Wrote: Either way, I'm trying to follow the RFC's for the four way handshake to understand if, armed with the hash already, I could create a four way handshake capture which hashcat would be happy with. Can you think of any reason this wouldn't be physically possible?

The problem with that approach (apart from being tedious) is you only get half the possible speed. Aimed with the actual derived key and not just a sniffed handshake, we can exploit the inner workings of PBKDF2: We can create the first 160 bits of the key with half of the work compared to cracking a sniffed handshake - and then do early rejection. So a generic non-naive PBKDF2 format will be exactly twice as fast as the sniffed-handshake WPAPSK format.

We already had a generic pbkdf2-hmac-sha1 format in John the Ripper (bleeding-jumbo branch) so I tested this today. I had to tweak it a little to allow for longer salts etc. After verifying the concept I threw an OpenCL format together too. There should be a Trac ticket for implementing generic PBKDF2 formats in Hashcat - if not, just add one.

Here's how to crack such a hash in JtR now (provided you have the very latest source from GitHub):

Let's say you have an ESSID of "Harkonen" (I made this from a well known test vector) and a DK of ee51883793a6f68e9615fe73c80a3aa6f2dd0ea537bce627b929183cc6e57925. The password for this key is "12345678".

Convert the ESSID to hex (this is because the format is generic so it can take binary salts). For example like this:
Code:
$ perl -e 'print unpack("H*", "Harkonen"), "\n"'
4861726b6f6e656e

The iteration count is always 4096. Now just put the pieces together:
Code:
$ echo 'Harkonen:$pbkdf2-hmac-sha1$4096$4861726b6f6e656e$ee51883793a6f68e9615fe73c80a3aa6f2dd0ea537bce627b929183cc6e57925' > wpapsk-dk.in
(the "Harkonen:" in this line is just a "username" that will be output if/when the hash is cracked. It's not part of the hash itself and can be omitted).

Now fire away. Note that I add the -min-length option because WPAPSK has a minimum length of 8 so we don't want to try shorter candidates:
Code:
$ ../run/john wpapsk-dk.in -inc:digits -min-len=8
Loaded 1 password hash (PBKDF2-HMAC-SHA1 [PBKDF2-SHA1 8x SSE2])
Press 'q' or Ctrl-C to abort, almost any other key for status
12345678         (Harkonen)
1g 0:00:00:00 DONE (2014-09-04 19:35) 2.500g/s 10240p/s 10240c/s 10240C/s 029258369..20011212
Use the "--show" option to display all of the cracked passwords reliably
Session completed
(the speed figures shown here are way low because the password was cracked immediately)

RE: Using WPA2 DK PSK (derrived Key) instead of 4Way Handshake - atom - 09-10-2014

I just saw this post, sounds interessting. Where is that WPA2 DK PSK coming from?

RE: Using WPA2 DK PSK (derrived Key) instead of 4Way Handshake - magnum - 09-10-2014

Earlier versions of Windows stored them in the registry. I believe many routers, just like OP's, store them. I have a feeling most smartphones do too.