sensepost/assless-chapsMSCHAPv2-Challenge/Response schnell mit einer Datenbank von NT-Hashes knacken.
Knacken von MSCHAPv2/NTLMv1 Challenge/Response schnell mit einer Datenbank von NT-Hashes
Assless CHAPs ist eine effiziente Methode, um den NT-Hash wiederherzustellen, der in einem MSCHAPv2/NTLMv1-Austausch verwendet wird, wenn du die Challenge und Response hast (z. B. von einem WiFi EAP WPE-Angriff).
Es erfordert eine Datenbank von NT-Hashes; Anleitungen zur Erstellung dieser aus vorhandenen Listen oder mit hashcat mit Wortlisten und Regeln findest du weiter unten. Ich habe eine Beispieldatenbank von SecLists beigefügt. Du musst sie entpacken (bunzip).
Ein MSCHAPv2-Austausch erfordert nicht, dass das Klartext-Passwort „geknackt“ wird, sondern wir benötigen lediglich den verwendeten NThash.
MSCHAPv2 teilt den NThash in drei Teile auf und verwendet jeden Teil als unterschiedlichen Schlüssel zur DES-Verschlüsselung derselben Challenge (abgeleitet von der Peer- und Authentifikator-Challenge). Der NTHash wird in zwei 7-Byte-Schlüssel und einen 2-Byte-Schlüssel aufgeteilt. Das bedeutet, dass der letzte Schlüssel mit NULLs aufgefüllt wird, um einen Schlüssel der erforderlichen Länge zu erhalten. Dieser kann aufgrund der Effizienz der DES-Operation und eines Schlüsselraums von 65.535 schnell brute-forced werden. Sobald wir diese zwei Bytes haben, können wir alle NThashes in unserer Datenbank nachschlagen, die auf diese zwei Bytes enden. Dies ergibt eine viel kleinere Menge möglicher Hashes zur Überprüfung.
Dies ist eine Form des Speicher-Zeit-Kompromisses, ähnlich einer Regenbogentabelle. Es ist auch eine Form des Hash Shuckings.
Dies wurde zum ersten Mal auf dem RF Hacking Village der Defcon 29 vorgestellt. Die Folien sind in diesem Repository enthalten.
Hier ist der Vergleich für drei Beispiel-Challenge/Response und drei verschiedene Wortlisten, eine kleine private, rockyou und die Have I Been Pwned-Liste. Diese wurden auf meinem Macbook Pro 2016 durchgeführt. Hashcat verwendet diesen Hash-Shucking-Kernel und die beiden integrierten GPUs sowie einen reinen statt optimierten Kernel (da letzterer noch nicht existiert). Hash3 ist nicht in den Listen enthalten, um die Leistung im ungünstigsten Fall zu simulieren. Ich habe die Zeit, die Hashcat benötigt, um den Wörterbuch-Cache beim ersten Durchlauf aufzubauen, nicht mit einbezogen.
Hash1
Kleine Hashliste:
hashcat 0.50s user 0.27s system 55% cpu 1.405 total (8597.8 kH/s)
assless 0.05s user 0.00s system 294% cpu 0.018 total
Rockyou-Hashliste:
hashcat 2.67s user 0.51s system 93% cpu 3.413 total
assless 0.05s user 0.01s system 281% cpu 0.021 total
HIBP-Hashliste:
hashcat 59.97s user 11.72s system 136% cpu 52.603 total (5620.6 kH/s)
assless 0.05s user 0.00s system 292% cpu 0.018 total
Hash 2
Kleine Hashliste:
hashcat 0.51s user 0.27s system 55% cpu 1.409 total (8704.7 kH/s)
assless 0.03s user 0.00s system 248% cpu 0.012 total
Rockyou-Hashliste:
hashcat 2.20s user 0.46s system 110% cpu 2.409 total (5798.4 kH/s)
assless 0.03s user 0.00s system 231% cpu 0.015 total
HIBP-Hashliste:
hashcat 65.37s user 12.74s system 135% cpu 57.712 total (5768.7 kH/s)
assless 0.03s user 0.00s system 249% cpu 0.013 total
Hash 3
Hash 3 existiert in keiner der Hashlisten, um die Leistung im ungünstigsten Fall zu simulieren.
Kleine Hashliste:
hashcat 0.67s user 0.34s system 66% cpu 1.526 total (7550.1 kH/s)
assless 0.02s user 0.00s system 211% cpu 0.012 total
Rockyou-Hashliste:
hashcat 2.71s user 0.52s system 94% cpu 3.415 total (5685.4 kH/s)
assless 0.02s user 0.01s system 181% cpu 0.014 total
HIBP-Hashliste:
hashcat 125.19s user 27.62s system 139% cpu 1:49.75 total (5634.9 kH/s)
assless 0.06s user 0.03s system 115% cpu 0.075 total
Die Rust-Version erfordert SQLite 3.6.8 oder neuer.
Die Python-Version erfordert python3, sqlite3 und pycryptodome.
Das Dienstprogramm zur Datenbankerstellung erfordert python3 und das sqlite3 CLI.
Dies gilt nur für die Rust-Version. Du benötigst cargo.
Nach der Installation von cargo wechsle einfach in das assless-chaps-rs-Verzeichnis und baue es mit:
cargo build --release
Das resultierende Binary befindet sich im Verzeichnis target/release/.
Assless benötigt die Challenge, Response und eine Datenbank von NThashes. Optional kann die Python-Version die gebündelte optimierte Zwei-Byte-Nachschlagdatei verwenden. Die einfachste Verwendung sieht so aus:
./assless-chaps <Challenge> <Response> <hashes.db>
Zum Beispiel:
./assless-chaps 5d79b2a85966d347 556fdda5f67d2b746ca3315fd8b93adcab5c792790a92e87 rockyou.db
Die Ausgabe sollte wie folgt aussehen:
[-] Two byte lookup file not provided, will brute force instead.
[+] Found in 22636 tries: 586c
[-] Found 222 hashes ending in 586c
[+] Found hash: 8846f7eaee8fb1
[-] Found after 186 hashes.
[+] Found hash: 17ad06bdd830b7
[+] Full hash: 8846f7eaee8fb117ad06bdd830b7586c
Der endgültige vollständige Hash 8846f7eaee8fb117ad06bdd830b7586c ist der NT-Hash für password.
Ich habe einige Zeit damit verbracht, eine Liste aller 65.535 möglichen Zwei-Byte-Werte zu erstellen, sortiert nach der häufigsten Verwendung in einem großen Korpus von Passwörtern. Diese Datei ist als twobytes enthalten. Du kannst sie einfach als viertes Argument an assless übergeben.
Dies spart normalerweise ein paar Runden DES, macht aber keinen großen Geschwindigkeitsunterschied. Vielleicht, wenn du viele Hashes verarbeitest.
python3 assless-chaps.py 5d79b2a85966d347 556fdda5f67d2b746ca3315fd8b93adcab5c792790a92e87 rockyou.db twobytes
[+] Found in 65533 tries: 586c
[-] Found 222 hashes ending in 586c
[+] Found hash: 8846f7eaee8fb1
[-] Found after 186 hashes.
[+] Found hash: 17ad06bdd830b7
[+] Full hash: 8846f7eaee8fb117ad06bdd830b7586c
Die Datei mksqlitedb.py hilft dabei, eine CSV-Hashdatei in die Datenbank umzuwandeln.
python3 mksqlitedb.py <database name> <csv file>
Die CSV-Datei erfordert drei Spalten:
Zum Beispiel wird der Hash 8846f7eaee8fb117ad06bdd830b7586c zu:
586c,8846f7eaee8fb1,17ad06bdd830b7
Ein Beispiel für eine Regexp-Transformation dafür wäre:
echo 8846f7eaee8fb117ad06bdd830b7586c | sed "s/^\(.\{14\}\)\(.\{14\}\)\(.\{4\}\)$/\3,\1,\2/"
Du kannst entweder eine vorhandene Liste von Hashes nehmen (wie die Have I Been Pwned-Listen) oder deine eigenen mit hashcat und deinen bevorzugten Wortlisten/Regel-Kombinationen erstellen.
Die HIBP-Passwortlisten sind bereits als NT-Hashes herunterladbar; man muss lediglich die Anzahl aus der Datei entfernen und sie in das CSV-Format konvertieren, um sie in die Datenbank zu importieren.
Dies kann mit dem standardmäßigen Unix-Dienstprogramm sed wie folgt erledigt werden:
sed "s/^\(.\{14\}\)\(.\{14\}\)\(.\{4\}\):.*/\3,\1,\2/" pwned-passwords-ntlm-ordered-by-hash.txt > hibp.csv
Danach kann es mit mksqlitedb.py hibp.db hibp.csv importiert werden.
Um eine reine Wortliste in eine Hashliste von nthashes zu konvertieren, kannst du nthasher verwenden, das große Wortlisten schnell verarbeiten kann. Die resultierenden Hashes müssen wie oben beschrieben in das erforderliche CSV-Format umgewandelt werden.
Ein wesentlich langsamerer nthasher, der die Hashes direkt im erforderlichen CSV-Format ausgibt, ist in diesem Repository enthalten und wird ganz einfach mit folgendem Befehl ausgeführt:
python3 nthash-from-clear.py <wordlist> > hashlist.csv
Wenn du die Wortliste mit Regeln erweitern möchtest, siehe den nächsten Abschnitt zur Verwendung von hashcat.
Du musst eine kleine Codeänderung am OpenCL-Modul des Modus 1000 vornehmen, damit es jeden Hash ausgibt, nicht nur die, die deinem Crack-Kandidaten entsprechen. Standardmäßig wird es den Hash im erforderlichen CSV-Format generieren.
OpenCL-Verzeichnis: cd hashcat/OpenCLpatch < m01000_a0-pure.cl.patchecho 11111111111111111111111111111111 > impossible_hashhashcat -m1000 impossible_hash rockyou.txt -r best64.rule --potfile-disable --quiet > rockyou.csvpython3 mksqlitedb.py rockyou.db rockyou.csvDie SQLite-Datenbank ist in der Regel 61% größer als die zu ihrer Erstellung verwendete CSV-Datei. Es kann auch je nach Dateigröße einige Zeit dauern, die Datenbank zu erstellen. Bereite deine Dateisystemanforderungen entsprechend vor.
Hier ist ein Beispiel mit dem rockyou-Wörterbuch:
Du könntest Platz sparen, indem du jeden Hash dynamisch konvertierst und einfügst und die Notwendigkeit der zwischengeschalteten CSV-Datei umgehst.
NTLMv1 funktioniert auf genau die gleiche Weise, es sei denn, es wird SSP verwendet. Du erkennst, ob SSP verwendet wird, wenn du eine LM-Antwort erhältst, die mit einer Reihe von Nullen endet. Du kannst das enthaltene ntlm-ssp.py verwenden, um die Server-Challenge zu erstellen, die assless benötigt.
Führe es wie folgt aus:
python3 ntlm-ssp.py <lm response> <challenge>
Wenn wir zum Beispiel die Beispiel-NTLMv1-SSP-Challenge-Response aus den hashcat-Beispiel-Hashes verwenden:
u4-netntlm::kNS:338d08f8e26de93300000000000000000000000000000000:9526fb8c23a90751cdd619b6cea564742e1e4bf33006ba41:cb8086049ec4736c
Du würdest LM und Challenge wie folgt übergeben:
python3 ntlm-ssp.py 338d08f8e26de93300000000000000000000000000000000 cb8086049ec4736c
Und erhältst die folgende Antwort:
The server challenge is: 724edf24aea0d68b
Die dann wie gewohnt mit assless-chaps geknackt werden kann:
./assless-chaps 724edf24aea0d68b 9526fb8c23a90751cdd619b6cea564742e1e4bf33006ba41 hashes.db