Hijacking Paired BLE Devices: Obtención de Long Term Key & Windows Impresonation

Como sabéis, el año pasado, y éste, realizo labores de Mentor en el Campus Internacional de Ciberseguridad, donde, entre otras muchas cosas, planteo algunos Trabajos de Fin de Máster para el Máster de Ciberseguridad. Éste, que os publico hoy en forma de artículo, es un trabajo que planteamos Pablo González - que ha dirigido el TFM también - y yo sobre los ataques a conexiones BLE. 

Figura 1: Hijacking Paired BLE Devices.

Obtención de Long Term Key & Windows Impresonation

El trabajo lo han realizado Alejandro Castaño y Miguel González Lara, que son quienes lo escriben a partir de aquí. Espero que os guste y os inspire para seguir trabajando sobre las posibilidades de ataques que se pueden realizar, una vez suplantado un equipo en una comunicación BLE. Este año plantearemos algún TFM que profundice en esta idea en la nueva edición del Máster de Ciberseguridad que comienza ahora.

Saludos Malignos,

Chema Alonso

Hijacking Paired BLE Devices: Obtención de Long Term Key & Windows Impresonation

Todos hemos oído hablar de Bluetooth, y de hecho es una tecnología que forma parte de nuestro día a día sin que nos demos cuenta. Lo que muchas veces pasa desapercibido es el hecho de que cuando hablamos de Bluetooth quizás estamos hablando en algunas ocasiones de Bluetooth Low Energy (BLE). BLE nace con la idea de poder utilizar esta misma tecnología con un consumo mucho menor de energía, lo cual permite poder utilizarlo en miles de dispositivos como herramienta de envío de datos, algo que nos puede facilitar, y mucho, el día a día. Pero claro, sabemos que comodidad y facilidades en ocasiones puede estar reñido con la seguridad, de hecho, a día de hoy, ya se han encontrado múltiples posibles vulnerabilidades a esta tecnología de radio y frente a las que se está buscando solución poco a poco:

• Sniffing Pasivo
• BIAS y BLESA
• Ataques de Firmware
• Blurtooth

Además, estas vulnerabilidades pueden afectar también al entorno empresarial, donde cada vez es más común el uso de tecnología, sobre todo en dispositivos IoT, que utilice el Bluetooth y Bluetooth Low Energy, cómo herramienta de envío de información, ya sea a nivel industrial, cómo un termómetro en una central de uranio, o un simple teclado inalámbrico utilizado por un empleado de la compañía. Todos estos dispositivos como parte del Shadow IoT de las empresas.

Es cierto que estos ataques requieren de cierta cercanía con el dispositivo para poder ser llevados a cabo y generalmente se habla de estar presente durante el proceso de emparejamiento, con el fin de obtener información que permite gran parte de estos ataques. Con esto en mente nos hicimos las siguientes preguntas:

• ¿Existe la posibilidad de robar los Tokens e información de un dispositivo BLE pareado a un equipo controlado?

• -¿Qué posibilidad hay de utilizar estos Tokens para robar información o el control de los dispositivos BLE?

Con esto en mente nos pusimos nuestras mejores galas de investigación y fuimos a por ello. El proceso paso por paso está explicado en nuestro proyecto de fin de máster, pero para hacernos una idea tuvimos que seguir varios pasos:

• Investigar el protocolo.
• Estudiar el registro de Windows.
• Estudiar la forma en que se almacena cierta información.
• Pruebas, pruebas y más pruebas.

POC 1: Obtener BLE Long Term Key

Es cierto, fue una carrera de fondo, pero tuvo su recompensa ya que tras las múltiples pruebas y el esfuerzo pudimos llegar a ciertas conclusiones. La primera de ellas, la importancia de la obtención de la Long Term Key (LTK), la cual podría permitir descifrar conexiones con el acceso adecuado, haciendo un PoC con un código corriendo sobre Raspberry Pi, un Micro:Bit v1.5 con placa NRF y programada en Python.

Figura 2: Libros para Makers en 0xWord que deberías tener:

Arduino para Hackes: PoCs & Hacks Just For Fun,

Hacking con Drones: Love is in the air &

Raspberry Pi para Hackers & Makers: PoCs & Hacks Just for Fun.

Si os interesa, podéis echar un vistazo a la PoC que permite conseguir la BLE LTK que hemos publicando en el GitHub siguiente:

Figura 3: PoC de obtención de BLE LTK en GitHub

La segunda y que más nos llamó la atención fue la posibilidad de suplantar completamente a un dispositivo, este caso para nuestra prueba de concepto utilizamos un ratón BLE de la siguiente forma:

• Emparejamiento del ratón en un ordenador con SO Windows
• Obtención de LTK, Erand y Ediv
• Creación de los directorios necesarios en un ordenador con SO Linux
• Directorio con la MAC suplantada del controlador Bluetooth de Windows
• Directorio con la MAC del ratón
• Fichero con la información de la LTK, Erand y Ediv
• Tenemos el control del ratón desde GNU/Linux.

La posibilidad de tomar este control implica que, dependiendo la situación y el dispositivo, pudiese hacerse con el control de cierta información que envía, suplantarlo, obtener otra información, etc… Para ello, creamos la herramienta BLETool que tienes en el siguiente GitHub.

Figura 4: BLETool en GitHub

Esta herramienta, utilizando credenciales en un sistema MS Windows de NT Authority\\System, permite extraer la información de pareo de un dispositivo BLE con ese sistema operativo. Así, con simples comandos se puede listar, exportar y preparar un comando para suplantar (impersonate en inglés) a este sistema operativo Windows para que el dispositivo BLE se conecte a nosotros en proximidad.

Figura 5: Comandos BLETool. exe en Windows

Con esta opción  (-oi o --OutputInfo) BLETool.exe va a extraer la información del registro de Windows y va a escribir un fichero llamado "info", en el directorio actual donde se está ejecutando la herramienta. Este fichero info va a contener la información necesaria que va a necesitar un equipo GNU/Linux con bluez para poder configurar un dispositivo maestro. Si se utiliza esta opción, se tiene que crear luego la estructura de directorios necesaria en /var/lib/bluetooth/ del equipo atacante.

Figura 6: Creando un volcado de la configuración BLE del equipo Windows

Para simplificar la creación de la configuración del equipo que va a suplantar a este Windows para conseguir que el dispositivo BLE se conecte a él, se puede utilizar la opción --outputBase64 o también -ob. Esta opción va a generar uno o varios comandos de GNI/Linux que ejecutándolos van a permitir crear en el equipo atacante la estructura de directorios necesaria en /var/lib/bluetooth/ y el fichero info que contiene la información BLE para suplantar al Windows en el ataque. Esta es la opción recomendada y más cómoda para extraer la información.

Figura 7: Comandos GNU/Linux para suplantar al Windows en conexión BLE

Con la opción Verbose, podrás ver la lista de dispositivos BLE que se han conectado a este equipo Windows, para que sepas qué se va a poder conectar a tu equipo atacante.

Figura 8: Información de dispositivos BLE conectados a este Windows.

Es decir, ya tendríamos lista toda la información necesaria para irnos a nuestra Raspberry Pi y suplantar al sistema Windows. Para ello, primero hay que ejecutar el comando que hemos extraído con BLETool.exe - ob, y tendremos la estructura de ficheros necesaria y la configuración BLE adecuada en el archivo Info.

Figura 9: Estructura de ficheros BLE en Raspberry Pi 

Luego, tendremos que poner la MAC Address del sistema operativo Windows, que es fundamental para las conexiones. Para ello tienes que ejecutar el comando hcitool siguiente:

hcitool cmd 0x3f 0x01 0x96 0xde 0x66 0x35 0x76 0x7c

Donde 0x3f 0x01 es el comando que se envía al controlador, por lo que no debes modificarlo. Y 0x96 0xde 0x66 0x35 0x76 0x7c es la MAC que quieres que tenga tu controlador, escrita en Little Endian, es decir al revés. Y lo compruebas con hciconfig:

Figura 10: Cambiada la MAC con hcitool

Una vez configurada, te queda reinicializar el servicio de BlueTooth, usando el comando:

• systemctl restart bluetooth

Y el resto es esperar a que los dispositivos BLE que ya habían negociado conexión con el sistema Windows al que estamos impersonando se conecten a nuestra Raspberry Pi  para que veamos que tenemos su conexión. Todos los datos que envíen, llegarán a nuestra máquina atacante.

Figura 11: Dispositivos BLE conectados a nuestra Raspberry Pi 

Podéis obtener más información en el Readme del propio GitHub donde viene explicado el proceso de investigación parte por parte. Y tienes todo el proceso explicado en el siguiente vídeo.

Figura 12: PoC de suplantación de Windows en conexión BLE

Aunque la posibilidad de recibir estos ataques es más baja que otros vectores pueden ser cruciales, por lo que el riesgo de recibir un ataque de estas características es muy alto. Además, teniendo en cuenta que cada vez esta tecnología es más frecuente, y puede encontrarse en dispositivos que ni siquiera se plantean durante un correcto bastionado de la empresa, hace que pueda pasar desapercibido el peligro.

Un saludo,

Autores: Alejandro Castaño y Miguel González Lara alumnos del Máster de Ciberseguridad del Campus Internacional de Ciberseguridad

Contactar con Alejando Castaño Caballero

Contactar con Miguel González Lara

OpenWifiPass: Hacking iPhones con WiFi Sharing Protocol

En el artículo de hoy vamos a hablar de OpenWifiPass, que es una prueba de concepto que se ha publicado recientemente y está ligada con los trabajos “Wi-Fi Sharing for All: Reverse Engineering and Breaking the Apple Wi-Fi Password Sharing Protocol” y “Disrupting Continuity of Apple’s Wireless Ecosystem Security: New Tracking, DoS, and MitM Attacks on iOS and macOS Through Bluetooth Low Energy, AWDL, and Wi-Fi” centrados en analizar el uso que Apple hace las tecnologías BLE. 

Figura 1: OpenWifiPass: Hacking iPhones con WiFi Sharing Protocol

En el pasado en Ideas Locas ya tomamos una investigación similar, la popular apple_bleee, como base para crear Airdrop Crazy y añadirlo a la lista de herramientas y utilidades para usar en cualquier proyecto de Hacking iOS: iPhone & iPad, y en este caso esta PoC se basa en las dos citadas, además de utilizar el mismo conjunto de protocolos.

Figura 2: Libro de Hacking iOS (iPhone & iPad) 2ª Edición
de Chema Alonso, Alejandro Ramos, Igor Lukic, Ioseba Palop.

-

Hoy hablaremos del proyecto OpenWifiPass el cual permite escanear en busca de peticiones Bluetooth de dispositivos iPhone/iPad que están solicitando contraseña de WiFi para conectarse a una red. Esta es una característica de los dispositivos de Apple que si tienes un iPhone, seguramente la hayas utilizado en algún momento. Imagínate que estás en casa de un amigo y en vez de darte la contraseña para que la introduzcas, tu iPhone solicita que le compartan la contraseña de la WiFi al dueño de la casa, que también tiene un iPhone.

