search

hashtopolis / server

Hashtopolis - distributed password cracking with Hashcat
GNU General Public License v3.0
1.45k stars 220 forks source link

Hash cracked during benchmarking phase, never successfully completes. #221

Closed Console closed 6 years ago

Console commented 7 years ago 
Your current Server version: v0.3.2
Current Client version: 0.43.13
Your current Hashcat version v3.6.0
Task Command: -a0 #HL# -r dive.rule rockyou.txt

Currently testing an SPN hash (13100) with a standard rockyou.txt and dive tasking. The password is known to be: AsdfJkl;

This works when calling hashcat manually using the details in the job.

./hashcat/hashcat64.bin -a0 ./hashlists/24 -r ./files/dive.rule ./files/rockyou.txt -m 13100

And successfully cracks the password in seconds, however a distributed job involving 1 to 6 hosts over the entire task fails to successful register a crack and i've re-run the task multiple times.

Closer inspection suspecting something was up with the benchmarking process as it was completing incredibly fast, revealed that the benchmark command:

sudo /home/xxxx/xxxx-hashtopussy/hashcat/hashcat64.bin --force -w2 --hash-type=13100 -a0 "/home/xxxx/xxxx-hashtopussy/hashlists/26" -r "/home/xxxx/xxxx-hashtopussy/files/dive.rule" "/home/xxxx/xxxx-hashtopussy/files/rockyou.txt" --runtime=30 --restore-disable --potfile-disable --session=hashtopussy --weak=0 *note I removed the --machine-readable.

Was actually cracking the hash within the first second of the benchmark.

hashcat (v3.6.0) starting...

OpenCL Platform #1: Intel(R) Corporation

Hashes: 1 digests; 1 unique digests, 1 unique salts Bitmaps: 16 bits, 65536 entries, 0x0000ffff mask, 262144 bytes, 5/13 rotates Rules: 99086

Applicable optimizers:

Watchdog: Hardware monitoring interface not found on your system. Watchdog: Temperature abort trigger disabled. Watchdog: Temperature retain trigger disabled.

Dictionary cache hit:

$krb5tgs$23$xxxx.xxxx$xxxx.xxxx$xxxx/xxxx_xxxx.xxxx.xxxx:1433$0815c0f53786fc7d32d38bff0c5bc50a$db3c62d7a3d69...SNIP...2644351ab0171f5479cefa3:AsdfJkl;

Session..........: hashtopussy Status...........: Cracked Hash.Type........: Kerberos 5 TGS-REP etype 23 Hash.Target......: $krb5tgs$23$*xxxx.xxxx$xxxx.xxxx$xxxx/xxxx...xxxx Time.Started.....: Fri Jun 30 09:48:35 2017 (1 sec) Time.Estimated...: Fri Jun 30 09:48:36 2017 (0 secs; Runtime limited: 29 secs) Guess.Base.......: File (/home/xxxx/xxxx-hashtopussy/files/rockyou.txt) Guess.Mod........: Rules (/home/xxxx/xxxx-hashtopussy/files/dive.rule) Guess.Queue......: 1/1 (100.00%) Speed.Dev.#1.....: 2946.5 kH/s (7.27ms) Recovered........: 1/1 (100.00%) Digests, 1/1 (100.00%) Salts Progress.........: 2457600/722948300620 (0.00%) Rejected.........: 0/2457600 (0.00%) Restore.Point....: 0/7296170 (0.00%) Candidates.#1....: 1234567 -> hORoScope HWMon.Dev.#1.....: N/A

Started: Fri Jun 30 09:48:33 2017 Stopped: Fri Jun 30 09:48:36 2017

Which meant the benchmark was completed within 1 second of starting, not lasting the full 30 seconds.

I'm not sure if this is causing the issue but its certainly an odd behaviour.

Here is some more debug output from hashtopussy earlier when trying to debug the task, as you can see it still runs the command just fine and appears to return a H/S figure and completes chunks. Just never registers a successful crack.

