WPA/WPA2 Pre-Shared-Key-Cracking verstehen

Aus xinux.net
Zur Navigation springen Zur Suche springen

Original Artikel

Einführung

Die wenigen Schwächen des Authentifizierungs-Handshake-Prozesses für WPA/WPA2-PSKs sind seit langem bekannt. Dieser Blog-Beitrag bedient nichts Neues oder bisher noch nicht in freier Wildbahn gesehenes oder Konferenzgespräche und verweist tatsächlich auf andere Sites (wie RFCs), die weitere Informationen liefern können. Es bietet jedoch eine gewisse Klarheit darüber, was während der Authentifizierung und damit des Cracking-Prozesses tatsächlich durchgeführt wird, war aber hauptsächlich eine Übung für mich, um zu lernen, wie alles auf einer niedrigeren Ebene funktioniert. Vielleicht ist es für jemand anderen im gleichen Szenario nützlich.

Einführung

Die wenigen Schwächen des Authentifizierungs-Handshake-Prozesses für WPA/WPA2-PSKs sind seit langem bekannt. Dieser Blog-Beitrag bedient nichts Neues oder bisher noch nicht in freier Wildbahn gesehenes oder Konferenzgespräche und verweist tatsächlich auf andere Sites (wie RFCs), die weitere Informationen liefern können. Es bietet jedoch eine gewisse Klarheit darüber, was während der Authentifizierung und damit des Cracking-Prozesses tatsächlich durchgeführt wird, war aber hauptsächlich eine Übung für mich, um zu lernen, wie alles auf einer niedrigeren Ebene funktioniert. Vielleicht ist es für jemand anderen im gleichen Szenario nützlich.

Überblick

Während des Authentifizierungsprozesses versuchen der Supplicant (Client) und der Authenticator (Access Point) jeweils nachzuweisen, dass sie die Passphrase des Pre-Shared-Key (`PSK`) unabhängig kennen, ohne den Schlüssel direkt preiszugeben. Dies geschieht, indem jeder eine Nachricht mit dem von ihnen generierten Pairwise-Master-Key (`PMK`) verschlüsselt, in jede Richtung überträgt und dann die jeweils empfangene Nachricht entschlüsselt. Der Vier-Wege-Handshake wird verwendet, um einen neuen Schlüssel namens Pairwise-Transient-Key ('PTK') zu erstellen, der aus den folgenden verketteten Daten besteht:

  • Paarweiser Hauptschlüssel
  • Authentifikator Nonce
  • Bittsteller Nonce
  • Authentifikator-MAC-Adresse
  • Anwärter MAC-Adresse

Das Ergebnis wird dann durch eine Pseudo-Random-Function (PRF) verarbeitet. Während dieses Handshake-Prozesses wird auch ein weiterer Schlüssel erstellt, der zum Entschlüsseln von Multicast-Datenverkehr verwendet wird, der als Group-Temporal-Key bezeichnet wird.

Tatsächlicher Handshake-Prozess

  • Zunächst sendet der Access Point innerhalb des ersten Handshake-Pakets einen ANonce-Schlüssel an den Client.
  • Der Client konstruiert dann seinen SNonce zusammen mit dem Pairwise-Transient-Key (PTK) und sendet dann den SNonce und Message Integrity Code (MIC) an den Zugangspunkt. [!]
  • Als nächstes konstruiert der Access Point den Group-Temporal-Key, eine Sequenznummer, die verwendet wird, um Replay-Angriffe auf den Client zu erkennen, und einen Message Integrity Code (MIC).
  • Zuletzt sendet der Client dann eine Bestätigung (ACK) an den Access Point.
  • An diesem Punkt wäre ein Angreifer in der Lage gewesen, genug vom Handshake abzufangen, um einen Angriff zum Knacken von Passwörtern durchzuführen.

Bau der PMK

Pairwise-Master-Keys werden bei der Erstellung der Pairwise-Transient-Keys verwendet und nie wirklich über das Netzwerk übertragen. Sie werden von den Pre-Shared-Keys (Enterprise WiFi verwendet einen von EAP erstellten Schlüssel, aber das ist nicht im Rahmen dieses Artikels) zusammen mit den anderen Informationen wie SSID, SSID-Länge abgeleitet. Die PMKs werden mit der Password-Based Key Derivation Function #2 (PBKDF2) erstellt, wobei die SHA1-Hashing-Funktion mit HMAC als Nachrichtenauthentifizierungscode verwendet wird: 

