16 ago. 2010

[WPA2-Hole196] FAQ sobre la explotación presentada en BlackHat y Defcon

WPA2, percibido como el protocolo de seguridad Wi-Fi más sólido, es ampliamente usado por las empresas para asegurar sus redes Wi-Fi. Pero los investigadores de AirTight han descubierto una vulnerabilidad llamada "Hole196" en el protocolo de seguridad de WPA2 que expone a las redes Wi-Fi aseguradas con WPA2 a los atacantes internos (insiders).

 

FAQs sobre la vulnerabilidad Hole196

 

¿Qué es la vulnerabilidad "Hole196"?

Hole196 es una vulnerabilidad en el protocolo de seguridad WPA2 que expone a las redes Wi-Fi aseguradas con WPA2 a los ataques desde dentro de la organización. AirTight Networks descubrió una vulnerabilidad en el protocolo WPA2, que fue documentada pero enterrada en la última línea de la página 196 del estándar de 1232 páginas de IEEE 802.11 (Revisión de 2007). Por ello el sobrenombre de Hole196 (Agujero196).

Algo central para esta vulnerabilidad es la clave temporal de grupo (GTK group temporal key) que es compartida entre todos los clientes autorizados en una red WPA2. En el comportamiento estándar, se supone que solo el AP trasmita tráfico cifrado de información dirigido al grupo usando la GTK y los clientes se supone que descifren ese tráfico usando la GTK. Sin embargo, ¡nada en el estándar impide que un cliente autorizado malicioso inyecte paquetes cifrados GTK falsificados! Al explotar la vulnerabilidad, un "insider" (cliente autorizado) puede leer y descifrar la información de otros usuarios autorizados también así como escanear sus dispositivos Wi-Fi en busca de vulnerabilidades, instalar malware y posiblemente comprometer esos dispositivos.

Resumiendo, esta vulnerabilidad significa que la privacidad entre usuarios esté inherentemente ausente en el aire en una red asegurada con WPA2.

¿Puede ser explotada esta vulnerabilidad solamente por atacantes internos, o puede un atacante externo hackear una red WPA2 usando el Hole196?

Para explotar Hole196, un usuario malicioso necesita conocer la clave de grupo (GTK) compartida por los usuarios autorizados en esa red Wi-Fi. Así que solo un atacante interno (un usuario autorizado) de una red WPA2, que tenga acceso a la GTK puede explotar esta vulnerabilidad.

Si la vulnerabilidad Hole196 solo puede ser explotada por atacantes internos, ¿nos debemos realmente preocupar por esto?

Vastos informes de encuestas muestran consistentemente que los ataques internos son la amenaza más común y costosa para la información y la seguridad de las empresas. Por ejemplo, consulte estos dos informes:

Si su organización es sensible a las amenazas internas y ya está tomando medidas para mitigar los ataques internos en las redes cableadas, entonces la vulnerabilidad Hole196 es importante ya que permite uno de los ataques internos conocidos más sigilosos que pueden ocasionar la fuga de información sensible(ej.: propiedad intelectual, secretos industriales, información financiera), el espionaje, el acceso no autorizado a recursos de TI, robo de identidad, etc.

¿Permite o supone Hole196 el quiebre de la clave de cifrado de WPA2?

¡No! Explotar la vulnerabilidad Hole196 no supone romper la clave de cifrado. Este no en un ataque al cifrado AES ni a la autenticación 802.1x (o PSK).

¿Consigue el atacante interno malicioso tener acceso a las claves privadas, por ejemplo, los pares de claves transitorias (PTKs) de otros usuarios autorizados en la red WPA2?

¡No! El atacante interno malicioso no consigue tener acceso a las claves privadas (PTKs) de otros usuarios Wi-Fi autorizados en la red WPA2.

Entonces, ¿de qué forma puede explotar un atacante interno la vulnerabilidad Hole196?

