Cómo espiar masivamente a nivel Geo-estratégico con el Wi-Fi Positioning Systems (WPS) de tu iPhone o tu Android

Los terminales Apple y Android utilizando hace mucho tiempo el llamado GPS-Asistido por WiFi, o lo que es lo mismo, acceder a la ubicación GPS de un dispositivo no solo por la señal GPS que se recibe de los satélites, sino analizando el mapa de dispositivos WiFi que se encuentran alrededor. Esto lo habréis notado en vuestras aplicaciones de mapas, ya que si desconectáis la WiFi de vuestro terminal, es más probable que se confunda en los mapas. Pero como vamos a ver, también estás ayudando a que se cree una base de datos mundial de inteligencia. Os lo explico.

Figura 1: Cómo espiar masivamente a nivel Geo-estratégico con el

Wi-Fi Positioning Systems (WPS) de tu iPhone o tu Android

El funcionamiento es muy sencillo, los dispositivos iPhone y Android recolectan qué BSSIDs tienen a su alrededor, la potencia de la señal, y la ubicación GPS que leen desde los satélites. Esto va a una base de datos mundial, donde se ubican los puntos WiFi en puntos físicos de los mapas.

Después, cuando se tienen ubicados esos puntos WiFi, para un dispositivo móvil, saber donde se encuentra es tan sencillo como pasar la lista de los BSSID que ve, y el servidor WPS de Apple o de Android le devuelve la ubicación precisa de dónde se encuentra. Evitar que tu Apple sea parte de este servicio WPS alimentándolo con datos no es posible, y en el caso de Google, tienes que cambiar el nombre de tus redes WiFi.

Figura 2: iSniff captura las redes WiFi que envían los iPhone para mejorar el GPS

Es decir, los terminales son generadores de la base de datos, así como consumidores de ellas, con lo que hay un mantenimiento constante de la misma. Con altas, bajas, modificaciones y consultas basadas en pares BSSID-GPS. Y esta información puede ser muy valiosa para muchas, muchas, muchas cosas, como ya hemos visto en el pasado, donde usando una herramienta como iSniff-GPS se podría saber qué redes WiFi estaba buscando un terminal iPhone, preguntar por ellas a la base de datos WPS, y saber exactamente en qué coordenadas GPS había estado ubicado un terminal iPhone. Una de las formulas habituales de preparar un ataque a un iPhone usando Rogue-AP como contamos en el libro de Hacking iOS (iPhone & iPad).

Figura 3: Libro de Hacking iOS (iPhone & iPad) 2ª Edición
de Chema Alonso, Alejandro Ramos, Igor Lukic, Ioseba Palop.

Esto no es nuevo. Lo conocemos desde el año 2009, 2010 que comenzaron a estudiarte estas cosas, y lo hemos utilizado incluso como forma de protegerse contra redes WiFi con Rogue AP, usando WIFI SSID-Prinning. Sin embargo, este mes se ha publicado un interesante artículo académico titulado "Surveilling the Masses with Wi-Fi-Based Positioning Systems" donde unos investigadores han hecho un estudio a escala con las bases de datos WPS, haciendo un volcado de las ubicaciones GPS de grandes cantidades de datos BSSID a lo largo de periodos de tiempo, lo que permite sacar Inteligencia Geo-Estratégica a los estados, o lo que es lo mismo, que esas bases de datos WPS que tienen Apple y Google tienen un valor estratégico de inteligencia enorme.

Figura 4: "Surveilling the Masses with Wi-Fi-Based Positioning Systems"

Para ello, la aproximación es bastante curiosa. Cada terminal iPhone y Android consulta sus bases de datos WPS con la lista de BSSIDs que conocen para obtener información de ubicación. Si se manda un solo BSSID a la base de datos en una consulta, se puede saber exactamente la ubicación GPS de ese dispositivo WIFI, así que si pudiéramos hacer una consulta con todos los posibles BSSIDs que se pueden construir, tendríamos un volcado exacto completo de la base de datos WPS en un determinado instante de tiempo. 

Figura 5: Algoritmo para hacer fuerza bruta a la base de datos WPS

con los OUIs de los principales fabricantes.

Esto no es muy práctico, pero si se analizan las posibles BSSID reservadas por fabricantes, que son un número limitados de OUI, se podría hacer un ataque de fuerza bruta más limitado, que de un volcado de la base de datos muy relevante. 