PMK = PBKDF2(HMAC−SHA1, PSK, SSID, 4096, 256)

HMAC-SHA1 ist die verwendete Pseudozufallsfunktion, während 4096 Iterationen dieser Funktion verwendet werden, um den 256- Bit-PMK zu erzeugen . Die SSID wird als Salt für den resultierenden Schlüssel verwendet, und natürlich wird die PSK (in diesem Fall die Passphrase) als Grundlage für diesen gesamten Prozess verwendet.

Die verwendete HMAC-Funktion: 

H(K XOR opad, H(K XOR ipad, passphrase))

Weitere Informationen zu HMAC-SHA1 aus RFC2104 sind unten zu sehen, gehen aber über meine Tiefe: 

opad = 0x5C * B
ipad = 0x36 * B

(1) append zeros to the end of K to create a B byte string (e.g., if K is of length 20 bytes and B=64, then K will be appended with 44 zero bytes 0x00)
(2) XOR (bitwise exclusive-OR) the B byte string computed in step (1) with ipad
(3) append the stream of data 'text' to the B byte string resulting from step (2)
(4) apply H to the stream generated in step (3)
(5) XOR (bitwise exclusive-OR) the B byte string computed in step (1) with opad
(6) append the H result from step (4) to the B byte string resulting from step (5)
(7) apply H to the stream generated in step (6) and output the result

Bau der PTK

Die Erzeugung der Pairwise-Transient-Keys erfolgt über eine weitere PRF (unter Verwendung einer ungeraden Kombination von SHA1, die in einem 512-Bit-String endet), die eine Kombination aus PMK, AP-MAC-Adresse, Client-MAC-Adresse, AP-Nonce, Kunde Nonce. Das Ergebnis ist dieser 512 Bit Pairwise-Transient-Key, der eigentlich eine Verkettung von fünf separaten Schlüsseln und Werten ist, die jeweils ihren eigenen Zweck und ihre eigene Verwendung haben:

  • Schlüsselbestätigungsschlüssel (`KCK`) – Wird während der Erstellung des *Nachrichtenintegritätscodes verwendet.
  • Key Encryption Key (`KEK`) - Wird vom Zugangspunkt während der Datenverschlüsselung verwendet.
  • Temporaler Schlüssel (`TK`) - Wird für die Verschlüsselung und Entschlüsselung von *Unicast-Paketen verwendet.
  • MIC Authenticator Tx Key (`MIC Tx`) - Wird nur mit TKIP-Konfigurationen für Unicast-Pakete verwendet, die von Access Points gesendet werden.
  • MIC Authenticator Rx Key (`MIC Rx`) - Wird nur mit TKIP-Konfigurationen für Unicast-Pakete verwendet, die von Clients gesendet werden.
Die resultierende Reihenfolge

Wpa2-crack-1.png

Der einzige Hinweis auf eine verwendbare PRF512-Funktion in Python war ein Codeauszug aus einer Frage zu Stack Overflow aus dem Jahr 2012: 

def customPRF512(key,A,B):
    blen = 64
    i    = 0
    R    = ''
    while i<=((blen*8+159)/160):
        hmacsha1 = hmac.new(key,A+chr(0x00)+B+chr(i),hashlib.sha1)
        i+=1
        R = R+hmacsha1.digest()
    return R[:blen]

Einige Beispielcodes, um eine Visualisierung dessen zu erhalten, was im Hintergrund passiert: 

#! /usr/bin/env python

import hmac,hashlib,binascii,sha
from pbkdf2 import PBKDF2

def customPRF512(key,A,B):
    blen = 64
    i    = 0
    R    = ''
    while i<=((blen*8+159)/160):
        hmacsha1 = hmac.new(key,A+chr(0x00)+B+chr(i),hashlib.sha1)
        i+=1
        R = R+hmacsha1.digest()
    return R[:blen]

ssid = raw_input('SSID: ')
passphrase = raw_input('Passphrase: ')
ap_mac = binascii.a2b_hex(raw_input("AP MAC: "))
s_mac = binascii.a2b_hex(raw_input("Client MAC: "))
anonce = binascii.a2b_hex(raw_input("ANonce: "))
snonce = binascii.a2b_hex(raw_input("SNonce: "))

