Posted by Star | Posted in | Posted on 22:29
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.
Si dividimos el nº total de IV’s entre los paquetes x seg. De la fórmula anterior:
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:
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:
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:
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.
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.
Si dividimos el nº total de IV’s entre los paquetes x seg. De la fórmula anterior:
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:
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
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.
- • 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.
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.
Comments (0)
Publicar un comentario