MAC aleatorias y privacidad (II)

Álvaro Núñez-Romero Casado    22 abril, 2019
MAC aleatorias y privacidad (II)

Como ya os contamos la semana pasada en la primera parte de este artículoAndroid 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 falsoPero 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.

Primera parte del artículo:
» MAC aleatorias y privacidad (I).

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *