Diagnóstico Inalámbrico: Analizar redes Wi-Fi en tu macOS

Cada día se puede aprender alguna funcionalidad nueva que contiene el propio sistema operativo, y que, aunque puede llevar un tiempo ya implementada, nunca hemos sabido de su existencia. Por ejemplo, ¿Sabes que hay utilidades que nos pueden ayudar a la hora de buscar el mejor canal para nuestra conexión inalámbrica? ¿Qué tenemos un sniffer para la captura de beacons ya integrado listo para su uso? Lo único que ocurre es que son utilidades que están escondidas y no nos damos cuenta de que existen si no las buscamos bien.

Estas utilidades relacionadas con nuestra conexión inalámbrica se encuentran bajo la aplicación de Diagnóstico Inalámbrico. Es decir, es una herramienta de diagnóstico para conocer que está haciendo que no podamos conectarnos a la WiFi. Una manera de tener acceso a esta aplicación es cuando tenemos un error a la hora de conectarnos a la red WiFi. El error que obtenemos contiene el botón "Ejecutar diagnóstico..." que nos llevará directos a esta herramienta. Aunque no la encontremos en nuestro Lauchpad ni en la carpeta de Aplicaciones, podemos acceder a ella si la buscamos a través del Spotlight ó presionando la tecla alt mientras pulsamos el icono del AirPort.

Figura 1: Abrir Diagnóstico Inalámbrico

Esta aplicación está pensada para hacernos la "vida más fácil" cuando tenemos problemas con nuestra conexión inalámbrica, por lo que lo primero que nos aparece es un asistente. Este asistente examina la conexión inalámbrica en busca de posibles problemas y nos genera un informe para que podamos revisarlo con más detenimiento. Si observamos las opciones que tenemos en el menú "Ventana" vemos varias utilidades interesantes. Por un lado, algunas muy básicas que nos pueden dar información sobre la red a la que ya estamos conectados como son "Información", "Rendimiento" o "Monitor" y por otro lado algunas utilidades que pueden ser más interesantes como son "Explorar"  y el esnifer incluido que lo encontramos tras el nombre de "Detector".

Figura 2: Opciones de Diagnóstico Inalámbrico

Cabe destacar las utilidades "Explorar" y "Detector". Con "Explorar" se pueden ver rápidamente las redes WiFi cercanas y obtener información que puede ser de especial interés como por ejemplo el BSSID, el tipo de seguridad o el canal, entre otros. Si nunca hemos cambiado nuestra password o tenemos seguridad WEP, podemos probar a recuperar nuestra password en una calculadora de claves WEP por defecto, ya que sólo necesitamos el nombre y el BSSID. La utilidad "Explorar" también nos muestra el canal más optimo para nuestra conexión inalámbrica, por lo que nos podemos ahorrar aplicaciones de pago que prometen hacer esto mismo como son WiFi Explorer o WiFi Signal.

En cuanto al "Detector", aunque no es un sniffer como WireShark, sí que es posible obtener información gracias a esta pequeña utilidad que nos proporciona el propio sistema operativo. Sólo tenemos que indicar el canal y la anchura del canal y la tarjeta se nos pondrá a "escuchar el aire" y comenzará a capturar paquetes.

Figura 3: Captura WCAP realizada con los

Esto nos creará un archivo con extensión .wcap que después abriremos con WireShark para examinar su contenido. Como se puede ver en la imagen, se puede obtener información de los Probes que los puntos de acceso de alrededor están enviando. Esto abre un abanico a poder utilizar la información para montar un Rogue AP y las características más interesantes, seguridad, canal, intensidad.  Apple dispone de un recurso para conocer más.

Ataque a iOS evita que la víctima actualice el sistema

En la pasada RootedCON 5ª Edición que tuvo lugar en Madrid, Raúl Siles, un conocido investigador en seguridad español, publicó una charla en la que hablaba de cómo mediante un fallo es posible convencer a un dispositivo iOS de que no existe una versión más actual. Este bug se explota mediante un ataque de red man in the middle - por ejemplo aprovechando las características de conexión a puntos de acceso WiFi maliciosos - y manipulando las cabeceras HTTP de la petición de actualizaciones.

El resultado es que desde iOS 5.0 a iOS 7.1.1 se puede convencer a un dispositivo de que no hay nuevas versiones disponibles y dejarlo fijado en esa versión, con todos los bugs que se hayan descubierto sin parchear.

Figura 1: Dispositivo iOS sin actualizaciones de sistema operativo

La presentación y el vídeo han sido publicados por RootedCON en su canal Youtube, y puedes verla aquí mismo. También la impartió en Area 41 en inglés y está publicada en este enlace.

Figura 2: Raul Siles - iOS: Back to the future

Como bien dice Raúl Siles, este bug podría ser explotado en un esquema de APT, sobre todo contra aquellos dispositivos iOS que solo se venden con WiFi y sin conexiones 3G, consiguiendo tenerlo controlado en todo momento a través de Rogue AP WiFi. Merece la pena que disfrutéis de la charla.

