1. Introducción.
El concepto de Bluetooth surge de la imperiosa necesidad de las grandes empresas de telecomunicaciones e informática, de desarrollar una interfaz abierta, que facilite la comunicación entre los diferentes equipos informáticos y telefónicos, aprovechando la capacidad y la movilidad de los dispositivos inalámbricos, para la total supresión de los cables de conexión, adoptando así un único estándar de conexión.
El Bluetooth Special Interest Group (SIG), una asociación comercial formada por líderes en telecomunicación, informática e industrias de red, es la encargada del desarrollo e introducción en el mercado de esta tecnología inalámbrica.
Los promotores de Bluetooth incluyen Agere, Ericsson, IBM, Intel, Microsoft, Motorola, Nokia y Toshiba, y centenares de compañías asociadas.
El nombre viene de Harald Bluetooth, un Vikingo y rey de Dinamarca a de los años 940 a 981, fue reconocido por su capacidad de ayudar a la gente a comunicarse. Durante su reinado unió Dinamarca y Noruega.
1.1. Propósito y alcance
El propósito de este taller es introducirnos en los aspectos de la seguridad de BlueTooth y en los ataques existentes que rompen esa seguridad.
1.2. Definiciones.
• SIG: Special Interest Group. La organización propietaria de la marca comercial BlueTooth, y la responsable del desarrollo y evolución de esta tecnología.
1.3. Referencias.
2. Especificaciones BlueTooth. 2.1. Tecnología. Bluetooth se puede definir como una propuesta de especificación de radio frecuencia por transmisión de corto alcance de datos, pudiendo transmitir a través de objetos sólidos no metálicos.
Su alcance nominal es de 10 cm a 10 m “en teoría”, pero puede extenderse a 100 m mediante el incremento de transmisión de energía. Más tarde analizaremos lo del alcance.
Los ordenadores, teléfonos móviles, aparatos domésticos y equipos de oficina, basados en Bluetooth pueden conectarse entre sí dentro de áreas físicas reducidas, sin necesidad de utilizar cableado, de forma “segura” (también analizaremos esto) y barata y a altas velocidades de transmisión.
También se pretende ofrecer acceso a Internet.
La tecnología usa la banda ISM (Industrial Scientific Medicine) de los 2.4 GHz que no necesita licencia, está disponible en casi todo el mundo.
Bluetooth es además, un módulo radio de baja potencia, puede integrarse en una amplia variedad de dispositivos. Soporta transmisión de tres canales de voz, vídeo y datos a una velocidad máxima de 1 Mbps, aunque la máxima velocidad real girará alrededor de los 721 Kbps.
Ya se habla de su uso para todo, seguridad del hogar, dispositivos médicos, etc.
2.2. Pila de Protocolos. La especificación de Bluetooth pretende que todas las aplicaciones sean capaces de operar entre sí. Para conseguir esta interoperabilidad, las aplicaciones en dispositivos remotos deben ejecutarse sobre una pila de protocolos idénticos.
Para comunicarse con otros dispositivos Bluetooth, se requiere un hardware específico para Bluetooth, que incluye un módulo de banda base, así como otro módulo de radio y una antena.
Además deberá haber un software encargado de controlar la conexión entre dos dispositivos Bluetooth; este software (Link Manager) por lo general correrá en un microprocesador dedicado. Los Link Managers de diferentes dispositivos Bluetooth se comunicarán mediante el protocolo LMP (Link Manager Protocol).
Además habrá otros módulos de software, que constituirán la pila de protocolos, y garantizarán la interoperabilidad entre aplicaciones alojadas en diferentes dispositivos Bluetooth.
La pila completa se compone tanto de protocolos específicos de Bluetooth (LM (Link Manager) y L2CAP (Logical Link Control Adaption Protocol), por ejemplo) como de protocolos no específicos de Bluetooth como son OBEX (Objects Exchange Protocol), UDP (User Datagram Protocol), TCP, IP, etc. Debido a que la hora de diseñar la torre de protocolos, el objetivo principal ha sido maximizar el número de protocolos existentes que se puedan reutilizar en las capas más altas para diferentes propósitos.
A parte de todos estos protocolos, la especificación define el HCI (Host Controller Interface), que se encarga de proporcionar una interfaz de comandos al controlador BaseBand, al gestor de enlace, y nos da acceso al estado del hardware y a los registros de control.
2.3. Descripción de los protocolos 2.3.1. Link Manager (LM) y Link Manager Protocol (LMP). 2.3.1.1. Link manager. El Link Manager es el sistema que consigue establecer la conexión entre dispositivos.
Se encarga del establecimiento, la autentificación y la configuración del enlace.
El Link Manager localiza a otros gestores y se comunica con ellos gracias al protocolo de gestión del enlace LMP.
Para poder realizar su función de proveedor de servicio, el LM utiliza los servicios incluidos en el controlador de enlace (LC, "Link Controller" o BaseBand).
El Link Manager Protocol básicamente consiste en un número de PDUs (Protocol Data Units) que son enviadas de un dispositivo a otro.
A continuación se enuncian los servicios soportados:
•Transmisión y recepción de datos.
•Petición de nombre: El gestor de enlace tiene un eficiente método para inquirir y reportar la ID de un dispositivo con una longitud de máximo 16 caracteres.
•Petición de las direcciones de enlace.
•Establecimiento de la conexión.
•Autentificación.
•Negociación del modo de enlace y establecimiento, por ejemplo, modo datos o modo voz/datos. Esto puede cambiarse durante la conexión.
2.3.1.2. Modos. Establecimiento de un dispositivo al modo "sniff". En este modo se reduce el ciclo de trabajo de una estación esclava, ya que sólo escucha cada M slots, siendo el valor de M negociado con el gestor de enlace. La estación maestra puede sólo comenzar la transmisión en tiempos/slots específicos, separados estos por intervalos regulares.
Mantenimiento de un dispositivo de enlace en espera. En modo espera, el apagado del receptor durante períodos de tiempo más largos ahorra energía. Cualquier entidad puede volver a establecer un enlace, con una latencia media de 4 segundos. Esto es definido por el gestor de enlace y manejado por el controlador de enlace.
Establecimiento de un dispositivo en modo "aparcado": Esto es útil cuando un dispositivo no necesita participar activamente en el canal, pero sí quiere permanecer sincronizado. En este modo dicha entidad "despierta" en intervalos regulares de tiempo para escuchar al canal y así poder re-sincronizarse con el resto de entidades de la piconet
2.3.2. Interfaz de la Controladora de la Máquina (HCI). La interfaz de la Controladora de la Máquina (Host Controller Interface) proporciona una interfaz de comandos para la controladora de banda base y para el gestor de enlace, y permite acceder al estado del hardware y a los registros de control.
Esta interfaz proporciona una capa de acceso homogénea para todos los dispositivos Bluetooth de banda base.
La capa HCI de la máquina intercambia comandos y datos con el firmware del HCI presente en el dispositivo Bluetooth. El driver de la capa de transporte de la controladora de la máquina (es decir, el driver del bus físico) proporciona ambas capas de HCI la posibilidad de intercambiar información entre ellas.
Una de las tareas más importantes de HCI que se deben realizar es el descubrimiento automático de otros dispositivos Bluetooth que se encuentren dentro del radio de cobertura. Esta operación se denomina en inglés inquiry (consulta). Tenga siempre presente que un dispositivo remoto sólo contesta a la consulta si se encuentra configurado en modo visible (discoverable mode).
% hccontrol -n ubt0hci inquiry
Inquiry result, num_responses=1
Inquiry result #0
BD_ADDR: 00:80:37:29:19:a4
Page Scan Rep. Mode: 0x1
Page Scan Period Mode: 00
Page Scan Mode: 00
Class: 52:02:04
Clock offset: 0x78ef
Inquiry complete. Status: No error [00]
BD_ADDR es la dirección identificativa única del dispositivo Bluetooth, similar a las direcciones MAC de las tarjetas Ethernet. Esta dirección se necesita para transmitir otro tipo de información a otros dispositivos.
Si se realiza una consulta (inquiry) sobre el dispositivo Bluetooth remoto, dicho dispositivo identificará nuestro computador como "nombre.de.su.sistema (ubt0)''. El nombre asignado al dispositivo local se puede modificar en cualquier momento.
El sistema Bluetooth proporciona una conexión punto a punto (con sólo dos unidades Bluetooth involucradas) o también una conexión punto multipunto. En el último caso, la conexión se comparte entre varios dispositivos Bluetooth.
2.3.3. Protocolo de Adaptación y de Control de Enlace a nivel Lógico (L2CAP). El protocolo L2CAP (Logical Link Control and Adaptation Protocol) proporciona servicios de datos tanto orientados a conexión como no orientados a conexión a los protocolos de las capas superiores, junto con facilidades de multiplexación y de segmentacion y reensamblaje.
L2CAP permite que los protocolos de capas superiores puedan transmitir y recibir paquetes de datos L2CAP de hasta 64 kilobytes de longitud.
L2CAP se basa en el concepto de canales. Un canal es una conexión lógica que se sitúa sobre la conexión de banda base. Cada canal se asocia a un único protocolo. Cada paquete L2CAP que se recibe a un canal se redirige al protocolo superior correspondiente. Varios canales pueden operar sobre la misma conexión de banda base, pero un canal no puede tener asociados más de un protocolo de alto nivel.
Una herramienta de diagnóstico interesante es btsockstat, para FreeBSD.
Realiza un trabajo similar al comando netstat, pero en este caso para las estructuras de datos relacionadas con el sistema Bluetooth. A continuación se muestra la información relativa a la misma conexión lógica del ejemplo anterior.
% btsockstat
Active L2CAP sockets
PCB Recv-Q Send-Q Local address/PSM Foreign address CID State
c2afe900 0 0 00:02:72:00:d4:1a/3 00:07:e0:00:0b:ca 66 OPEN
Active RFCOMM sessions
L2PCB PCB Flag MTU Out-Q DLCs State
c2afe900 c2b53380 1 127 0 Yes OPEN
Active RFCOMM sockets
PCB Recv-Q Send-Q Local address Foreign address Chan DLCI State
c2e8bc80 0 250 00:02:72:00:d4:1a 00:07:e0:00:0b:ca 3 6 OPEN
El protocolo RFCOMM proporciona emulación de puertos serie a través del protocolo L2CAP. Este protocolo se basa en el estándar de la ETSI denominado TS 07.10. RFCOMM es un protocolo de transporte sencillo, con soporte para hasta 9 puertos serie RS-232 (EIATIA-232-E). El protocolo RFCOMM permite hasta 60 conexiones simultáneas (canales RFCOMM) entre dos dispositivos Bluetooth.
Para los propósitos de RFCOMM, un camino de comunicación involucra siempre a dos aplicaciones que se ejecutan en dos dispositivos distintos (los extremos de la comunicación). Entre ellos existe un segmento que los comunica. RFCOMM pretende cubrir aquellas aplicaciones que utilizan los puertos serie de las máquinas donde se ejecutan. El segmento de comunicación es un enlace Bluetooth desde un dispositivo al otro (conexión directa).
RFCOMM trata únicamente con la conexión de dispositivos directamente, y también con conexiones entre el dispositivo y el modem para realizar conexiones de red. RFCOMM puede soportar otras configuraciones, tales como módulos que se comunican via Bluetooth por un lado y que proporcionan una interfaz de red cableada por el otro.
2.3.5. Protocolo de Descubrimiento de Servicios (SDP). El Protocolo de Descubrimiento de Servicios (Service Discovery Protocol o SDP) permite a las aplicaciones cliente descubrir la existencia de diversos servicios proporcionados por uno o varios servidores de aplicaciones, junto con los atributos y propiedades de los servicios que se ofrecen.
Estos atributos de servicio incluyen el tipo o clase de servicio ofrecido y el mecanismo o la información necesaria para utilizar dichos servicios.
SDP se basa en una determinada comunicación entre un servidor SDP y un cliente SDP.
El servidor mantiene una lista de registros de servicios, los cuales describen las características de los servicios ofrecidos. Cada registro contiene información sobre un determinado servicio. Un cliente puede recuperar la información de un registro de servicio almacenado en un servidor SDP lanzando una petición SDP. Si el cliente o la aplicación asociada con el cliente decide utilizar un determinado servicio, debe establecer una conexión independiente con el servicio en cuestión. SDP proporciona un mecanismo para el descubrimiento de servicios y sus atributos asociados, pero no proporciona ningún mecanismo ni protocolo para utilizar dichos servicios.
Normalmente, un cliente SDP realiza una búsqueda de servicios acotada por determinadas características. No obstante hay momentos en los que resulta deseable descubrir todos los servicios ofrecidos por un servidor SDP sin que pueda existir ningún conocimiento previo sobre los registros que pueda contener. Este proceso de búsqueda de cualquier servicio ofrecido se denomina navegación o browsing.
El siguiente ejemplo muestra cómo realizar una consulta de navegación una consulta de navegación SDP mediante el servidor Bluetooth SDP denominado sdpd y el cliente de línea de comando denominado sdpcontrol se incluyen en la instalación estándar de FreeBSD.
% sdpcontrol -a 00:01:03:fc:6e:ec browse
Record Handle: 00000000
Service Class ID List:
Service Discovery Server (0x1000)
Protocol Descriptor List:
L2CAP (0x0100)
Protocol specific parameter #1: u/int/uuid16 1
Protocol specific parameter #2: u/int/uuid16 1
Record Handle: 0x00000001
Service Class ID List:
Browse Group Descriptor (0x1001)
Record Handle: 0x00000002
Service Class ID List:
LAN Access Using PPP (0x1102)
Protocol Descriptor List:
L2CAP (0x0100)
RFCOMM (0x0003)
Protocol specific parameter #1: u/int8/bool 1
Bluetooth Profile Descriptor List:
LAN Access Using PPP (0x1102) ver. 1.0
Resulta importante resaltar una vez más que cada servicio posee una lista de atributos (por ejemplo en el canal RFCOMM). Dependiendo de los servicios que se quieran utilizar puede resultar necesario anotar algunos de los atributos. Algunas implementaciones de Bluetooth no soportan navegación de servicios y pueden devolver una lista vacía. En este caso se puede intentar buscar algún servicio determinado. OBEX Object Push (OPUSH):
% sdpcontrol -a 00:01:03:fc:6e:ec search OPUSH
Desde que se inició la especificación de este estándar, una de las principales preocupaciones del SIG fue garantizar la interoperabilidad total entre dispositivos de distintos fabricantes, siempre y cuando éstos compartan el mismo perfil.
Los perfiles especifican cómo utilizar la pila de protocolos de Bluetooth para implementar una solución que trabaje sin problemas con las de otras marcas. En cada uno se establecen opciones y parámetros, además de detallar cómo usar los distintos procedimientos de los diversos estándares que se encuentren implicados.
Podemos ver la estructura de perfiles de BlueTooth y su dependencia en el siguiente gráfico.
Los perfiles tienen dependencia de otro perfil si reutilizan partes de él. En el gráfico vemos como el perfil Object Push depende del Generic Object Exchange, de Serial Port y de Generic Access.
Han sido desarrollados más perfiles, y todo indica que se seguirán desarrollando otros nuevos.
En este tutorial comentaremos solo los dos siguientes, pero si alguien quiere profundizar en el tema, tiene más información en:
http://www.palowireless.com/infotooth/tutorial/profiles.asp 2.3.6.1. Acceso Telefónico a Redes (DUN) y Acceso a Redes mediante perfiles PPP (LAN). El perfil de Acceso Telefónico a Redes (Dial-Up Networking o DUN) se utiliza mayoritariamente con modems y teléfonos celulares. Los escenarios cubiertos por este perfil se describen a continuación:
• Utilización de un teléfono celular o un modem por una computadora para simular un modem sin cables que se conecte a un servidor de acceso telefónico a redes o para otros servicios de acceso telefónico relacionados;
• Utilización de un teléfono celular o un modem por un computador para recibir llamadas de datos.
El Acceso a Redes con perfiles PPP (LAN) se puede utilizar en las siguientes situaciones:
• Acceso LAN para un único dispositivo Bluetooth;
• Acceso LAN para múltiples dispositivos Bluetooth;
• Conexión de PC a PC (utilizando emulación de PPP sobre una línea serie).
2.3.6.2. Perfil OBEX Object Push (OPUSH). OBEX es un protocolo muy utilizado para transferencias de ficheros sencillas entre dispositivos móviles. Su uso más importante se produce en comuncaciones por infrarrojos, donde se utiliza para transferencia de ficheros genéricos entre portátiles o dispositivos Palm y para enviar tarjetas de visita o entradas de la agenda entre teléfonos celulares y otros dispositivos con aplicaciones PIM.
El cliente OBEX se utiliza para introducir y para recuperar recuperar objetos del servidor OBEX. Un objeto puede por ejemplo ser una tarjeta de visita o una cita. El cliente OBEX puede obtener un número de canal RFCOMM del dispositivo remoto utilizando SDP. Esto se hace especificando el nombre del servicio en lugar del número de canal RFCOMM. Los nombres de servicios soportados son: IrMC, FTRN y OPUSH. Es posible especificar el canal RFCOMM como un número.
A continuación se muestra un ejemplo de una sesión OBEX donde el objeto que posee la información del dispositivo se recupera del teléfono celular y un nuevo objeto (la tarjeta de visita) se introduce en el directorio de dicho teléfono.
% obexapp -a 00:80:37:29:19:a4 -C IrMC
obex> get
get: remote file> telecom/devinfo.txt
get: local file> devinfo-t39.txt
Success, response: OK, Success (0x20)
obex> put
put: local file> new.vcf
put: remote file> new.vcf
Success, response: OK, Success (0x20)
obex> di
Success, response: OK, Success (0x20)
Hay tres modos primarios de seguridad.
Modo 1. Sin seguridad. Todos los mecanismos de seguridad (autenticación y cifrado) están deshabilitados. Además el dispositivo se situa en modo promiscuo, permitiendo que todos los dispositivos Bluetooth se conecten a él.
Modo 2. En la capa L2CAP, nivel de servicios. Los procedimientos de seguridad son inicializados después de establecerse un canal entre el nivel LM y el de L2CAP. Un gestor de seguridad controla el acceso a servicios y dispositivos. Variando las políticas de seguridad y los niveles de confianza se pueden gestionar los accesos de aplicaciones con diferentes requerimientos de seguridad que operen en paralelo.
Su interface es muy simple y no hay ninguna codificación adicional de PIN o claves.
Modo 3. En el nivel de Link. Todas las rutinas están dentro del chip BlueTooth y nada es transmitido en plano. Los procedimientos de seguridad son iniciados antes de establecer algún canal. Aparte del cifrado tiene autenticación PIN y seguridad MAC. Su metodología consiste en compartir una clave de enlace (clave de linkado) secreta entre un par de dispositivos. Para generar esta clave, se usa un procedimiento de “pairing” cuando los dos dispositivos se comunican por primera vez.
3.1.2. Emparejamiento de Dispositivos Por defecto, la comunicación Bluetooth no se valida, por lo que cualquier dispositivo puede en principio hablar con cualquier otro. Un dispositivo Bluetooth (por ejemplo un teléfono celular) puede solicitar autenticación para realizar un determinado servicio (por ejemplo para el servicio de marcación por modem).
La autenticación de Bluetooth normalmente se realiza utilizando códigos PIN. Un código PIN es una cadena ASCII de hasta 16 caracteres de longitud. Los usuarios deben introducir el mismo código PIN en ambos dispositivos.
Una vez que el usuario ha introducido el PIN adecuado ambos dispositivos generan una clave de enlace. Una vez generada, la clave se puede almacenar en el propio dispositivo o en un dispositivo de almacenamiento externo. La siguiente vez que se comuniquen ambos dispositivos se reutilizará la misma clave.
El procedimiento descrito hasta este punto se denomina emparejamiento (pairing). Es importante recordar que si la clave de enlace se pierde en alguno de los dispositivos involucrados se debe volver a ejecutar el procedimiento de emparejamiento.
No existe ninguna limitación en los códigos PIN a excepción de su longitud. Algunos dispositivos (por ejemplo los dispositivos de mano Bluetooth) pueden obligar a escribir un número predeterminado de caracteres para el código PIN.
3.1.3. Inicialización y Generación de la claves. La Clave de Linkado es generada durante una fase de inicialización, cuando dos dispositivos empiezan a comunicarse. Según la especificación BlueTooth, la clave es generada durante la fase de inicialización cuando el usuario introduce un PIN idéntico en ambos dispositivos. Después de completarse la inicialización, los dispositivos se autentican de manera automática y transparente y se lleva a cabo el cifrado de la conexión.
Generación de claves en la Inicialización
Nota: En este esquema los algoritmos E21 y E22 son agrupados en uno genérico llamado E2.
El proceso de Inicialización se desarrolla según los siguientes pasos:
3.1.3.1 Generación de una clave de inicialización Kinit.
Aplicando el
PIN del dispositivo y su longitud, el
BD_ADDR (48 bits) y un número aleatorio de 128bits,
IN_RAND al algoritmo E22 .
El resultado es una palabra de 128 bits, referida como K
init.
Resaltamos que el PIN está disponible en ambos dispositivos BlueTooth, y que IN_RAND es transmitido en plano.
Respecto a BD_ADDR, si uno de los dispositivos tiene un PIN fijo, se usa la BD_ADDR del dispositivo asociado, y si ambos tienen un PIN variable, se usa el PIN del dispositivo que recibe el IN_RAND (el Slave).
Esto debido a que algunos dispositivos tienen un PIN predefinido que no puede ser modificado, con lo cual este PIN tiene que introducirse en el dispositivo al que queremos emparejarnos. Si ambos tienen un PIN fijo, no pueden emparejarse.
3.1.3.2 Generación de la clave de linkado Kab. Usando el algoritmo E21, ambos dispositivos crean la clave de linkado.
Los dispositivos usan la clave de inicialización para intercambiar dos nuevos números aleatorios de 128 bits, conocidos como LK_RAND
A y LK_RAND
B. Cada dispositivo genera un número aleatorio de 128 bits y lo envía al otro dispositivo previamente XOReado bit a bit con K
init. Dado que ambos dispositivos conocen K
init, cada dispositivo conoce ambas LK_RAND.
Usando como parámetros de entrada un BD_ADDR y el LK_RAND, el algoritmo E21 obtiene la clave de linkado K
ab.
3.1.3.3. Autenticación BlueTooth El procedimiento de autenticación sigue el conocido esquema “challenge-response”, desafío-respuesta.
Los pasos son los siguiente:
• El “demandante” transfiere su dirección de 48 bits (BD_ADDR) al “verificador”.
• El verificador le transfiere un “desafío” aleatorio de 128 bits (AU_RAND) al demandante.
• El verificador usa el algoritmo E1 para generar el “response” de autenticación, usando como parámetros la dirección del demandante, BD_ADDR
b, la Clave de Linkado, K
ab, y el desafío. El demandante realiza la misma operación.
• El demandante le devuelve el “response”, SRES, al verificador.
• El verificador compara el SRES del demandante con el que el ha calculado.
• Si los valores de los 32 bits de los SRES son idénticos, el verificador establece la conexión.
En este proceso, se crea además un número de 96 bits llamado ACO (Authenticated Ciphering Offset) en ambos dispositivos, que será usada durante para la creación de la Clave de Cifrado.
3.1.3.4 Generación de la clave de cifrado. Cuando el Link Manager (LM) activa el cifrado, se crea la Clave de Cifrado, K
c, que es modificada cada vez que el dispositivo entra en modo dicho modo.
La Clave de Cifrado es generada aplicando al algoritmo E3 la Clave de Linkado, un número aleatorio de 128 bits y un Ciphering Offset (COF) basado en el valor de ACO del proceso de autenticación.
En este punto ya estaríamos en condiciones de transferir datos cifrados.
3.1.4. Proceso de cifrado en BlueTooth. La especificación de BlueTooth, cono hemos permite tres modos de cifrado diferentes.
• Modo 1. Ninguna parte del tráfico de datos es cifrada.
• Modo 2. El tráfico general va sin cifrar, pero el tráfico dirigido individualmente se cifra según las claves individuales de la conexión.
• Modo 3. Todo el tráfico es cifrado acorde a la Clave de Cifrado.
La información de usuario es protegida por cifrado de la carga útil (payload), ya que el código de acceso y la cabecera del paquete nunca son cifrados. El cifrado se lleva a cabo con el algoritmo de cifrado E0, que consiste básicamente de tres partes, como se ve en la figura siguiente:
Algoritmo de cifrado E0
Una parte que realiza la inicialización (generación de la clave de carga útil). Una segunda parte que es el generador de cadenas de claves, y finalmente una tercera parte en la cual se realiza el cifrado o el descifrado.
Los parámetros de entrada a dicho algoritmo serán la clave de cifrado que se obtiene del algoritmo E3, la BD_ADDR del maestro y el reloj del mismo y un número aleatorio.
El Generador de Clave de KeyStream combina los bits de entrada de una forma apropiada y los guarda en 4 registros de desplazamiento retroalimentados, conocidos como Linear Feedback Shift Registers (LSFR). Estos registros son de 25, 31, 33 y 39 bits (128 en total). Este método viene derivado del generador de cifrado de Streams de Massey y Rueppel.
Cuando el cifrado está activo, el maestro envía un número aleatorio (RAND) al esclavo. Antes de la transmisión de cada paquete, el LFSR se inicializa en el Generador de Clave de Carga mediante la combinación de RAND, la identificación del maestro, la clave de cifrado K
c y el número de reloj (o número de Slot).
Como el tamaño de la Clave de Cifrado varía desde 8 a 128 bits, tiene que ser "negociado" entre los dispositivos previamente. En cada dispositivo hay un parámetro que define la longitud máxima permitida de la clave. En esta negociación, el maestro manda su sugerencia al esclavo, y este puede aceptarla o enviar otra sugerencia. Así hastaque haya consenso entre los dispositivos, o la uno de ellos aborte la negociación. En cada aplicación, hay definido un tamaño mínimo de clave aceptable, y si estos requerimientos no son cumplidos por ambos dispositivos, la aplicación aborta la negociación, y el cifrado no puede ser usado. Esto es necesario para evitar la situación donde uno de los dispositivos fuerce un cifrado débil algún fin malicioso.
Finalmente se genera el KeyStream (K
cipher) que es sumada en módulo-2 a los datos que se desean cifrar. El descifrado se realizará exactamente de la misma manera usando la misma clave que se usó para el cifrado.
Cada paquete de carga útil es cifrado separadamente, lo cual se consigue si tenemos en cuenta que una de las entradas al algoritmo E0 es el reloj del maestro, el cual cambia una unidad cada intervalo de tiempo (625µs), por lo que la clave de carga útil será diferente para cada paquete, excepto para aquellos que ocupen más de un intervalo de tiempo, en cuyo caso el valor del reloj del primer intervalo de tiempo del paquete será el que se utilizará para todo el paquete.
Descripción funcional del procedimiento de cifrado
3.2. Debilidades de la seguridad. 3.2.1. Generales •
No está demostrada la fuerza del generador pseudoaleatorio del procedimiento “challenge-Response”. Se podrían pruducir números estáticos o repeteciones periódicas que redujeran su efectividad.
•
PINs cortos son permitidos. De hecho se puede elegir la longitud del PIN, que va de entre 1 a 16 bytes. Normalmente los usuarios los prefieren muy cortos.
•
No hay una forma “elegante” de generar y distribuir el PIN. Establecer PINs en una red BlueTooth grande y con muchos usuarios puede ser dificil, y esto lleva normalmente a problemas de seguridad.
•
La longitud de la clave de cifrado es negociable.Es necesario un procedimiento de generación de claves mas fuerte.
•
En el caso del modo 3, la clave maestra es compartida. Es necesario desarrollar un esquema de transmisión de claves mejorado.
•
No existe autenticación de usuarios. Sólo está implementada la autenticación de dispositivos.
•
No hay límite de intentos de autenticación. •
El algoritmo de cifrado por bloques E0 es muy débil. Más tarde se analiza.
•
La autenticación es un simple “challenge-response” con hashes. Según esta diseñado, el esquema es vulnerable a ataques “Man in the Middle”.
•
Los servicios de seguridad son limitados. Servicios de auditoría, de no repudio, etc, no están implementados.
3.2.2. Vulnerabilidades del cifrado. Dejando aparte de que el cifrado es opcional, veremos que además acaece de varias vulnerabilidades.
•
El algoritmo de cifrado por bloques E0 es débil. Aunque se perfilaba como relativamente seguro hace pocos años. Su sistema de creación del Stream para el cifrado es mucho más complejo, y soluciona los problemas de reutilización de claves como el que tiene el RC4 del wifi (802.11b).
Sin embargo, como con todos los algoritmos de cifrado, su seguridad va cayendo paulatinamente.
Aunque E0 permite longitudes de clave que van desde 1 hasta 16 bytes (8-128 bits), Jakobbson y Wetzel presentaron un ataque con complejidad matemática de O(2^100) (esto es el equivalente a reducir la longitud de clave efectiva de 128 a 100 bits).
Posteriormente Fluhrer y Lucks presentaron otro ataque que requería desde O(2^73) hasta O(2^84), dependiendo de la cantidad de keystream capturado.
Hasta aquí podríamos decir que las posibilidades de ataque de recuperación de la Clave de Cifrado no eran efectivas, considerando que para conseguir un O(2^73) había que tener unos 14.000 gigas de keystream.
Pero luego los ataques se fueron perfeccionando, hasta que en 2004, Yi Lu y Serge Vaudenay presentaron un nuevo ataque de correlación, que resuelve en O(2^37) con una cantidad de keystream consecutivo de 64 gigas, mejorándolo en el CryptoAsia 2004 a 2^40 operaciones simples solo con los primeros 24 bits de 2^35 frames.
•
Uso parcial del reloj. Como hemos visto, el reloj del dispositivo maestr es un parámetro de entrada para la generación del Stream de cifrado. Aunque parece que por un fallo de diseño el bit más significativo de su valor es ignorado, permitiendo este hecho entre otras cosas ataques tipo Man in The Middle.
•
Los datos cifrados pueden ser manipulados. Incluso con el cifrado más fuerte, las caracteristicas de los cifrados de Stream permiten que los datos interceptados en un ataque Man in The Middle puedan ser convenientemente manipulados dependiendo de la cantidad de texto cifrado conocida. Así es posible por ejemplo manipular cabeceras IP.
3.3. Vulnerabilidades de la seguridad. Son debidas principalmente a prácticas de codificación erróneas en el desarrollo de los servicios RFCOMM, al desconocimiento de los protocolos de seguridad BlueTooth y demás (OBEX), y a la reutilización de servicios antiguos para protocolos diferentes.
3.3.1. Permisos IrMC • IrMC define los permisos de acceso para los objetos comunes
• Hay objetos visibles aunque el servicio sea “no emparejado”
• Servicios abiertos intencionadamente.
3.3.2. Errores de pila • Buffers Overflows.
• Fallos en la implementación de servicios como en el chequeo de la longitud de datos o la integridad de paquetes en OBEX, o terminaciones NULL.
3.3.3. Servicios ocultos. • Servicios con los más altos privilegios se dejan abiertos pero escondidos.
• Canales traseros para hacerle la vida más fácil a otros dispositivos.
• Acceso completo al comando AT, y por lo tanto a todo el dispositivo.
En el siguiente apartado, el 3.4, veremos los comandos necesarios para manipular sin restricciones un móvil BlueTooth, y veremos como hacerlo a través del IrD. Empieza la parte práctica.
4.2 Ataques BlueBug con comandos ATDespués de haber visto toda la teoría referente a la estructura del protocolo Bluetooth y, habiéndonos centrado en lo relativo a la Seguridad, a continuación pasamos a documentar algunas técnicas, herramientas y aplicaciones basadas en la inserción de comandos AT que permiten llevar a la práctica aspectos de la Inseguridad en Bluetooth.
Estos ataques crean una conexión al dispositivo, dando acceso completo al comando de configuración AT.
Nos permiten básicamente las posibilidades de:
- Control de las llamadas.
- Mandar/leer/borrar SMS.
- Leer/grabar entradas de la agenda.
- Desviar/realizar llamadas de voz/datos.
Por ejemplo, podríamos espiar las conversaciones mantenidas en una reunión. Haciendo que el teléfono de la victima realice una llamada silenciosa a nuestro teléfono, o a cualquier teléfono de cualquier parte del mundo, creamos un canal de comunicación vía GSM que nos permitirá escuchar toda la conversación de la reunión.
Podríamos también instalar una pasarela en el teléfono de la victima, redirigiendo sus llamadas a nuestro teléfono, teniendo así la posibilidad de escuchar y grabar sus conversaciones sin su conocimiento. O podríamos mandar un SMS desde nuestra Laptop a través de su teléfono, haciendole creer al destinatario que los mando la victima. Es posible incluso hacer que el mensaje no se grabe en enviados
Todo esto es debido a que la implementación de los mecanismos de seguridad suele ser muy pobre. Además contamos con varios servicios no documentados o abiertos en los canales RFCOMM.
Hemos dividido esta parte de ataques Bluebug en varios escenarios distintos.
Para cada uno de los distintos escenarios, hemos documentado varios ataques que hacen uso de técnicas y herramientas que permiten explotar vulnerabilidades en teléfonos móviles GSM desde diferentes plataformas: PC, teléfono móvil y PDA.
Por supuesto, previamente al ataque debe tener lugar la detección, scaneado y enumeración de dispositivos Bluetooth en el ámbito de acción del atacante, con el fin de conocer más el sistema a comprometer.
4.2.1. Escenario 1. Desde PC [Linux] El ataque que se va a documentar a continuación tiene lugar en el siguiente escenario:
•
Plataforma atacante: Distribución Linux, en este caso Ubuntu, y adaptador BlueTooth.
•
Plataforma comprometida: Un teléfono móvil que incorpore Bluetooth.
Recordamos que en dispositivos para el PC, sin ninguna modificación en el hardware, la distancia máxima aproximada será de 100 m.
Hemos elegido este modelo porque lo tiene mucha gente y lo que se trata es de poder llevar a la práctica la teoría.
Quede constancia de que en principio la Ngage no es vulnerable, o así viene definida por el fabricante y no hemos encontrado documentación que la catalogue entre los dispositivos vulnerables.
Aún así, hemos podido constatar que no está tan protegida como se cree.
Puede que vuestra Ngage no sea vulnerable a alguno/s de los bugs comentados en este capítulo, ya que depende mayormente del firmware y puede que ya este parcheada.
4.2.1.1. Requisitos previos. Lo primero sería conectar nuestro adaptador Bluetooth USB al PC y activar el Bluetooth de nuestra Ngage en modo NO oculto o visible.
4.2.1.2 Obtener los canales de transmisión. Como venimos explicando anteriormente, tenemos que realizar una detección de datos del dispositivo a atacar. Vamos a comprobar que canales del protocolo RFCOMM usa nuestra Ngage para transmitir datos mediante Bluetooth.
Para ello necesitaremos instalar los siguientes paquetes en nuestro Linux:
• Bluez-utils
• Bluez-pin
Una vez instalados estos paquetes hacemos un escaneo de dispositivos para comprobar que detectamos la Ngage. Para ello abrimos un terminal en Linux, nos identificamos como root y tecleamos:
Esto nos devolverá algo parecido a:
Scanning ...
00:60:57:D0:F9:15 Ngage
Lo que quiere decir que ha detectado un dispositivo con Bluetooth llamado Ngage y su dirección Mac es 00:60:57:D0:F9:15.
Una vez que sabemos la Mac de nuestra Ngage podemos usar la utilidad
sdptool para obtener datos sobre el móvil. La sintaxis de esta utilidad es:
Al usar este comando la respuesta que nos mostrara será algo como esto:
zaerik@ubuntu:~ $ sdptool browse 00:60:57:D0:F9:15
Browsing 00:60:57:D0:F9:15 ...
Service Name: Fax
Service RecHandle: 0x10000
Service Class ID List:
"Fax" (0x1111)
"Generic Telephony" (0x1204)
Protocol Descriptor List:
"L2CAP" (0x0100)
"RFCOMM" (0x0003)
Channel: 1
Language Base Attr List:
code_ISO639: 0x656e
encoding: 0x6a
base_offset: 0x100
Profile Descriptor List:
"Fax" (0x1111)
Version: 0x0100
Service Name: Dial-up Networking
Service RecHandle: 0x10001
Service Class ID List:
"Dialup Networking" (0x1103)
"Generic Networking" (0x1201)
Protocol Descriptor List:
"L2CAP" (0x0100)
"RFCOMM" (0x0003)
Channel: 1
Language Base Attr List:
code_ISO639: 0x656e
encoding: 0x6a
base_offset: 0x100
Profile Descriptor List:
"Dialup Networking" (0x1103)
Version: 0x0100
Service Name: Bluetooth Serial Port
Service Description: Bluetooth Serial Port
Service Provider: Symbian Ltd.
Service RecHandle: 0x10004
Service Class ID List:
"Serial Port" (0x1101)
Protocol Descriptor List:
"L2CAP" (0x0100)
"RFCOMM" (0x0003)
Channel: 3
Language Base Attr List:
code_ISO639: 0x656e
encoding: 0x6a
base_offset: 0x100
Service Name: OBEX Object Push
Service RecHandle: 0x10005
Service Class ID List:
"OBEX Object Push" (0x1105)
Protocol Descriptor List:
"L2CAP" (0x0100)
"RFCOMM" (0x0003)
Channel: 9
"OBEX" (0x0008)
Language Base Attr List:
code_ISO639: 0x656e
encoding: 0x6a
base_offset: 0x100
Profile Descriptor List:
"OBEX Object Push" (0x1105)
Version: 0x0100
Service Name: OBEX File Transfer
Service RecHandle: 0x10006
Service Class ID List:
"OBEX File Transfer" (0x1106)
Protocol Descriptor List:
"L2CAP" (0x0100)
"RFCOMM" (0x0003)
Channel: 10
"OBEX" (0x0008)
Language Base Attr List:
code_ISO639: 0x656e
encoding: 0x6a
base_offset: 0x100
Profile Descriptor List:
"OBEX File Transfer" (0x1106)
Version: 0x0100
Service Name: Handsfree Audio Gateway
Service RecHandle: 0x10007
Service Class ID List:
"" (0x111f)
"Generic Audio" (0x1203)
Protocol Descriptor List:
"L2CAP" (0x0100)
"RFCOMM" (0x0003)
Channel: 2
Language Base Attr List:
code_ISO639: 0x656e
encoding: 0x6a
base_offset: 0x100
Profile Descriptor List:
"" (0x111e)
Version: 0x0100
Lo que quiere decir que nuestra Ngage tiene activos los canales 1,2, 3, 9 y 10 del rfcomm para transmitir datos mediante Bluetooth emulando una conexión RS232.
Bien, vamos a recordar algo más sobre la pila de protocolos de BlueTooth.
El RFCOMM nos permite una emulación de cable serie RS-232 entre dispositivos. Podemos conectar varias decenas de dispositivos entre sí, mediante diferentes conexiones a RFCOMM.
Como vemos en el gráfico, los comandos AT van hacia el L2CAP a través de los canales del RFCOMM, al igual que los comandos del OBEX y demás, por eso tenemos diferentes canales que nos dan diferentes funcionalidades.
4.2.1.3. Comandos AT en la Ngage Hay muchos mas comandos AT, pero en las pruebas solo nos aceptaba algunos (es como si estuviese parcheada contra ciertas cosas), quizás si tenéis una Ngage con un firmware diferente al de las pruebas consigáis algo mas.
Para este apartado necesitaremos instalar los siguientes paquetes:
• rfcomm
• cu
4.2.1.4. Enlazar rfcomm1 con la Mac de la Ngage por el canal 1. Como hemos visto, el canal que a priori van a permitirnos hacer llamadas y cosas de telefonía es el 1, "Generic Telephony".
Abrimos una terminal como root y ejecutamos el comando:
rfcomm bind /dev/rfcomm1 1
Ahora abrimoss un terminal como usuario normal y ejecutamos el comando:
Entonces la Ngage nos pedirá un PIN para conectar con el PC, y escribimos un numero cualquiera, ahora nos pedirá el PIN en el PC y escribimos el mismo código con lo que en la Ngage nos aparecerá un mensaje confirmando que aceptamos la conexión con el PC.
Cuando aparezca este mensaje pulsamos la opción Si.
Ahora en el terminal de Linux nos aparecerá algo así
Y ahí podremos escribir directamente los comandos AT que ejecutaran diferentes acciones en la Ngage.
4.2.1.6 Obtener información básica de la Ngage En el terminal anterior simplemente escribimos los siguientes comandos AT:
• ATI - Devuelve la marca del móvil.
• AT+CGMM – Devuelve modelo de móvil.
• AT+CGMR – Devuelve la versión del firmware de nuestro móvil.
Estos comandos no mostraran nada en la Ngage, es decir el dueño no se dara cuenta de lo que estamos haciendo.
4.2.1.7. Obtener Imei Para esto se usa el siguiente comando AT:
• AT+CGSN
Este comando tampoco mostrara nada en la Ngage.
4.2.1.8 Hacer que llame al número que nosotros queramos Hasta aquí todo parece de lo más normal y poco peligroso, pero ahora veremos como nos permite hacer una llamada desde el PC através de móvil.
Para esto se usa los siguientes comandos AT:
• ATD12345 – Este comando hara que la Ngage haga una llamada de datos al numero “12345”.
• ATD12345; – Este comando hara que la Ngage haga una llamada de voz al numero “12345”.
En la Ngage veremos esto:
Llamada de datos
Llamada de voz
4.2.1.9 Otros comandos AT Por ultimo decir que además de los comandos AT que hemos usado en los tres últimos puntos hay muchos más, lo que pasa es que no todos son aceptados por la Ngage, puede que vuestra Ngage acepte mas comandos AT, ya que esto depende de la versión de firmware que tenga. Si queréis probar mas comandos AT os recomiendo que os leáis el punto del taller Bluetooth donde se habla de ellos.
4.1. Localización y enumeración de dispositivos BlueTooth. 4.1. Ataques de localización y enumeración. Las cabeceras BlueTooth no están cifradas, lo que nos permite muchas posibilidades de ataque a la capa LM.
Para realizar estos ataques vamos a centrarnos en las capas más altas de la pila de protocolos y sacar ventaja de ellas permitiéndonos entre otras cosas.
- Localizar dispositivos BlueTooth en modo “visible”.
- Localizar dispositivos BlueTooth en modo “no visible”.
- Enumerar información de sus servicios.
Todos los ejemplos de este apartado están realizados en un Nokia Ngage y con Ubuntu.
4.1.1. Modo “visible”. Si los dipositivos están en modo visible, simplemente escaneando con la herramienta hcitool de las librerias Bluez nos muestra todos los dipositivos visibles a nuestro alcance.
4.1.2. Modo “no visible”. Un gran número de vendedores desactivan todas las medidas de seguridad y marcan el dispositivo como “no visible”, creyendo que si está oculto, estará seguro.
Aplicando principios generales del funcionamiento de las redes, y las especificaciones del protocolo, nos damos cuenta que los dispositivos no visibles responden, como no podía ser de otra manera, a una llamada directa y a las peticiones enviadas al servicio inquiry.
Aquí vemos como el scan no nos muestra el dispositivo, pero sin embargo si referenciamos la MAC directamente si nos contesta las peticiones.
4.1.2.1. Obtención de MAC por fuerza bruta. Los vendedores esgrimen que el tiempo de localización de la BD_ADDR (dirección MAC) es inviable, una media de 11 horas, pero herramientas multihilo, como RedFang puede utilizar simultáneamente 8 adaptadores BlueTooth USB, reduciendo el tiempo a unos 90 minutos.
4.1.3. Enumeración de servicios. Ahora ya tendríamos localizados todos los dispositivos BlueTooth con los que podemos “contactar”, y seremos capaces de averiguar lo siguiente:
- La dirección BlueTooth (p.e. MAC)
- Clase de dispositivo.
- Tipo de dispositivo.
- Nombre del dispositivo.
Para la extracción de toda esta información necesitamos seguir una serie de pasos, por los que iremos ascendiendo a través de la pila de protocolos, desde el HCI (nivel Link) hasta el SDP (aplicación), para ir recogiendo la información.
4.1.3.1 HCI (Con HCItool) El primer paso es obtener la clase de dispositivo, que nos indicará sus capacidades.
Luego el parámetro info de hcitool nos revelará toda la información posible que nos pueda dar el esta parte del protocolo BlueTooth.
4.1.3.2 SDP (con SDPtool) Ahora cambiamos al protocolo SDP, que nos revelará los servicios de interface y aplicaciones del dispositivo, como puerto de serie, FTP, interface de red, inbox, fax, etc.
También nos permitirá buscar un servicio, añadirlo, borrarlo, etc.
4.2.2. Desde PC [Windows]El siguiente artículo adapta el ataque Bluebug a un entorno Windows XP.
Las pruebas se han llevado a cabo con un
Nokia 6820.
4.2.2.1. Requisitos previos.Lo primero es insertar el dispositivo USB Bluetooth en nuestro equipo e instalarlo para que Windows pueda trabajar con él.
Por parte del teléfono móvil a comprometer, este debe tener Bluetooth activado.
Por último, recomendamos que los dos dispositivos (PC y teléfono) se encuentren previamente emparejados.
4.2.2.2. Detectar el teléfono móvil Bluetooth.Desde Mis Sitios de Bluetooth, procedemos a buscar dispositivos con la acción
Buscar dispositivos a mi alcance.
4.2.2.3. Detectar servicios Bluetooth en el teléfono móvil.Seleccionamos el objeto Nokia 6820 y ejecutamos la acción
Detectar servicios.
4.2.2.4. Establecimiento de conexión con el Puerto Serie COM1.De entre todos los servicios disponibles en el teléfono móvil, seleccionamos el servicio de Puerto Serie COM1 y creamos una conexión.
El teléfono móvil pedirá aceptación de conexión con el dispositivo PC y, en caso positivo, aparecerá el siguiente mensaje en nuestra pantalla.
Este mensaje nos advierte que cualquier aplicación PC puede acceder a la conexión establecida con el teléfono móvil utilizando el Puerto COM4 del PC.
4.2.2.5. Envío de comandos AT al teléfono móvil a través de Hyperterminal.Ahora que ya sabemos cual es el puerto COM que permite al PC comunicarse con el teléfono móvil, iniciamos la aplicación Hyperterminal y creamos una nueva conexión a través del puerto COM4.
A partir de este momento, ya seremos capaces de enviar comandos AT al teléfono móvil a través de Hyperterminal.
Descargar documento: http://www.geocities.com/unrayodesoul/Ataque.Bluebug.desde.Windows.by.Gospel.pdf4.2.3. Desde PC [Anexo Windows, otra forma de hacerlo...]En el post anterior se explicaba como mandar comandos AT desde windows utilizando el driver de vuestro Bluetooth-usb proporcionado por el fabricante.
En este post explicaré cómo mandar comandos AT a un Nokia 3650 utilizando los drivers Bluettoth que ofrece el Service Pack 2 de Windows XP. Por ello es necesario tener instalado SP2.
4.2.3.1. Agregando el dispositivo BluetoothComenzaremos por pinchar nuestro dispositivo a una ranura libre usb y esperaremos a que aparezca un icono azul con el logo de Bluetooth en la bandeja de sistema...
Una vez localizado pincharemos con el botón derecho y seleccionaremos "Abrir la configuración Bluetooth":
En la ventana que aparecerá a continuación pincharemos en Agregar y en la ventana con título "Asistente para agregar dispositivos Bluetooth", marcaremos la casilla "Mi dispositivo está configurado y listo para ser detectado." y pulsaremos en Siguiente.
Una vez detectado lo seleccionaremos y pincharemos en Siguiente:
4.2.3.2. Conocer el puerto COM para mandar comandos ATTras haber esperado un rato para que windows configure el dispositivo, lo siguiente que deberemos averiguar es el puerto COM que ha configurado para mandar comandos AT.
Esto lo descubriremos seleccionando el móvil recién configurado en la ventana "Dispositivos Bluetooth" y pinchando en Propiedades.
En la siguiente ventana con las propiedades del móvil, seleccionaremos la pestaña Servicios y nos fijaremos en el puerto COM que tenga asignado "Acceso telefónico a redes (DUN)"
En caso de que no estuviera marcada su casilla correspondiente, la marcaríamos.
En este caso es el puerto COM9.
La verdad es que deberían salir más servicios de los que muestra esa pestaña, pero para este caso nos vale con que se muestre el DUN.
Para una lista detallada de los servicios teneis que utilizar la utilidad "sdptool" para linux, explicada en otro post.
4.2.3.3. Utilizar HyperTerminal para mandar comandos ATUna vez que sabemos el puerto COM ejecutaremos el programa HyperTerminal de Microsoft (Inicio/Ejecutar "hypertrm.exe") y crearemos una nueva conexión con el nombre que queramos.
En la siguiente ventana titulada "Conectar a" deberemos seleccionar el puerto COM de antes en la lista desplegable "Conectar usando:"
En el momento que pulsemos aceptar, el 3650 nos informará de si deseamos aceptar una nueva conexión procedente de nuestro PC y aceptaremos.
En este momento ya podremos mandar y probar comandos AT en nuestro móvil...
Agradecimientos a godspel por sus textos , para los que les guste el hacking por bluetooth les recomiendo que visiten el blog de godspel
http://elblogdegospel.blogspot.comTambien visiten elhacker.net
sAludos
Entradas