Figura 6: Mapa de calor de BSSIDs descubiertos aleatoriamente con OUIS

Y aún mejor, como lo importante es que los identificadores tienen que ser de algún dispositivo que alguna vez haya podido estar encendido al alcance de un terminal Android o iPhone, utilizando datasets de BSSIDs volcados por Wardrivers en todos los proyectos de Wardriving que existen desde hace años, se puede crear un Corpus de Datos de BSSID válidos a nivel mundial de dispositivos WiFi identificados.

Figura 7: WIGLE.NET tiene un DataSet de WiFi, BlueTooth y Antenas Celulares

Con la aproximación de poder hacer un ataque de fuerza bruta a un OUI de un fabricante de interés, y con el Corpus Mundial de dispositivos BSSID volcados en datasets por Wardrivers, los investigadores pudieron hacer un volcado relevante de las bases de datos WPS en varios instantes de tiempo, permitiendo ver cómo afecta un determinado evento militar, una catastrofe o un atentado en las bases de datos WPS, lo que permite inferir el impacto que ha tenido dicho evento.

Figura 8: Los puntos rojos son dispositivos WiFi en Apple WPS que estaban antes

del incendio en la isla de MAUI pero que un mes después habían desaparecido

Al mismo tiempo, al poder hacerse consultas de dispositivos que se mueven por el mundo, se pueden localizar los puntos WiFi que se desplazan kilómetros, y conocer cuáles de ellos han estado en zonas de interés militar para los estados, o poder saber cuando un dispositivo que ha estado en un determinado país está entrado en tu país y levantar alertas de seguridad.

Figura 9: Dispositivos que han entrado en Ucrania y dónde estaban un mes antes

Es decir, los investigadores han demostrado el valor Geo-Estratégico de estas bases de datos WPS, y el impacto que puede tener tanto para el espionaje masivo de países, como para la inteligencia, y cómo podría ser explotada por cualquier nación para preparar un ataque o tener información crucial de objetivos, lo que es algo sensible. 

Figura 10: Mapa de calor de dispositivos WiFi en Gaza entre el

13 de Octubre y el 19 de Noviembre de 2023.

Por supuesto, los investigadores han hecho una publicación responsable de sus descubrimientos, y han avisado de todas las medidas que se pueden tomar para mitigar este tipo de volcados de datos WPS desde actores adversarios que puedan estar utilizando este tipo de información para cosas que no deseamos nadie.

¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)  

OpenWifiPass: Hacking iPhones con WiFi Sharing Protocol

En el artículo de hoy vamos a hablar de OpenWifiPass, que es una prueba de concepto que se ha publicado recientemente y está ligada con los trabajos “Wi-Fi Sharing for All: Reverse Engineering and Breaking the Apple Wi-Fi Password Sharing Protocol” y “Disrupting Continuity of Apple’s Wireless Ecosystem Security: New Tracking, DoS, and MitM Attacks on iOS and macOS Through Bluetooth Low Energy, AWDL, and Wi-Fi” centrados en analizar el uso que Apple hace las tecnologías BLE. 

Figura 1: OpenWifiPass: Hacking iPhones con WiFi Sharing Protocol

En el pasado en Ideas Locas ya tomamos una investigación similar, la popular apple_bleee, como base para crear Airdrop Crazy y añadirlo a la lista de herramientas y utilidades para usar en cualquier proyecto de Hacking iOS: iPhone & iPad, y en este caso esta PoC se basa en las dos citadas, además de utilizar el mismo conjunto de protocolos.

Figura 2: Libro de Hacking iOS (iPhone & iPad) 2ª Edición
de Chema Alonso, Alejandro Ramos, Igor Lukic, Ioseba Palop.

-

Hoy hablaremos del proyecto OpenWifiPass el cual permite escanear en busca de peticiones Bluetooth de dispositivos iPhone/iPad que están solicitando contraseña de WiFi para conectarse a una red. Esta es una característica de los dispositivos de Apple que si tienes un iPhone, seguramente la hayas utilizado en algún momento. Imagínate que estás en casa de un amigo y en vez de darte la contraseña para que la introduzcas, tu iPhone solicita que le compartan la contraseña de la WiFi al dueño de la casa, que también tiene un iPhone.

Figura 3: Opción de compartir la clave de la WiFi en iPhone

