Closed TevPalver closed 3 years ago
I can confirm the same problem. Freshly pulled hashtopolis, hashcat 6.1.1.
I have created a branch issue/678-cracked-wpa-hashes-22000-skipped with a fix but have no rights to push in order to create a pull request.
I have created a branch issue/678-cracked-wpa-hashes-22000-skipped with a fix but have no rights to push in order to create a pull request.
In order to create a pull request, you need to fork the repository where you then can push your changes. From there you can then create a pull request.
Regarding the issue in general, please describe in which form exactly you input the hashes and if you selected that the hashes are salted or not. Hashcat example hashes do not use the colon, so I assume it's just the hcx tool which uses other separators, correct?
I have entered the hashes in plain text as I get them from hcxpngtool:
WPA*02*b4afcfe9a2dd52c2ec2a085b8ba9cbd9*021337a7f057*f018983ad8f6*494f2d535430315730362d4d*1ed6c813ae56ce8a003c569dcbae94fcd7c7f980c77d1cdd99eb33024ac1a5b9*0203007502010a0010000000000000000172ff36025021cabc5569a6f03b9c3790f87e2ec18da0bd77562177711fd13e65000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000001630140100000fac040100000fac040100000fac020c00*02
Hashcat delivers the crack like this:
'b4afcfe9a2dd52c2ec2a085b8ba9cbd9:021337a7f057:f018983ad8f6:<the clear text SSID>', '<the clear text password>', '446f686132303230', '644801957'
Uh ok... that's pretty bad of hashcat then, the hash is built together differently when printing.. I'll have a look. Ideally this would not need a workaround fix in hashtopolis, but should be made better by hashcat.
It is important to understand that WPA is composed of two main parts with different hash types. Additional the second part is divided into three (four with PMKID) types of hash: first part: PBKDF2 to calculate the PMK (result located in potfile) - always unique on WPA1, WPA2, WPA2 key version 3 related networks (but not unique on SAE/WPA3 and EAP related networks)
$ wlangenpmk -e testnetwork -p 'hashcat!'
essid (networkname)....: testnetwork
password...............: hashcat!
plainmasterkey (SHA1)..: 141e6a8c99a26c52f65bf98e2a4bd8325c823d8072df85066bd17c798692c334
putting this together, you'll see the hashcat potfile format: 141e6a8c99a26c52f65bf98e2a4bd8325c823d8072df85066bd17c798692c334*746573746e6574776f726b:hashcat! the ESSID (SALT) is in HEX, because all characters (inclusive non printable ones) are allowed here. (0x00...0xff) and second part: HMAC_MD5, HMAC-SHA1, AES_128_CBC (according to WPA1, WPA2, WPA2 keyver 3) or HMAC-SHA1-128 (PMKID) (result located in outfile - that include MIC and/or PMKID to identify the network to which the result belongs) to derive the session key (PTK)
While the PMK is static on a network, the other keys will change from connection attempt to connection attempt. Please notice that in the second part all values are absolutely random (in case of hcxdumptool attacks that will include the MAC of the AP and/or the MAC of the CLIENT, too).
It is much better (and reduce disk space as well as GPU time) to put focus on the static PMK instead on the dynamic session keys, especially on very large hash files. Please read more here: https://hashcat.net/forum/thread-9712-post-51061.html#pid51061
Cheers Mike
To make it a little more complicated (and to confirm the PMK, running hashcat), let's enter the royal class of hash cracking:
We take the hash and the ESSID from our example code it by base64:
ALGO: SHA1
ITERATIONS: 4096 according to PBKDF2 on WPA
ESSID: dGVzdG5ldHdvcms=
PMK: FB5qjJmibFL2W/mOKkvYMlyCPYBy34UGa9F8eYaSwzQ=
putting all together will lead us to this hashline:
sha1:4096:dGVzdG5ldHdvcms=:FB5qjJmibFL2W/mOKkvYMlyCPYBy34UGa9F8eYaSwzQ=
we have to to this, because hashcat only accept base64 encoded values on that hashmode
please see hashmode 12000:
https://hashcat.net/wiki/doku.php?id=example_hashes
Now we feed hashcat with this hash line:
$ hashcat -m 12000 sha1:4096:dGVzdG5ldHdvcms=:FB5qjJmibFL2W/mOKkvYMlyCPYBy34UGa9F8eYaSwzQ= -a 3 'hashcat!'
and wait for the result:
hashcat (v6.1.1-120-g15bf8b730) starting...
CUDA API (CUDA 11.1)
====================
* Device #1: GeForce GTX 1080 Ti, 10839/11175 MB, 28MCU
sha1:4096:dGVzdG5ldHdvcms=:FB5qjJmibFL2W/mOKkvYMlyCPYBy34UGa9F8eYaSwzQ=:hashcat!
Session..........: hashcat
Status...........: Cracked
Hash.Name........: PBKDF2-HMAC-SHA1
Hash.Target......: sha1:4096:dGVzdG5ldHdvcms=:FB5qjJmibFL2W/mOKkvYMlyC...aSwzQ=
Time.Started.....: Tue Dec 22 13:33:13 2020 (0 secs)
Time.Estimated...: Tue Dec 22 13:33:13 2020 (0 secs)
Guess.Mask.......: hashcat! [8]
Guess.Queue......: 1/1 (100.00%)
Speed.#1.........: 48 H/s (0.23ms) @ Accel:16 Loops:64 Thr:1024 Vec:1
Recovered........: 1/1 (100.00%) Digests
Progress.........: 1/1 (100.00%)
Rejected.........: 0/1 (0.00%)
Restore.Point....: 0/1 (0.00%)
Restore.Sub.#1...: Salt:0 Amplifier:0-1 Iteration:4032-4095
Candidates.#1....: hashcat! -> hashcat!
Hardware.Mon.#1..: Temp: 46c Fan: 30% Util: 20% Core:1506MHz Mem:5005MHz Bus:16
Started: Tue Dec 22 13:33:09 2020
Stopped: Tue Dec 22 13:33:14 2020
Many ways lead to Rome and the important thing is, to start walking and not resigned and doubting to remain in a passive, suffering position. I really like PMKs.
Very interesting, didn't know that you can just directly put them into such a pbkdf2 form. Though, I'm not very experienced with attacking WPA stuff, never really dig into that part of hash cracking.
A small question regarding the cracking of mode 22000 in Hashtopolis. The output of a cracked hash should be good to match uniquely to the original input, right? (So, by re-arranging and changing the format a bit, to look it up).
That depend on the user and his experience. For me, PMK*ESSID:PSK is everything I need. Strictly speaking, I use the calculated PMKs also as Rainbow Table on networks, running the same ESSID. And if I really need the correlation between a single hash and the recovered network PSK, hashcat --show will do the trick for me. But an unexperienced user may need MAC_AP, ESSID (not in hex) and PSK to do the same. So it could be a good idea to provide "both sides of the medal".
BTW: Your question "The output of a cracked hash should be good to match uniquely to the original input, right?" is hard to answer, because WPA consist of many hash types.
On static hashes like md5, sha1, ... I answer it with yes. On dynamic hashes like WPA, I personally tend to no, because the hash changes all the time.
Maybe I need to rephrase my question, to make sure we understand each other correctly. What I mean is, for mode 22000 founds, hashcat is printing MIC/PMKID:MAC_AP:MAC_CLIENT:ESSID:PSK
. So my question would be, if the 4 values are enough to be able to always identify the original hash (which is saved in the Hashtopolis DB) in the WPA*...
format.
Or is it possible that two different input hashes could result in the exact same found output line from hashcat?
Usually the MIC and/or the PMKID is enough to identify the hash. Both are unique. But I suggest to store the PMK, too. If hashcat recovered the PSK of a network, you already have paid the price (calculation of PBKDF2). If you store only the hash and the PSK, you have to pay the price (PBKDF2 calculation - 4096 iterations) next time again. https://github.com/RealEnder/dwpa/commit/6014a51ad83c39af43d1c05fbbcc6087955eec4f
Normally you'll never get the same hash for a network (WPA countermeasure). Every time you capture the 4way handshake, it will is different. On every CLIENT, the PMKID is different, too.
BTW: I sent you a PM, you can reply to.
I forgot to add and example the last important hash mode: 22001 - the extreme fast "verify mode"
$ hashcat -m 22001 test.22000 -a3 141e6a8c99a26c52f65bf98e2a4bd8325c823d8072df85066bd17c798692c334
hashcat (v6.1.1-120-g15bf8b730) starting...
CUDA API (CUDA 11.1)
====================
* Device #1: GeForce GTX 1080 Ti, 10839/11175 MB, 28MCU
112233445566:aabbccddeeff:testnetwork:141e6a8c99a26c52f65bf98e2a4bd8325c823d8072df85066bd17c798692c334
Session..........: hashcat
Status...........: Cracked
Hash.Name........: WPA-PMK-PMKID+EAPOL
Hash.Target......: test.22000
Time.Started.....: Wed Dec 23 09:59:37 2020 (0 secs)
Time.Estimated...: Wed Dec 23 09:59:37 2020 (0 secs)
Guess.Mask.......: 141e6a8c99a26c52f65bf98e2a4bd8325c823d8072df85066bd17c798692c334 [64]
Guess.Queue......: 1/1 (100.00%)
Speed.#1.........: 2159 H/s (0.00ms) @ Accel:64 Loops:1024 Thr:1024 Vec:1
Recovered........: 1/1 (100.00%) Digests
Progress.........: 1/1 (100.00%)
Rejected.........: 0/1 (0.00%)
Restore.Point....: 0/1 (0.00%)
Restore.Sub.#1...: Salt:0 Amplifier:0-1 Iteration:0-1
Candidates.#1....: 141e6a8c99a26c52f65bf98e2a4bd8325c823d8072df85066bd17c798692c334 -> 141e6a8c99a26c52f65bf98e2a4bd8325c823d8072df85066bd17c798692c334
Hardware.Mon.#1..: Temp: 49c Fan: 33% Util: 6% Core:1506MHz Mem:5005MHz Bus:16
Started: Wed Dec 23 09:59:36 2020
Stopped: Wed Dec 23 09:59:38 2020
Now, you have got an overview about WPA related/relevant hash modes 22000, 22001 and 12000, how to use them and how to interpret the result.
Also you should know that nearly all values (except ESSID and PSK) can be totally random. In case of hcxdumptool attacks, the only static hash value of a network is the result and the parameters of the PBKDF2 calculation, as written to hashcat potfile. In our example:
141e6a8c99a26c52f65bf98e2a4bd8325c823d8072df85066bd17c798692c334*746573746e6574776f726b:hashcat!
And to confirm your statement - yes, WPA is a crazy thing!
I wanted to see if this was enough info to push forward with a hash mode 2200x implementation for Hashtopolis?
Is there a workaround that can be used as we wait?
Is there a workaround that can be used as we wait?
I used the fix create by turmsegler "branch issue/678-cracked-wpa-hashes-22000-skipped with a fix"
-a 3 #HL# soadfuck?d?d?d?d
Describe your problem in as much detail as possible " It's broke " is not a description.
The problem is the same as there https://github.com/s3inlc/hashtopolis/issues/618 but with hashtype 22000. After hcxdumptool->hcxpcapngtool I got WPA hashes in 22000 format. Client successfully cracks them with the following debug output. But hashtopolis skips it. If I use 2500 or 16800 hashtypes with the same hashes than everything works great. The output file: