BackDoor Room 13 Team Blog de informatica general... con estilo :)

Código:

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.



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)



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.

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:



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()


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 );
}

Código:

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:



En otra shell:





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)



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:



Luego lanzamos airtun-ng



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:



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



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í:



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...





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:



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í:



* 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 :D

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....