mirror of
https://github.com/HackTricks-wiki/hacktricks.git
synced 2025-10-10 18:36:50 +00:00
Translated ['src/generic-methodologies-and-resources/pentesting-wifi/REA
This commit is contained in:
Translator
parent
d99cd5a9c7
commit
94d42ebf06
@ -25,6 +25,7 @@
|
||||
- [Spoofing LLMNR, NBT-NS, mDNS/DNS and WPAD and Relay Attacks](generic-methodologies-and-resources/pentesting-network/spoofing-llmnr-nbt-ns-mdns-dns-and-wpad-and-relay-attacks.md)
|
||||
- [Spoofing SSDP and UPnP Devices with EvilSSDP](generic-methodologies-and-resources/pentesting-network/spoofing-ssdp-and-upnp-devices.md)
|
||||
- [Pentesting Wifi](generic-methodologies-and-resources/pentesting-wifi/README.md)
|
||||
- [Enable Nexmon Monitor And Injection On Android](generic-methodologies-and-resources/pentesting-wifi/enable-nexmon-monitor-and-injection-on-android.md)
|
||||
- [Evil Twin EAP-TLS](generic-methodologies-and-resources/pentesting-wifi/evil-twin-eap-tls.md)
|
||||
- [Phishing Methodology](generic-methodologies-and-resources/phishing-methodology/README.md)
|
||||
- [Clone a Website](generic-methodologies-and-resources/phishing-methodology/clone-a-website.md)
|
||||
|
||||
@ -17,7 +17,13 @@ iwconfig wlan0mon mode managed #Quit mode monitor - managed mode
|
||||
iw dev wlan0 scan | grep "^BSS\|SSID\|WSP\|Authentication\|WPS\|WPA" #Scan available wifis
|
||||
iwlist wlan0 scan #Scan available wifis
|
||||
```
|
||||
## Tools
|
||||
## Werkzeuge
|
||||
|
||||
### Hijacker & NexMon (Android internes Wi-Fi)
|
||||
|
||||
{{#ref}}
|
||||
enable-nexmon-monitor-and-injection-on-android.md
|
||||
{{#endref}}
|
||||
|
||||
### EAPHammer
|
||||
```
|
||||
@ -59,7 +65,7 @@ Dieses Tool automatisiert **WPS/WEP/WPA-PSK** Angriffe. Es wird automatisch:
|
||||
- Nach möglichen Netzwerken scannen - Und Ihnen erlauben, die Opfer auszuwählen
|
||||
- Wenn WEP - WEP-Angriffe starten
|
||||
- Wenn WPA-PSK
|
||||
- Wenn WPS: Pixie Dust-Angriff und den Brute-Force-Angriff (seien Sie vorsichtig, der Brute-Force-Angriff kann lange dauern). Beachten Sie, dass es keinen Null-PIN oder Datenbank/erzeugte PINs versucht.
|
||||
- Wenn WPS: Pixie Dust-Angriff und der Brute-Force-Angriff (seien Sie vorsichtig, der Brute-Force-Angriff kann lange dauern). Beachten Sie, dass es keinen Null-PIN oder Datenbank/erzeugte PINs versucht.
|
||||
- Versuchen, die PMKID vom AP zu erfassen, um sie zu knacken
|
||||
- Versuchen, Clients des AP zu deauthentifizieren, um einen Handshake zu erfassen
|
||||
- Wenn PMKID oder Handshake, versuchen, mit den Top5000 Passwörtern zu bruteforcen.
|
||||
@ -67,9 +73,9 @@ Dieses Tool automatisiert **WPS/WEP/WPA-PSK** Angriffe. Es wird automatisch:
|
||||
## Angriffsübersicht
|
||||
|
||||
- **DoS**
|
||||
- Deauthentifizierung/Dissoziation -- Alle (oder ein bestimmtes ESSID/Client) trennen
|
||||
- Zufällige gefälschte APs -- Netze verstecken, mögliche Scanner zum Absturz bringen
|
||||
- AP überlasten -- Versuchen, den AP abzutöten (normalerweise nicht sehr nützlich)
|
||||
- Deauthentication/Disassociation -- Alle (oder ein bestimmtes ESSID/Client) trennen
|
||||
- Zufällige gefälschte APs -- Netzwerke verstecken, mögliche Scanner zum Absturz bringen
|
||||
- AP überlasten -- Versuchen, den AP zu töten (normalerweise nicht sehr nützlich)
|
||||
- WIDS -- Mit dem IDS spielen
|
||||
- TKIP, EAPOL -- Einige spezifische Angriffe, um einige APs zu DoS
|
||||
- **Cracking**
|
||||
@ -85,19 +91,19 @@ Dieses Tool automatisiert **WPS/WEP/WPA-PSK** Angriffe. Es wird automatisch:
|
||||
- **Offenes** Evil Twin \[+ DoS] -- Nützlich, um Anmeldeinformationen für das Captive Portal zu erfassen und/oder LAN-Angriffe durchzuführen
|
||||
- **WPA-PSK** Evil Twin -- Nützlich für Netzwerkangriffe, wenn Sie das Passwort kennen
|
||||
- **WPA-MGT** -- Nützlich, um Unternehmensanmeldeinformationen zu erfassen
|
||||
- **KARMA, MANA**, **Loud MANA**, **Bekannte Beacon**
|
||||
- **KARMA, MANA**, **Loud MANA**, **Bekannter Beacon**
|
||||
- **+ Offen** -- Nützlich, um Anmeldeinformationen für das Captive Portal zu erfassen und/oder LAN-Angriffe durchzuführen
|
||||
- **+ WPA** -- Nützlich, um WPA Handshakes zu erfassen
|
||||
- **+ WPA** -- Nützlich, um WPA-Handshakes zu erfassen
|
||||
|
||||
## DOS
|
||||
|
||||
### Deauthentifizierungs-Pakete
|
||||
### Deauthentication-Pakete
|
||||
|
||||
**Beschreibung von** [**hier**:](https://null-byte.wonderhowto.com/how-to/use-mdk3-for-advanced-wi-fi-jamming-0185832/)**.**
|
||||
|
||||
**Deauthentifizierungs**-Angriffe, eine verbreitete Methode im Wi-Fi-Hacking, beinhalten das Fälschen von "Management"-Frames, um **Geräte gewaltsam von einem Netzwerk zu trennen**. Diese unverschlüsselten Pakete täuschen Clients vor, dass sie vom legitimen Netzwerk stammen, was Angreifern ermöglicht, WPA Handshakes zu sammeln, um sie zu knacken, oder um Netzwerkverbindungen dauerhaft zu stören. Diese Taktik, die in ihrer Einfachheit alarmierend ist, wird weit verbreitet eingesetzt und hat erhebliche Auswirkungen auf die Netzwerksicherheit.
|
||||
**Deauthentication**-Angriffe, eine verbreitete Methode im Wi-Fi-Hacking, beinhalten das Fälschen von "Management"-Frames, um **Geräte gewaltsam von einem Netzwerk zu trennen**. Diese unverschlüsselten Pakete täuschen die Clients vor, dass sie vom legitimen Netzwerk stammen, was Angreifern ermöglicht, WPA-Handshakes zu sammeln, um sie zu knacken, oder um Netzwerkverbindungen dauerhaft zu stören. Diese Taktik, die in ihrer Einfachheit alarmierend ist, wird weit verbreitet eingesetzt und hat erhebliche Auswirkungen auf die Netzwerksicherheit.
|
||||
|
||||
**Deauthentifizierung mit Aireplay-ng**
|
||||
**Deauthentication mit Aireplay-ng**
|
||||
```
|
||||
aireplay-ng -0 0 -a 00:14:6C:7E:40:80 -c 00:0F:B5:34:30:30 ath0
|
||||
```
|
||||
@ -109,7 +115,7 @@ aireplay-ng -0 0 -a 00:14:6C:7E:40:80 -c 00:0F:B5:34:30:30 ath0
|
||||
|
||||
### Disassoziationspakete
|
||||
|
||||
**Disassoziationspakete**, ähnlich wie Deauthentifizierungspakete, sind eine Art von Management-Frame, die in Wi-Fi-Netzwerken verwendet werden. Diese Pakete dienen dazu, die Verbindung zwischen einem Gerät (wie einem Laptop oder Smartphone) und einem Access Point (AP) zu trennen. Der Hauptunterschied zwischen Disassoziation und Deauthentifizierung liegt in ihren Nutzungsszenarien. Während ein AP **Deauthentifizierungspakete sendet, um unerwünschte Geräte ausdrücklich aus dem Netzwerk zu entfernen, werden Disassoziationspakete typischerweise gesendet, wenn der AP heruntergefahren wird**, neu gestartet oder sich bewegt, wodurch die Trennung aller verbundenen Knoten erforderlich wird.
|
||||
**Disassoziationspakete**, ähnlich wie Deauthentifizierungspakete, sind eine Art von Management-Frame, die in Wi-Fi-Netzwerken verwendet werden. Diese Pakete dienen dazu, die Verbindung zwischen einem Gerät (wie einem Laptop oder Smartphone) und einem Access Point (AP) zu trennen. Der Hauptunterschied zwischen Disassoziation und Deauthentifizierung liegt in ihren Nutzungsszenarien. Während ein AP **Deauthentifizierungspakete sendet, um unerwünschte Geräte ausdrücklich aus dem Netzwerk zu entfernen, werden Disassoziationspakete typischerweise gesendet, wenn der AP heruntergefahren wird**, neu gestartet wird oder sich bewegt, wodurch die Trennung aller verbundenen Knoten erforderlich wird.
|
||||
|
||||
**Dieser Angriff kann mit mdk4 (Modus "d") durchgeführt werden:**
|
||||
```bash
|
||||
@ -150,7 +156,7 @@ Die Abfrage von Access Points (APs) überprüft, ob ein SSID ordnungsgemäß ang
|
||||
|
||||
**ANGRIFFSMODUS m: Ausnutzung von Michael-Gegenmaßnahmen**
|
||||
|
||||
Das Senden von zufälligen oder doppelten Paketen an verschiedene QoS-Warteschlangen kann Michael-Gegenmaßnahmen auf **TKIP APs** auslösen, was zu einer einminütigen Abschaltung des APs führt. Diese Methode ist eine effiziente Taktik für **DoS** (Denial of Service) Angriffe.
|
||||
Das Senden von zufälligen oder doppelten Paketen an verschiedene QoS-Warteschlangen kann Michael-Gegenmaßnahmen auf **TKIP-APs** auslösen, was zu einem einminütigen Shutdown des APs führt. Diese Methode ist eine effiziente Taktik für **DoS** (Denial of Service)-Angriffe.
|
||||
```bash
|
||||
# -t <BSSID> of a TKIP AP
|
||||
# -j use inteligent replay to create the DoS
|
||||
@ -158,7 +164,7 @@ mdk4 wlan0mon m -t EF:60:69:D7:69:2F [-j]
|
||||
```
|
||||
**ANGRIFFSMODUS e: EAPOL Start- und Logoff-Paket-Injektion**
|
||||
|
||||
Das Überfluten eines AP mit **EAPOL Start-Frames** erzeugt **falsche Sitzungen**, überlastet den AP und blockiert legitime Clients. Alternativ führt das Injizieren von **falschen EAPOL Logoff-Nachrichten** zu einer erzwungenen Trennung der Clients, wobei beide Methoden den Netzwerkdienst effektiv stören.
|
||||
Das Überfluten eines AP mit **EAPOL Start-Frames** erzeugt **falsche Sitzungen**, überwältigt den AP und blockiert legitime Clients. Alternativ führt das Injizieren von **falschen EAPOL Logoff-Nachrichten** zu einer erzwungenen Trennung der Clients; beide Methoden stören effektiv den Netzwerkdienst.
|
||||
```bash
|
||||
# Use Logoff messages to kick clients
|
||||
mdk4 wlan0mon e -t EF:60:69:D7:69:2F [-l]
|
||||
@ -186,7 +192,7 @@ _**Airgeddon**_ bietet die meisten der in den vorherigen Kommentaren vorgeschlag
|
||||
|
||||
## WPS
|
||||
|
||||
WPS (Wi-Fi Protected Setup) vereinfacht den Prozess der Verbindung von Geräten mit einem Router und verbessert die Einrichtungszeit und -einfachheit für Netzwerke, die mit **WPA** oder **WPA2** Personal verschlüsselt sind. Es ist ineffektiv für die leicht angreifbare WEP-Sicherheit. WPS verwendet eine 8-stellige PIN, die in zwei Hälften validiert wird, was es anfällig für Brute-Force-Angriffe macht, aufgrund der begrenzten Anzahl von Kombinationen (11.000 Möglichkeiten).
|
||||
WPS (Wi-Fi Protected Setup) vereinfacht den Prozess der Verbindung von Geräten mit einem Router und verbessert die Einrichtungsgeschwindigkeit und -einfachheit für Netzwerke, die mit **WPA** oder **WPA2** Personal verschlüsselt sind. Es ist ineffektiv für die leicht angreifbare WEP-Sicherheit. WPS verwendet eine 8-stellige PIN, die in zwei Hälften validiert wird, was es anfällig für Brute-Force-Angriffe macht, aufgrund der begrenzten Anzahl von Kombinationen (11.000 Möglichkeiten).
|
||||
|
||||
### WPS Bruteforce
|
||||
|
||||
@ -262,7 +268,7 @@ Wie der ursprüngliche Beitrag erklärt, wird das **PMKID** mit bekannten Daten
|
||||
```bash
|
||||
PMKID = HMAC-SHA1-128(PMK, "PMK Name" | MAC_AP | MAC_STA)
|
||||
```
|
||||
Angesichts der Tatsache, dass der "PMK Name" konstant ist, kennen wir die BSSID des AP und der Station, und das `PMK` identisch mit dem aus einem vollständigen 4-Wege-Handshake ist, kann **hashcat** diese Informationen nutzen, um den PSK zu knacken und das Passwort wiederherzustellen!
|
||||
Da der "PMK-Name" konstant ist, kennen wir die BSSID des AP und der Station, und das `PMK` identisch mit dem aus einem vollständigen 4-Wege-Handshake ist, kann **hashcat** diese Informationen nutzen, um den PSK zu knacken und das Passwort wiederherzustellen!
|
||||
|
||||
Um diese Informationen zu **sammeln** und das Passwort lokal zu **bruteforcen**, kannst du Folgendes tun:
|
||||
```bash
|
||||
@ -285,7 +291,7 @@ john hashes.txt --wordlist=/usr/share/wordlists/rockyou.txt
|
||||
```
|
||||
Bitte beachten Sie, dass das Format eines korrekten Hashs **4 Teile** enthält, wie: `4017733ca8db33a1479196c2415173beb808d7b83cfaa4a6a9a5aae7566f6461666f6e65436f6e6e6563743034383131343838`. Wenn Ihrer **nur** **3 Teile** enthält, ist er **ungültig** (der PMKID-Capture war nicht gültig).
|
||||
|
||||
Beachten Sie, dass `hcxdumptool` **auch Handshakes erfasst** (etwas wie dies wird erscheinen: **`MP:M1M2 RC:63258 EAPOLTIME:17091`**). Sie könnten die **Handshakes** in **hashcat**/**john**-Format mit `cap2hccapx` **transformieren**.
|
||||
Beachten Sie, dass `hcxdumptool` **auch Handshakes erfasst** (etwas wie dies wird erscheinen: **`MP:M1M2 RC:63258 EAPOLTIME:17091`**). Sie können die **Handshakes** in **hashcat**/**john**-Format mit `cap2hccapx` **umwandeln**.
|
||||
```bash
|
||||
tcpdump -r /tmp/attack.pcapng -w /tmp/att.pcap
|
||||
cap2hccapx pmkid.pcapng pmkid.hccapx ["Filter_ESSID"]
|
||||
@ -358,14 +364,14 @@ In **Enterprise-WiFi-Setups werden Sie auf verschiedene Authentifizierungsmethod
|
||||
- **PEAP-MSCHAPv2**: Oft als PEAP bezeichnet, kombiniert es den anfälligen MSCHAPv2 Challenge/Response-Mechanismus mit einem schützenden TLS-Tunnel.
|
||||
- **PEAP-EAP-TLS (oder PEAP-TLS)**: Ähnlich wie EAP-TLS, initiiert jedoch einen TLS-Tunnel, bevor Zertifikate ausgetauscht werden, und bietet eine zusätzliche Sicherheitsebene.
|
||||
|
||||
Weitere Informationen zu diesen Authentifizierungsmethoden finden Sie [hier](https://en.wikipedia.org/wiki/Extensible_Authentication_Protocol) und [hier](https://www.intel.com/content/www/us/en/support/articles/000006999/network-and-i-o/wireless-networking.html).
|
||||
Sie finden weitere Informationen zu diesen Authentifizierungsmethoden [hier](https://en.wikipedia.org/wiki/Extensible_Authentication_Protocol) und [hier](https://www.intel.com/content/www/us/en/support/articles/000006999/network-and-i-o/wireless-networking.html).
|
||||
|
||||
### Benutzername erfassen
|
||||
|
||||
Laut [https://tools.ietf.org/html/rfc3748#page-27](https://tools.ietf.org/html/rfc3748#page-27) sieht es so aus, als ob, wenn Sie **EAP** verwenden, die **"Identitäts"** **nachrichten** **unterstützt** werden müssen, und der **benutzername** wird im **"Response Identity"** Nachrichten im **Klartext** gesendet.
|
||||
Laut [https://tools.ietf.org/html/rfc3748#page-27](https://tools.ietf.org/html/rfc3748#page-27) sieht es so aus, als ob, wenn Sie **EAP** verwenden, die **"Identitäts"** **nachrichten** **unterstützt** werden müssen, und der **benutzername** wird in den **"Response Identity"** Nachrichten im **Klartext** gesendet.
|
||||
|
||||
Selbst bei Verwendung einer der sichersten Authentifizierungsmethoden: **PEAP-EAP-TLS**, ist es möglich, den **benutzernamen, der im EAP-Protokoll gesendet wird, zu erfassen**. Dazu **erfassen Sie eine Authentifizierungs Kommunikation** (starten Sie `airodump-ng` in einem Kanal und `wireshark` im selben Interface) und filtern Sie die Pakete nach `eapol`.\
|
||||
Im Paket "**Response, Identity**" wird der **benutzername** des Clients erscheinen.
|
||||
Selbst bei Verwendung einer der sichersten Authentifizierungsmethoden: **PEAP-EAP-TLS** ist es möglich, den **Benutzernamen, der im EAP-Protokoll gesendet wird, zu erfassen**. Dazu **erfassen Sie eine Authentifizierungs Kommunikation** (starten Sie `airodump-ng` in einem Kanal und `wireshark` im selben Interface) und filtern Sie die Pakete nach `eapol`.\
|
||||
Im Paket "**Response, Identity**" wird der **Benutzername** des Clients erscheinen.
|
||||
|
||||
.png>)
|
||||
|
||||
@ -373,27 +379,27 @@ Im Paket "**Response, Identity**" wird der **benutzername** des Clients erschein
|
||||
|
||||
Die Identitätsverbergung wird sowohl von EAP-PEAP als auch von EAP-TTLS unterstützt. Im Kontext eines WiFi-Netzwerks wird eine EAP-Identitätsanfrage typischerweise vom Access Point (AP) während des Assoziierungsprozesses initiiert. Um den Schutz der Anonymität der Benutzer zu gewährleisten, enthält die Antwort des EAP-Clients auf dem Gerät des Benutzers nur die wesentlichen Informationen, die der ursprüngliche RADIUS-Server benötigt, um die Anfrage zu verarbeiten. Dieses Konzept wird durch die folgenden Szenarien veranschaulicht:
|
||||
|
||||
- EAP-Identität = anonym
|
||||
- In diesem Szenario verwenden alle Benutzer das pseudonyme "anonym" als ihre Benutzerkennung. Der ursprüngliche RADIUS-Server fungiert entweder als EAP-PEAP- oder EAP-TTLS-Server, der für die Verwaltung der serverseitigen PEAP- oder TTLS-Protokolle verantwortlich ist. Die innere (geschützte) Authentifizierungsmethode wird dann entweder lokal behandelt oder an einen entfernten (Heim-)RADIUS-Server delegiert.
|
||||
- EAP-Identität = anonym@realm_x
|
||||
- EAP-Identity = anonym
|
||||
- In diesem Szenario verwenden alle Benutzer das pseudonyme "anonym" als ihre Benutzerkennung. Der ursprüngliche RADIUS-Server fungiert entweder als EAP-PEAP- oder EAP-TTLS-Server, der für die Verwaltung der serverseitigen PEAP- oder TTLS-Protokolle verantwortlich ist. Die innere (geschützte) Authentifizierungsmethode wird dann entweder lokal behandelt oder an einen entfernten (Heim-) RADIUS-Server delegiert.
|
||||
- EAP-Identity = anonym@realm_x
|
||||
- In dieser Situation verbergen Benutzer aus verschiedenen Bereichen ihre Identitäten, während sie ihre jeweiligen Bereiche angeben. Dies ermöglicht es dem ursprünglichen RADIUS-Server, die EAP-PEAP- oder EAP-TTLS-Anfragen an RADIUS-Server in ihren Heimatbereichen weiterzuleiten, die als PEAP- oder TTLS-Server fungieren. Der ursprüngliche RADIUS-Server fungiert ausschließlich als RADIUS-Relay-Knoten.
|
||||
- Alternativ kann der ursprüngliche RADIUS-Server als EAP-PEAP- oder EAP-TTLS-Server fungieren und entweder die geschützte Authentifizierungsmethode behandeln oder an einen anderen Server weiterleiten. Diese Option erleichtert die Konfiguration unterschiedlicher Richtlinien für verschiedene Bereiche.
|
||||
|
||||
In EAP-PEAP, sobald der TLS-Tunnel zwischen dem PEAP-Server und dem PEAP-Client eingerichtet ist, initiiert der PEAP-Server eine EAP-Identitätsanfrage und überträgt sie durch den TLS-Tunnel. Der Client antwortet auf diese zweite EAP-Identitätsanfrage, indem er eine EAP-Identitätsantwort sendet, die die wahre Identität des Benutzers durch den verschlüsselten Tunnel enthält. Dieser Ansatz verhindert effektiv die Offenlegung der tatsächlichen Identität des Benutzers gegenüber jedem, der den 802.11-Verkehr abhört.
|
||||
|
||||
EAP-TTLS folgt einem etwas anderen Verfahren. Bei EAP-TTLS authentifiziert sich der Client typischerweise mit PAP oder CHAP, gesichert durch den TLS-Tunnel. In diesem Fall enthält der Client ein User-Name-Attribut und entweder ein Password- oder CHAP-Password-Attribut in der ersten TLS-Nachricht, die nach der Tunnelherstellung gesendet wird.
|
||||
EAP-TTLS folgt einem etwas anderen Verfahren. Bei EAP-TTLS authentifiziert sich der Client typischerweise mit PAP oder CHAP, gesichert durch den TLS-Tunnel. In diesem Fall enthält der Client ein User-Name-Attribut und entweder ein Password- oder CHAP-Password-Attribut in der ersten TLS-Nachricht, die nach der Tunnel-Einrichtung gesendet wird.
|
||||
|
||||
Unabhängig vom gewählten Protokoll erlangt der PEAP/TTLS-Server Kenntnis von der wahren Identität des Benutzers, nachdem der TLS-Tunnel eingerichtet wurde. Die wahre Identität kann als user@realm oder einfach als user dargestellt werden. Wenn der PEAP/TTLS-Server auch für die Authentifizierung des Benutzers verantwortlich ist, besitzt er nun die Identität des Benutzers und fährt mit der durch den TLS-Tunnel geschützten Authentifizierungsmethode fort. Alternativ kann der PEAP/TTLS-Server eine neue RADIUS-Anfrage an den Heim-RADIUS-Server des Benutzers weiterleiten. Diese neue RADIUS-Anfrage lässt die PEAP- oder TTLS-Protokollschicht weg. In Fällen, in denen die geschützte Authentifizierungsmethode EAP ist, werden die inneren EAP-Nachrichten ohne die EAP-PEAP- oder EAP-TTLS-Hülle an den Heim-RADIUS-Server übertragen. Das User-Name-Attribut der ausgehenden RADIUS-Nachricht enthält die wahre Identität des Benutzers und ersetzt den anonymen User-Name aus der eingehenden RADIUS-Anfrage. Wenn die geschützte Authentifizierungsmethode PAP oder CHAP (nur von TTLS unterstützt) ist, werden das User-Name-Attribut und andere Authentifizierungsattribute, die aus der TLS-Nutzlast extrahiert wurden, in der ausgehenden RADIUS-Nachricht ersetzt, wodurch der anonyme User-Name und die TTLS EAP-Message-Attribute aus der eingehenden RADIUS-Anfrage verdrängt werden.
|
||||
Unabhängig vom gewählten Protokoll erlangt der PEAP/TTLS-Server Kenntnis von der wahren Identität des Benutzers, nachdem der TLS-Tunnel eingerichtet wurde. Die wahre Identität kann als user@realm oder einfach user dargestellt werden. Wenn der PEAP/TTLS-Server auch für die Authentifizierung des Benutzers verantwortlich ist, besitzt er nun die Identität des Benutzers und fährt mit der durch den TLS-Tunnel geschützten Authentifizierungsmethode fort. Alternativ kann der PEAP/TTLS-Server eine neue RADIUS-Anfrage an den Heim-RADIUS-Server des Benutzers weiterleiten. Diese neue RADIUS-Anfrage lässt die PEAP- oder TTLS-Protokollebene weg. In Fällen, in denen die geschützte Authentifizierungsmethode EAP ist, werden die inneren EAP-Nachrichten ohne die PEAP- oder EAP-TTLS-Hülle an den Heim-RADIUS-Server übertragen. Das User-Name-Attribut der ausgehenden RADIUS-Nachricht enthält die wahre Identität des Benutzers und ersetzt den anonymen User-Name aus der eingehenden RADIUS-Anfrage. Wenn die geschützte Authentifizierungsmethode PAP oder CHAP (nur von TTLS unterstützt) ist, werden das User-Name-Attribut und andere Authentifizierungsattribute, die aus der TLS-Nutzlast extrahiert wurden, in der ausgehenden RADIUS-Nachricht ersetzt, wodurch der anonyme User-Name und die TTLS EAP-Message-Attribute aus der eingehenden RADIUS-Anfrage verdrängt werden.
|
||||
|
||||
Für weitere Informationen siehe [https://www.interlinknetworks.com/app_notes/eap-peap.htm](https://www.interlinknetworks.com/app_notes/eap-peap.htm)
|
||||
|
||||
### EAP-Bruteforce (Password Spray)
|
||||
|
||||
Wenn vom Client erwartet wird, dass er einen **Benutzernamen und ein Passwort** verwendet (beachten Sie, dass **EAP-TLS in diesem Fall nicht gültig sein wird**), könnten Sie versuchen, eine **Liste** von **Benutzernamen** (siehe nächsten Teil) und **Passwörtern** zu erhalten und versuchen, den Zugang mit [**air-hammer**](https://github.com/Wh1t3Rh1n0/air-hammer)** zu **bruteforcen**.
|
||||
Wenn vom Client erwartet wird, dass er einen **Benutzernamen und ein Passwort** verwendet (beachten Sie, dass **EAP-TLS in diesem Fall nicht gültig ist**), könnten Sie versuchen, eine **Liste** von **Benutzernamen** (siehe nächster Teil) und **Passwörtern** zu erhalten und versuchen, den Zugang mit [**air-hammer**](https://github.com/Wh1t3Rh1n0/air-hammer)** zu **bruteforcen**.
|
||||
```bash
|
||||
./air-hammer.py -i wlan0 -e Test-Network -P UserPassword1 -u usernames.txt
|
||||
```
|
||||
Sie könnten diesen Angriff auch mit `eaphammer` durchführen:
|
||||
Du könntest diesen Angriff auch mit `eaphammer` durchführen:
|
||||
```bash
|
||||
./eaphammer --eap-spray \
|
||||
--interface-pool wlan0 wlan1 wlan2 wlan3 wlan4 \
|
||||
@ -407,16 +413,16 @@ Sie könnten diesen Angriff auch mit `eaphammer` durchführen:
|
||||
|
||||
- Das 802.11-Protokoll definiert, wie eine Station einem Extended Service Set (ESS) beitritt, spezifiziert jedoch nicht die Kriterien zur Auswahl eines ESS oder eines Access Points (AP) innerhalb davon.
|
||||
- Stationen können zwischen APs, die dasselbe ESSID teilen, umherwandern und die Konnektivität über ein Gebäude oder Gebiet aufrechterhalten.
|
||||
- Das Protokoll erfordert die Authentifizierung der Station zum ESS, schreibt jedoch keine Authentifizierung des APs zur Station vor.
|
||||
- Das Protokoll erfordert die Authentifizierung der Station zum ESS, verlangt jedoch keine Authentifizierung des APs zur Station.
|
||||
|
||||
### Bevorzugte Netzwerklisten (PNLs)
|
||||
|
||||
- Stationen speichern die ESSID jedes drahtlosen Netzwerks, mit dem sie sich verbinden, in ihrer Bevorzugten Netzwerk Liste (PNL), zusammen mit netzwerkspezifischen Konfigurationsdetails.
|
||||
- Die PNL wird verwendet, um automatisch eine Verbindung zu bekannten Netzwerken herzustellen, was die Benutzererfahrung verbessert, indem der Verbindungsprozess optimiert wird.
|
||||
|
||||
### Passive Scans
|
||||
### Passive Scanning
|
||||
|
||||
- APs senden regelmäßig Beacon-Frames aus, die ihre Präsenz und Merkmale ankündigen, einschließlich der ESSID des APs, es sei denn, das Broadcasting ist deaktiviert.
|
||||
- APs senden regelmäßig Beacon-Frames aus, um ihre Präsenz und Merkmale anzukündigen, einschließlich der ESSID des APs, es sei denn, das Broadcasting ist deaktiviert.
|
||||
- Während des passiven Scannens hören Stationen auf Beacon-Frames. Wenn die ESSID eines Beacons mit einem Eintrag in der PNL der Station übereinstimmt, kann die Station automatisch eine Verbindung zu diesem AP herstellen.
|
||||
- Das Wissen um die PNL eines Geräts ermöglicht potenzielle Ausnutzung, indem die ESSID eines bekannten Netzwerks nachgeahmt wird, um das Gerät dazu zu bringen, sich mit einem bösartigen AP zu verbinden.
|
||||
|
||||
@ -428,9 +434,9 @@ Sie könnten diesen Angriff auch mit `eaphammer` durchführen:
|
||||
|
||||
## Einfacher AP mit Umleitung ins Internet
|
||||
|
||||
Bevor erklärt wird, wie man komplexere Angriffe durchführt, wird erklärt, **wie** man einfach einen **AP** erstellt und seinen **Verkehr** an eine Schnittstelle umleitet, die **mit** dem **Internet** verbunden ist.
|
||||
Bevor erklärt wird, wie man komplexere Angriffe durchführt, wird erklärt, **wie** man einfach einen **AP** erstellt und seinen **Verkehr** an eine mit dem **Internet** verbundene Schnittstelle **umleitet**.
|
||||
|
||||
Verwenden Sie `ifconfig -a`, um zu überprüfen, ob die wlan-Schnittstelle zum Erstellen des AP und die Schnittstelle, die mit dem Internet verbunden ist, vorhanden sind.
|
||||
Verwenden Sie `ifconfig -a`, um zu überprüfen, ob die wlan-Schnittstelle zum Erstellen des AP und die mit dem Internet verbundene Schnittstelle vorhanden sind.
|
||||
|
||||
### DHCP & DNS
|
||||
```bash
|
||||
@ -448,7 +454,7 @@ log-queries
|
||||
log-dhcp
|
||||
listen-address=127.0.0.1
|
||||
```
|
||||
Dann **setzen Sie IPs** und **Routen**:
|
||||
Dann **IP-Adressen** und **Routen** festlegen:
|
||||
```bash
|
||||
ifconfig wlan0 up 192.168.1.1 netmask 255.255.255.0
|
||||
route add -net 192.168.1.0 netmask 255.255.255.0 gw 192.168.1.1
|
||||
@ -504,7 +510,7 @@ Sie können einen sehr einfachen Open Evil Twin (ohne die Möglichkeit, den Date
|
||||
```bash
|
||||
airbase-ng -a 00:09:5B:6F:64:1E --essid "Elroy" -c 1 wlan0mon
|
||||
```
|
||||
Sie könnten auch einen Evil Twin mit **eaphammer** erstellen (beachten Sie, dass die Schnittstelle **NICHT** im **Monitor**-Modus sein **sollte**):
|
||||
Sie können auch einen Evil Twin mit **eaphammer** erstellen (beachten Sie, dass die Schnittstelle **NICHT** im **Monitor**-Modus sein **sollte**):
|
||||
```bash
|
||||
./eaphammer -i wlan0 --essid exampleCorp --captive-portal
|
||||
```
|
||||
@ -512,13 +518,13 @@ Oder mit Airgeddon: `Optionen: 5,6,7,8,9 (im Evil Twin Angriffsmenü).`
|
||||
|
||||
.png>)
|
||||
|
||||
Bitte beachten Sie, dass standardmäßig, wenn ein ESSID im PNL als WPA-geschützt gespeichert ist, das Gerät sich nicht automatisch mit einem offenen Evil Twin verbindet. Sie können versuchen, den echten AP zu DoS'en und hoffen, dass der Benutzer manuell mit Ihrem offenen Evil Twin verbindet, oder Sie könnten den echten AP DoS'en und einen WPA Evil Twin verwenden, um den Handshake zu erfassen (mit dieser Methode können Sie das Opfer nicht zu Ihnen verbinden, da Sie den PSK nicht kennen, aber Sie können den Handshake erfassen und versuchen, ihn zu knacken).
|
||||
Bitte beachten Sie, dass standardmäßig, wenn ein ESSID im PNL als WPA-geschützt gespeichert ist, das Gerät sich nicht automatisch mit einem offenen Evil Twin verbindet. Sie können versuchen, den echten AP zu DoS und hoffen, dass der Benutzer manuell mit Ihrem offenen Evil Twin verbindet, oder Sie könnten den echten AP DoS und einen WPA Evil Twin verwenden, um den Handshake zu erfassen (mit dieser Methode können Sie das Opfer nicht zu Ihnen verbinden, da Sie den PSK nicht kennen, aber Sie können den Handshake erfassen und versuchen, ihn zu knacken).
|
||||
|
||||
_Einige Betriebssysteme und Antivirenprogramme warnen den Benutzer, dass die Verbindung zu einem offenen Netzwerk gefährlich ist..._
|
||||
|
||||
### WPA/WPA2 Evil Twin
|
||||
|
||||
Sie können einen **Evil Twin mit WPA/2** erstellen, und wenn die Geräte so konfiguriert sind, dass sie sich mit diesem SSID über WPA/2 verbinden, werden sie versuchen, sich zu verbinden. Um den **4-Wege-Handshake abzuschließen**, müssen Sie auch das **Passwort** kennen, das der Client verwenden wird. Wenn Sie es **nicht wissen**, wird die **Verbindung nicht abgeschlossen**.
|
||||
Sie können einen **Evil Twin mit WPA/2** erstellen, und wenn die Geräte so konfiguriert sind, dass sie sich mit diesem SSID mit WPA/2 verbinden, werden sie versuchen, sich zu verbinden. Auf jeden Fall müssen Sie **auch wissen**, das **Passwort**, das der Client verwenden wird, um den **4-Wege-Handshake** abzuschließen. Wenn Sie es **nicht wissen**, wird die **Verbindung nicht abgeschlossen**.
|
||||
```bash
|
||||
./eaphammer -i wlan0 -e exampleCorp -c 11 --creds --auth wpa-psk --wpa-passphrase "mywifipassword"
|
||||
```
|
||||
@ -533,9 +539,9 @@ Um diese Angriffe zu verstehen, empfehle ich, vorher die kurze [WPA Enterprise E
|
||||
./apd_launchpad.py -t victim -s PrivateSSID -i wlan0 -cn company.com
|
||||
hostapd-wpe ./victim/victim.conf -s
|
||||
```
|
||||
In der Konfigurationsdatei können Sie viele verschiedene Dinge auswählen, wie SSID, Kanal, Benutzerdateien, cret/key, dh-Parameter, WPA-Version und Auth...
|
||||
In der Konfigurationsdatei können Sie viele verschiedene Dinge auswählen, wie ssid, Kanal, Benutzerdateien, cret/key, dh-Parameter, wpa-Version und Auth...
|
||||
|
||||
[**Verwendung von hostapd-wpe mit EAP-TLS, um jede Zertifizierung anzumelden.**](evil-twin-eap-tls.md)
|
||||
[**Verwendung von hostapd-wpe mit EAP-TLS, um jedes Zertifikat zur Anmeldung zuzulassen.**](evil-twin-eap-tls.md)
|
||||
|
||||
**Verwendung von EAPHammer**
|
||||
```bash
|
||||
@ -549,15 +555,15 @@ Standardmäßig zielt EAPHammer auf diese Authentifizierungsmethoden ab (beachte
|
||||
```
|
||||
GTC,MSCHAPV2,TTLS-MSCHAPV2,TTLS,TTLS-CHAP,TTLS-PAP,TTLS-MSCHAP,MD5
|
||||
```
|
||||
Dies ist die Standardmethodik, um lange Verbindungszeiten zu vermeiden. Sie können jedoch auch die Authentifizierungsmethoden vom schwächsten zum stärksten angeben:
|
||||
Dies ist die Standardmethodik, um lange Verbindungszeiten zu vermeiden. Sie können jedoch auch angeben, die Authentifizierungsmethoden von der schwächsten bis zur stärksten zu servieren:
|
||||
```
|
||||
--negotiate weakest
|
||||
```
|
||||
Oder Sie könnten auch verwenden:
|
||||
|
||||
- `--negotiate gtc-downgrade`, um eine hocheffiziente GTC-Downgrade-Implementierung (Klartext-Passwörter) zu verwenden.
|
||||
- `--negotiate manual --phase-1-methods PEAP,TTLS --phase-2-methods MSCHAPV2,GTC,TTLS-PAP`, um die angebotenen Methoden manuell anzugeben (wenn die gleichen Authentifizierungsmethoden in der gleichen Reihenfolge wie die Organisation angeboten werden, wird der Angriff viel schwieriger zu erkennen sein).
|
||||
- [Finden Sie weitere Informationen im Wiki](http://solstice.sh/wireless/eaphammer/2019/09/10/eap-downgrade-attacks/)
|
||||
- `--negotiate manual --phase-1-methods PEAP,TTLS --phase-2-methods MSCHAPV2,GTC,TTLS-PAP`, um die angebotenen Methoden manuell anzugeben (das Anbieten der gleichen Authentifizierungsmethoden in der gleichen Reihenfolge wie die Organisation macht den Angriff viel schwieriger zu erkennen).
|
||||
- [Weitere Informationen im Wiki finden](http://solstice.sh/wireless/eaphammer/2019/09/10/eap-downgrade-attacks/)
|
||||
|
||||
**Verwendung von Airgeddon**
|
||||
|
||||
@ -566,7 +572,7 @@ Oder Sie könnten auch verwenden:
|
||||
|
||||
.png>)
|
||||
|
||||
### Debugging von PEAP und EAP-TTLS TLS-Tunneln in Evil Twin-Angriffen
|
||||
### Debugging von PEAP und EAP-TTLS TLS-Tunneln bei Evil Twin-Angriffen
|
||||
|
||||
_Diese Methode wurde in einer PEAP-Verbindung getestet, aber da ich einen beliebigen TLS-Tunnel entschlüssele, sollte dies auch mit EAP-TTLS funktionieren._
|
||||
|
||||
@ -585,20 +591,20 @@ Und schauen Sie sich den neuen **"Decrypted TLS"-Tab** an:
|
||||
|
||||
.png>)
|
||||
|
||||
## KARMA, MANA, Loud MANA und Angriffe mit bekannten Beacons
|
||||
## KARMA, MANA, Laut MANA und Bekannte Beacon-Angriffe
|
||||
|
||||
### ESSID- und MAC-Black/Whitelists
|
||||
### ESSID- und MAC-Blacklist/Whitelist
|
||||
|
||||
Verschiedene Arten von Media Access Control Filterlisten (MFACLs) und deren entsprechende Modi und Auswirkungen auf das Verhalten eines bösartigen Access Points (AP):
|
||||
|
||||
1. **MAC-basierte Whitelist**:
|
||||
- Der bösartige AP antwortet nur auf Probeanfragen von Geräten, die in der Whitelist angegeben sind, und bleibt für alle anderen, die nicht aufgeführt sind, unsichtbar.
|
||||
- Der bösartige AP antwortet nur auf Abfrageanfragen von Geräten, die in der Whitelist angegeben sind, und bleibt für alle anderen, die nicht aufgeführt sind, unsichtbar.
|
||||
2. **MAC-basierte Blacklist**:
|
||||
- Der bösartige AP ignoriert Probeanfragen von Geräten auf der Blacklist, wodurch der bösartige AP für diese spezifischen Geräte unsichtbar wird.
|
||||
- Der bösartige AP ignoriert Abfrageanfragen von Geräten auf der Blacklist, wodurch der bösartige AP für diese spezifischen Geräte unsichtbar wird.
|
||||
3. **SSID-basierte Whitelist**:
|
||||
- Der bösartige AP antwortet nur auf Probeanfragen für spezifische ESSIDs, die aufgelistet sind, und bleibt für Geräte, deren bevorzugte Netzwerklisten (PNLs) diese ESSIDs nicht enthalten, unsichtbar.
|
||||
- Der bösartige AP antwortet nur auf Abfrageanfragen für spezifische ESSIDs, die aufgelistet sind, und bleibt unsichtbar für Geräte, deren Bevorzugte Netzwerklisten (PNLs) diese ESSIDs nicht enthalten.
|
||||
4. **SSID-basierte Blacklist**:
|
||||
- Der bösartige AP antwortet nicht auf Probeanfragen für die spezifischen ESSIDs auf der Blacklist, wodurch er für Geräte, die nach diesen bestimmten Netzwerken suchen, unsichtbar wird.
|
||||
- Der bösartige AP antwortet nicht auf Abfrageanfragen für die spezifischen ESSIDs auf der Blacklist, wodurch er für Geräte, die nach diesen bestimmten Netzwerken suchen, unsichtbar wird.
|
||||
```bash
|
||||
# example EAPHammer MFACL file, wildcards can be used
|
||||
09:6a:06:c8:36:af
|
||||
@ -638,9 +644,9 @@ Ein **Loud MANA-Angriff** ist eine fortgeschrittene Strategie, wenn Geräte kein
|
||||
```
|
||||
### Bekannter Beacon-Angriff
|
||||
|
||||
Wenn der **Loud MANA Angriff** möglicherweise nicht ausreicht, bietet der **Bekannte Beacon-Angriff** einen weiteren Ansatz. Diese Methode **brute-forced den Verbindungsprozess, indem sie einen AP simuliert, der auf jeden Netzwerknamen reagiert und durch eine Liste potenzieller ESSIDs aus einer Wortliste wechselt**. Dies simuliert die Anwesenheit zahlreicher Netzwerke, in der Hoffnung, eine ESSID innerhalb der PNL des Opfers zu treffen, was einen Verbindungsversuch zum gefälschten AP auslöst. Der Angriff kann verstärkt werden, indem er mit der `--loud` Option kombiniert wird, um einen aggressiveren Versuch zu unternehmen, Geräte zu fangen.
|
||||
Wenn der **Loud MANA Angriff** möglicherweise nicht ausreicht, bietet der **Bekannte Beacon-Angriff** einen weiteren Ansatz. Diese Methode **brute-forced den Verbindungsprozess, indem sie einen AP simuliert, der auf jeden Netzwerknamen reagiert und durch eine Liste potenzieller ESSIDs aus einer Wortliste wechselt**. Dies simuliert die Präsenz zahlreicher Netzwerke, in der Hoffnung, eine ESSID innerhalb der PNL des Opfers zu treffen, was einen Verbindungsversuch zum gefälschten AP auslöst. Der Angriff kann verstärkt werden, indem er mit der `--loud` Option kombiniert wird, um einen aggressiveren Versuch zu unternehmen, Geräte zu fangen.
|
||||
|
||||
Eaphammer hat diesen Angriff als MANA-Angriff implementiert, bei dem alle ESSIDs in einer Liste geladen werden (Sie könnten dies auch mit `--loud` kombinieren, um einen Loud MANA + Bekannte Beacons Angriff zu erstellen):
|
||||
Eaphammer hat diesen Angriff als MANA-Angriff implementiert, bei dem alle ESSIDs in einer Liste geladen werden (du könntest dies auch mit `--loud` kombinieren, um einen Loud MANA + Bekannte Beacons Angriff zu erstellen):
|
||||
```bash
|
||||
./eaphammer -i wlan0 --mana [--loud] --known-beacons --known-ssids-file wordlist.txt [--captive-portal] [--auth wpa-psk --creds]
|
||||
```
|
||||
@ -669,7 +675,7 @@ Diese Methoden, insbesondere die PIN-Eingabe, sind anfällig für die gleichen S
|
||||
|
||||
### EvilDirect Hijacking
|
||||
|
||||
**EvilDirect Hijacking** ist ein Angriff, der spezifisch auf Wi-Fi Direct abzielt. Er spiegelt das Konzept eines Evil Twin-Angriffs wider, zielt jedoch auf Wi-Fi Direct-Verbindungen ab. In diesem Szenario gibt sich ein Angreifer als legitimer Gruppenbesitzer aus, um Geräte zu täuschen, damit sie sich mit einer bösartigen Entität verbinden. Diese Methode kann mit Tools wie `airbase-ng` ausgeführt werden, indem der Kanal, ESSID und MAC-Adresse des impersonierten Geräts angegeben werden:
|
||||
**EvilDirect Hijacking** ist ein Angriff, der spezifisch auf Wi-Fi Direct abzielt. Er spiegelt das Konzept eines Evil Twin-Angriffs wider, zielt jedoch auf Wi-Fi Direct-Verbindungen ab. In diesem Szenario gibt sich ein Angreifer als legitimer Gruppenbesitzer aus, um Geräte zu täuschen, sich mit einer bösartigen Entität zu verbinden. Diese Methode kann mit Tools wie `airbase-ng` ausgeführt werden, indem der Kanal, ESSID und MAC-Adresse des impersonierten Geräts angegeben werden:
|
||||
|
||||
## References
|
||||
|
||||
|
||||
@ -0,0 +1,128 @@
|
||||
# Aktivieren des NexMon-Monitor-Modus & Paket-Injektion auf Android (Broadcom-Chips)
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
## Übersicht
|
||||
Die meisten modernen Android-Handys verfügen über einen Broadcom/Cypress-Wi-Fi-Chipsatz, der ohne 802.11-Monitor-Modus oder Frame-Injektionsfähigkeiten ausgeliefert wird. Das Open-Source-NexMon-Framework patcht die proprietäre Firmware, um diese Funktionen hinzuzufügen, und stellt sie über eine Shared Library (`libnexmon.so`) und einen CLI-Helfer (`nexutil`) zur Verfügung. Durch das Vorladen dieser Bibliothek in den Standard-Wi-Fi-Treiber kann ein gerootetes Gerät rohen 802.11-Verkehr erfassen und beliebige Frames injizieren – was die Notwendigkeit eines externen USB-Adapters beseitigt.
|
||||
|
||||
Diese Seite dokumentiert einen schnellen Workflow, der ein vollständig gepatchtes Samsung Galaxy S10 (BCM4375B1) als Beispiel verwendet, mit:
|
||||
|
||||
* NexMon Magisk-Modul, das die gepatchte Firmware + `libnexmon.so` enthält
|
||||
* Hijacker Android-Anwendung zur Automatisierung des Umschaltens des Monitor-Modus
|
||||
* Optional Kali NetHunter chroot, um klassische drahtlose Tools (aircrack-ng, wifite, mdk4 …) direkt gegen die interne Schnittstelle auszuführen
|
||||
|
||||
Die gleiche Technik gilt für jedes Handy, das einen öffentlich verfügbaren NexMon-Patch hat (Pixel 1, Nexus 6P, Galaxy S7/S8 usw.).
|
||||
|
||||
---
|
||||
|
||||
## Voraussetzungen
|
||||
* Android-Handy mit einem unterstützten Broadcom/Cypress-Chipsatz (z. B. BCM4358/59/43596/4375B1)
|
||||
* Root mit Magisk ≥ 24
|
||||
* BusyBox (die meisten ROMs/NetHunter enthalten es bereits)
|
||||
* NexMon Magisk ZIP oder selbstkompilierten Patch, der bereitstellt:
|
||||
* `/system/lib*/libnexmon.so`
|
||||
* `/system/xbin/nexutil`
|
||||
* Hijacker ≥ 1.7 (arm/arm64) – https://github.com/chrisk44/Hijacker
|
||||
* (Optional) Kali NetHunter oder ein beliebiges Linux chroot, in dem Sie drahtlose Tools ausführen möchten
|
||||
|
||||
---
|
||||
|
||||
## Flashen des NexMon-Patches (Magisk)
|
||||
1. Laden Sie die ZIP für Ihr genaues Gerät/Firmware herunter (Beispiel: `nexmon-s10.zip`).
|
||||
2. Öffnen Sie Magisk -> Module -> Aus Speicher installieren -> wählen Sie die ZIP aus und starten Sie neu.
|
||||
Das Modul kopiert `libnexmon.so` in `/data/adb/modules/<module>/lib*/` und stellt sicher, dass die SELinux-Labels korrekt sind.
|
||||
3. Überprüfen Sie die Installation:
|
||||
```bash
|
||||
ls -lZ $(find / -name libnexmon.so 2>/dev/null)
|
||||
sha1sum $(which nexutil)
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Konfigurieren von Hijacker
|
||||
Hijacker kann den Monitor-Modus automatisch umschalten, bevor `airodump`, `wifite` usw. ausgeführt werden. Fügen Sie in **Einstellungen -> Erweitert** die folgenden Einträge hinzu (bearbeiten Sie den Bibliothekspfad, wenn Ihr Modul abweicht):
|
||||
```
|
||||
Prefix:
|
||||
LD_PRELOAD=/data/user/0/com.hijacker/files/lib/libnexmon.so
|
||||
|
||||
Enable monitor mode:
|
||||
svc wifi disable; ifconfig wlan0 up; nexutil -s0x613 -i -v2
|
||||
|
||||
Disable monitor mode:
|
||||
nexutil -m0; svc wifi enable
|
||||
```
|
||||
Aktivieren Sie „Monitor-Modus beim Start von airodump starten“, damit jeder Hijacker-Scan im nativen Monitor-Modus erfolgt (`wlan0` anstelle von `wlan0mon`).
|
||||
|
||||
Wenn Hijacker beim Start Fehler anzeigt, erstellen Sie das erforderliche Verzeichnis im gemeinsamen Speicher und öffnen Sie die App erneut:
|
||||
```bash
|
||||
mkdir -p /storage/emulated/0/Hijacker
|
||||
```
|
||||
### Was bedeuten diese `nexutil`-Flags?
|
||||
* **`-s0x613`** Schreibe Firmware-Variable 0x613 (FCAP_FRAME_INJECTION) → `1` (Aktivieren des TX von beliebigen Frames).
|
||||
* **`-i`** Setze das Interface in den Monitor-Modus (Radiotap-Header wird hinzugefügt).
|
||||
* **`-v2`** Setze die Ausführlichkeitsebene; `2` druckt Bestätigung und Firmware-Version.
|
||||
* **`-m0`** Stelle den verwalteten Modus wieder her (wird im *disable*-Befehl verwendet).
|
||||
|
||||
Nach dem Ausführen von *Enable monitor mode* solltest du das Interface im Monitor-Zustand sehen und in der Lage sein, rohe Frames mit:
|
||||
```bash
|
||||
airodump-ng --band abg wlan0
|
||||
```
|
||||
---
|
||||
|
||||
## Manuelle Einzeile (ohne Hijacker)
|
||||
```bash
|
||||
# Enable monitor + injection
|
||||
svc wifi disable && ifconfig wlan0 up && nexutil -s0x613 -i -v2
|
||||
|
||||
# Disable and return to normal Wi-Fi
|
||||
nexutil -m0 && svc wifi enable
|
||||
```
|
||||
Wenn Sie nur passives Sniffing benötigen, lassen Sie das `-s0x613` Flag weg.
|
||||
|
||||
---
|
||||
|
||||
## Verwendung von `libnexmon` in Kali NetHunter / chroot
|
||||
Standardbenutzerwerkzeuge in Kali kennen NexMon nicht, aber Sie können sie zwingen, es über `LD_PRELOAD` zu verwenden:
|
||||
|
||||
1. Kopieren Sie das vorgebaute Shared Object in das chroot:
|
||||
```bash
|
||||
cp /sdcard/Download/kalilibnexmon.so <chroot>/lib/
|
||||
```
|
||||
2. Aktivieren Sie den Monitor-Modus vom **Android-Host** (Befehl oben oder über Hijacker).
|
||||
3. Starten Sie ein beliebiges drahtloses Tool in Kali mit dem Preload:
|
||||
```bash
|
||||
sudo su
|
||||
export LD_PRELOAD=/lib/kalilibnexmon.so
|
||||
wifite -i wlan0 # oder aircrack-ng, mdk4 …
|
||||
```
|
||||
4. Deaktivieren Sie den Monitor-Modus wie gewohnt auf Android, wenn Sie fertig sind.
|
||||
|
||||
Da die Firmware bereits die Radiotap-Injektion verarbeitet, verhalten sich Benutzerwerkzeuge genau wie bei einem externen Atheros-Adapter.
|
||||
|
||||
---
|
||||
|
||||
## Typische Angriffe möglich
|
||||
Sobald Monitor + TX aktiv ist, können Sie:
|
||||
* WPA(2/3-SAE) Handshakes oder PMKID mit `wifite`, `hcxdumptool`, `airodump-ng` erfassen.
|
||||
* Deauthentifizierungs-/Dissoziationsrahmen injizieren, um Clients zum Wiederverbinden zu zwingen.
|
||||
* Beliebige Management-/Datenrahmen mit `mdk4`, `aireplay-ng`, Scapy usw. erstellen.
|
||||
* Rogue APs erstellen oder KARMA/MANA-Angriffe direkt vom Telefon ausführen.
|
||||
|
||||
Die Leistung auf dem Galaxy S10 ist vergleichbar mit externen USB NICs (~20 dBm TX, 2-3 M pps RX).
|
||||
|
||||
---
|
||||
|
||||
## Fehlersuche
|
||||
* `Device or resource busy` – stellen Sie sicher, dass der **Android-WLAN-Dienst deaktiviert ist** (`svc wifi disable`), bevor Sie den Monitor-Modus aktivieren.
|
||||
* `nexutil: ioctl(PRIV_MAGIC) failed` – die Bibliothek ist nicht vorab geladen; überprüfen Sie den `LD_PRELOAD`-Pfad.
|
||||
* Rahmeninjektion funktioniert, aber keine Pakete erfasst – einige ROMs blockieren Kanäle hart; versuchen Sie `nexutil -c <channel>` oder `iwconfig wlan0 channel <n>`.
|
||||
* SELinux blockiert die Bibliothek – setzen Sie das Gerät auf *Permissive* oder beheben Sie den Modulkontext: `chcon u:object_r:system_lib_file:s0 libnexmon.so`.
|
||||
|
||||
---
|
||||
|
||||
## Referenzen
|
||||
* [Hijacker auf dem Samsung Galaxy S10 mit drahtloser Injektion](https://forums.kali.org/t/hijacker-on-the-samsung-galaxy-s10-with-wireless-injection/10305)
|
||||
* [NexMon – Firmware-Patching-Framework](https://github.com/seemoo-lab/nexmon)
|
||||
* [Hijacker (aircrack-ng GUI für Android)](https://github.com/chrisk44/Hijacker)
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
Loading…
x
Reference in New Issue
Block a user