Como se indica en el Github del proyecto de OpenWifiPass es una prueba experimental de ingeniería inversa del proyecto Open Wireless Link. El código se proporciona con fines de investigación y educativos. Como prueba de concepto que es el proyecto no ha sido probado y está incompleto, aunque funcional para la prueba de concepto. ¿Qué es incompleto? Realmente el código no verifica la identidad del solicitante de la contraseña a través del protocolo.

Requisitos para probar el proyecto

Los requisitos para probar el proyecto son pocos, nos vale con tener a mano una Raspberry Pi 4 y disponer de Raspbian o cualquier distro GNU/Linux que ejecutemos en una Raspberry. Desde el punto de vista de dependencias se hará uso de bluepy, pero el proceso de instalación es realmente sencillo, por lo que no habrá problemas. El código de la herramienta está escrito en Python.

Figura 4: "Raspberry Pi para Hackers & Makers: PoCs & Hacks Just For Fun"
de Amador Aparicio, Pablo Abel Criado y Héctor Alonso

El hacerlo con Raspberry es por darle un toque "maker" y hacerlo "portable" y porque tiene el adaptador de Bluetooth integrado y va a ser rápido montar el proyecto, pero podría hacerse en cualquier entorno con un adaptador Bluetooth compatible. El adaptador debe poder utilizar Bluetooth Low-Energy.

Figura 5: Repositorio GitHub de OpenWifiPass

¿Cómo instalamos el proyecto? Este paso es uno de los más sencillos, para el tipo de herramientas o pruebas de concepto con los que nos movemos generalmente. Lo primero será hacer el git clone del proyecto y, posteriormente, ejecutar la siguiente instrucción pip3 install ./openwifipass. La instalación es bastante rápida y nos prepara un módulo llamado openwifipass. Para la ejecución de la herramienta debemos ejecutar la instrucción:

sudo -E Python3 -m openwifipass --ssid [nombre SSID de la rea a compartir contraseña WiFi] --psk [contraseña que se quiere enviar al dispositivo].

Cuando lo arrancamos, veremos que se queda en “Start Scanning” un rato, y parece que no ocurre nada. Esto es normal, ya que debemos esperar a que desde un iPhone/iPad nos soliciten la contraseña WiFi de una red conocida. Nosotros, en el ejemplo, estamos ofreciendo la red bit_up, por lo que cuando un iPhone/iPad en nuestro alcance, intente conectarse a la red se produce el intercambio de información.

Figura 6: Arrancando OpenWifipass 

Nos estamos haciendo pasar por un dispositivo de Apple y estamos negociando y entregando la contraseña WiFi que el usuario quiere, y en el momento en que algún dispositivo se quiera conectar a la red, se entrega la password que hemos decidido nosotros.

Figura 7: Un dispositivo ha pedido la password y se la hemos entregado

Mientras tanto en el dispositivo móvil encontramos lo siguiente, la contraseña se configura automáticamente y se conecta contra la red WiFi. En la imagen no se visualiza, pero en el apartado de “contraseña” faltarían los puntos de la contraseña introduciéndose y conectando con la red.

Figura 8: Contraseña entregada al iPhone

La prueba de concepto está genial. El trabajo es brillante y todos los detalles de la investigación se irán publicando por parte de sus investigadores, pero lo que nos queda claro es que es más que utilizable, por ejemplo, en un ejercicio de Red Team en múltiples escenarios. Pongamos que necesitamos ganar acceso a un sitio o conseguir información de un objetivo concreto, dentro del ejercicio de Red Team. 

Figura 9: El Red Team de la empresa
de Eduardo Arriols en 0xWord

El montaje de una red WiFi a través de un punto de acceso bajo nuestro control - un Rogue AP - con el SSID de “nombre_empresa” puede ser llamativo para muchos. En el momento que el usuario intente conectarse desde iOS, tendríamos montado la rasp con la PoC y le proporcionaríamos la contraseña al usuario. En ese instante, el usuario se conecta a nuestro punto de acceso WiFi y toda su comunicación pasa por nosotros en un esquema de Man in the middle. El esquema y el ataque mola, muy aprovechable en un ejercicio de Red Team, pero eso lo dejamos para otro artículo.

 

Saludos,

Pablo González Pérez (@pablogonzalezpe), escritor de los libros "Metasploit para Pentesters: Gold Edition", "Hacking con Metasploit: Advanced Pentesting" "Hacking Windows", "Ethical Hacking", "Got Root",  “Pentesting con Powershell (2ª Edición)”, "Pentesting con Kali Silver Edition" y de "Empire: Hacking Avanzado en el Red Team", Microsoft MVP en Seguridad y Security Researcher en el equipo de "Ideas Locas" de la unidad CDCO de Telefónica.  Para consultas puedes usar el Buzón Público para contactar con Pablo González - Conseguir 100 Tempos Gratis en MyPublicInbox

 Contactar con Pablo González

Wild Wild Wifi "Dancing with wolves": 5 WEP/WPA/WPA2-TOTP-Biometry

La última parte de esta serie dedicada a Wild Wild WiFi tiene que ver con el último de los trabajos que hicimos en este área de estudio. Se trata de dar una vuelta de tuerca a la idea del protocolo WEP-TOTP, WPA-TOTP y WPA2-TOTP de la que os hablé en la parte 4 de esta serie. Se trata de no utilizar una Pre-Shared Key en el proceso, y sustituirla por un derivado biométrico del usuario de la red.

Figura 34: Wild Wild Wifi "Dancing with wolves": 5 WEP/WPA/WPA2-TOTP-Biometry

Este método lo depositamos en una patente en Julio de 2017, debido a que la idea tenía suficientes avances tecnológicos como para merecer la invención, y el funcionamiento es bastante sencillo una vez vistas las partes anteriores.

Figura 35: Patente registrada en Julio de 2017

El objetivo es generar una clave de una red WEP, WPA o WPA que sigan utilizando el protocolo PSK estandarizado, pero hacer que la clave PSK que tienen los protocolos estándares se cambie cada cierto tiempo, utilizando una clave generada por un algoritmo TOTP. Este algoritmo generará la clave final utilizando como parte del proceso un derivado de la biometría de la persona que quiere usar la red WiFi.

Figura 36: Parte biométrica del proceso de enrollment.

Para ello, durante la fase de aprovisionamiento inicial de la red WiFi se hará un proceso de enrollment de la biometría del usuario - solo una vez - en el Access Point. El proceso generará un hash de la biometría que será utilizado posteriormente.

Con el valor biométrico como dato de entrada se generará un valor aleatorio que será parte de la semilla del algoritmo TOTP que generará las claves que la red WEP, WPA o WPA2 TOTP utilizará para cifrar los datos del usuario por la red. Este valor será pasado al cliente usando algún método, como mostrarlo por pantalla con un QRCode o de cualquier otra forma.

Figura 37: Parte aleatoria del proceso de aprovisionamiento

En cualquier intento de conexión el cliente pedirá conexión, y el servidor (Access Point) le hará un "Challenge" que deberá cumplir. Para ello, el cliente pedirá las credenciales biométricas al usuario para hacer el derivado de la misma. Después extraerá el valor aleatorio que el Access Point le entregó como parte final del proceso de enrollment, y con la suma de ambos tendrá la semilla del algoritmo TOTP para generar la clave de cifrado temporal.

Figura 38: Proceso de establecimiento de conexión a la red WiFi

Con este valor, cifrará un mensaje "Hello" que podrá ser descifrado solo por el Access Point que tiene el valor biométrico del usuario (que obtuvo durante el proceso de enrollment) y el valor aleatorio que se generó, lo que le permitirá tener el mismo algoritmo TOTP de generación de claves en ambos puntos de la comunicación.

Conclusiones

Al final, el trabajo que hemos visto en esta serie no es más que una reflexión continua sobre cómo se pueden mejorar las medidas de seguridad que tienen los protocolos conocidos y cómo podrían funcionar de manera diferente.

A lo largo de las partes hemos visto que se podrían mejorar las opciones de seguridad que tienen los clientes WiFi de dispositivos móviles o sistemas operativos para detectar ataques en la red, para acotar los ataques de Rogue AP utilizando SSID Pinning. Cómo se pueden reducir las ventanas de exposición de las claves PSK en protocolos WEP, WPA o WPA2-PSK utilizando algoritmos TOTP, y cómo se puede hacer este proceso más robusto haciendo uso de biometría.

Figura 39: Wild Wild Wifi

Para poder seguir el trabajo completo, os dejo las diapositivas subidas a SlideShare, y la lista completa de todos los artículos publicados en esta serie, con las explicaciones correspondientes.