Figura 3: Opción de compartir la clave de la WiFi en iPhone

Como se indica en el Github del proyecto de OpenWifiPass es una prueba experimental de ingeniería inversa del proyecto Open Wireless Link. El código se proporciona con fines de investigación y educativos. Como prueba de concepto que es el proyecto no ha sido probado y está incompleto, aunque funcional para la prueba de concepto. ¿Qué es incompleto? Realmente el código no verifica la identidad del solicitante de la contraseña a través del protocolo.

Requisitos para probar el proyecto

Los requisitos para probar el proyecto son pocos, nos vale con tener a mano una Raspberry Pi 4 y disponer de Raspbian o cualquier distro GNU/Linux que ejecutemos en una Raspberry. Desde el punto de vista de dependencias se hará uso de bluepy, pero el proceso de instalación es realmente sencillo, por lo que no habrá problemas. El código de la herramienta está escrito en Python.

Figura 4: "Raspberry Pi para Hackers & Makers: PoCs & Hacks Just For Fun"
de Amador Aparicio, Pablo Abel Criado y Héctor Alonso

El hacerlo con Raspberry es por darle un toque "maker" y hacerlo "portable" y porque tiene el adaptador de Bluetooth integrado y va a ser rápido montar el proyecto, pero podría hacerse en cualquier entorno con un adaptador Bluetooth compatible. El adaptador debe poder utilizar Bluetooth Low-Energy.

Figura 5: Repositorio GitHub de OpenWifiPass

¿Cómo instalamos el proyecto? Este paso es uno de los más sencillos, para el tipo de herramientas o pruebas de concepto con los que nos movemos generalmente. Lo primero será hacer el git clone del proyecto y, posteriormente, ejecutar la siguiente instrucción pip3 install ./openwifipass. La instalación es bastante rápida y nos prepara un módulo llamado openwifipass. Para la ejecución de la herramienta debemos ejecutar la instrucción:

sudo -E Python3 -m openwifipass --ssid [nombre SSID de la rea a compartir contraseña WiFi] --psk [contraseña que se quiere enviar al dispositivo].

Cuando lo arrancamos, veremos que se queda en “Start Scanning” un rato, y parece que no ocurre nada. Esto es normal, ya que debemos esperar a que desde un iPhone/iPad nos soliciten la contraseña WiFi de una red conocida. Nosotros, en el ejemplo, estamos ofreciendo la red bit_up, por lo que cuando un iPhone/iPad en nuestro alcance, intente conectarse a la red se produce el intercambio de información.

Figura 6: Arrancando OpenWifipass 

Nos estamos haciendo pasar por un dispositivo de Apple y estamos negociando y entregando la contraseña WiFi que el usuario quiere, y en el momento en que algún dispositivo se quiera conectar a la red, se entrega la password que hemos decidido nosotros.

Figura 7: Un dispositivo ha pedido la password y se la hemos entregado

Mientras tanto en el dispositivo móvil encontramos lo siguiente, la contraseña se configura automáticamente y se conecta contra la red WiFi. En la imagen no se visualiza, pero en el apartado de “contraseña” faltarían los puntos de la contraseña introduciéndose y conectando con la red.

Figura 8: Contraseña entregada al iPhone

La prueba de concepto está genial. El trabajo es brillante y todos los detalles de la investigación se irán publicando por parte de sus investigadores, pero lo que nos queda claro es que es más que utilizable, por ejemplo, en un ejercicio de Red Team en múltiples escenarios. Pongamos que necesitamos ganar acceso a un sitio o conseguir información de un objetivo concreto, dentro del ejercicio de Red Team. 

Figura 9: El Red Team de la empresa
de Eduardo Arriols en 0xWord

El montaje de una red WiFi a través de un punto de acceso bajo nuestro control - un Rogue AP - con el SSID de “nombre_empresa” puede ser llamativo para muchos. En el momento que el usuario intente conectarse desde iOS, tendríamos montado la rasp con la PoC y le proporcionaríamos la contraseña al usuario. En ese instante, el usuario se conecta a nuestro punto de acceso WiFi y toda su comunicación pasa por nosotros en un esquema de Man in the middle. El esquema y el ataque mola, muy aprovechable en un ejercicio de Red Team, pero eso lo dejamos para otro artículo.

 

Saludos,

Pablo González Pérez (@pablogonzalezpe), escritor de los libros "Metasploit para Pentesters: Gold Edition", "Hacking con Metasploit: Advanced Pentesting" "Hacking Windows", "Ethical Hacking", "Got Root",  “Pentesting con Powershell (2ª Edición)”, "Pentesting con Kali Silver Edition" y de "Empire: Hacking Avanzado en el Red Team", Microsoft MVP en Seguridad y Security Researcher en el equipo de "Ideas Locas" de la unidad CDCO de Telefónica.  Para consultas puedes usar el Buzón Público para contactar con Pablo González - Conseguir 100 Tempos Gratis en MyPublicInbox

 Contactar con Pablo González

Cinco mujeres hacker que posiblemente no conoces y su gran aportación al mundo de la Ciencia y la Tecnología (Parte 2 de 5): Hedy Lamarr

