Seguridad en WiFi (Técnico) - Problemas concretos de Seguridad en WiFi

a.   Puntos ocultos: Este es un problema específico de las redes inalámbricas, pues suele ser muy común que los propios empleados de la empresa por cuestiones de comodidad, instalen sus propios puntos de acceso. Este tipo de instalaciones, si no se controlan, dejan huecos de seguridad enormes en la red. El peor de estos casos es la situación en la cual un intruso lo deja oculto y luego ingresa a la red desde cualquier ubicación cercana a la misma.  La gran ventaja que queda de este problema es que es muy fácil su identificación siempre y cuando se propongan medidas de auditorías periódicas específicas para las infraestructuras WiFi de la empresa, dentro del plan o política de seguridad.

b.   Falsificación de AP: Es muy simple colocar una AP que difunda sus SSID, para permitir a cualquiera que se conecte, si sobre el mismo se emplean técnicas de “Phishing”, se puede inducir a creer que se está conectando a una red en concreto. Existen varios productos ya diseñados par falsificar AP, en la terminología WiFi se los suelen llamar “Rogue AP” o Fake AP”, el más común es un concocido srcipt en Perl denominado justamente “FakeAP”, que envía Beacons con diferentes ESSID y difernetes direcciones MAC con o sin empleo de WEP. Se puede descargar de :

Http://www.blackalchemy.to/project/fakeap/ ∞

c.   Deficiencias en WEP (Características lineales de CRC32): Esta característica fue demostrada en teoría por Nikita Borisov, Ian Goldberg y David Wagner. El ICV permite verificar la integridad de un mensaje, por lo tanto, el receptor aceptará el mensaje si su ICV es válido (Recuerdo que es un simple CRC32). Esto presenta dos problemas:

- El CRC es independiente de al clave empleada.

- Los CRC son lineales CRC (m?k) = CRC (m) ? CRC (k). En virtud de esta linealidad, se puede generar un ICV válido. Un atacante debe interceptar un mensaje (conocido o no) y modificarlo en forma conocida para generar un mensaje m`, operando sobre el mismo obtendrá un paquete que será aceptado por el receptor.

d.   ICV independiente de la llave: Esta característica fue demostrada en teoría por David Wagner. Nuevamente se trata el ICV, el cual se calcula previamente a comenzar el proceso criptográfico, por lo tanto no depende de la clave ni del IV. Esta debilidad da lugar a que conocido el texto plano de un solo paquete encriptado con WEP, sea posible inyectar paquetes en la red.

e.   Tamaño de IV demasiado corto: El IV tiene 24 bits de longitud (224 = 16.777.216) y viaja como texto plano. Un punto de acceso que opere con grandes volúmenes de tráfico comenzará a repetir este IV a partir de aproximadamente 5 horas. Esta repetición hace que matemáticamente se pueda operar para poder obtener el texto plano de mensajes con IV repetido (sin gran nivel de dificultad). El estándar especifica que el cambio de IV es opcional, siendo un valor que empieza con cero y se va incrementando en uno.

f.    Deficiencias en el método de autenticación:

Si un atacante captura el segundo y tercer mensaje de administración en una autenticación mutua. El segundo posee el desafío en texto plano y el tercero contiene el mensaje criptografiado con la clave compartida. Con estos datos, posee todos los elementos para autenticarse con éxito sin conocer el secreto compartido (Con esto sólo logra autenticarse, luego queda el acceso a la red).

g.       Debilidades en el algoritmo key Scheduling de RC4: scott Fluhrer, Itsik Mantin y Adi Shamir publicaron en Agosto del 2001 la demostración teórica de la vulnerabilidad más devastadora de las existentes hasta ahora en la encriptación WEP. Adam Stubblefield, un trabajador de AT&T Labs, fue la primera persona que implementó este ataque con éxito.

Demostraron que usando sólo la primera palabra de un keystream, podían obtener información de la clave secreta compartida. Se buscan IVs que causen que no haya información de la llave en el keystream. Los autores llamaron a esta condición “resolved condition” o condición resuelta.
El número de paquetes que se necesitan recolectar antes de descubrir un byte de la llave varía en función de en que valor se encuentre el contador de IV’s de las tarjetas que se estén monitorizando. Hay 9.000 IV's débiles en los 16 millones de IV's posibles.

---

¿Cuántos paquetes encriptados se necesitan recolectar para crackear la llave WEP?

---

–  La mayoría de las llaves pueden ser adivinadas después de encontrar aproximadamente 2000 paquetes resueltos.

–  Algunas llaves requieren que capturemos incluso más de 4000 paquetes resueltos

Se puede adivinar la llave después de recolectar de 5 a 10 millones de paquetes encriptados. Poco después de que el trabajo realizado por estos tres autores y la vulnerabilidad práctica de Stubblefield fueran publicados, aparecieron dos herramientas en Internet que implementan totalmente el ataque:

- Wepcrack: http://wepcrack.sourceforge.net∞

- Airsnort: http://airsnort.shmoo.com∞

Esto fue la sentencia definitiva para WEP.

h.   Debilidad en WPA: Un estudio realizado por Robert Moskowitz, director de ICSA Labs, indica que el sistema utilizado por WPA para el intercambio de la información utilizada para la generación de las claves de cifrado es muy débil. Según este estudio, WPA en determinadas circunstancias es incluso más inseguro que WPE. Cuando las claves preestablecidas utilizadas en WPA utilizan palabras presentes en el diccionario y la longitud es inferior a los 20 caracteres, el atacante sólo necesitará interceptar el tráfico inicial de intercambio de claves. Sobre este tráfico, realizando un ataque de diccionario, el atacante puede obtener la clave preestablecida, que es la información necesaria para obtener acceso a la red. Es decir, a diferencia de WEP en que es necesario capturar un volumen significativo de tráfico para poder identificar las claves, en WPA únicamente capturando el tráfico de intercambio de claves para poder realizar este ataque de diccionario. No es un problema nuevo, pues fue apuntado durante la verificación inicial del protocolo. Es solo una muestra que una implementación inadecuada puede afectar negativamente cualquier sistema de cifrado. Como hemos indicado, el problema solo es explotable bajo una serie de circunstancias muy concretas. Este problema puntual no es, en absoluto, una indicación de la debilidad de WPA. Únicamente es un recordatorio de la necesidad de utilizar claves convenientemente largas y que incluyan caracteres especiales.