1.- Mummy 

2.- SSDI Pinning 

3.- PsicoWiFI 

4.- WEP/WPA/WPA2-TOTP

5.- WEP/WPA/WPA2-TOTP-Biometry

Saludos Malignos!

****************************************************************************
- Wild, Wild, WiFi: 1.- Mummy
- Wild, Wild, WiFi: 2.- SSID Pinning
- Wild, Wild, WiFi: 3.- PsicoWifi
- Wild, Wild, WiFi: 4.- WEP/WPA*-TOTP
- Wild, Wild, WiFi: 5.- WEP/WPA/WPA2-TOTP-Biometry
****************************************************************************

Wild Wild Wifi "Dancing with wolves": 3.- PsicoWiFi

Continuando con el trabajo que hicimos con Mummy en "Living in the Jungle" y la conceptualización de la protección mediante SSID Pinning que queda descrita en el artículo anterior construimos un par de clientes. Uno de ellos para el sistema operativo Android y otro para el sistema operativo Microsoft Windows. 

Figura 16: Wild Wild Wifi "Dancing with wolves": 3.- PsicoWiFi

Este cliente Wi-Fi que implementa SSID Pinning se denominó PsicoWiFi. Ahora veremos las diferencias entre los clientes PsicoWiFi para Android y PsicoWiFi para Windows, ya que hay pequeñas diferencias en la implementación.

Figura 18: Logo de PsicoWiFi

6.- PsicoWiFi para Android

El cliente PsicoWiFi para Android implementa las tres opciones que se han explicado anteriormente. Se asume que el dispositivo Androrid tiene GPS y que está activado en el momento de conectarse por primera vez a una nueva red. No obstante, el usuario tiene la opción de elegir qué protección quiere aplicar o no a cada conexión cuando hace el SSID Pinning.

Figura 19: PsicoWiFi para Android

El cliente PsicoWFi para Android, cuando se realiza una conexión automática a una red de la Lista de Redes Preferidas en el dispositivo, comprobará todas las opciones de SSID Pinning y, si no las cumple, desconectará la red y pasará al siguiente perfil de red en la Lista de Redes Preferidas, como se puede ver en el siguiente vídeo.

Figura 20: Demo de PsicoWiFi para Android

Este cliente no incorpora las opciones de seguridad de Mummy, pues es solo una PoC, pero por supuesto se podrían añadir todas las opciones descritas e implementadas en la otra herramienta para juntar todas las protecciones.

7.- PsicoWiFi para Windows

En el caso de PsicoWiFi para Windows no se utiliza la opción de ubicación por GPS, ya que se asume que la gran mayoría de sistemas de escritorio con MS Windows no llevan este tipo de característica.

Figura 21: PsicoWiFi para Windows

Por eso, como se ve en el vídeo, el funcionamiento es similar.

Figura 22: Demo de PsicoWiFi para Windows

Como se ve, funciona como un servicio en el sistema operativo MS Windows que se invoca cada vez que se produce una autoconexión a una red Wi-Fi de la Lista de Redes Preferidas para comprobar el SSID Pinning y decidir si debe dejar la conexión o desconectarla.

8.- MAC Spoffer

Como opción de privacidad extra en los últimos sistemas operativos Microsoft Windows se añadió la opción de hacer un MAC Spoofing periódico para evitar el tracking de personas por medio de su dirección MAC y hacer más complicado el tracking de los paquetes. 

Figura 23: Opción de usar dirección de hardware aleatorias deshabilitada

Esta opción solo está disponible en las últimas versiones de MS Windows, y además, debe ser activada a nivel de tarjeta de red por el usuario, ya que por defecto no se utiliza esta característica. Por supuesto, nos parece una buena idea de seguridad, y por eso pensamos que esta opción se puede añadir a todos los clientes Wi-Fi que se utilicen en todos los sistemas operativos, como se ve en este vídeo.

Figura 24: Demo de MAC Spoofer en PsicoWiFi para Windows

En este caso la hemos aplicado a PsicoWiFi para Windows, pero podría ser añadido - y creemos que debería estar presente por defecto - en todos los sistemas operativos de escritorio y móviles que se utilizan hoy en día.

Saludos Malignos!