Si os decimos que una de las invenciones en la ciencia que fue clave en el desarrollo de tecnologías que hoy utilizas todos tus días, como son las redes WiFi, las conexiones BlueTooth o el sistema GPS, fue diseñado por una mujer hacker y actriz que rompió las normas de su tiempo con una película que generó escándalo - al estilo de Instinto Básico o 9 Semanas y media pero en 1933-, y que lo hizo porque quería proteger los torpedos controlados por radio que se utilizaban en la Segunda Guerra Mundial para luchar contra los nazis, seguramente pienses que es el guión de una película de Quentin Tarantino. Pero no, es la historia de Hedy Lamarr.

Figura 10: Cinco mujeres hacker que posiblemente no conoces

y su gran aportación al mundo de la Ciencia y la Tecnología

(Parte 2 de 5):  Hedy Lamarr

La historia de Hedy Lamarr es de cine, y nunca mejor dicho, como comprobarás ahora. Además, la podemos incluir en la honrosa lista de mujeres hackers (junto por ejemplo a Joan Clarke) que ayudaron a vencer a los nazis utilizando la Ciencia y la Tecnología. Nacida en 1914 en la ciudad de Viena (Austria) y desde pequeña se quedó fascinada con el mundo del teatro y del celuloide. 

Figura 11: Hedy Lamarr 

Pronto destacó como actriz y se hizo mundialmente famosa por una película muy adelantada a su tiempo llamada “Ectasy”, donde se veían primeras interacciones sexuales y el orgasmo de una mujer. Tanto impactó generó esta película en ese tiempo que fue prohibida por el Papa Pio XII e incluso el mismísimo Hitler también se llego a pronunciar en contra de ella, y eso que sólo se mostraban las caras de los actores en las escenas teóricamente eróticas, dejando a la imaginación del espectador todo.

Figura 12: Póster de la película Ectasy

En el año 1933, el mismo en el que se estrenó la polémica película, conoció a su marido, Friedich Mandl, un “angelito” traficante y fabricante de armas cercano al mundo fascista de Hitler y Mussolini. Pronto Hedy no pudo aguantar más la vida junto a su marido, que según ella se volvió posesivo y controlador, además de que ella tenía descendencia judía, lo que la hacía potencialmente víctima del régimen nazi. Así que decidió abandonarlo todo y escapar a Londres y desde allí, viajar a Hollywood. Allí llegó a ser la protagonista de varias películas donde llegó incluso a compartir cartel con estrellas como Clark Gable y James Stewart entre otros. 

Figura 13: Hedy Lamar junto a Victor Mature en una escena

de la oscarizada película “Sanson y Dalila”

Y en este punto te preguntarás ¿dónde está la contribución de Hedy Lamarr a la Tecnología? Pues ahora veremos el gran giro de guion en su fantástica historia. Lamarr tenía como entretenimiento inventar y desarrollar ideas, que después implementaba, a pesar de no tener formación específica en ningún campo concreto. Llegó a desarrollar inventos tan dispares como una pastilla para crear una bebida carbonatada, un collar para perros fluorescente o incluso un semáforo mejorado para el tráfico. Pero su gran aportación llegó durante la Segunda Guerra Mundial.

Ella pensó que los torpedos controlados por control remoto se podrían desviar fácilmente de su rumbo si se interceptaba y modificaba la señal de radio. Así que se le ocurrió la idea de crear un sistema de salto de frecuencia (frecuency-hopping) para evitar esa intercepción al cambiar rápidamente de frecuencias. Para implementar su idea llamó a su amigo, George Antheil, compositor y pianista para que le ayudara a fabricarlo (de hecho, el prototipo era un piano que se sincronizaba con diferentes señales de radio). 

Figura 14: US Patent 2.292.387 de Hedy Kiesler Markey

(Hedy Lamarr) y George Antheil

Para ello desarrollaron la patente US Patent 2.292.387 para un sistema de guiado de radio que utilizaba el espectro ensanchado y los saltos de frecuencia que antes hemos mencionado. El problema era que el sistema que idearon no era fácil de implementar (y la marina norteamericana, que estaba en plena guerra, no era muy receptiva para implementar un trabajo externo) y no fue hasta 1962 cuando por fin, se pudo comprobar su efectividad.

Figura 15: Detalle de la patente presentada por Hedy Lamarr

donde se puede ver su nombre en la firma.

La invención del salto de frecuencia es una técnica que se ha implementado actualmente (además de en su idea original, para evitar la interceptación de los torpedos) en tecnologías tan conocidas que usamos en nuestro día a día como son los protocolos de comunicación WiFi, el sistema GPS y la conexión de dispositivos Bluetooth, entre otros muchos lugares donde se emplea esta técnica.

Figura 16: George Antheil y Hedy Lamarr CE Hall of Fame Team Induction 2014

No fue hasta 1997 cuando por fin, un premio de la Electronic Frontier Foundation llamado Pionner Award le fue concedido por su trabajo. Este reconocimiento público fue el detonante de otros muchos más, como el BULBIE Gnass Spirit of Achievement Bronze Award, en 2014 el Hall of Fame de Consumer Electronic o en 2017 el Lamp Luminary, que fueron llegando poco a poco hasta nuestros días.  Hedy Lamarr falleció el 19 de enero del año 2000 a la edad de 85 años. 

*************************************************************************************

- Cinco Mujeres Hacker que posiblemente no conoces: Arianna Wright Rosenbluth 

- Cinco Mujeres Hacker que posiblemente no conoces: Hedy Lamarr

- Cinco Mujeres Hacker que posiblemente no conoces: Elizebeth S. Friedman

- Cinco Mujeres Hacker que posiblemente no conoces: Radia Perlman

- Cinco Mujeres Hacker que posiblemente no conoces: Elizabeth Jake Feinler 

*************************************************************************************

