diff --git a/src/SUMMARY.md b/src/SUMMARY.md index a8361fb1f..93b6e3273 100644 --- a/src/SUMMARY.md +++ b/src/SUMMARY.md @@ -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) diff --git a/src/generic-methodologies-and-resources/pentesting-wifi/README.md b/src/generic-methodologies-and-resources/pentesting-wifi/README.md index 23cac77c1..4a91af0b3 100644 --- a/src/generic-methodologies-and-resources/pentesting-wifi/README.md +++ b/src/generic-methodologies-and-resources/pentesting-wifi/README.md @@ -19,6 +19,12 @@ iwlist wlan0 scan #Scan available wifis ``` ## Strumenti +### Hijacker & NexMon (Wi-Fi interno Android) + +{{#ref}} +enable-nexmon-monitor-and-injection-on-android.md +{{#endref}} + ### EAPHammer ``` git clone https://github.com/s0lst1c3/eaphammer.git @@ -56,10 +62,10 @@ sudo python setup.py install # Install any dependencies Questo strumento automatizza gli attacchi **WPS/WEP/WPA-PSK**. Esso automaticamente: - Imposta l'interfaccia in modalità monitor -- Scansiona per possibili reti - E ti consente di selezionare la vittima(o) +- Scansiona per possibili reti - E ti consente di selezionare la vittima/e - Se WEP - Lancia attacchi WEP - Se WPA-PSK -- Se WPS: attacco Pixie dust e attacco di bruteforce (fai attenzione, l'attacco di bruteforce potrebbe richiedere molto tempo). Nota che non prova PIN nulli o PIN generati da database. +- Se WPS: attacco Pixie dust e attacco di bruteforce (fai attenzione, l'attacco di bruteforce potrebbe richiedere molto tempo). Nota che non prova PIN nulli o PIN generati/database. - Prova a catturare il PMKID dall'AP per decifrarlo - Prova a disautenticare i client dell'AP per catturare un handshake - Se PMKID o Handshake, prova a bruteforce usando le prime 5000 password. @@ -136,7 +142,7 @@ mdk4 wlan0mon b -a -w nta -m ``` **MODALITÀ D'ATTACCO a: Denial-Of-Service di Autenticazione** -Inviare frame di autenticazione a tutti i punti di accesso (AP) accessibili entro portata può sovraccaricare questi AP, specialmente quando sono coinvolti numerosi client. Questo traffico intenso può portare a instabilità del sistema, causando il blocco o persino il ripristino di alcuni AP. +Inviare frame di autenticazione a tutti i punti di accesso (AP) accessibili entro portata può sovraccaricare questi AP, specialmente quando sono coinvolti numerosi client. Questo traffico intenso può portare a instabilità del sistema, causando il blocco o persino il riavvio di alcuni AP. ```bash # -a BSSID send random data from random clients to try the DoS # -i BSSID capture and repeat pakets from authenticated clients @@ -146,11 +152,11 @@ mdk4 wlan0mon a [-i EF:60:69:D7:69:2F] [-a EF:60:69:D7:69:2F] -m ``` **ATTACK MODE p: SSID Probing and Bruteforcing** -Il probing degli Access Points (AP) verifica se un SSID è correttamente rivelato e conferma il raggio dell'AP. Questa tecnica, unita al **bruteforcing di SSID nascosti** con o senza una wordlist, aiuta a identificare e accedere a reti nascoste. +Il probing degli Access Points (APs) verifica se un SSID è correttamente rivelato e conferma il raggio dell'AP. Questa tecnica, unita al **bruteforcing di SSID nascosti** con o senza una wordlist, aiuta a identificare e accedere a reti nascoste. **ATTACK MODE m: Michael Countermeasures Exploitation** -Inviare pacchetti casuali o duplicati a diverse code QoS può attivare le contromisure Michael su **TKIP AP**, portando a un'interruzione dell'AP di un minuto. Questo metodo è una tattica efficiente di attacco **DoS** (Denial of Service). +Inviare pacchetti casuali o duplicati a diverse code QoS può attivare le contromisure Michael su **TKIP APs**, portando a un'interruzione dell'AP di un minuto. Questo metodo è una tattica efficiente di attacco **DoS** (Denial of Service). ```bash # -t of a TKIP AP # -j use inteligent replay to create the DoS @@ -192,10 +198,10 @@ WPS (Wi-Fi Protected Setup) semplifica il processo di connessione dei dispositiv Ci sono 2 strumenti principali per eseguire questa azione: Reaver e Bully. -- **Reaver** è stato progettato per essere un attacco robusto e pratico contro WPS, ed è stato testato contro una vasta gamma di punti di accesso e implementazioni WPS. +- **Reaver** è stato progettato per essere un attacco robusto e pratico contro WPS, ed è stato testato su una vasta gamma di punti di accesso e implementazioni WPS. - **Bully** è una **nuova implementazione** dell'attacco di forza bruta WPS, scritto in C. Ha diversi vantaggi rispetto al codice reaver originale: meno dipendenze, prestazioni migliorate in memoria e CPU, gestione corretta dell'endianness e un set di opzioni più robusto. -L'attacco sfrutta la **vulnerabilità del PIN WPS**, in particolare la sua esposizione delle prime quattro cifre e il ruolo dell'ultima cifra come checksum, facilitando l'attacco di forza bruta. Tuttavia, le difese contro gli attacchi di forza bruta, come **il blocco degli indirizzi MAC** degli aggressori, richiedono **la rotazione degli indirizzi MAC** per continuare l'attacco. +L'attacco sfrutta la **vulnerabilità del PIN WPS**, in particolare la sua esposizione delle prime quattro cifre e il ruolo dell'ultima cifra come checksum, facilitando l'attacco di forza bruta. Tuttavia, le difese contro gli attacchi di forza bruta, come il **blocco degli indirizzi MAC** degli aggressori, richiedono la **rotazione degli indirizzi MAC** per continuare l'attacco. Una volta ottenuto il PIN WPS con strumenti come Bully o Reaver, l'attaccante può dedurre il WPA/WPA2 PSK, garantendo **accesso persistente alla rete**. ```bash @@ -236,8 +242,8 @@ Tutti gli attacchi WPS proposti possono essere facilmente eseguiti utilizzando _ - 5 e 6 ti permettono di provare **il tuo PIN personalizzato** (se ne hai uno) - 7 e 8 eseguono l'**attacco Pixie Dust** -- 13 ti consente di testare il **PIN NULL** -- 11 e 12 **raccolgono i PIN relativi all'AP selezionato da database disponibili** e **generano** possibili **PIN** utilizzando: ComputePIN, EasyBox e opzionalmente Arcadyan (consigliato, perché no?) +- 13 ti consente di testare il **NULL PIN** +- 11 e 12 **raccoglieranno i PIN relativi all'AP selezionato da database disponibili** e **genereranno** possibili **PIN** utilizzando: ComputePIN, EasyBox e opzionalmente Arcadyan (consigliato, perché no?) - 9 e 10 testeranno **ogni possibile PIN** ## **WEP** @@ -297,7 +303,7 @@ _Ho notato che alcuni handshake catturati con questo strumento non potevano esse ### Cattura dell'handshake -Un attacco alle reti **WPA/WPA2** può essere eseguito catturando un **handshake** e tentando di **crackare** la password **offline**. Questo processo implica il monitoraggio della comunicazione di una rete specifica e del **BSSID** su un particolare **canale**. Ecco una guida semplificata: +Un attacco alle reti **WPA/WPA2** può essere eseguito catturando un **handshake** e tentando di **crackare** la password **offline**. Questo processo implica il monitoraggio della comunicazione di una rete specifica e del **BSSID** su un determinato **canale**. Ecco una guida semplificata: 1. Identificare il **BSSID**, il **canale** e un **client connesso** della rete target. 2. Utilizzare `airodump-ng` per monitorare il traffico di rete sul canale e BSSID specificati, sperando di catturare un handshake. Il comando apparirà così: @@ -346,9 +352,9 @@ In **configurazioni WiFi aziendali, incontrerai vari metodi di autenticazione**, 6A:FE:3B:73:18:FB -58 19 0 0 1 195 WPA2 CCMP MGT NameOfMyWifi ``` 1. **EAP-GTC (Generic Token Card)**: -- Questo metodo supporta i token hardware e le password monouso all'interno di EAP-PEAP. A differenza di MSCHAPv2, non utilizza una sfida tra pari e invia le password in chiaro al punto di accesso, ponendo un rischio per attacchi di downgrade. +- Questo metodo supporta i token hardware e le password monouso all'interno di EAP-PEAP. A differenza di MSCHAPv2, non utilizza una sfida peer e invia le password in chiaro al punto di accesso, ponendo un rischio per attacchi di downgrade. 2. **EAP-MD5 (Message Digest 5)**: -- Comporta l'invio dell'hash MD5 della password dal client. Non è **raccomandato** a causa della vulnerabilità agli attacchi di dizionario, della mancanza di autenticazione del server e dell'incapacità di generare chiavi WEP specifiche per la sessione. +- Comporta l'invio dell'hash MD5 della password dal client. **Non è raccomandato** a causa della vulnerabilità agli attacchi di dizionario, della mancanza di autenticazione del server e dell'incapacità di generare chiavi WEP specifiche per la sessione. 3. **EAP-TLS (Transport Layer Security)**: - Utilizza sia certificati lato client che lato server per l'autenticazione e può generare dinamicamente chiavi WEP basate su utente e sessione per proteggere le comunicazioni. 4. **EAP-TTLS (Tunneled Transport Layer Security)**: @@ -371,25 +377,25 @@ All'interno del pacchetto "**Response, Identity**", apparirà il **nome utente** ### Identità Anonime -Il nascondimento dell'identità è supportato sia da EAP-PEAP che da EAP-TTLS. Nel contesto di una rete WiFi, una richiesta di EAP-Identity è tipicamente avviata dal punto di accesso (AP) durante il processo di associazione. Per garantire la protezione dell'anonimato dell'utente, la risposta del client EAP sul dispositivo dell'utente contiene solo le informazioni essenziali necessarie affinché il server RADIUS iniziale elabori la richiesta. Questo concetto è illustrato attraverso i seguenti scenari: +Il nascondimento dell'identità è supportato sia da EAP-PEAP che da EAP-TTLS. Nel contesto di una rete WiFi, una richiesta EAP-Identity è tipicamente avviata dal punto di accesso (AP) durante il processo di associazione. Per garantire la protezione dell'anonimato dell'utente, la risposta del client EAP sul dispositivo dell'utente contiene solo le informazioni essenziali necessarie per il server RADIUS iniziale per elaborare la richiesta. Questo concetto è illustrato attraverso i seguenti scenari: - EAP-Identity = anonimo -- In questo scenario, tutti gli utenti utilizzano il pseudonimo "anonimo" come identificatore utente. Il server RADIUS iniziale funge da server EAP-PEAP o EAP-TTLS, responsabile della gestione del lato server del protocollo PEAP o TTLS. Il metodo di autenticazione interno (protetto) viene quindi gestito localmente o delegato a un server RADIUS remoto (domestico). +- In questo scenario, tutti gli utenti utilizzano il pseudonimo "anonimo" come identificatore utente. Il server RADIUS iniziale funge da server EAP-PEAP o EAP-TTLS, responsabile della gestione del lato server del protocollo PEAP o TTLS. Il metodo di autenticazione interno (protetto) è quindi gestito localmente o delegato a un server RADIUS remoto (domestico). - EAP-Identity = anonimo@realm_x -- In questa situazione, gli utenti di diversi domini nascondono le loro identità mentre indicano i rispettivi domini. Questo consente al server RADIUS iniziale di proxy le richieste EAP-PEAP o EAP-TTLS ai server RADIUS nei loro domini domestici, che fungono da server PEAP o TTLS. Il server RADIUS iniziale opera esclusivamente come nodo di relay RADIUS. -- In alternativa, il server RADIUS iniziale può funzionare come server EAP-PEAP o EAP-TTLS e gestire il metodo di autenticazione protetto o inoltrarlo a un altro server. Questa opzione facilita la configurazione di politiche distinte per vari domini. +- In questa situazione, gli utenti di diversi domini nascondono le loro identità mentre indicano i rispettivi domini. Questo consente al server RADIUS iniziale di inoltrare le richieste EAP-PEAP o EAP-TTLS ai server RADIUS nei loro domini domestici, che fungono da server PEAP o TTLS. Il server RADIUS iniziale opera esclusivamente come nodo di relay RADIUS. +- In alternativa, il server RADIUS iniziale può funzionare come server EAP-PEAP o EAP-TTLS e gestire il metodo di autenticazione protetta o inoltrarlo a un altro server. Questa opzione facilita la configurazione di politiche distinte per vari domini. -In EAP-PEAP, una volta stabilito il tunnel TLS tra il server PEAP e il client PEAP, il server PEAP avvia una richiesta di EAP-Identity e la trasmette attraverso il tunnel TLS. Il client risponde a questa seconda richiesta di EAP-Identity inviando una risposta di EAP-Identity contenente la vera identità dell'utente attraverso il tunnel crittografato. Questo approccio previene efficacemente la rivelazione della vera identità dell'utente a chiunque stia ascoltando il traffico 802.11. +In EAP-PEAP, una volta stabilito il tunnel TLS tra il server PEAP e il client PEAP, il server PEAP avvia una richiesta EAP-Identity e la trasmette attraverso il tunnel TLS. Il client risponde a questa seconda richiesta EAP-Identity inviando una risposta EAP-Identity contenente la vera identità dell'utente attraverso il tunnel crittografato. Questo approccio previene efficacemente la rivelazione della vera identità dell'utente a chiunque stia ascoltando il traffico 802.11. EAP-TTLS segue una procedura leggermente diversa. Con EAP-TTLS, il client tipicamente si autentica utilizzando PAP o CHAP, protetti dal tunnel TLS. In questo caso, il client include un attributo User-Name e un attributo Password o CHAP-Password nel messaggio TLS iniziale inviato dopo l'instaurazione del tunnel. -Indipendentemente dal protocollo scelto, il server PEAP/TTLS acquisisce conoscenza della vera identità dell'utente dopo che il tunnel TLS è stato stabilito. La vera identità può essere rappresentata come user@realm o semplicemente user. Se il server PEAP/TTLS è anche responsabile dell'autenticazione dell'utente, ora possiede l'identità dell'utente e procede con il metodo di autenticazione protetto dal tunnel TLS. In alternativa, il server PEAP/TTLS può inoltrare una nuova richiesta RADIUS al server RADIUS domestico dell'utente. Questa nuova richiesta RADIUS omette il livello del protocollo PEAP o TTLS. Nei casi in cui il metodo di autenticazione protetto è EAP, i messaggi EAP interni vengono trasmessi al server RADIUS domestico senza l'involucro EAP-PEAP o EAP-TTLS. L'attributo User-Name del messaggio RADIUS in uscita contiene la vera identità dell'utente, sostituendo l'User-Name anonimo della richiesta RADIUS in arrivo. Quando il metodo di autenticazione protetto è PAP o CHAP (supportato solo da TTLS), l'attributo User-Name e altri attributi di autenticazione estratti dal payload TLS vengono sostituiti nel messaggio RADIUS in uscita, sostituendo l'User-Name anonimo e gli attributi TTLS EAP-Message trovati nella richiesta RADIUS in arrivo. +Indipendentemente dal protocollo scelto, il server PEAP/TTLS acquisisce conoscenza della vera identità dell'utente dopo che il tunnel TLS è stato stabilito. La vera identità può essere rappresentata come user@realm o semplicemente user. Se il server PEAP/TTLS è anche responsabile dell'autenticazione dell'utente, ora possiede l'identità dell'utente e procede con il metodo di autenticazione protetto dal tunnel TLS. In alternativa, il server PEAP/TTLS può inoltrare una nuova richiesta RADIUS al server RADIUS domestico dell'utente. Questa nuova richiesta RADIUS omette il livello del protocollo PEAP o TTLS. Nei casi in cui il metodo di autenticazione protetta è EAP, i messaggi EAP interni vengono trasmessi al server RADIUS domestico senza l'involucro EAP-PEAP o EAP-TTLS. L'attributo User-Name del messaggio RADIUS in uscita contiene la vera identità dell'utente, sostituendo l'User-Name anonimo della richiesta RADIUS in arrivo. Quando il metodo di autenticazione protetta è PAP o CHAP (supportato solo da TTLS), l'attributo User-Name e altri attributi di autenticazione estratti dal payload TLS vengono sostituiti nel messaggio RADIUS in uscita, sostituendo l'User-Name anonimo e gli attributi TTLS EAP-Message trovati nella richiesta RADIUS in arrivo. Per ulteriori informazioni controlla [https://www.interlinknetworks.com/app_notes/eap-peap.htm](https://www.interlinknetworks.com/app_notes/eap-peap.htm) ### EAP-Bruteforce (password spray) -Se ci si aspetta che il client utilizzi un **nome utente e una password** (nota che **EAP-TLS non sarà valido** in questo caso), allora potresti provare a ottenere un **elenco** di **nomi utente** (vedi la parte successiva) e **password** e provare a **bruteforce** l'accesso utilizzando [**air-hammer**](https://github.com/Wh1t3Rh1n0/air-hammer)**.** +Se ci si aspetta che il client utilizzi un **nome utente e una password** (nota che **EAP-TLS non sarà valido** in questo caso), allora potresti provare a ottenere un **elenco** di **nomi utente** (vedi la parte successiva) e **password** e provare a **bruteforare** l'accesso utilizzando [**air-hammer**](https://github.com/Wh1t3Rh1n0/air-hammer)**.** ```bash ./air-hammer.py -i wlan0 -e Test-Network -P UserPassword1 -u usernames.txt ``` @@ -401,32 +407,32 @@ Puoi anche eseguire questo attacco utilizzando `eaphammer`: --password bananas \ --user-list users.txt ``` -## Teoria degli attacchi ai client +## Teoria degli attacchi ai Client -### Selezione della rete e roaming +### Selezione della Rete e Roaming - Il protocollo 802.11 definisce come una stazione si unisce a un Extended Service Set (ESS) ma non specifica i criteri per selezionare un ESS o un access point (AP) al suo interno. - Le stazioni possono passare da un AP all'altro condividendo lo stesso ESSID, mantenendo la connettività in un edificio o in un'area. - Il protocollo richiede l'autenticazione della stazione all'ESS ma non impone l'autenticazione dell'AP alla stazione. -### Elenchi di reti preferite (PNL) +### Elenchi di Reti Preferite (PNL) - Le stazioni memorizzano l'ESSID di ogni rete wireless a cui si connettono nel loro Elenco di Reti Preferite (PNL), insieme ai dettagli di configurazione specifici della rete. - Il PNL viene utilizzato per connettersi automaticamente a reti conosciute, migliorando l'esperienza dell'utente semplificando il processo di connessione. -### Scansione passiva +### Scansione Passiva - Gli AP trasmettono periodicamente frame beacon, annunciando la loro presenza e caratteristiche, incluso l'ESSID dell'AP a meno che la trasmissione non sia disabilitata. - Durante la scansione passiva, le stazioni ascoltano i frame beacon. Se l'ESSID di un beacon corrisponde a un'entrata nel PNL della stazione, la stazione può connettersi automaticamente a quell'AP. - La conoscenza del PNL di un dispositivo consente potenziali sfruttamenti mimando l'ESSID di una rete conosciuta, ingannando il dispositivo a connettersi a un AP malevolo. -### Probing attivo +### Probing Attivo - Il probing attivo implica che le stazioni inviino richieste di probing per scoprire AP vicini e le loro caratteristiche. - Le richieste di probing dirette mirano a un ESSID specifico, aiutando a rilevare se una rete particolare è entro portata, anche se è una rete nascosta. - Le richieste di probing broadcast hanno un campo SSID nullo e vengono inviate a tutti gli AP vicini, consentendo alla stazione di controllare eventuali reti preferite senza rivelare i contenuti del suo PNL. -## AP semplice con reindirizzamento a Internet +## AP Semplice con reindirizzamento a Internet Prima di spiegare come eseguire attacchi più complessi, verrà spiegato **come** semplicemente **creare** un **AP** e **reindirizzare** il suo **traffico** a un'interfaccia connessa **a** Internet. @@ -518,7 +524,7 @@ _Alcuni OS e AV avviseranno l'utente che connettersi a una rete aperta è perico ### WPA/WPA2 Evil Twin -Puoi creare un **Evil Twin utilizzando WPA/2** e se i dispositivi sono configurati per connettersi a quel SSID con WPA/2, cercheranno di connettersi. Comunque, **per completare il 4-way-handshake** hai anche bisogno di **conoscere** la **password** che il client utilizzerà. Se **non la conosci**, la **connessione non sarà completata**. +Puoi creare un **Evil Twin utilizzando WPA/2** e se i dispositivi sono configurati per connettersi a quel SSID con WPA/2, cercheranno di connettersi. Comunque, **per completare il 4-way-handshake** devi anche **conoscere** la **password** che il client utilizzerà. Se **non la conosci**, la **connessione non sarà completata**. ```bash ./eaphammer -i wlan0 -e exampleCorp -c 11 --creds --auth wpa-psk --wpa-passphrase "mywifipassword" ``` @@ -535,7 +541,7 @@ hostapd-wpe ./victim/victim.conf -s ``` Nel file di configurazione puoi selezionare molte cose diverse come ssid, canale, file utente, cret/key, parametri dh, versione wpa e auth... -[**Utilizzando hostapd-wpe con EAP-TLS per consentire a qualsiasi certificato di accedere.**](evil-twin-eap-tls.md) +[**Utilizzando hostapd-wpe con EAP-TLS per consentire a qualsiasi certificato di effettuare il login.**](evil-twin-eap-tls.md) **Utilizzando EAPHammer** ```bash @@ -549,7 +555,7 @@ Per impostazione predefinita, EAPHammer propone questi metodi di autenticazione ``` GTC,MSCHAPV2,TTLS-MSCHAPV2,TTLS,TTLS-CHAP,TTLS-PAP,TTLS-MSCHAP,MD5 ``` -Questa è la metodologia predefinita per evitare tempi di connessione lunghi. Tuttavia, puoi anche specificare al server i metodi di autenticazione dal più debole al più forte: +Questa è la metodologia predefinita per evitare lunghi tempi di connessione. Tuttavia, puoi anche specificare di servire i metodi di autenticazione dal più debole al più forte: ``` --negotiate weakest ``` @@ -568,7 +574,7 @@ Oppure puoi anche usare: ### Debugging dei tunnel TLS PEAP e EAP-TTLS negli attacchi Evil Twins -_Questo metodo è stato testato in una connessione PEAP, ma poiché sto decrittografando un tunnel TLS arbitrario, dovrebbe funzionare anche con EAP-TTLS._ +_Questo metodo è stato testato in una connessione PEAP, ma poiché sto decrittografando un tunnel TLS arbitrario, dovrebbe funzionare anche con EAP-TTLS_ All'interno della **configurazione** di _hostapd-wpe_ **commenta** la riga che contiene _**dh_file**_ (da `dh_file=/etc/hostapd-wpe/certs/dh` a `#dh_file=/etc/hostapd-wpe/certs/dh`)\ Questo farà sì che `hostapd-wpe` **scambi chiavi utilizzando RSA** invece di DH, quindi sarai in grado di **decrittografare** il traffico successivamente **conoscendo la chiave privata del server**. @@ -577,7 +583,7 @@ Ora avvia il **Evil Twin** utilizzando **`hostapd-wpe`** con quella configurazio Ora o più tardi (quando hai già catturato alcune intenzioni di autenticazione) puoi aggiungere la chiave RSA privata a wireshark in: `Edit --> Preferences --> Protocols --> TLS --> (RSA keys list) Edit...` -Aggiungi una nuova voce e compila il modulo con questi valori: **Indirizzo IP = qualsiasi** -- **Porta = 0** -- **Protocollo = data** -- **File chiave** (**seleziona il tuo file chiave**, per evitare problemi seleziona un file chiave **senza protezione da password**). +Aggiungi una nuova voce e compila il modulo con questi valori: **Indirizzo IP = qualsiasi** -- **Porta = 0** -- **Protocollo = data** -- **File Chiave** (**seleziona il tuo file chiave**, per evitare problemi seleziona un file chiave **senza protezione da password**). ![](<../../images/image (687).png>) @@ -585,11 +591,11 @@ E guarda il nuovo **"tab Decrypted TLS"**: ![](<../../images/image (231).png>) -## KARMA, MANA, Loud MANA e attacco a beacon noti +## KARMA, MANA, Loud MANA e attacco ai beacon noti ### Liste nere/rosse di ESSID e MAC -Diversi tipi di Liste di Filtri di Controllo degli Accessi ai Media (MFACLs) e i loro corrispondenti modi ed effetti sul comportamento di un Access Point (AP) fraudolento: +Diversi tipi di Liste di Filtri di Controllo degli Accessi ai Media (MFACL) e i loro corrispondenti modi ed effetti sul comportamento di un Access Point (AP) fraudolento: 1. **Whitelist basata su MAC**: - L'AP fraudolento risponderà solo alle richieste di probe da dispositivi specificati nella whitelist, rimanendo invisibile a tutti gli altri non elencati. @@ -598,7 +604,7 @@ Diversi tipi di Liste di Filtri di Controllo degli Accessi ai Media (MFACLs) e i 3. **Whitelist basata su SSID**: - L'AP fraudolento risponderà alle richieste di probe solo per specifici ESSID elencati, rendendolo invisibile ai dispositivi le cui Liste di Rete Preferite (PNL) non contengono quegli ESSID. 4. **Blacklist basata su SSID**: -- L'AP fraudolento non risponderà alle richieste di probe per gli specifici ESSID sulla blacklist, rendendolo invisibile ai dispositivi che cercano quelle particolari reti. +- L'AP fraudolento non risponderà alle richieste di probe per gli specifici ESSID sulla blacklist, rendendolo invisibile ai dispositivi che cercano quelle reti particolari. ```bash # example EAPHammer MFACL file, wildcards can be used 09:6a:06:c8:36:af @@ -632,13 +638,13 @@ L'attacco MANA opera monitorando sia le richieste di probe dirette che quelle br ``` ### Loud MANA -Un **attacco Loud MANA** è una strategia avanzata per quando i dispositivi non utilizzano il probing diretto o quando le loro Liste di Rete Preferite (PNL) sono sconosciute all'attaccante. Funziona sul principio che **i dispositivi nella stessa area sono probabilmente inclini a condividere alcuni nomi di rete nelle loro PNL**. Invece di rispondere in modo selettivo, questo attacco trasmette risposte di probing per ogni nome di rete (ESSID) trovato nelle PNL combinate di tutti i dispositivi osservati. Questo approccio ampio aumenta la possibilità che un dispositivo riconosca una rete familiare e tenti di connettersi al Punto di Accesso (AP) malevolo. +Un **attacco Loud MANA** è una strategia avanzata per quando i dispositivi non utilizzano il probing diretto o quando le loro Liste di Rete Preferite (PNL) sono sconosciute all'attaccante. Funziona sul principio che **i dispositivi nella stessa area probabilmente condividono alcuni nomi di rete nelle loro PNL**. Invece di rispondere in modo selettivo, questo attacco trasmette risposte di probing per ogni nome di rete (ESSID) trovato nelle PNL combinate di tutti i dispositivi osservati. Questo approccio ampio aumenta la possibilità che un dispositivo riconosca una rete familiare e tenti di connettersi al Punto di Accesso (AP) malevolo. ```bash ./eaphammer -i wlan0 --cloaking full --mana --loud [--captive-portal] [--auth wpa-psk --creds] ``` ### Known Beacon attack -Quando l'**attacco Loud MANA** potrebbe non essere sufficiente, l'**attacco Known Beacon** presenta un altro approccio. Questo metodo **forza il processo di connessione simulando un AP che risponde a qualsiasi nome di rete, ciclando attraverso un elenco di potenziali ESSID** derivati da una wordlist. Questo simula la presenza di numerose reti, sperando di abbinare un ESSID all'interno del PNL della vittima, provocando un tentativo di connessione all'AP fabbricato. L'attacco può essere amplificato combinandolo con l'opzione `--loud` per un tentativo più aggressivo di catturare i dispositivi. +Quando l'**attacco Loud MANA** potrebbe non essere sufficiente, l'**attacco Known Beacon** presenta un altro approccio. Questo metodo **forza il processo di connessione simulando un AP che risponde a qualsiasi nome di rete, ciclano attraverso un elenco di potenziali ESSID** derivati da una wordlist. Questo simula la presenza di numerose reti, sperando di abbinare un ESSID all'interno della PNL della vittima, inducendo un tentativo di connessione all'AP fabbricato. L'attacco può essere amplificato combinandolo con l'opzione `--loud` per un tentativo più aggressivo di catturare i dispositivi. Eaphammer ha implementato questo attacco come un attacco MANA in cui tutti gli ESSID all'interno di un elenco sono caricati (puoi anche combinare questo con `--loud` per creare un attacco Loud MANA + Known beacons): ```bash @@ -659,7 +665,7 @@ L'**attacco Known Beacon Burst** comporta la **trasmissione rapida di frame beac **Wi-Fi Direct** è un protocollo che consente ai dispositivi di collegarsi direttamente tra loro utilizzando il Wi-Fi senza la necessità di un punto di accesso wireless tradizionale. Questa capacità è integrata in vari dispositivi Internet of Things (IoT), come stampanti e televisori, facilitando la comunicazione diretta tra dispositivi. Una caratteristica notevole di Wi-Fi Direct è che un dispositivo assume il ruolo di punto di accesso, noto come proprietario del gruppo, per gestire la connessione. -La sicurezza per le connessioni Wi-Fi Direct è stabilita tramite **Wi-Fi Protected Setup (WPS)**, che supporta diversi metodi per il pairing sicuro, tra cui: +La sicurezza per le connessioni Wi-Fi Direct è stabilita attraverso **Wi-Fi Protected Setup (WPS)**, che supporta diversi metodi per il pairing sicuro, tra cui: - **Push-Button Configuration (PBC)** - **PIN entry** diff --git a/src/generic-methodologies-and-resources/pentesting-wifi/enable-nexmon-monitor-and-injection-on-android.md b/src/generic-methodologies-and-resources/pentesting-wifi/enable-nexmon-monitor-and-injection-on-android.md new file mode 100644 index 000000000..52f800c59 --- /dev/null +++ b/src/generic-methodologies-and-resources/pentesting-wifi/enable-nexmon-monitor-and-injection-on-android.md @@ -0,0 +1,128 @@ +# Abilitare la modalità monitor NexMon e l'iniezione di pacchetti su Android (chip Broadcom) + +{{#include ../../banners/hacktricks-training.md}} + +## Panoramica +La maggior parte dei moderni telefoni Android integra un chipset Wi-Fi Broadcom/Cypress che viene fornito senza modalità monitor 802.11 o capacità di iniezione di frame. Il framework open-source NexMon patcha il firmware proprietario per aggiungere queste funzionalità e le espone tramite una libreria condivisa (`libnexmon.so`) e un helper CLI (`nexutil`). Pre-caricando quella libreria nel driver Wi-Fi stock, un dispositivo rootato può catturare il traffico 802.11 raw e iniettare frame arbitrari, eliminando la necessità di un adattatore USB esterno. + +Questa pagina documenta un flusso di lavoro veloce che prende come esempio un Samsung Galaxy S10 completamente patchato (BCM4375B1), utilizzando: + +* Modulo NexMon Magisk contenente il firmware patchato + `libnexmon.so` +* Applicazione Android Hijacker per automatizzare l'attivazione della modalità monitor +* Chroot Kali NetHunter opzionale per eseguire strumenti wireless classici (aircrack-ng, wifite, mdk4 …) direttamente contro l'interfaccia interna + +La stessa tecnica si applica a qualsiasi dispositivo che ha una patch NexMon disponibile pubblicamente (Pixel 1, Nexus 6P, Galaxy S7/S8, ecc.). + +--- + +## Requisiti +* Dispositivo Android con un chipset Broadcom/Cypress supportato (es. BCM4358/59/43596/4375B1) +* Root con Magisk ≥ 24 +* BusyBox (la maggior parte delle ROM/NetHunter lo include già) +* ZIP NexMon Magisk o patch auto-compilata che fornisce: +* `/system/lib*/libnexmon.so` +* `/system/xbin/nexutil` +* Hijacker ≥ 1.7 (arm/arm64) – https://github.com/chrisk44/Hijacker +* (Opzionale) Kali NetHunter o qualsiasi chroot Linux dove intendi eseguire strumenti wireless + +--- + +## Flashing della patch NexMon (Magisk) +1. Scarica il ZIP per il tuo dispositivo/firmware esatto (esempio: `nexmon-s10.zip`). +2. Apri Magisk -> Moduli -> Installa da memoria -> seleziona il ZIP e riavvia. +Il modulo copia `libnexmon.so` in `/data/adb/modules//lib*/` e assicura che le etichette SELinux siano corrette. +3. Verifica l'installazione: +```bash +ls -lZ $(find / -name libnexmon.so 2>/dev/null) +sha1sum $(which nexutil) +``` + +--- + +## Configurazione di Hijacker +Hijacker può attivare automaticamente la modalità monitor prima di eseguire `airodump`, `wifite`, ecc. In **Impostazioni -> Avanzate** aggiungi le seguenti voci (modifica il percorso della libreria se il tuo modulo è diverso): +``` +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 +``` +Abilita “Avvia la modalità monitor all'avvio di airodump” in modo che ogni scansione di Hijacker avvenga in modalità monitor nativa (`wlan0` invece di `wlan0mon`). + +Se Hijacker mostra errori all'avvio, crea la directory necessaria nella memoria condivisa e riapri l'app: +```bash +mkdir -p /storage/emulated/0/Hijacker +``` +### Cosa significano quei flag `nexutil`? +* **`-s0x613`** Scrivi la variabile firmware 0x613 (FCAP_FRAME_INJECTION) → `1` (abilita TX di frame arbitrari). +* **`-i`** Metti l'interfaccia in modalità monitor (l'intestazione radiotap sarà aggiunta). +* **`-v2`** Imposta il livello di verbosità; `2` stampa conferma e versione del firmware. +* **`-m0`** Ripristina la modalità gestita (utilizzata nel comando *disable*). + +Dopo aver eseguito *Enable monitor mode* dovresti vedere l'interfaccia in stato monitor e essere in grado di catturare frame grezzi con: +```bash +airodump-ng --band abg wlan0 +``` +--- + +## Manual one-liner (senza 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 +``` +Se hai solo bisogno di sniffing passivo, ometti il flag `-s0x613`. + +--- + +## Utilizzo di `libnexmon` all'interno di Kali NetHunter / chroot +Gli strumenti di user-space di Kali non conoscono NexMon, ma puoi costringerli a usarlo tramite `LD_PRELOAD`: + +1. Copia l'oggetto condiviso precompilato nel chroot: +```bash +cp /sdcard/Download/kalilibnexmon.so /lib/ +``` +2. Abilita la modalità monitor dall'**host Android** (comando sopra o tramite Hijacker). +3. Avvia qualsiasi strumento wireless all'interno di Kali con il preload: +```bash +sudo su +export LD_PRELOAD=/lib/kalilibnexmon.so +wifite -i wlan0 # o aircrack-ng, mdk4 … +``` +4. Quando hai finito, disabilita la modalità monitor come al solito su Android. + +Poiché il firmware gestisce già l'iniezione radiotap, gli strumenti di user-space si comportano proprio come su un adattatore Atheros esterno. + +--- + +## Attacchi tipici possibili +Una volta attivo monitor + TX puoi: +* Catturare handshake WPA(2/3-SAE) o PMKID con `wifite`, `hcxdumptool`, `airodump-ng`. +* Iniettare frame di deautenticazione/disassociazione per costringere i client a riconnettersi. +* Creare frame di gestione/dati arbitrari con `mdk4`, `aireplay-ng`, Scapy, ecc. +* Costruire AP malevoli o eseguire attacchi KARMA/MANA direttamente dal telefono. + +Le prestazioni sul Galaxy S10 sono comparabili a NIC USB esterni (~20 dBm TX, 2-3 M pps RX). + +--- + +## Risoluzione dei problemi +* `Device or resource busy` – assicurati che il **servizio Wi-Fi di Android sia disabilitato** (`svc wifi disable`) prima di abilitare la modalità monitor. +* `nexutil: ioctl(PRIV_MAGIC) failed` – la libreria non è pre-caricata; controlla il percorso di `LD_PRELOAD`. +* L'iniezione di frame funziona ma non vengono catturati pacchetti – alcune ROM bloccano hard i canali; prova `nexutil -c ` o `iwconfig wlan0 channel `. +* SELinux blocca la libreria – imposta il dispositivo su *Permissivo* o correggi il contesto del modulo: `chcon u:object_r:system_lib_file:s0 libnexmon.so`. + +--- + +## Riferimenti +* [Hijacker on the Samsung Galaxy S10 with wireless injection](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 for Android)](https://github.com/chrisk44/Hijacker) + +{{#include ../../banners/hacktricks-training.md}}