****************************************************************************
- Wild, Wild, WiFi: 1.- Mummy
- Wild, Wild, WiFi: 2.- SSID Pinning
- Wild, Wild, WiFi: 3.- PsicoWifi
- Wild, Wild, WiFi: 4.- WEP/WPA*-TOTP
- Wild, Wild, WiFi: 5.- WEP/WPA/WPA2-TOTP-Biometry
****************************************************************************

Wild Wild WiFi "Dancing with Wolves": 1.- Mummy

Era el año 2010 cuando estuvimos jugando con las redes Wi-Fi. Por aquellos años ya se conocía una gran cantidad de ataques a redes inalámbricas, y sin embargo las redes Wi-Fi inseguras estaban muy extendidas. En aquellos años pensamos que era posible hacer, o añadir protecciones en el cliente Wi-Fi que venía con los sistemas operativos, y trabajamos en hacer un pequeño cliente para Windows que añadiera algunas protecciones extras.

Figura 1: Wild Wild WiFi "Dancing with Wolves": 1.- Mummy

Para comenzar el artículo, vamos a analizar qué hicimos en aquel trabajo del año 2010, para luego ir viendo qué hemos ido haciendo en ese área de seguridad después. Comencemos por Mummy.

1.- Living in the Jungle

Para explicar todo lo que teníamos en mente, hicimos un paper al que llamamos "Living in the jungle: Legitimate users in legitimate, insecure Wireless Networks", que acompañamos con una pequeña herramienta, en modo PoC, llamada Mummy.

Figura 2: Living in the Jungle: Legitimate users in Legitimate Insecure Wireless Networks

El trabajo, que podéis leer en el documento adjunto, recogía una pequeña matriz de riesgos en redes Wi-Fi inseguras en aquellos tiempos, donde se quedaban fuera del estudio las redes empresariales, ya que estábamos focalizados en redes legítimas inseguras. Podríamos haber mirado redes EAP-MS-Chapv2 o similares redes de infraestructura con vulnerabilidades conocidas, pero nuestra opción fue centrarnos en las más comunes, así que miramos las redes OPEN, WEP, WPA-PSK, WPA2-PSK.

Figura 3: Matriz de riesgos en "Living in the jungle" (2010)

Como la inseguridad de las redes WPA-PSK y WPA2-PSK en aquellos tiempos dependía de la facilidad o dificultad de crackear la clave mediante ataques al proceso de autenticación, metimos un pequeño estudio de lo difícil que sería para un atacante romper la contraseña. En los artículos de Atacar redes WPA/WPA2-PSK y Crackear WPA/WPA2-PSK hablábamos en el año 2009 de estas cosas.

Figura 4: Estudio de complejidad de contraseñas en WPA/WPA2-PSK

También miramos el comportamiento de los vecinos conectados a la red, añadiendo detección de ataques de ARP-Spoofing, 0-Attack, o inyección de paquetes en redes WEP para saber si teníamos un atacante activo en la red.

Figura 5: Cliente Mummy con nivel de riesgo de la red Wi-Fi

Todo eso lo implementamos en Mummy, con el objeto de que el cliente Wi-Fi diera más información sobre la red a la que nos estábamos conectando para tomar una mejor decisión. Por supuesto, aunque la red fuera muy segura, y no pasara absolutamente nada en este momento, hace falta recalcar que la red Wi-Fi podría tener un "insider" previo que hubiera conseguir la clave con anterioridad, y ahora no estuviera activo, y puede ser que el AP ya estuviera comprometido desde origen. Cosas que no tenían nada que ver con este trabajo.

Figura 6: Alertas de seguridad en Mummy

Aquello se quedó en 2010, pero las tecnologías Wi-Fi, y lo relativo a su seguridad, siguió avanzando, a veces con mejoras positivas, otras con empeoramientos en términos de seguridad en pro de la usabilidad.

2.- Clientes Wi-Fi en Windows, iOS y OSX/macOS empeorados

Con la popularización de los smartphones vimos que los clientes que venían con iOS eran bastante pobres en seguridad, como escribía yo en un artículo de Seguridad Apple del año 2011, donde se echaban en falta las siguientes posibilidades.

Figura 7: Carencias del cliente Wi-Fi en iOS

De hecho, en 2012, cuando hicimos los ataques basados en JavaScript Botnets a dispositivos iOS (iPhone & iPad), lo hacíamos utilizando Rogue APs que explotaban esas debilidades, y en el libro de Hacking iOS: iPhone & iPad, detallamos cómo robar datos de la navegación desde Safari para iOS en un iPad o iPhone usando estas técnicas.