Happy Hacking Hackers!!!

Autores:

Fran Ramírez, (@cyberhadesblog) es investigador de seguridad y miembro del equipo de Ideas Locas en CDO en Telefónica, co-autor del libro "Microhistorias: Anécdotas y Curiosidades de la historia de la informática (y los hackers)", del libro "Docker: SecDevOps", también de "Machine Learning aplicado a la Ciberseguridad” además del blog CyberHades. Puedes contactar con Fran Ramirez en MyPublicInbox.

 Contactar con Fran Ramírez en MyPublicInbox

Rafael Troncoso (@tuxotron) es Senior Software Engineer en SAP Concur, co-autor del libro "Microhistorias: Anécdotas y Curiosidades de la historia de la informática (y los hackers)", del libro "Docker: SecDevOps" además del blog CyberHades. Puedes contactar con Rafael Troncoso en MyPublicInbox.

Contactar con Rafael Troncoso en MyPublicInbox

Una pequeña explicación del uso de BLE (Bluetooth Low Energy) en Radar COVID-19

Hoy en día, tanto el protocolo Bluetooth como la especificación Bluetooth Low Energy (BLE) se han convertido en unos de los protocolos más utilizados en el mundo. De hecho, muchos de los dispositivos más cotidianos y que usamos en el día a día lo tienen incorporado: ordenador personal y navegadores de Internet - que se pueden usar para proteger la navegación en canales paralelos como en el caso del Second Web Browsing (2FWB) - e incluso en páginas web con la especificación WebBlueTooth, smartphones, tablets, smartwatches, auriculares como los AirPods Pro, teclados, luces inteligentes, impresoras, trackers busca-cosas, cámaras digitales con accesos BLE,  altavoces como los del ataque Diritytooth, smartTVs, patinetes eléctricos, vídeoconsolas y muchos, muchos más.

Figura 1: Una pequeña explicación del uso de
BLE (Bluetooth Low Energy) en Radar COVID-19

Todos ellos tienen características de seguridad y privacidad que hay que analizar, y en el mundo del Ethical Hacking y la auditoría de seguridad tenemos herramientas como BLECTF para probar nuestras habilidades en competiciones Capture The Flag basadas en BLE o retos en formaciones de pentesting BLE, herramientas como BTLEJack & Micro:Bit para probar los ataques Man in the Middle que se pueden programar con Microsoft MakeCode, como vimos,  y la herramienta HomePWN del equipo de Ideas Locas de CDCO que construyó Pablo González y sus compañeros, que fue a la BlackHat Europe el año pasado para explicar cómo se pueden hacer ataques a conexiones BLE. 

Al final, Bluetooth es un protocolo de comunicación inalámbrica que actúa con una radiofrecuencia en la banda ISM de los 2.4 GHz que puede ser usado para muchas cosas. Permite la transmisión de datos de forma inalámbrica entre distintos dispositivos, permitiendo, por ejemplo, comunicar nuestro portátil u ordenador con periféricos como un teclado y un ratón o que nuestro smartphone se comunique con nuestros auriculares inalámbricos. También, se utiliza para la compartición de archivos entre dispositivos, como por ejemplo música o fotografías. Además, Bluetooth no necesita estar en la línea de visión de los dispositivos, es decir, puede haber obstáculos o una pared entre ellos.

En posts anteriores, ya se ha hablado bastante de este protocolo, analizando ciertos aspectos de éste y mostrando algunas herramientas para poder estudiarlo, analizarlo - como ya hemos dicho - y ver posibles ejemplos de ataques. En este artículo, quiero centrarme en explicar cómo se puede utilizar Bluetooth o cómo se está utilizando para combatir al COVID-19. Para ello, me centraré en una pequeña parte, pero muy importante, de este protocolo: el Bluetooth advertising.

Bluetooth advertising

¿A qué nos referimos cuando hablamos de Bluetooth advertising? Bluetooth advertising es la forma en la que un dispositivo Bluetooth se da a conocer de forma pública para que otros dispositivos puedan conectarse a él. Para realizar las comunicaciones, Bluetooth Low Energy (BLE) dispone de 40 canales, numerados del 0 al 39 en la banda de los 2.4 GHz, tal y como puede verse en la imagen siguiente. Generalmente, durante la publicación o el advertisement, se utilizan los canales 37, 38 y 39, aunque en versiones recientes de Bluetooth también pueden utilizarse otros canales. Nosotros solamente nos centraremos en el uso de estos 3 canales. La parte buena de estos 3 canales, tal y como se muestra en la imagen siguiente, es que no colisionan con ningún canal WiFi.

Figura 2: Canales utilizados en Bluetooth Low Energy (BLE) 

Es importante destacar también que, en este artículo, no entraremos en todos los detalles de cómo se realiza el proceso de advertisement. Solamente, quiero dar una buena intuición de cómo funciona y qué es lo que se hace durante este proceso para explicar posteriormente cómo se está utilizando para el COVID-19.

Durante el proceso de anuncio o advertisement, el dispositivo BLE transmite el mismo paquete en los 3 canales. De esta forma, otro dispositivo u otros dispositivos BLE serán capaces de ver esos paquetes y obtener una determinada información. Es importante mencionar que no todos los dispositivos BLE envían paquetes de anuncio. Esto depende del tipo de aplicación para la que está pensado y de su rol GAP (Generic Access Profile), definido en una de las capas más superficiales que forman la arquitectura de BLE.

Roles GAP (Generic Access Profile)