Mac OS X: Saber qué servidor DHCP te ha atendido [Tip]

En un equipo con OS X no es demasiado intuitivo conocer qué servidor DHCP te ha concedido una determinada configuración de red. No existe ningún sitio en la configuración del interfaz gráfico de las Preferencias de Red donde se pueda ver esto, y tampoco está en las opciones que se pueden consultar con el comando ifconfig ni en los comandos habituales de DHCP Client en sistemas, lo que puede liar a más de uno si no se ha topado con esto antes.

Esto no quiere decir que sea difícil, sólo que está en otro sitio. Para acceder a esta información se utiliza el comando ipconfig - no confundir con ifconfig - con el modificador getpacket y el interfaz de red a consultar, de tal manera que se puede acceder a los detalles de configuración DHCP / BootP.

Figura 1: Configuración del servicio DHCP en un interfaz de red en OS X

En concreto, el servidor DHCP que te ha atendido aparece en el valor server_identifier. Esperamos que esta información te ahorre unas vueltas por el interfaz buscando este dato, cuando te preocupe que haya un Rogue DHCP en la red.

iStupid o cómo descubrir la Prefered Network List de iOS

Esta semana se han publicado todas las diapositivas de todas las presentaciones que se han dado en la última RootedCON 2013. Entre ellas, hoy queremos destacar la presentación de Raúl Siles de Taddong "Why iOS (Android and Others) Fail Inexplicably?" sobre lo mal que funcionan las configuraciones WiFi de los dispositivos móviles, en especial las conexiones WiFi de iOS.

Raúl Siles - Wi-Fi: Why iOS (Android and others) Fail inexplicably? [Rooted CON 2013]

En esa presentación, Raúl Siles recoge todos o casi todos los puntos de inseguridad que ya hemos ido publicando aquí, como que no se pueda consultar la Lista de Redes Preferidas PNL (Prefered Network List), que no se puedan manipular la lista de certificados de digitales de entidades confianza, que no se muestre información correcta sobre el tipo de red WiFi al que te conectas, que no se puedan eliminar las redes WiFi de la PNL sino estás en contacto con ella, que no valide el BSSID de la red, que no se pueda establecer en la búsqueda de la red si es una red oculta o no, o que la información que de Apple en los expedientes de seguridad cuando saca una nueva actualización sera prácticamente inexistente.

Figura 1; iStupid

De hecho, Raúl Siles propone usar iStupid, una herramienta de descubrimiento de redes WiFi en la PNL de un dispositivo iOS como forma de auditoria personal de nuestros dispositivos, para saber qué redes son las que busca nuestro dispositivo y por las que puede ser atacada, sin tener que ir a soluciones basadas en apps que necesitas jailbreak, como WiFi Passwords.

Lion: Ataque con Applet y Portal Cautivo en Metasploit

Mac OS X Lion ofrece un sistema de auto-reconocimiento de portales cautivos, que en una red insegura puede ser utilizado para preparar un esquema de ataque. Un portal cautivo es una página web a la que los usuarios son redirigidos cuando se unen a una red, normalmente WiFi, para autenticarse antes de poder utilizar el servicio.  Se suelen encontrar en sitios como hoteles, cafeterías, universidades, centros comerciales, aeropuertos, etcétera. Esta característica también está disponible en iOS.

Esta función, en una red insegura puede representar un riesgo de seguridad general del equipo y del usuario, tal y como explican en Secure State, ya que es perfecta para preparar un ataque. El ataque es posible, ya que es conocida la prueba que Mac OS X Lion realiza para detectar la existencia del portal cautivo, que es la petición de la URL:

http://www.apple.com/library/test/success.html

Cuando esta petición falla se abre una ventana especial en el navegador para el portal cautivo. Este tipo de comportamiento está preparado para los portales cautivos que se ofrecen en redes inalámbricas abiertas, no con cifrado WEP o WPA, y un atacante puede utilizarlo como vamos a ver ahora mismo.

La descripción general del ataque

Los atacantes pueden controlar la página del portal cautivo mediante el uso de técnicas ya conocidas, como las empleadas, por ejemplo, por el script Karmetasploit. Se pueden configurar servidores DHCP y DNS, para manejar las comunicaciones de la víctima, incluso monitorizar el tráfico completo, una vez que se ha conseguido un esquema de man in the middle.

El objetivo es interceptar la petición al dominio www.apple.com que realiza Mac OS X Lion para detectar el portal cautivo. Así, una vez que el atacante puede redirigir el tráfico del cliente al sistema del atacante, en lugar de a Apple, se puede realizar una variedad enorme de ataques client side attack.

Con el módulo auxiliary/server/http se podrían capturar cookies de la víctima, mediante el uso de alguna página gancho. Pero quizá uno de los más interesantes es el uso de un Applet de Java y conseguir una shell reversa con Meterpreter para Mac OS X.

Este ataque no es nada nuevo, y simplemente se reduce a que a la víctima le saldrá una ventana con un Applet que pedirá autorización simulando ser parte del portal cautivo. Cuando la víctima acepte, se ejecutará la sesión de Meterpreter devolviendo el control a la máquina del atacante. 

