Exfiltración del IMEI

Exfiltración del IMEI en aplicaciones móviles

Hoy en día, la exfiltración del IMEI es una práctica que los desarrolladores están llevando a cabo. Se desconoce si lo utilizan para identificar de forma única al usuario dentro de la aplicación, o bien con otras intenciones. En cualquier caso, la fuga de esta información pone en riesgo la privacidad del usuario.

En el momento que el IMEI sale del dispositivo móvil, para un atacante resulta factible interceptarlo y utilizarlo para suplantar el teléfono del usuario y acceder a recursos de forma ilegítima.

La mayoría de estas aplicaciones envían el IMEI en claro, y aunque otras protejan este dato sensible mediante el envío de un hash, la privacidad del usuario se ve igualmente comprometida.

Como veremos más adelante, a partir de un hash un atacante podría recuperar de forma sencilla el IMEI mediante tablas de hashes precalculados. La propia estructura del IMEI hace que sea vulnerable a este ataque y tenga éxito en tiempo útil, ya que la mayor parte del número puede ser conocido y el espacio de posibilidades se ve reducido drásticamente.

¿Qué es el IMEI? ¿Cuál es su estructura?

Básicamente se podría decir que el IMEI (International Mobile System Equipment Identity) es un número que permite identificar de forma única cualquier dispositivo móvil asociado a una red GSM. Este número suele encontrarse impreso en el compartimento de la batería del dispositivo, o bien puede consultarse en la mayoría de ellos tecleando el código USSD *#06#.

De forma general, el IMEI está formado por 14 dígitos más 1 dígito de control o checksum, y se encuentra estructurado de la siguiente forma:

Estructura del IMEI

Estructura del IMEI

El primer campo, compuesto por 8 dígitos, se denomina TAC (Type Allocation Code), e identifica el modelo específico del dispositivo móvil. Precisamente este campo es el que facilita la recuperación del IMEI a partir de su hash, ya que al tratarse de información pública que puede obtenerse fácilmente en Internet, el espacio de posibilidades se ve reducido y por tanto el ataque (que más adelante se verá) puede finalizar en un tiempo más que razonable.

El segundo campo está compuesto por 6 dígitos y se corresponde con el número de serie del dispositivo móvil. A diferencia del campo anterior, esta información es privada y es considerada la parte sensible del IMEI. Es por ello que en el ataque se deben de tener en cuenta todos los posibles números de serie.

Por último, se encuentra 1 dígito de control o checksum que se calcula a partir de los dos campos anteriores para verificar que el IMEI es correcto. Esta suma de verificación se realiza mediante el algoritmo de Luhn o algoritmo de módulo 10 que se utiliza para la validación de distintos números de identificación.

¿Qué supondría una exfiltración del IMEI?

Ante una exfiltración del IMEI pueden darse muchas situaciones, desde un simple bloqueo del dispositivo por haberlo reportado como perdido o robado, hasta situaciones más complejas en las que la identidad del usuario es suplantada permitiendo al atacante acceder a recursos de forma ilícita.

Por ejemplo, imaginemos que contamos con una aplicación para consultar el buzón de voz. Seguramente esta aplicación esté diseñada para que los mensajes de voz solo se puedan leer desde el propio dispositivo del usuario, y no desde diferentes dispositivos. Para ello, se podría implementar un control para que el IMEI del teléfono coincidiera con el número que se tuviera registrado. Si un atacante consiguiera este número, podría suplantar al usuario y acceder a su buzón de voz.

Pero no solo existe este tipo de casos. A principios de septiembre de 2012, Sam Granger publicó en su blog (no disponible) el artículo WhatsApp is using IMEI numbers as passwords donde descubrió que WhatsApp estaba usando el MD5 del IMEI del teléfono invertido como contraseña, y el propio número de teléfono como nombre de usuario.

En cualquier caso, en el momento que las aplicaciones extraen el IMEI, la privacidad del usuario queda expuesta, ya que estas aplicaciones podrían identificar de forma única al usuario que las utiliza. Y aunque una única aplicación (por ejemplo un navegador) no pueda obtener un perfil completo del usuario por la información que proporciona, sí que podría cruzar este IMEI con otra aplicación que el usuario utilice (por ejemplo un cliente de correo) y construir un perfil más detallado a partir de la información recabada por ambas.

¿Realmente generar el hash del IMEI aporta seguridad?

A pesar de que existan pocas aplicaciones móviles que generen el hash del IMEI antes de enviarlo (la mayoría de ellas lo hacen en claro), realmente no consiguen proteger la privacidad de los usuarios.

Como pudo verse más arriba, el problema radica en la propia estructura del número IMEI. Los 8 primeros dígitos que representan el TAC identifican el modelo del dispositivo móvil, un dato que puede obtenerse de forma pública solo con saber (o averiguar) el modelo del dispositivo. De esta forma, al conocer la mayor parte del IMEI, la dificultad del ataque tiene lugar únicamente en el número de serie (6 dígitos), ya que el último dígito se calcula en función de los anteriores.

Debido a esta estructura seguida por el IMEI, realmente no se consigue una distribución aleatoria del número, sino que su entropía es relativamente baja, haciendo que sea vulnerable a un ataque de tablas de hashes precalculados que se verá a continuación.

Atacando el hash del IMEI