Antes de ver los roles GAP que existen, es importante mencionar que se distinguen dos tipos de aplicaciones en función de estos roles: aplicaciones orientadas al broadcasting y aplicaciones orientadas a la conexión. En la primera de ellas, el dispositivo no admite conexiones, solamente envía paquetes de anuncio. En la segunda, los dispositivos BLE establecen una conexión e intercambian datos entre ellos. Existen los siguientes 4 roles GAP:

- Broadcaster: envían cada cierto tiempo paquetes de anuncio, sin admitir conexiones. El tiempo varía entre unos pocos milisegundos y aproximadamente 10 segundos. Es configurable.

- Observer: están atentos a leer y captar esos paquetes de anuncio. Tampoco admiten conexiones.

- Peripheral: son capaces de enviar paquetes de anuncio para darse a conocer y aceptar conexiones procedentes de una central.

- Central: son capaces de leer y captar paquetes de anuncio para establecer una conexión con esos dispositivos. Si se trata de un broadcaster, lógicamente, no podrán establecer una conexión con él. Sin embargo, si se trata de un dispositivo con el rol peripheral sí. Es importante destacar que un mismo dispositivo puede utilizar varios roles al mismo tiempo. Por ejemplo, nuestro smartphone. Este podría actuar como central para un smartwatch o unos auriculares inalámbricos y al mismo tiempo actuar como peripheral para nuestro ordenador. 

Llegado a este punto, muchos os preguntaréis lo siguiente: ¿para qué quiero un dispositivo que sea capaz de darse a conocer o de anunciarse para luego no admitir conexiones? No os preocupéis, más adelante veréis cómo se pueden utilizar para combatir al COVID-19. Hasta este momento, solamente quiero que os quedéis con el siguiente concepto: un dispositivo BLE es capaz de enviar paquetes “públicos” y visibles por otros dispositivos, sin la necesidad de tener que admitir conexiones.

Un paquete de anuncio tiene una capacidad de payload útil de 37 bytes, de los cuáles 6 bytes son utilizados obligatoriamente para especificar un identificador único (que no tiene por qué ser siempre el mismo). Esto nos deja disponibles 31 bytes para enviar información, que generalmente suele enviarse con una determinada estructura e identificadores. En caso de necesitar enviar más información podemos utilizar la funcionalidad Scan Request y Scan Response.

Además, el dispositivo receptor es capaz de medir la fuerza de la señal (RSSI o Received Signal Strength Indicator) con la que está recibiendo esos paquetes de anuncio o advertisement. Esto permite al receptor o descubridor aproximar la distancia a la que se encuentra el emisor. Es cierto que este valor no solamente depende de la distancia, sino que también depende de otros factores como los obstáculos, las paredes y otros factores ambientales. Además, es un valor que varía en función del dispositivo BLE que se esté utilizando.

Aun así, existen varios papers que ya han obtenido resultados bastante buenos combinando este valor con otras métricas. Lo que sí está claro es que podemos usarlo, combinándolo con métodos matemáticos (Kalman Filter por ejemplo) y ya estudiados, para predecir una distancia. Quizás, no podamos predecir distancias directas pero sí que podemos definir “cubos” o distancias orientativas.

BlueTooth Low Energy y su uso frente al COVID-19: Exposure Notifications

Llegados a este punto, ya podemos analizar o ver cómo podemos utilizar Bluetooth o más concretamente BLE para combatir al COVID-19. Gracias al RSSI podemos aproximar distancias entre dispositivos y gracias a los paquetes de anuncio podemos compartir información con otros dispositivos sin necesidad de tener que establecer una conexión previa.

Partiendo de que todos nosotros solemos llevar un smartphone en el bolsillo, podríamos utilizar BLE para medir de forma automática la distancia con todas las personas con las que estamos en contacto en nuestro día a día. Además, gracias a los paquetes de anuncio podríamos guardar un número o identificador de todas esas personas con las que hemos estado en contacto, dentro de un almacenamiento local de nuestro móvil, de forma que si alguna de estas personas se contagia del virus seamos capaces de saberlo y saber cuánto tiempo hemos estado en contacto con ellas y, así, determinar qué probabilidad de contagio tenemos.

Pues, esto ya existe. Las empresas Google y Apple han desarrollado una API, llamada Exposure Notifications, que el gobierno de cada país puede incluir en una aplicación Android o Apple para detectar y rastrear contagios de COVID-19. En el caso de España es Radar COVID. Además, existe ya algún estudio que dice que esta aplicación es bastante más efectiva que los rastreadores manuales, detectando hasta el doble de contagios. 

¿Cuál es el objetivo de Radar COVID?

El objetivo fundamental es ser capaz de detectar contagios sin utilizar datos personales que identifiquen a una persona. Entonces para ello, voy a utilizar el ejemplo el gráfico siguiente, que proporciona Google para dar detalles del algoritmo, ver qué papel juega el BLE en todo esto y mostrar que, efectivamente, no utiliza datos personales del usuario.

Figura 3: Gráfico que explica el funcionamiento

Partimos del ejemplo del gráfico, donde nuestros protagonistas son dos personas que no se conocen entre ellas, Alice y Bob, y que tienen un smartphone con esta aplicación y con el BLE activado. Sus smartphones generan identificadores únicos (Rolling Proximity Identifiers) cada 15 minutos aproximadamente, a partir de una clave que se genera cada 24 horas (Temporary Exposure Key). Estos identificadores son emitidos cada cierto tiempo (unos milisegundos) por el smartphone en forma de paquetes de anuncio BLE. Para más detalles, ver la tabla siguiente.

Figura 4: Estructura e información que envía nuestro smartphone cuando

