La mayoría de usuarios de teléfonos
móviles Bluetooth ha tenido la necesidad alguna vez de emparejar su
teléfono con otro dispositivo con el fin de transferir archivos vía
Bluetooth o conectarse a equipos manos libres o receptores GPS. Es un
hecho que la conducta habitual suele ser mantener esos enlaces activos
aun cuando estos se encuentren en desuso o la conexión haya sido
esporádica. ¿Qué ocurriría si cada uno de esos enlaces activos pudiera
convertirse en una puerta trasera a nuestro teléfono, con acceso
transparente al control total de las funciones del teléfono y los
archivos almacenados? En efecto, dado que todos los mecanismos de
seguridad empleados por Bluetooth se realizan a nivel de dispositivo, y
no de usuario, suplantar la identidad de un dispositivo emparejado y
utilizar sus credenciales de confianza para acceder a un teléfono sin
que el usuario se percate resulta una acción trivial. En esto consiste
el ataque BD_ADDR Spoofing.
BD_ADDR Spoofing
Tabla de contenidos |
| Bluetooth y los mecanismos de seguridad de autenticación y autorización |
| El ataque BD_ADDR Spoofing |
| Demostración práctica del ataque |
Bluetooth y los mecanismos de seguridad de autenticación y autorización
A fin de poder entender el desarrollo del ataque, es importante conocer los mecanismos de seguridad que utiliza Bluetooth y porque son fácilmente explotables debido a su diseño.
Autenticación
La autenticación es el proceso
por el cual un dispositivo Bluetooth verifica su identidad en otro
dispositivo para poder acceder a los servicios que ofrece.
Todas las funciones de seguridad de nivel de enlace están basadas en el
concepto de clave de enlace, el cual es un número pseudoaleatorio
de 128 bits almacenado individualmente por cada par de dispositivos
Bluetooth. La autenticación no requiere la intervención del usuario;
implica un esquema de desafío/respuesta entre cada par de dispositivos
que emplea una clave de enlace secreta común de 128 bits.
Consecuentemente, este esquema se utiliza para autentificar
dispositivos, no usuarios.
Una vez que los dispositivos emparejados disponen de la clave
de enlace, utilizan esta clave común para autentificarse
automáticamente en las sucesivas conexiones. El proceso de
autenticación está basado en el esquema desafío/respuesta y transcurre
de la siguiente forma:
Autorización1) El dispositivo reclamante envía su dirección BD_ADDR al dispositivo verificador.
2) El verificador devuelve un desafío aleatorio de 128 bits al demandante.
3) El reclamante usa el algoritmo E1 para generar la respuesta de autenticación (SRES) de 32 bits, usando como parámetros de entrada la dirección BD_ADDR del reclamante, la clave de enlace Kab almacenada y el desafío. El verificador realiza la misma operación en paralelo.
4) El reclamante devuelve la respuesta SRES al verificador.
5) El verificador comprueba la respuesta SRES recibida por el reclamante con la respuesta SRES calculada por él.
6) Si los valores de SRES coinciden, el verificador y el reclamante intercambian los papeles y repiten el proceso entero.
La autorización es el procedimiento que determina los derechos que tiene un dispositivo Bluetooth para acceder a los servicios que ofrece un sistema.
El mecanismo de autorización en dispositivos Bluetooth se lleva a cabo mediante niveles de confianza. Los dispositivos tienen tres niveles de confianza, los cuales determinan la capacidad de acceso a los servicios: total, parcial o restringida y nula.
- Un dispositivo de confianza mantiene una relación de emparejamiento y dispone de acceso sin restricciones a todos los servicios.
- Un dispositivo de confianza restringida mantiene una relación de emparejamiento pero tiene acceso restringido a uno o varios servicios.
- Un dispositivo no confiable es aquel que no mantiene siquiera una relación de emparejamiento. No se le permite el acceso a ningún servicio.
En el caso de que un determinado dispositivo de confianza
intente acceder a un servicio autorizado, no se requiere ningún
procedimiento de confirmación, accede de forma transparente.
En el caso de que un determinado dispositivo de confianza restringida o no confiable intente acceder a un servicio restringido, se requiere un procedimiento explícito de confirmación por parte del usuario para permitir o denegar el acceso a ese dispositivo. Nótese que para algunos servicios, como el Perfil de Carga de Objetos (OBEX PUSH) es posible conceder permisos de acceso temporal a dispositivos no emparejados previamente.
En la mayoría de dispositivos es posible marcar manualmente los dispositivos emparejados como dispositivos de confianza, para evitar la confirmación en cada intento de conexión.
En realidad ...
Los credenciales de seguridad de autenticación y autorización son simples en diseño y débiles en la práctica por estar basados en información que puede ser fácilmente suplantada.
Estudiando detenidamente la arquitectura de seguridad en Bluetooth, se comprueba que…
3.2.1 Authorisation and
Authentication
Authorisation is the process of deciding if device X is
allowed to have access to service Y. This is where the concept of
‘trusted’ exists. Trusted devices (authenticated and indicated as
“trusted”), are allowed access to services.
3.2.2 Security Levels of Services
Authorisation Required: Access is only granted automatically
to trusted devices (i.e., devices marked as such in the device
database) or untrusted devices after an authorisation procedure.
Fuente: Apdo. 3.2 Security Levels – Bluetooth Security Architecture
Version 1.0 (www.bluetooth.com)
Esto significa que un dispositivo autorizado puede acceder automáticamente a todos los servicios que requieran autorización. Para que un dispositivo sea considerado como autorizado permanentemente debe estar marcado como tal en la lista de dispositivos de confianza y para ello debe tratarse también de un dispositivo autenticado.
Sin embargo, un hecho importante que se omite es que si un servicio no requiere autenticación, la clave de enlace no entra en juego necesariamente y el acceso se basa únicamente en la dirección BD_ADDR de dispositivo, de forma que si existe en la lista de dispositivos de confianza, este queda autorizado.
4.2.1 Authentication
The authentication procedure is based on a challenge-response
scheme […]. The verifier sends […] a random number (the challenge) to
the claimant. The claimant calculates a response, that is a function of
this challenge, the claimant’s BD_ADDR and a secret key. The response
is sent back to the verifier, that checks if the response was correct
or not. […] A successful calculation of the authentication response
requires that two devices share a secret key.
Fuente: Apdo. 4.2 Security - Core v2.0 + EDR (www.bluetooth.org,
disponible para miembros del SIG)
Esto significa que la autenticación se basa en la dirección BD_ADDR de dispositivo y en la clave de enlace secreta compartida, de forma que si el esquema desafío/respuesta es positivo, este queda autenticado.
En resumen,
- La autorización se basa únicamente en la dirección BD_ADDR de dispositivo.
- La autenticación se basa en la dirección BD_ADDR de dispositivo y en la clave de enlace compartida.
Dado que tanto el mecanismo de autorización como el esquema de desafío/respuesta utilizado para la autenticación verifican la identidad de dispositivos, no usuarios, surgen dos preguntas:
- ¿Qué pasa si un equipo atacante suplanta la dirección BD_ADDR de un dispositivo de confianza? ¿Queda autorizado en el dispositivo destino?
- ¿Qué pasa si un atacante tiene acceso a la clave de enlace de uno de los dispositivos emparejados? ¿Puede utilizarla para autenticarse en el otro dispositivo?
Desde luego que sí.
El ataque BD_ADDR Spoofing
El ataque BD_ADDR Spoofing permite suplantar la identidad de un dispositivo de confianza y utilizar sus credenciales para acceder a perfiles que requieren autorización y/o autenticación con el fin de atacar otro dispositivo Bluetooth.
Se denomina BD_ADDR Spoofing
por su analogía con el clásico ataque MAC Spoofing
en redes Ethernet, el cual permite a un atacante suplantar la dirección
MAC de un equipo para suplantar su identidad y llevar a cabo acciones
maliciosas contra el resto de equipos de la red, ya sea interceptando
las comunicaciones dirigidas al equipo suplantado o utilizando sus
credenciales con el fin de acceder a un sistema con acceso limitado.
Puesto que hay dos mecanismos de seguridad en Bluetooth, el ataque BD_ADDR Spoofing se puede desarrollar en dos
niveles:
- Suplantación de la dirección BD_ADDR de un dispositivo de confianza para acceder a perfiles que requieren autorización.
- Suplantación de la dirección BD_ADDR y obtención de la clave de enlace generada durante el emparejamiento para acceder a perfiles que requieren autenticación.
Alcance del ataque BD_ADDR Spoofing
Para poder evaluar las consecuencias que tiene el hecho de desarrollar
un ataque BD_ADDR Spoofing
con éxito sobre un teléfono móvil, es importante conocer los
principales vectores de ataque en teléfonos Bluetooth.
- Comandos AT:
Los comandos AT son un conjunto de instrucciones codificadas que
permiten configurar el teléfono móvil y enviarle órdenes a ejecutar.
Básicamente, a través de los comandos AT un atacante puede realizar las
siguientes acciones en un teléfono móvil:
- Realizar llamadas de voz y configurar desvíos de llamadas.
- Acceder a la agenda de contactos: leer, añadir, eliminar, …
- Acceder a la agenda de llamadas: últimas llamadas perdidas, recibidas y enviadas.
- Gestión de mensajes SMS: leer bandeja de entrada, escribir y enviar, eliminar, …
- Acceso por OBEX
- A través de OBEX Object Push es posible el envío de archivos.
- A través de OBEX File Transfer es posible acceder al sistema de archivos del teléfono: subida, descarga, listado y borrado de archivos y directorios. Es posible acceder a archivos almacenados tanto en memoria del teléfono como en tarjetas extraíbles.
Demostración práctica del ataque
Con el fin de demostrar el alcance del ataque BD_ADDR Spoofing voy a basarme en tres escenarios
habituales de interconexión de equipos Bluetooth. Cada uno de los
escenarios permitirá observar lo fácil que resulta para un atacante
suplantar la identidad de un dispositivo de confianza y/o emparejado
con el fin de llevar a cabo ciertas acciones maliciosas contra un
teléfono móvil.
El primer escenario tiene como objetivo demostrar cómo es posible
saltarse el mecanismo de autorización suplantando la identidad de un
dispositivo de confianza.
El segundo y el tercer escenario tienen como objetivo demostrar cómo es
posible saltarse el mecanismo de autenticación suplantando la identidad
de un dispositivo emparejado. En el segundo escenario, para acceder a
los comandos AT; en el tercero, para acceder a archivos del teléfono.
En todos los escenarios, el equipo atacante será el mismo: un ordenador
portátil con Fedora Core 5 y BlueZ, la pila de protocolos oficial para
Linux.
Escenario 1
Un
teléfono móvil Nokia n80 se empareja con un
equipo Manos Libres y marca este dispositivo como confiable. El
objetivo del atacante es suplantar la identidad del Manos Libres y
acceder al perfil de Carga de Objetos del teléfono, el cual requiere
autorización, pero no autenticación, y permite el envío simple de
archivos e intercambio de tarjetas de visita y contactos entre
teléfonos.
SALTÁNDONOS LA AUTORIZACIÓN…
El objetivo del atacante es conectarse al Perfil de Carga de Objetos
(OBEX Object Push), disponible a través del canal 9, y enviar un
archivo al teléfono.
Inicialmente, si el atacante intenta conectarse al Perfil de
Carga de Objetos y enviar un archivo, al tratarse de un equipo no
incluido en la lista de dispositivos de confianza, el usuario del Nokia
n80 deberá autorizar explícitamente la conexión.
Es muy probable que el usuario del Nokia n80 no
confié en el emisor del envío y por ello deniegue el intento de
conexión.
Para evitar el mecanismo de autorización, el atacante puede suplantar
la identidad de un dispositivo de confianza del teléfono como, en este
caso, el Manos Libres. El atacante debe conocer la dirección BD_ADDR
del equipo a suplantar y cambiar la dirección BD_ADDR del módulo
Bluetooth utilizado por su equipo por esta nueva. Para ello, el
atacante puede hacer uso de la herramienta bdaddr,
que permite configurar la dirección BD_ADDR y otros parámetros en
módulos hardware Bluetooth.
A partir de ese momento, el atacante está en disposición de conectarse
a un perfil del teléfono móvil que requiera autorización de forma
transparente ya que, a ojos del teléfono, el intento de conexión
proviene de un dispositivo incluido en la lista de dispositivos de
confianza.
Así pues, el atacante puede intentar conectarse de nuevo al Perfil de
Carga de Objetos del teléfono y enviar el archivo. Esta vez, la
conexión se realizará sin que el usuario del teléfono se percate de la
acción.
El archivo enviado por el equipo atacante será automáticamente recibido
por el teléfono móvil y almacenado en la bandeja de entrada de mensajes
sin que el usuario haya tenido que autorizar la recepción del mismo.
Escenario 2
Un
teléfono móvil Motorola PEBL se empareja con una
PDA Acer n300 y marca este dispositivo como
confiable. El objetivo del atacante es suplantar la identidad de la PDA
y conectarse al Perfil de Auriculares del teléfono, el cual requiere
autenticación a aquellos dispositivos emparejados y permite el acceso a
los comandos AT.
SALTÁNDONOS LA AUTENTICACIÓN…
Para demostrar cómo es posible saltarse el mecanismo de autenticación
suponemos que la PDA Acer n300 y el teléfono Motorola
PEBL están emparejados.
El objetivo del atacante es conectarse al Perfil de Auriculares,
disponible en el canal 3 y acceder al juego de comandos AT.
Inicialmente, si el atacante intenta conectarse al Perfil de
Auriculares, al tratarse de un equipo desconocido (no incluido en el
histórico de dispositivos conectados anteriormente), el teléfono Motorola
PEBL denegará automáticamente el intento de conexión.
Para saltarse el mecanismo de autenticación, el atacante puede
suplantar la identidad de un dispositivo emparejado con el teléfono
como, en este caso, la PDA. El atacante debe conocer la dirección
BD_ADDR del equipo a suplantar y cambiar la dirección BD_ADDR del
módulo Bluetooth utilizado por su equipo por esta nueva con ayuda de la
herramienta bdaddr.
Adicionalmente, debe obtener la clave de enlace generada durante el
emparejamiento de la PDA con el teléfono Motorola PEBL
e instalar esa clave de enlace en el equipo atacante.
Los medios de obtención de la clave de enlace escapan al
alcance de esta exposición. Simplemente comentaremos que existen diversos modos de obtener la clave de enlace de la PDA:
- Mediante ingeniería social.
- Robándola del registro de la PDA, donde se almacena la clave de enlace, ya sea por acceso físico o mediante la explotación de alguna vulnerabilidad en el sistema operativo.
- Capturando mediante sniffing las claves temporales del emparejamiento Bluetooth y crackeándolas para obtener el PIN y la clave de enlace.
En aquellas PDAs con Windows Mobile 5.0 y pila de protocolos
Bluetooth Broadcom/Widcomm, las claves de enlace generadas durante el
emparejamiento con otros dispositivos Bluetooth se almacenan en la
clave de registro
HKLM\Software\WIDCOMM\BtConfig\Devices\BD_ADDR\LinkKey. Sin embargo, es
necesario tener en cuenta que aunque estas claves de enlace se
almacenan en texto claro, lo hacen con un desorden de endianness.
Una vez que el atacante obtiene la clave de enlace, debe instalarla en
su equipo Linux atacante, en el fichero \var\lib\bluetooth\BD_ADDR del
módulo Bluetooth\linkkeys con el siguiente formato:
|
BD_ADDR del dispositivo emparejado |
Clave de enlace de 16 bytes |
0 |
A partir de ese momento, el atacante está en disposición de conectarse
a un perfil del teléfono móvil que requiera autenticación de forma
transparente ya que, a ojos del teléfono, el intento de conexión
proviene de un dispositivo emparejado.
Así pues, el atacante puede intentar conectarse de nuevo al Perfil de
Auriculares del teléfono y, esta vez, la conexión se realizará con
éxito y sin que el usuario del teléfono se percate de la acción.
Con la conexión establecida, el atacante puede enviar comandos AT al Motorola
PEBL y realizar acciones tales como acceder a la agenda de
contactos o realizar llamadas de voz.
O acceder a la bandeja de entrada de mensajes SMS ;)
Escenario 3
Un
teléfono móvil Nokia n80 se empareja con una PDA Acer
n300 y marca este dispositivo como confiable. El objetivo
del atacante es suplantar la identidad de la PDA y conectarse al Perfil
de Transferencia de Archivos del teléfono, el cual requiere
autenticación y permite el acceso al sistema de archivos para poder
descargarse ficheros almacenados en la memoria y en la tarjeta
extraíble.
SALTÁNDONOS LA AUTENTICACIÓN…
Para demostrar cómo es posible saltarse el mecanismo de autenticación
suponemos que la PDA Acer n300 y el teléfono Nokia
n80 están emparejados.
El objetivo del atacante es conectarse al Perfil de Transferencia de
Archivos (OBEX File Transfer), disponible en el canal 11 y acceder a
archivos almacenados en el teléfono.
Inicialmente, si el atacante intenta conectarse al Perfil de
Transferencia de Archivos, al tratarse de un equipo no autenticado, se
lanza el proceso de emparejamiento de dispositivos con intercambio de
clave PIN.
Para evitar el mecanismo de autenticación, el atacante puede suplantar
la identidad de la PDA a partir de su dirección BD_ADDR y la clave de
enlace obtenida tal y como se ha visto en el anterior escenario con el Motorola
PEBL.
A partir de ese momento, el atacante está en disposición de conectarse
al Perfil de Transferencia de Archivos del teléfono móvil de forma
transparente y llevar a cabo las siguientes acciones:
Listar los archivos y recorrer los directorios.
Descargarse archivos.
Eliminar archivos.
Documentos relacionados
 |
Revisión del ataque BD_ADDR Spoofing - ¿Todavía piensas que Bluetooth es seguro? |