Los desarrolladores de aplicaciones móviles, en su afán de proteger la privacidad del usuario y por tanto la confidencialidad del IMEI, generan el hash como medida de protección ante una exfiltración del IMEI. Sin embargo, seguramente no tuvieron en cuenta la escasa aleatoriedad del número (debido a su estructura inherente) y la facilidad con la que se puede obtener a partir de un hash.

Si el IMEI fuera realmente aleatorio, el ataque se complicaría por cuestiones de tiempo, puesto que habría que considerar prácticamente todo el espacio de posibilidades (salvo el último dígito). En este caso, si tuviéramos una capacidad de cómputo capaz de generar 1 millón de hashes por segundo, tardaríamos aproximadamente unos 3 años (1014 / 106 segundos) en precalcular todos los hashes necesarios para el ataque.

Sin embargo, tal y como se ha explicado antes, la propia estructura del IMEI acaba facilitando el ataque de tal forma que, si se compara con el tiempo anterior, puede concluir de forma inmediata.

Creación de tablas de hashes precalculados

Como paso previo y fundamental en el ataque, se calculan todas las tablas necesarias de hashes precalculados. Estas tablas tendrán como clave el hash generado, y como valor el posible IMEI a partir del cual se ha calculado el hash, donde la función hash usada dependerá de la que utilice la propia aplicación móvil sobre el IMEI.

Tabla de hashes precalculados para el TAC 35186905

Tabla de hashes precalculados para el TAC 35186905

La imagen anterior se correspondería con el inicio de una tabla de hashes (utilizando SHA-1) para un dispositivo móvil cuyo TAC es el 35186905. En el bloque de la derecha se fija este valor en cada entrada, y se tienen en cuenta todos los posibles números de serie (marcados en gris) para obtener todos los IMEIs posibles, previo cálculo del dígito de control mediante el algoritmo de Luhn. En el bloque de la izquierda se genera el hash por cada uno de ellos, llegando a construir una tabla con un total de 106 entradas o posibles IMEIs para el TAC 35186905.

Obtención de TACs objetivo

Sin embargo, para poder construir estas tablas, es necesario conocer los TACs objetivo. Si se tratara de un ataque dirigido, solo habría que averiguar el modelo del dispositivo y generar una tabla con todos los posibles hashes precalculados a partir del TAC correspondiente. En cambio, si el ataque no fuera dirigido, se podrían generar las tablas de hashes de los TACs más comunes.

Pero… ¿dónde se pueden consultar los TACs de todos los dispositivos del mercado? Realmente existen multitud servicios en Internet que permiten consultar información detallada de un dispositivo móvil (fabricante, modelo, especificaciones técnicas,…) a través de su IMEI: IMEI.info, IMEIData.net, NumberingPlans.com, Nobbi.com,… Sin embargo, estos servicios no permiten hacer búsquedas a partir de un fabricante o modelo para obtener un TAC, ni tampoco ofrecen de forma pública sus bases de datos.

Collin Mulliner (@collinrm) se encontró en la misma situación y decidió crear una base de datos pública con fines de investigación. Formada por un conjunto de ficheros CSV que recogen gran cantidad de TACs para distintas marcas y modelos, donde también pueden encontrarse colaboraciones de otras personas.

De igual forma, en Scribd.com también pueden encontrarse listados de TACs de forma pública, como puede ser este documento.

Cálculo del dígito de control

De cara a generar un IMEI de forma correcta, es necesario calcular el último dígito como una suma de verificación a partir del resto de campos: el TAC elegido y el número de serie correspondiente. Para ello, solo hay que utilizar el algoritmo de Luhn pasándole como parámetro los campos anteriores concatenados.

Para realizar este cálculo, se puede usar el siguiente código Python obtenido de la Wikipedia:

Descifrado del hash del IMEI

Una vez realizada toda la preparación del ataque, ya solo hay que esperar a que se produzca una exfiltración del IMEI para interceptar el hash y descifrarlo. Tan sencillo como hacer una búsqueda del hash en las tablas anteriores y obtener el IMEI.

Conclusiones

A lo largo del artículo se ha podido ver de forma clara los riesgos y las consecuencias a las que un usuario se expone cuando se produce una exfiltración del IMEI.

Se conocen casos en los que los desarrolladores de aplicaciones móviles utilizan el IMEI para identificar los usuarios de forma única, pero se desconoce con qué otras intenciones realizan esta práctica. En la mayoría de ellos, esta información sensible viaja totalmente en claro, mientras que en otros casos se envía un hash del IMEI.

En cualquier caso, dada la facilidad del ataque por la insuficiente aleatoriedad de la estructura del IMEI, en el momento que un atacante consigue interceptarlo, tanto la confidencialidad del número como la privacidad del usuario quedan comprometidas.

Por una parte, los desarrolladores de aplicaciones no deberían de utilizar ningún parámetro único del dispositivo para identificar al usuario dentro de la aplicación, ni enviar esta información (cuando sea sensible) en claro o sin garantizar la confidencialidad tal y como se ha visto en el artículo con el IMEI.

Y por otra parte, como usuarios, deberíamos de evitar usar estas aplicaciones; identificando mediante un análisis estático si realmente están solicitando los permisos necesarios para acceder a esta información, y mediante un análisis dinámico para inspeccionar el tráfico y ver si se está realizando una exfiltración de la misma.

Pedro Castillo

Pedro Castillo

Ingeniero Informático apasionado por la seguridad y la tecnología. Incansable perseguidor de retos. En constante reciclaje.

Ver descripción | Ver perfil en LinkedIn
Pedro Castillo