realiza el anuncio o advertisement utilizando la API Exposure Notifications

Entonces, cuando Alice y Bob se encuentran, sus smartphones son capaces de obtener los identificadores de uno y de otro, es decir, el smartphone de Bob obtiene el identificador de Alice y el de Alice obtiene el identificador de Bob. Estos identificadores se almacenan de forma local en sus smartphones. 

Cuando a Bob le diagnostican y le comunican que está contagiado de COVID-19, este tiene la posibilidad de subir a la nube todos los identificadores únicos que ha generado su smartphone, de forma voluntaria. De esta forma, cuando los identificadores de Bob estén en la nube, la aplicación será capaz de alertar a Alice, comparando los identificadores con los que ha estado en contacto en los últimos 14 días y almacenados en su móvil de forma local con los identificadores que hay en la nube.

La aplicación NO almacena los identificadores de todos los paquetes de anuncio que recibe, solamente almacena aquellos que cumplen con el tiempo de exposición y distancia especificados. Este tiempo y distancia lo decide cada aplicación que utiliza la API. La API genera la Temporary Exposure Key cada 24 horas por cuestiones de privacidad y seguridad. Además, los Rolling Proximity Identifiers se renuevan cada 15 minutos con el fin de evitar que un smartphone pueda ser monitorizado a través de estos identificadores. Seguramente muchos de vosotros tengáis interés por ver más acerca de esta API, así que os dejo por aquí un enlace a la documentación.

Y con esto termina el post 😊. A mí, personalmente, me parecen increíbles muchas de las aplicaciones que se le están dando al BLE. Una de ellas es esta. Y las que vendrán.

Saludos,

Autor: Alberto Rivera, de Ideas Locas CDCO

AirPods Pro: Unas pruebas en casa de Safety & Security (II de III) Cómo te pueden vigilar por tus AirPods sin que lo sepas.

Hoy que he sacado algo de tiempo os escribo la segunda parte de esta serie, donde os voy a hablar de un tema de "Safety" que me preocupa bastante. Y es que el coste de estos AirPods Pro es muy alto, y al igual que sucedía con los teléfonos de alta gama, son propensos a generar incidentes de robo, con y sin violencia. Pero también puede servir para espiar la ubicación de una persona en todo momento. 

Figura 7: AirPods Pro: Unas pruebas en casa de Safety & Security (II de III)
Cómo te pueden vigilar por tus AirPods sin que lo sepas.

En los terminales iPhone el uso de Find My iPhone y marcar el terminal como perdido exigiendo al que lo tenga que se autentique con la cuenta de Apple ID del dueño, redujo mucho este tipo de incidentes. Es decir, el bloqueo de los terminales iPhone por parte del dueño fue un elemento disuasorio muy importante entre los ladrones, ya que venderlos robados y bloqueados no es algo sencillo. Por eso pensé en si llevaban algún mecanismo similar en los AirPods Pro... y la respuesta es sí y no, por lo que yo he probado.

3.- Pareado con multiples dispositivos y multiples Apple ID

En un inicio pensé que, si conectabas unos AirPods Pro a un terminal Apple (MacBook, iPhone o Apple Watch) que pertenecía a un Apple ID, entonces ya no se podría parear a cualquier otro dispositivo en el que el Apple ID fuera otro distintos. Pero no. Parece que Apple no quiso cruzar ese puente y puedes conectar unos AirPods Pro a dispositivos con diferentes cuentas de Apple ID.

Figura 8: Los AirPods Pro no se pueden bloquear como robados o perdidos

Así que, si alguien se encuentra tus AirPods Pro o te los roba los puede utilizar, de hecho, la prueba que hice en la parte anterior de conectar cada auricular con dispositivos distintos lo hice con dos dispositivos asociados a dos Apple ID diferentes.

Figura 9: Los AirPods aparecen en el Find My iPhone de TODAS las cuentas de Apple ID
que lo han pareado alguna vez.

Y esto es muy curioso, ya que cualquiera de las cuentas de Apple ID que haya pareado correctamente los AirPods podrá usarlos... y esto tiene unas implicaciones de Seguridad y Privacidad interesantes. Lecciones aprendidas:

h.- Compartir AirPods Pro es compartir localización de Apple ID.

4.- Regalar unos AirPods para vigilar a una persona

Vamos a suponer que una persona desea vigilar a otra persona y saber dónde está en todo momento. Podría ser un padre que quiera tener un "control parental" de una persona, o una pareja que quiera vigilar los movimientos de otra persona cuando entre y salga de casa o del trabajo... o cosas peores. Basta con que haga lo siguiente:

1.- Compra unos AirPods Pro. 

2.- Los parea y usa en tu terminal iPhone. 

3.- Se los regala a la persona que quiere vigilar. 

4.- La persona vigilada puede usar Find My iPhone para saber donde están los AirPods Pro, y por ende, el dueño de los mismos.

Esto abre un problema serio de privacidad, ya que si compras unos AirPods Pro de segunda mano, o te los regalan, y alguien los ha pareado ya en su cuenta, puede que estés enviándole constantemente tu localización a Find My y cuando esta persona este cerca (a distancia de BlueTooth) podrá verla. Y puede que no sea lo que quieres. Y encima la persona que te tiene vigilada no ha tenido ni que instalar un troyano, ni nada. 

Figura 10: Todas las cuentas de Apple ID podrán saber dónde están esos AirPods Pro

