Álvaro Núñez-Romero Casado

Como ya os contamos la semana pasada en la primera parte de este artículo, Android Q incluirá la posibilidad de transmitir direcciones MAC aleatorias por defecto, suponiendo un nuevo paso hacia un sistema que respeta más y mejor la privacidad del usuario. Vamos a intentar aclarar en esta segunda entrada qué pasa exactamente con los diferentes sistemas operativos. Qué pasa con iOS En el caso de la randomización de iOS, no es tan perfecta como podría ser. Desde sus inicios con iOS 8 ya han ido perfeccionando la técnica en diferentes versiones. Según la documentación oficial: En sus comienzos, se ve como sólo se generaban las MACs cuando el dispositivo no estaba asociado y estaba bloqueado (Unassociated PNO Scans), además de la necesidad de cumplir una configuración que no todos los usuarios tienen, puesto que era necesario tener desactivado los ajustes de localización, indicando de esta manera al sistema operativo que queríamos ser "anónimos" para que no nos rastreasen. Esto resultaba un problema, por la cantidad de usuarios y servicios que dependen de los servicios de localización. Con la llegada de iOS 9 se incorporaron mejoras, como Location Scans y Auto Join Scans, que permiten la aleatorización en los escaneos y asociaciones de redes wifi cautivas (como por ejemplo en los hoteles), así como en puntos de acceso público (Public Hotspots). Pero siempre habrá pistas para conocer si una misma interfaz está ofreciendo direcciones MAC "falsas". Como ejemplo práctico, observando una captura de probe request en un iPhone con iOS 10, vemos lo siguiente: Captura de paquetes probe request de un iPhone con iOS 10 Fijémonos en la captura. Podríamos llegar a suponer que la MAC 92:56:28:75:80:5d está emitida por la misma interfaz en el momento t0 y que en el momento t1 se cambia a 9a:cc:97:ee:2d:80. Lo suponemos por lo siguiente: Si miramos el último paquete probe request de la MAC 92:56:28:75:80:5d es el número 5566. El primero de la MAC 9a:cc:97:ee:2d:80 es el 5945. Con esto se pretende destacar que no hay cruce de paquetes entre ambas direcciones. Cuando termina uno, empieza otro sin colisiones. No se cruzan los valores. Algo parecido ocurre con es el número de secuencia (SN). Se puede observar que la secuencia sigue de manera más o menos normal (hay un buen salto, pero tiene relación) aun cuando ha cambiado la MAC. Examinando en detalle los paquetes seleccionados: Comparación de dos paquetes que probablemente se traten del mismo dispositivo. Vemos que uno de los Tag: Vendor Specific corresponde a Apple, por lo que se sabe que el dispositivo es Apple, además que también coinciden los otros Tag: Vendor Specific. Esto puede no ser otra gran pista que aumentan las probabilidades de acierto. El problema de los SSID ocultos: Se vuelve a presentar el problema de los SSID ocultos, y este sí que puede ser un factor determinante para conocer si una MAC está cambiando. En la siguiente captura se han seleccionado los dos paquetes que comparten un SSID concreto (oculto) y que viene a significar que una red oculta recordada por la interfaz, está cambiando su MAC, pero preguntando de forma oculta por el SID que recordaba cada cierto tiempo. Se podría llegar a argumentar que podrían ser dos dispositivos diferentes de un mismo usuario que se hayan conectado a la misma red, pero si unimos todas las razones anteriormente expuestas, se puede suponer con bastante probabilidad que el dispositivo en cuestión es el mismo con diferentes MACs. Para terminar de ver todo esto de forma más clara, si se aplica el filtro que busca por ese SSID oculto obtenemos lo siguiente: Filtro con probe request a un SSID oculto Aun con todo esto, una vez que el dispositivo sale del alcance de la monitorización, la próxima vez que vuelva el dispositivo a encontrarse dentro del alcance hay que realizar todo el análisis de nuevo, puesto que el factor del número de secuencia se pierde, y ya hemos mencionado que el único factor determinante que puede existir son los SSID ocultos. Quizás gracias a ellos sea posible volver a detectar a un determinado usuario, pero si no existen SSID ocultos que pregunten los probe request, no se sabrá a ciencia cierta si estamos ante un mismo usuario capturado anteriormente. Un último detalle importante es que Apple aleatoriza también los 24 primeros bits. Recordemos que estos 24 bits deben ser adquiridos a la Autoridad de Registro de IEEE y definen al fabricante. Qué pasa cuando está conectado a una red Wi-Fi Cuando el iPhone está conectado a una red de confianza, los paquetes probe request que envía, sí que los manda con su MAC real. Es a la hora de desconectarse de la red cuando automáticamente empieza a generar los probe request con la MAC aleatoria. iPhone conectado a una Wi-Fi de confianza y enviando probe request con su MAC Address En el caso de la captura, vemos como la MAC real deja de serlo y pasa a ser 16:0d:69:bb:84:0d y que el número de secuencia sigue teniendo "secuencia" y sigue buscando por un SSID oculto que coincide. Creación de punto de acceso falso con el SSID que busca el móvil Si creamos un punto de acceso falso que coincida con el SSID (podemos conocer un SSID por los probe request que se mandan a los a los SSID ocultos) y con el mismo tipo de autenticación que tenía la red, el móvil se intentará conectar automáticamente y se podrá obtener la MAC real del dispositivo. Se puede ver que la MAC no se transmite por los paquetes probe request hasta que el dispositivo está conectado, y en este caso, a no ser que se sepa la contraseña del punto de acceso, el cliente nunca se conectará al punto de acceso falso. Pero sí que intentará hacer la autenticación y por tanto se obtiene en ese momento la dirección MAC. No se captura la MAC usando Wireshark, pero sí que se captura a través de la creación del AP falso, en este caso con la herramienta airbase-ng, de la suite de aircrack-ng. Qué pasa con Android En el caso de Android, la generación aleatoria de direcciones MACs empieza en Marshmallow, la versión 6 del sistema operativo de Google. Según la nota de cambios en Android 6, para mejorar la privacidad de los dispositivos los desarrolladores no tendrán acceso a la dirección MAC del hardware bluetooth y Wi-Fi para usar en sus aplicaciones, y a la hora de intentar obtenerla se consigue el valor constante de 02:00:00:00:00:00. Además tenemos la siguiente nota relativa a la búsqueda de redes Wi-Fi: "Nota: Cuando un dispositivo con Android 6.0 (nivel de API 23) inicia un escaneo de Wi-Fi o Bluetooth en segundo plano, la operación es visible para dispositivos externos como si proviniera de una dirección MAC aleatoria" Antes de que fuera implementado de manera nativa la generación de MACs, el desarrollador Chainflare desarrolló la aplicación Pry-Fi que realiza esta misma acción. Es necesario tener permisos de superusuario para poder usarla (teléfono con root). Qué pasa con Windows Windows implementa la medida de la generación aleatoria de MACs a partir de Windows 10, aunque por defecto está desactivado. Para activar estas opciones se debe ir a la configuración de Red e Internet y seleccionar el apartado de Wi-Fi. Aquí encontramos la opción (desactivada por defecto) de "Direcciones de hardware aleatorias". Si la opción no está habilitada, es posible que se haya establecido ya en el registro una MAC diferente a la original. Es necesario eliminarla del registro para poder activar la opción. Se puede comprobar si el sistema es compatible con la aleatorización con este comando: netsh wlan show wirelesscapabilities activarlo con este: set randomization enabled=yes interface="Wi-Fi" Una característica que ofrece Windows 10 es que permite generar MACs aleatorias también en las redes preferidas, pudiendo decidir por cada red individualmente si queremos una MAC distinta siempre que nos conectemos, una MAC diferente al día o utilizar la real. Las opciones de aleatorización pueden resultar útiles si no se tiene filtrado de MAC en la red. Analizando paquetes con la opción de generar direcciones de hardware aleatorias activadas Nuestras propuestas Hemos desarrollado dos herramientas para sacar el máximo partido a estas funcionalidades en Windows y Android. Estas herramientas permitirán de forma cómoda mejorar la privacidad y el control de conexión de tu red Wi-Fi desde una única herramienta centralizada y sencilla de utilizar, aumentando posibilidades del sistema operativo y de la interfaz de red. Para Windows, disponemos de PsicoWiFi para Windows, disponible desde esta dirección: https://www.elevenpaths.com/es/labstools/psicowifi/index.html https://www.youtube.com/watch?v=dCdj0QchFso Para Android, disponemos de una prueba de concepto llamada PsicoWiFi Mobile, disponible desde esta dirección: https://www.elevenpaths.com/es/labstools/psicowifi-movil/index.html Primera parte del artículo: » MAC aleatorias y privacidad (I).