El escenario

Supongamos que nos situamos en una famosa tienda de café. Los usuarios van con sus equipos Mac OS X Lion y aprovechan para navegar, consultar el correo, realizar sus gestiones bancarias, lo típico de un café. Es razonable suponer que CoffeShopX podría ser un SSID válido recordado por su Mac Book Air/Pro. Un atacante establece un rogue AP abierto de WiFi emitiendo el SSID CoffeShopX, mientras que también hace de DHCP y DNS. Una vez que la víctima con su Mac se une a la red inalámbrica - el atacante se aprovecha de la no validación del BSSID por parte de Mac OS X Lion y esto propicia múltiples esquemas de ataque -, la solicitud a www.apple.com será redireccionada al atacante. ¿Cómo conseguir la shell de Meterpreter? Mediante el uso de los siguientes pasos.

• Conectar a una red inalámbrica. El atacante creará su propia red con un rogue AP spoofeando el SSID original, por ejemplo con Karmetasploit. Para garantizar que el AP original sea inútil, se puede hacer antes un ataque de agotamiento de direcciones IP en el servidor DHCP original.

• Utilizar el módulo auxiliary/server/dhcp para ejecutar el servidor rogue DHCP.

Figura 1: Configuración DHCP

•  Utilizar el módulo auxiliary/server/fakedns para configurar un servidor DNS que falsifique las peticiones de resolución de nombres. La dirección IP que se devolverá será la del atacante. 

Figura 2: Configuración DNS

• Utilizar el módulo exploit/multi/browser/java_signed_applet para configurar un servidor web malicioso. La variable SRVPORT se deja en el puerto 8080, el URIPATH se establece en /portal y no hay que configurar mucho más, simplemente indicar que SRVHOST es la dirección IP del atacante.

Figura 3: Configuración del módulo java_signed_applet

•  A continuación, en un servidor Apache, se debe configurar una página web, index.html. Esta página será la mostrada por el atacante cuando se realicen las peticiones al dominio de Apple, al puerto 80. Esta página redirige al exploit de Java. 

Figura 4: Código de la página web montada en Apache

•  Toca esperar las conexiones de los usuarios, el proceso pasará a ser automático y se conectarán nada más entrar a la red. 

Figura 5: Sesión inversa de Meterpreter

El ataque funcionará si el usuario dispone de Java en su equipo, cosa no muy dificíl después de que se encuentre en billones de dispositivos en el mundo según el eslogan de Java. Cuando los usuarios que se conectan a la falsa red ven la carga de Java dentro de su navegador en la página del portal cautivo, tendrán 2 opciones permitir la ejecución o no, si pulsan en permitir se creará la sesión inversa de Meterpreter.

Figura 6: El supuesto portal cautivo solicitando autorización para el Applet Java

Os recomendamos que controléis el BSSID real al que se conecta nuestro equipo, y sobretodo extremeis las precauciones en hoteles, cafeterías, aeropuertos, etcétera. Esta técnica, aunque tiene una parte basada en la ingeniería social, es probable que engañe a muchos, que piensen que es la manera normal de conectarse al portal. Si ya te has conectado antes a ese portal cautivo... no piques.

Si quieres aprender más sobre cómo funciona Metasploit, puedes leer el libro de Pablo González Metasploit para Pentesters

WiFis Ad-hoc en iOS: Cuidado a qué te conectas

Con la aparición de las redes WiFi, rápidamente proliferaron los ataque con Rogue APs, equipos que simulan ser una red conocida para que la víctima se conecte a ella y tener un perfecto ataque de man in the middle. Como esto dio grandes resultados, rápidamente aparecieron los que lo hacían desde equipos de escritorio haciendo uso de las conexiones Ad-hoc. 

Para detectar las conexiones ofrecidas vía Ad-hoc, es decir, las ofrecidas por otro equipo cercano, los sistemas operativos ofrecen alguna alerta que permita detectarlas fácilmente, como se puede ver en la visualización de redes WiFi en Mac OS X Lion 10.7.4. En la imagen inferior se puede ver cómo Secureap y la red iPhone de Pablo Escorial son redes Ad-hoc ofrecidas en el alcance de este equipo.

Figura 1: Redes WiFi visualizadas en Mac OS X Lion

Sin embargo, en el sistema iOS esto no está funcionando de igual manera. En la imagen de abajo hay una red llamada Free Public WiFi que realmente es una red Ad-hoc, y como puede verse, no ofrece ningún icono que la diferencie de las redes de Infraestructura, lo que simplifica los ataques de Rogue AP realizados con este tipo de conexiones Ad-hoc.

Figura 2: Redes WiFi visualizadas en iOS

Ten especial cuidado con las redes WiFi a las que te conectas. Elimina todas las redes WiFi cuando hayas terminado de conectarte a ellas, y recuerda que los sistemas iOS no validan el BSSID de la red, lo que las hace más atacables ante los ataques Rogue AP.