key_data = min(ap_mac,s_mac) + max(ap_mac,s_mac) + min(anonce,snonce) + max(anonce,snonce)
pke = "Pairwise key expansion"
key_data = min(ap_mac,s_mac) + max(ap_mac,s_mac) + min(anonce,snonce) + max(anonce,snonce)

pmk = PBKDF2(passphrase, ssid, 4096).read(32)
ptk = customPRF512(pmk,pke,key_data).encode('hex')

print ("\nPMKey: " + pmk)
print ("PTKey: " + ptk)
print ("KCK: " + ptk[0:16])

Der PMK und der PTK werden dann an das Terminal gedruckt, wobei die ersten 16 Bytes des PTK der KCK sind.

Was wird eigentlich für das Knacken berechnet? Sobald das zweite Paket des Handshakes erfasst wurde, verfügt ein Angreifer über genügend Informationen, um zu versuchen, den Pairwise-Transient-Key zu berechnen (unter Verwendung einer angenommenen PSK-Passphrase), der dann verwendet werden kann, um den Key-Confirmation-Key zu extrahieren und die Nachricht zu berechnen compute Integritätscode. Es ist dieser MIC, der beim Vergleich mit dem echten MIC verwendet wird, um die Gültigkeit der angenommenen PSK zu bestimmen.

Dieser ganze Prozess wird für jeden Wörterbucheintrag (oder Brute-Force-Versuch) während des Passwortknackens erneut ausgeführt, was der Grund für die langsame Leistung von Hashcat, Cowpatty und John The Ripper ist (obwohl ich immer noch 100.000 Hashes P/s verwalte). mit Oclhashcat, was zeigt, wie fantastisch der Code von Atom optimiert ist).

Der MIC wird unter Verwendung von HMAC_MD5 berechnet, das seine Eingabe vom KCK-Schlüssel innerhalb des PTK erhält. Leider war ich nicht in der Lage, Python-Code zur Berechnung des MIC zu finden, selbst nachdem ich den Quellcode von Aircrack-ng und Cowpatty überprüft hatte (meine C-Kenntnisse fehlen stark). Erweitere das oben Gesagte und lass es mich wissen, wenn jemand eine Idee hat!

Schlussfolgerungen

Wenn ich den Rechenaufwand für jeden Versuch des Vergleichs der MICs kenne, beruhigt mich die Sicherheit der Verwendung von PSK-Authentifizierung in persönlichen Netzwerken etwas, aber es beweist, wie unschätzbar zufällige Passphrasen in verschiedenen kryptografischen Implementierungen wie dieser sind , insbesondere Passphrasen, die länger sind und mehr Entropie enthalten. Verwenden Sie für Ihr PSK eine Passphrase mit 15 Zeichen, die eine Kombination aus Groß- und Kleinbuchstaben, numerischen und Sonderzeichen enthält, die kein Wörterbuchwort sind . Oh, und ändern Sie es auch regelmäßig. Wenn ich oder jemand anderes Ihre Passphrase knacken würde, würde ein Angreifer nicht viel davon gebrauchen können. Wenn er in einem Monat dorthin zurückkehrt, kann keine Verbindung hergestellt werden, da er auf einen neuen Wert geändert wurde.

Noch wichtiger ist, dass Sie für Ihre Unternehmensnetzwerke keine PSK-Authentifizierung verwenden. Es gibt zwar einige Schwachstellen in bestimmten EAP-Konfigurationen, diese sind jedoch viel einfacher zu beseitigen als ein Offline-Angriff, wie er gegen PSKs in der Lage ist.

Wenn eine der oben genannten Informationen falsch ist, senden Sie mir bitte eine E-Mail und ich werde die erforderlichen Änderungen vornehmen und entsprechend gutschreiben.

Verweise Ich habe einige externe Quellen verwendet, um diese Prozesse weiter zu verstehen. Sie sind in keiner bestimmten Reihenfolge:

https://en.wikipedia.org/wiki/IEEE_802.11i-2004 http://tools.ietf.org/html/rfc2104 http://www.tldp.org/HOWTO/8021X-HOWTO/intro.html

Abgerufen von „https://xinux.net/index.php?title=WPA/WPA2_Pre-Shared-Key-Cracking_verstehen&oldid=23626“