Android Q incluirá la posibilidad de transmitir direcciones MAC aleatorias por defecto (si bien ya se podía desde la versión 6.0). Esto es un paso hacia un sistema que respeta más y mejor la privacidad del usuario. ¿Por qué? ¿Cómo influye la MAC en la privacidad? ¿En qué casos se transmite y supone un problema? ¿Cómo lo manejan los sistemas operativos? ¿Es suficiente esta aleatoriedad? Vamos a intentar aclarar este interesante asunto. MAC y redes Wi-Fi Cuando nos conectamos a una red inalámbrica, los dispositivos guardan información acerca del sitio al que se conectan (cuando está activada la opción “recordar redes”). La próxima vez que el dispositivo vuelva al mismo sitio, se conectará automáticamente a la red y para que esto sea posible, los dispositivos están constantemente en segundo plano preguntado por las redes Wi-Fi que se encuentran disponibles a su alrededor. Si alguna red coincide con la que tiene almacenada el dispositivo en su lista de redes preferidas (PNL), comenzará un proceso de autenticación. Pero, ¿cómo preguntan los dispositivos si hay redes conocidas a su alrededor? Para estar al tanto de las redes alrededor, se utilizan paquetes llamados probe request. Los dispositivos están constantemente buscando puntos de acceso cercanos, por lo que estos paquetes son mandados a broadcast esperando la respuesta de los puntos de acceso que responderán con paquetes probe response, devolviendo información sobre su SSID (excepto los SSID ocultos) y otra información relacionada con la autenticación. Cuando un SSID coincide con alguno que el dispositivo tenga guardado en su PNL, se manda un probe request a el SSID concreto y comienza el proceso de autenticación y asociación. Este sería el flujo completo de trabajo: probe request => probe response => authentication request => authentication response => association request => association response El problema de esto es que cada vez que un dispositivo cliente manda un paquete probe request, se puede obtener su dirección MAC y como estos paquetes se están enviando constantemente, se podría hacer un seguimiento al dispositivo si se tiene acceso a diferentes puntos de acceso que escuchan esa misma MAC. Crear una red con SSID oculto puede parecer una interesante medida de seguridad para pasar desapercibidos, sin embargo, estas redes tienen un gran inconveniente. Cuando se hace un probe request a broadcast, responden todos los puntos de acceso cercanos que no estén ocultos. Sin embargo cuando el dispositivo busca un punto de acceso con SSID oculto conocido por él, lo que hace es mandar un probe request preguntando por el SSID oculto específico. De esta forma en realidad se está desvelando la identidad de esa red oculta y dando pistas a los posibles atacantes sobre las redes a las que nos conectamos habitualmente o en el trabajo, con lo que volvemos a un problema de privacidad. Los diferentes puntos de acceso podrían escuchar por un SSID oculto característico. Además de esto, algunos equipos han tenido vulnerabilidades en algunas versiones y al realizar los probe request podían publicar parte de su PNL, facilitando a un atacante poder realizar un ataque evil twin (crear punto de acceso falso que conozca el dispositivo de la víctima y se autoconecte sin que la víctima tenga conocimiento de ello). La solución a este tipo de vulnerabilidad es simplemente tener el software actualizado. Así que fundamentalmente, tenemos el problema del tracking y el envío de información potencialmente sensible con las MAC y con los SSID ocultos. Breve introducción al estándar 802.11 y las peticiones Veamos primero un par de deficiones: Beacon frame: El punto de acceso manda periódicamente los beacon frame para anunciar su presencia y la información como el timestamp, SSID y otros parámetros relacionados con el punto de acceso. Continuamente se escanean todos los canales de radio en 802.11 y escucha los beacons para elegir qué punto de acceso es mejor para asociarse. Probe request frame: Una estación manda un paquete probe request cuando necesita obtener información sobre otra estación. Por ejemplo, se envía un paquete probe request para determinar qué puntos de acceso están en su rango. Para descubrir redes nuevas, existen dos tipos de escaneo: Pasivo: escaneando todos los canales y escuchando todos los paquetes (beacons), pero no es eficiente. Activo: en este modelo el dispositivo irá escaneando por canales pero, en vez de escuchando pasivamente las señales de ese canal, se mandan los paquetes Probe Request para preguntar por las redes disponibles en él. En el escaneo activo, los paquetes Probe Request pueden a su vez ser enviados de dos formas: Broadcast (ff:ff:ff:ff:ff:ff). Una vez que el paquete es mandado se establece un límite de tiempo para obtener las respuestas (el dispositivo o la estación comienza un contador ProbeTimer). Al finalizar el timer, el dispositivo procesa la respuesta recibida. Si no hay respuesta recibida la estación se mueve a otro canal y repite el proceso de descubrimiento. En el caso de los ocultos (que no mandan probe requests a todos) el punto de acceso o dispositivo puede mandar un paquete Probe Request especificando el SSID que está buscando (son los llamados paquetes Probe Request Directos). En este caso responderá la única estación o punto de acceso que tenga ese SSID por el que se está preguntando. Se da en los puntos de acceso con SSID oculto. Para entender todo esto a nivel prácticos, son buenas herramientas ProbeKit y Sniff-Probes. Escaneos y protección de privacidad Para evitar el seguimiento a través de la MAC expuesta en los probe request, los fabricantes han tomado una medida "radical": la posibilidad crear direcciones de MAC aleatorias a la hora de realizar este tipo de búsquedas. Los dispositivos móviles fueron los primeros en realizar estas acciones, empezando Apple en su versión de sistema operativo iOS 8, Android en su versión 6.0 Marshmallow y Windows en Windows 10 Mobile. Para Android ya se publicó una aplicación antes de la salida de Marshmallow llamada Pry-Fi, desarrollada por Chainflare, pero que necesita de permisos de root para su ejecución, y por tanto limitando el uso de esta para usuarios avanzados. Los sistemas operativos de escritorio también se han sumado a esta medida de protección anti-tracking. En Windows 10 aparece una opción para generar direcciones MAC aleatorias en las preferencias de Wi-Fi, donde también es posible asignar la generación aleatoria de MAC incluso en las redes preferidas de manera individual. Aunque como se ha demostrado en varias ocasiones, la aleatorización no es siempre suficiente (además de las particularidades con las que lo hacen Windows).Incluso recientemente, unos investigadores de la US Naval Academy, han estudiado y descubierto el método con el que aseguran que pueden trackear el 100% de los dispositivos que usan randomización de MACs. Para ello dicen ser capaces de obtener la MAC original del dispositivo. Toda la información de esta investigación en el paper A Study of MAC Address Randomization in Mobile Devices and When it Fails. En la siguiente entrega, veremos cómo implementan exactamente los diferentes sistemas operativos todo esto.