Es casi involuntario para todos, lo único que tiene que estar activado en el terminal de la persona que se va a "espiar" es el servicio de Find My iPhone que, probablemente lo tendrá activado. Lo peor de todo es que la persona que tiene los AirPods  pareados por alguien que le vigila no tiene ninguna información. No sabe que sus AirPods Pro han sido pareados a varios Apple ID, y no sale que está compartiendo su localización - vale, no es la suya, es la de su iPhone conectado a sus AirPods - con otro Apple ID cuando esté cerca. Lo que permite a un acosador vigilar cuando entra y sale de casa, cuando entra y sale del trabajo, etcétera. Esto creo que está mal hecho por Apple. Es algo que debería arreglar.

Figura 11: Activar Last Location en Find My iPhone

Por supuesto, si te los roban, es difícil localizar quién te los quitó si no estás cerca, pues el servicio solo te deja ver la localización de tus AirPods cuando estás a distancia de BlueTooth, luego si te los roban, el ladrón podrá usar tus AirPods y tu no recibirás la ubicación. Es decir, el modelo que ha elegido Apple deja puertas abiertas a tu privacidad a distancia de BlueTooth y no resuelve el problema del robo. Mal doblemente.

j.- Si te roban unos AirPods es difícil que localices al ladrón.

Pero mucho peor, puede que en la oficina dejes los AirPods Pro encima de la mesa, alguien los paree a su cuenta, y luego te los deje otra vez en tu sitio. Tú no te darías cuenta de que estás siendo vigilado, pero a partir de ese momento pueden vigilar tus movimientos de entrada y salida de la oficina con Find My iPhone. Peligroso.

Figura 12: Si llevas los AirPods y el estuche cerca, cualquiera puede parearse en un descuido.

Haz la prueba tu mismo. Parea tus AirPods Pro con dos terminales iPhone y entra en Find My iPhone, los AirPods Pro estarán bajo vigilancia de localización de ambas cuentas y aparecerán en los dos Find My iPhone. Peligroso. Muy peligroso.

4.- El pareado es la clave

Pensando en todo eso, la clave es el pareado de los AirPods. Si te pueden parear los AirPods Pro, los pueden usar para saber dónde estás, y los pueden usar libremente. Esto último será un reclamo para ladrones con y sin violencia. Pero... ¿cómo evitar el pareado?

Figura 13: Número de Serie en el estuche cargador

Para parearse hace faltan que tengas los auriculares y el estuche cargador de batería de AirPods Pro juntos. Así que si sales a la calle, tal vez no llevar el estuche cargador de batería es una buena opción para evitar estos problemas. Y tener siempre a buen recaudo el número de serie de tus AirPods Pro. Si alguien se hace con el número de serie, puede pedir un clonado de tus AirPods Pro y parearlos a su cuenta igualmente.

Figura 14: Apple pide el número de serie para pedir una pieza
(uno de los dos auriculares o el estuche cargador "perdido")

Este número de serie se necesita para poder pedir a Apple una estuche cargador de batería nuevo, o unos auriculares nuevos que puedan funcionar juntos. Si no tienen el mismo número de serie no funcionan para hacer el pareado. Esta información del número de serie se puede conseguir de tres sitios distintos, que debes vigilar:

1.- De tu caja del producto. 

2.- Del estuche de batería - está dentro grabada -. 

3.- De la información de los AirPods Pro en tu tu iPhone una vez pareados.

Como ves, en el punto tres volvemos a tener el mismo problema. Si alguien es capaz de tocar tu estuche de batería con tus auriculares dentro y parearlo con su iPhone, podrá tener también acceso a tu número de serie. Esto deja unas lecciones importantes:

Figura 15: Si se parean, pueden ver tu número de serie

k.- Tú número de serie es importante. 

l.- Si separas tu estuche cargador de batería de los AirPods cuando estás en la calle no te podrán robar los AirPods tan fácilmente.

Fin de la segunda parte

La verdad es que cada vez que he jugado a fondo con las tecnologías Apple, han aparecido pequeños "corner cases" que acaban siendo peligrosos. Recuerdo el truco de bar usando Siri para robar las cuentas de correo electrónico de los usuarios de iPhone o el famoso DirtyTooth de hace tres años que permitía robarte la agenda de contactos completa, pero son muchos más los que te vas encontrando cuando ves cómo funcionan las cosas en detalle. Os dejo el truco de bar en un vídeo de dos minutos que grabé hace ya unos años.

Figura 16: Truco para robar cuentas con Siri en iPhone

Ahora el ver el cómo con unos AirPods Pro tu privacidad se puede ir al trate completamente me deja más que preocupado. Ya os recomendé en el artículo anterior el libro que escribimos de Hacking iOS:  iPhone & iPad 2ª Edición donde contamos muchos detalles de cómo funciona la seguridad de estas tecnologías, pero si os ha gustado esto, os recomiendo que conozcáis bien, bien como funciona vuestro iPhone.

Figura 17: Libro de Hacking iOS:iPhone & iPad (2ª Edicón) en 0xWord de
Chema Alonso, Ioseba Palop, Pablo Gonzáleez y Alejandro Ramos entre otros.

Espero que estas cosas os sean útiles, que en la tercera parte vamos a habla de alguna cosa más bastante curiosa sobre este capricho tan caro que son los AirPods Pro.

Saludos Malignos!

*****************************************************************************************************
- AirPods Pro: Unas pruebas en casa de Safety & Security (I de III)
- AirPods Pro: Unas pruebas en casa de Safety & Security (II de III)
- AirPods Pro: Unas pruebas en casa de Safety & Security (III de III)
*****************************************************************************************************
Autor: Chema Alonso (Contactar con Chema Alonso)