MAC aleatorias y privacidad (I)

Álvaro Núñez-Romero Casado    15 abril, 2019
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.

Álvaro Núñez-Romero Casado
Innovación y laboratorio en ElevenPaths
@toolsprods
www.elevenpaths.com/

Deja un comentario

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