Nuestros hallazgos muestran que un atacante interno podría explotar Hole196 de tres maneras: (1) por envenenamiento ARP y ataques hombre-en-el-medio (MitM); (2) por inyección de código malicioso en otros dispositivos Wi-Fi autorizados; y (3) lanzando un ataque de denegación de servicio (DoS) sin usar frames de desconexión. En una red WPA2, un atacante interno malicioso emite paquetes falsos (con la dirección MAC del AP como dirección del emisor) cifrados usando la clave compartida de grupo (GTK) directamente a otros clientes Wi-Fi autorizados en la red. Un ejemplo de una explotación que puede ser lanzada usando GTK es el clásico ataque (MitM) de envenenamiento ARP (demostrado en Black Hat Arsenal 2010 y Defcon18). En la explotación de envenenamiento ARP, el atacante interno puede incluir por ejemplo un mensaje de Solicitud ARP dentro del paquete cifrado-GTK. La Solicitud ARP tiene la dirección actual del gateway, pero la dirección MAC de la máquina del atacante. Todos los clientes que reciben este mensaje actualizarán sus tablas ARP. Mapeando la dirección MAC del atacante con la dirección IP del gateway.

Todos los clientes Wi-Fi “envenenados” enviarán todo su tráficos, cifrado con sus respectivas laves privadas (PTKs), al AP, pero con la dirección MAC del atacante como destino. El AP podrá descifrar el tráfico y reenviarlo al atacante, ahora cifrándolo usando la PTK del atacante. Debido a que todo el tráfico que llega al atacante (desde el AP) está cifrado con la PTK del atacante, el atacante puede descifrarlo (incluyendo credenciales de login, correos y otra información sensible).

El atacante puede entonces elegir reenviar el tráfico al gateway actual de la red, de modo que los clientes WiFi víctimas no vean ningún comportamiento anormal y continúen con sus comunicaciones.

Pero la falsificación ARP (MitM) siempre fue posible sobre Ethernet o incluso en una red WPA2 mediante el AP, ¿qué tiene de nuevo?

La falsificación ARP (y el MitM) es un ataque clásico tanto en redes cableadas como en redes Wi-Fi. Sin embargo, en esta antigua forma de lanzar el ataque, el AP reenvía los mensajes ARP falsificados tanto por la red inalámbrica como por la cableada. Los mensajes que van por el cable van en claro (sin cifrar). La seguridad de las redes cableadas ha evolucionado con el pasar de los años al punto que los IDS/IPS para cable e incluso algunos switches de red pueden atrapar rápidamente y bloquear este ataque en el cable actualmente.

El punto sutil (que mucha gente parece pasar por alto) sobre explotar la GTK en WPA2 para lanzar un ataque de falsificación ARP es que la huella de el ataque queda solo en el aire y la carga del paquete cifrada. De tal modo ninguna solución del lado cableado de la red va a detectar nunca este ataque que ocurre en WPA2, ni podrá ningún AP existente ver nada anormal.

Y observe que la falsificación ARP es solo un ejemplo de una explotación de esta vulnerabilidad. Son posibles ataques más sofisticados.

¿Puede ser explotada prácticamente esta vulnerabilidad?

A diferencia de la vulnerabilidad WPA-TKIP (anunciada en Noviembre 2008) que fue principalmente de interés teórico, la vulnerabilidad Hole196 puede ser explotada prácticamente usando software open source existente tal como el driver madwifi y el wpa supplicant, y agregando diez líneas de código. El ataque MitM usando falsificación ARP fue demostrado en Black Hat Arsenal 2010 y Defcon18. Otros ataques como escaneo de puertos, explotación de vulnerabilidades de SO y aplicaciones, inyección de malware, manipulación de DNS, denegación de servicio, etc. son posibles abusando la GTK.

¿Son vulnerables a este ataque todas las implementaciones de WPA y WPA2?

¡Si! Hole196 es una vulnerabilidad fundamental en el diseño del protocolo. Todas las redes Wi-Fi que usan WPA o WPA2, sin importar la autenticación (PSK u 802.1x) y el cifrado (AES) que usen, son vulnerables.

¿Son vulnerables a Hole196 las arquitecturas WLAN que usan APs solitarios y aquellas que usan controladores WLAN?

Esta vulnerabilidad es fundamental al diseño de protocolo WPA/WPA2. Así que en la medida que la arquitectura WLAN (basada en AP solitarios o controladoras) siga el estándar, es vulnerable a Hole196.

¿Hay algún arreglo en el estándar del protocolo 802.11 que pueda implementar con una actualización de software para protegerme de esta vulnerabilidad?

A diferencia del caso de vulnerabilidades anteriores en los protocolos de cifrado y autenticación Wi-Fi, no hay alternativa inmediata en el estándar 802.11 que pueda ser usada para solucionar o sortear esta vulnerabilidad.

¿Puedo usar la característica de aislamiento del cliente (o PSPF) de mi infraestructura para protegerme del Hole196 de WPA2?

El aislamiento de cliente no es parte del estándar 802.11, sino una característica propietaria que está disponible en algunos APs y controladores WLAN. La implementación de la característica es probable que varíe de proveedor a proveedor. Activar la característica de aislamiento de cliente (o PSPF) en un AP o en un controlador WLAN puede impedir que dos clientes Wi-Fi asociados a un AP puedan comunicarse entre sí a través del AP. Esto significa que mientras el atacante interno malicioso puede continuar enviando paquetes cifrados GTK falsos directamente a otros clientes en la red, el tráfico de información desde los clientes víctimas no será reenviado por el AP al dispositivo Wi-Fi del atacante. Si embargo, un atacante puede superar esta característica de aislamiento de cliente Wi-Fi fijando un gateway falo en la red cableada, envenenando el caché ARP en los dispositivos Wi-Fi autorizados que usan GTK y redirigiendo todo el tráfico al gateway falso en lugar de dirigirlo a su dispositivo Wi-Fi. Además, otros ataques tales como inyección de malware, escaneo de puertos, denegación de servicio, etc. siguen siendo posibles usando solo el primer paso (enviar paquetes cifrados con GTK).

¿Hay algo que pueda instalar en mi laptop para protegerme del Hole196 WPA2?

Se puede instalar programas (como Snort o DecaffeintID) en algunos laptops Windows y Linux para detectar envenenamiento ARP, aunque no es práctico instalar software manualmente en una gran cantidad de equipos de usuario. Es más, estos programas no son soportados en la mayoría de los equipos de usuario (ej.: iPhones, iPads, Blackberry, Windows Mobile, Windows 7, etc.) que continuaran estando en riesgo de la vulnerabilidad Hole196 de WPA2. Además, estos programas no pueden impedir que el atacante interno lance otros ataques basados en Hole196 tales como inyección de malware, escaneo de puertos, denegación de servicio, etc.

¿Puede una solución del lado cableado como un IDS/IPS o un detector de envenenamiento ARP en el switch de la red detectar este ataque?

La huella de los ataques internos a WPA2 basados en Hole196 está limitada al aire, (las emisiones de radiofrecuencia solamente), haciéndolos uno de los ataques internos más sigilosos conocidos. Como resultado, no hay solución de seguridad en la parte cableadas (IDS/IPS, firewall, o detector de envenenamiento ARP de switch) que pueda detectar estos ataques.

¿Un sistema de detección de intrusos inalámbrico (WIPS) puede detectar este ataque?

Hole196 es otro ejemplo más de una vulnerabilidad inalámbrica que demanda un enfoque multi-capa de la seguridad inalámbrica. Un sistema de prevención de intrusos inalámbrico (WIPS) puede detectar ataques basados en Hole196 y proveer la capa adicional de seguridad para proteger de forma abarcativa las redes inalámbricas de las empresas de amenazas tales como los AP intrusos, mal comportamiento de clientes Wi-Fi, malas configuraciones de su infraestructura WLAN, y vulnerabilidades en la seguridad de los protocolos Wi-Fi.

¿Pueden los proveedores de AP WLAN diseñar una solución propietaria para la vulnerabilidad manteniendo la interoperabilidad?

Los proveedores de AP WLAN pueden sortear la vulnerabilidad Hole196 deteniendo el uso de clave de grupo compartida (GTK). La mayoría de las arquitecturas WLAN basadas en controlador de hoy en día, es posible “apagar” la emisión (broadcast) de tráfico de los AP al aire y en su lugar usar el controlador WLAN como el proxy ARP. En otras palabras, en esta configuración, no se usa la GTK.

Pero de acuerdo al estándar actual de protocolo WPA2, una GTK debe ser asignada por el AP a cada cliente durante el proceso de asociación (negociación de cuatro vías). Los proveedores de AP pueden implementar un parche para su software de AP para asignar una GTK única generada aleatoriamente a cada cliente en lugar de compartir la misma GTK entre todos los clientes. Usar una GTK única neutralizaría la vulnerabilidad Hole196 y permitiría aún la interoperabilidad (compatibilidad hacia atrás) con todos los dispositivos Wi-Fi clientes estándar. Y habría un costo mínimo asociado a este cambio en términos de reducción de la transferencia de datos.

En ausencia de un proxy ARP, un AP puede enviar emisión de tráfico al aire como unicast a clientes individuales, aunque esto resultaría potencialmente en la degradación de la transferencia de datos WLAN dependiendo de la cantidad de tráfico de emisión.

En el largo plazo, este enfoque de depreciar el uso de una GTK compartida podría ser adoptado en el estándar IEEE 802.11 y podría usarse solamente PTK.

Chema ha publicado más información en su Blog

Traducción: Raúl Batista - Segu-Info
FUENTE: http://www.securitybydefault.com/

Author & Editor

Ingeniero Civil en Computación (Universidad de Chile FCFM) y Diplomado en Gestión y Evaluación de Proyectos TI (Universidad de Chile FEN). Actualmente trabajo como Project Manager en varios proyectos y como asesor tecnológico para empresas.

0 Notaciones:

Publicar un comentario

Nota: solo los miembros de este blog pueden publicar comentarios.

Labels

0-day (12) 1337day (1) 8.8 (2) Adobe Acrobat (1) Android (2) Anonimato (1) Anonymous (9) BackDoor (2) BackTrack (15) badUSB (1) Base64 (1) Black Hat (7) BlackHat (1) Blackploit (25) Brute Force (3) Bug (106) Bypass Password (1) Bypass Redirect (1) C99 Shell (1) Carding (1) CheatSheet (15) Chilean Way (1) Conference (10) Cryptsetup (1) CSRF (1) DDoS (11) DEF CON (3) DEFCON (7) Diapositivas (1) Diseño Web (1) Distro Linux (27) Documental (2) DoS (2) Drupal (1) DuckDuckGo (1) E-zine (18) Ekoparty (1) Escaneo (4) España (1) Exploit (64) Ezine (1) Facebook (1) Fast-Info (44) FBI (1) Ficheros Binarios (1) Firefox (4) Flash (2) Forense (9) Fuerza Bruta (11) Fuga de Datos (1) GhostShell (1) GNU/Linux (4) Google (2) Guía (1) Hack T00LZ (130) Hack Tips (63) Hacked (6) Hacking (18) Hacking Hardware (5) HashCat (1) Herramientas (121) HighSecCON (1) Humor Geek (13) Infografía (1) Ingeniería Social (5) Inj3ct0r (1) Internet Explorer (3) Java (7) JavaScript (2) Kali (3) KitPloit (1) Leaks (21) Linux OS (79) LulzSec (1) Mac OS (10) Magazine (1) Malaware (3) Malaware Tools (12) Malware (1) Man in the Middle (15) Manuales (3) MD5 CRACK (4) Metasploit (57) MSSQL (1) MySQL (6) MySQL CRACK (1) Nmap (6) Nmap NSE (2) Noticias (193) NTLM CRACK (1) Ofuscar (5) OpenSolaris OS (1) OpenSSL (1) ORACLE (1) OWASP (3) Paper (10) PDF (7) PenTest (14) Perl (2) Phearking (13) Phishing (3) PHP (13) phpMyAdmin (1) PoC (1) Premios Bitacoras (1) Presentaciones (11) PRISM (1) Privacidad (2) Programación (12) Programas Linux (41) Programas Windows (41) Pwned (1) Python (5) Reconocimiento (5) Ruby (2) s (1) Scripts (7) Seguridad (145) Seguridad Web (140) Seguridad Wireless (19) Sensitive Data Exposure (2) SHA1 CRACK (1) Shellshock (1) Slides (1) Spoofing (1) Spyware (1) SQLi (19) SQLi Tools (7) SQLMap (2) SSH (1) Textos (74) Tips (57) Troyanos y Virus (11) Trucos (7) Trucos Win (7) Turiales (56) Tutoriales (18) Twitter (1) Ubuntu (2) Underc0de (1) UnderDOCS (1) Unlock (1) URL Redirection (1) UXSS (1) vBulletin (1) Video (48) Virtualización (2) Web T00LZ (17) Wifislax (1) Wikileaks (1) WikiRebels (1) Windows OS (66) Wireless Tools (13) XSS (16) Youtube (1)

 
biz.