{"action":"chunk","response":"SUCCESS","status":"OK","chunk":2000,"skip":2641287,"length":496}
/home/xxxx/xxxx-hashtopussy/hashcat/hashcat64.bin  --force -w2 --hash-type=13100 -a0 "/home/xxxx/xxxx-hashtopussy/hashlists/26"   -r "/home/xxxx/xxxx-hashtopussy/files/dive.rule" "/home/xxxx/xxxx-hashtopussy/files/rockyou.txt" --outfile-check-dir="/home/xxxx/xxxx-hashtopussy/hashlists/zaps26"  --potfile-disable --quiet --restore-disable --session=hashtopussy --status --machine-readable --status-timer=5 --outfile-check-timer=5 --remove --remove-timer=5 --separator=: -s 2641287 -l 496
STATUS  2   SPEED   1557    1   EXEC_RUNTIME    0.934115    CURKU   2641287 PROGRESS    261718785634    261763710338    RECHASH 0   1   RECSALT 0   1   TEMP    -1  REJECTED    0
{"action":"solve","token":"B2CsNwh36x","chunk":2000,"keyspaceProgress":2641287,"progress":261718785634,"total":261763710338,"speed":1557,"state":2,"cracks":[]}
{"action":"solve","response":"SUCCESS","cracked":0,"skipped":0,"zaps":[]}
Progress:  8.59% | Speed:1.56MH/s | Cracks:0    | Accepted:0    | Zapped:0    | Queue:1 
STATUS  2   SPEED   1508    1   EXEC_RUNTIME    0.936873    CURKU   2641287 PROGRESS    261725654242    261763710338    RECHASH 0   1   RECSALT 0   1   TEMP    -1  REJECTED    0
{"action":"solve","token":"B2CsNwh36x","chunk":2000,"keyspaceProgress":2641287,"progress":261725654242,"total":261763710338,"speed":1508,"state":2,"cracks":[]}
{"action":"solve","response":"SUCCESS","cracked":0,"skipped":0,"zaps":[]}
Progress: 22.57% | Speed:1.51MH/s | Cracks:0    | Accepted:0    | Zapped:0    | Queue:1 
STATUS  2   SPEED   1493    1   EXEC_RUNTIME    0.938272    CURKU   2641287 PROGRESS    261732673634    261763710338    RECHASH 0   1   RECSALT 0   1   TEMP    -1  REJECTED    0
{"action":"solve","token":"B2CsNwh36x","chunk":2000,"keyspaceProgress":2641287,"progress":261732673634,"total":261763710338,"speed":1493,"state":2,"cracks":[]}
{"action":"solve","response":"SUCCESS","cracked":0,"skipped":0,"zaps":[]}
Progress: 36.85% | Speed:1.49MH/s | Cracks:0    | Accepted:0    | Zapped:0    | Queue:1 
STATUS  2   SPEED   1400    1   EXEC_RUNTIME    0.946614    CURKU   2641287 PROGRESS    261739800162    261763710338    RECHASH 0   1   RECSALT 0   1   TEMP    -1  REJECTED    0
{"action":"solve","token":"B2CsNwh36x","chunk":2000,"keyspaceProgress":2641287,"progress":261739800162,"total":261763710338,"speed":1400,"state":2,"cracks":[]}
{"action":"solve","response":"SUCCESS","cracked":0,"skipped":0,"zaps":[]}
Progress: 51.35% | Speed:1.40MH/s | Cracks:0    | Accepted:0    | Zapped:0    | Queue:1 
STATUS  2   SPEED   1514    1   EXEC_RUNTIME    0.942368    CURKU   2641287 PROGRESS    261746658850    261763710338    RECHASH 0   1   RECSALT 0   1   TEMP    -1  REJECTED    0
{"action":"solve","token":"B2CsNwh36x","chunk":2000,"keyspaceProgress":2641287,"progress":261746658850,"total":261763710338,"speed":1514,"state":2,"cracks":[]}
{"action":"solve","response":"SUCCESS","cracked":0,"skipped":0,"zaps":[]}
Progress: 65.30% | Speed:1.51MH/s | Cracks:0    | Accepted:0    | Zapped:0    | Queue:1 
STATUS  2   SPEED   1555    1   EXEC_RUNTIME    0.935074    CURKU   2641287 PROGRESS    261753692130    261763710338    RECHASH 0   1   RECSALT 0   1   TEMP    -1  REJECTED    0
{"action":"solve","token":"B2CsNwh36x","chunk":2000,"keyspaceProgress":2641287,"progress":261753692130,"total":261763710338,"speed":1555,"state":2,"cracks":[]}
{"action":"solve","response":"SUCCESS","cracked":0,"skipped":0,"zaps":[]}
Progress: 79.62% | Speed:1.56MH/s | Cracks:0    | Accepted:0    | Zapped:0    | Queue:1 
STATUS  2   SPEED   1559    1   EXEC_RUNTIME    0.937950    CURKU   2641287 PROGRESS    261761128162    261763710338    RECHASH 0   1   RECSALT 0   1   TEMP    -1  REJECTED    0
STATUS  4   SPEED   1526    1   EXEC_RUNTIME    0.930973    CURKU   2641783 PROGRESS    261763710338    261763710338    RECHASH 0   1   RECSALT 0   1   TEMP    -1  REJECTED    0
{"action":"solve","token":"B2CsNwh36x","chunk":2000,"keyspaceProgress":2641287,"progress":261761128162,"total":261763710338,"speed":1559,"state":2,"cracks":[]}
Attack finished
{"action":"solve","response":"SUCCESS","cracked":0,"skipped":0,"zaps":[]}
Progress: 94.75% | Speed:1.56MH/s | Cracks:0    | Accepted:0    | Zapped:0    | Queue:2 
{"action":"solve","token":"B2CsNwh36x","chunk":2000,"keyspaceProgress":2641783,"progress":261763710338,"total":261763710338,"speed":1526,"state":4,"cracks":[]}
{"action":"solve","response":"SUCCESS","cracked":0,"skipped":0,"zaps":[]}
Progress:100.00% | Speed:1.53MH/s | Cracks:0    | Accepted:0    | Zapped:0    | Queue:1 
Finished processing chunk
Getting chunk...