Figura 8: Owning bad guys {and mafia} using Javascript Botnets
Además, los sistemas operativos OS X/macOS habían rebajado el nivel de seguridad en el cliente Wi-Fi, eliminado del sistema la comprobación de BSSID del AP en el perfil de conexión almacenado. Esto tiene riesgos importantes que aprovechan los ataques de Rogue AP tal y como reflexionamos en este otro artículo. Sin embargo, algo que Windows sí hacía, fue a peor en términos de seguridad y a "mejor" en términos de usabilidad, y la comprobación de BSSID también se eliminó de los sistemas operativos Windows 10.


Figura 9: Raúl Siles en 2013 analizando los clientes Wi-Fi
Es decir, no solo no habíamos mejorado la seguridad, sino que habíamos ido empeorándola poco a poco haciendo que el control que un usuario tiene sobre las conexiones a las redes Wi-Fi es menor cada vez y las implementaciones son bastantes pobres. En la charla de Raúl Siles de RootedCON 2013 se puede ver como de "pobres" eran esos clientes Wi-Fis.

¿Se puede mejorar esto? Pues de muchas formas, y nosotros jugamos con esto durante estos años haciendo cosas de todo tipo. Os lo iré contando en las siguientes partes.

Saludos Malignos!

****************************************************************************
- Wild, Wild, WiFi: 1.- Mummy
- Wild, Wild, WiFi: 2.- SSID Pinning
- Wild, Wild, WiFi: 3.- PsicoWifi
- Wild, Wild, WiFi: 4.- WEP/WPA*-TOTP
- Wild, Wild, WiFi: 5.- WEP/WPA/WPA2-TOTP-Biometry
****************************************************************************

Antes del test de intrusión vete de Wardriving por la zona

Cuando quieres utilizar una JavaScript Botnet con un Rogue AP para infectar terminales móviles la elección del nombre SSID de la red WiFi es fundamental. Para ello, puedes sniffar el espacio para que ver qué redes están buscando, pero esto puede resultar infructuoso si tienes el tiempo limitado. Deberías estar un tiempo antes recolectando mensajes Probe para tener una buena miriada de redes WiFi que puedas utilizar en la configuración del Rogue AP.

El problema en ese situación es que si las redes a las que se conectan esos dispositivos tienen algún tipo de seguridad, no será posible establecer la conexión con ellos si no sabemos los protocolos que usa y la contraseña. Solo nos funcionaría con redes abiertas a las que se hubiera conectado antes.

Para conseguir que la "cangrejera" WiFi que vas a montar en la recepción de la empresa a la que vas a hacer el test de intrusión se llene de cangrejos según estos vayan pasando, lo mejor es que tengas listas redes WiFi con tu Karmetaexploit y tu Metasploit que los usuarios habitualmente utilicen. Por ejemplo, unas buenas candidatas serían las de cafeterías y restaurantes cercanos a los que los empleados puedan irse a comer de vez en cuanto.

Para ello, antes de montar tu Rogue AP, lo suyo es que te hayas hecho con un alguna herramienta de WarDriving que te provea de las redes WiFi con las contraseñas cercanas de las que tienes cientos para dispositivos móviles como WiFiFoFum para iOS e incluso como 4sqrWiFi que permiten encontrar redes vía FourSquare. Si no, te das un paseo con tu suite de herramientas de cracking preferida y haces tú el mapa de las redes WiFi más probables que vayan a usar los empleados cuando vayan a tomar café o comer.

Figura 1: WiFiFoFum para iOS

El resto es poner tu Rogue AP y esperar que iPhones, iPads, incluso los Mac OS X o cualquier otro dispositivo que no valide el BSSID - ¿Es importante la validación del BSSID? - de la WiFi se coma la conexión, pida un fichero a través nuestro y se coma el JavaScript con el Payload de la Botnet. Y así estará, dándonos acceso a la Intranet de la empresa, a la que podremos llegar a través de este equipo infectado haciendo un ataque dirigido con la botnet en JavaScript.

Así que ya sabes, antes de preparar un Rogue AP + JavaScript Botnet hay que hacer un poquito de WarDriving por la zona para tener éxito.

Saludos Malignos!