NB: Yes this is using my laptop, we're experiencing exactly the same behaviour on our GPU powered rigs.

winxp5421 commented 7 years ago

Does this also occur when using the Speedtest benchmark or do you see this on only the Runtime benchmark?

Console commented 7 years ago

Only tested runtime so far, but will switch to speedtest and report back.

Console commented 7 years ago

So looked into this some more. Looking at the command used for benchmarking it clearly re-covers the space when it begins the cracking job. So I don't think this is related to actual benchmarking, it was just a happy coincidence.

I think its the same issue as the lad with the DCC2 hashes is experiencing (https://github.com/s3inlc/hashtopussy/issues/206), as we've just experienced it again with another KRB TGS (13100) hash btw I did put a bodge in the code to expand the database field for hashes as we're routinely hitting 2600 character+ krb tgs tickets - bodge listed in detail here: (https://github.com/s3inlc/hashtopussy/issues/184) just in case that's the cause of my issues.

Chunk shows as "cracked" but the hashlist is not showing the cracked password and other agents continue to crack while the agent that cracked the hash errors with a "hashfile is empty or corrupt" it was a single hash however so that's to be expected as locally it has removed it from its hashfile.

Thankfully the chunk shows as cracked so we were able to find the password manually by subbing in the -s and -l values provided on the chunk activity page.

s3inlc commented 6 years ago

I know it's some time ago since this happened, but I think I might finally know the reason causing this. In this case it would be a connection of two smaller not ideal things on the server. As there might have an error happened during the submission of the hash, it was able to update the chunk and the hashlist counters, but not saving the plain in the hashes. In the old version the transactions were not handled correctly inside the DBA, so if a part failed, the applied changes were not rollback. I assume that this could be the reason for this special behaviour. It would be good, if you later then could run it with the upcoming 0.5.0 version and check if this ever happens again.

s3inlc commented 6 years ago

As this issue is sitting here for a longer time and there was a huge code change since, I close this issue now. Most likely this issue is related to the hash length issues.

If the issue still persists with the newest version, please reopen.