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

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 (I de III)

A principios de año por fin me pude hacer con mis AirPods Pro para utilizarlos con mi iPhone y mi equipamiento de Apple - que ya sabéis que tengo un MacBook Pro antiguo y un iPad Pro ya que hablo muchas veces de ellos -. La verdad es que costó conseguirlos, pero la verdad es que es un dispositivo fantásticamente cómodo y de una de calidad en el sistema de Cancelación de Ruido que me encanta.

Figura 1: AirPods Pro: Unas pruebas en casa de Safety & Security (I de III)

No os voy a hablar mucho de lo mucho que me gustan, sino de otras cosas. De lo mucho que me preocupan, tanto por perderlos, como de que una niña como Mi Hacker los utilice. Desde el primer momento me preocupó ver que no hay ningún sistema de protección anti-robo aparentemente, y que si te los quitan, los puede utilizar cualquiera.

View this post on Instagram

Me ha costado tiempo conseguirlos, que desde navidades estaban agotados... pero con ayuda de compis los tengo. ¡Qué maravilla el “noise cacellation”! Es otra movida como cascos.

A post shared by Chema Alonso (@chemaalonso) on Feb 17, 2020 at 12:25am PST

Esto que os he dicho, aunque aparentemente es cierto, existen un montón de situaciones curiosas que he ido descubriendo y probado - gracias a que a veces le robo a Mi Hacker sus AirPods Pro y su viejo iPhone - al más puro estilo de Big Band Theory. Vale, si no has pillado la referencia, en uno de los capítulos el Doctor Leonard Hofstadter, el Doctor Sheldon Cooper, y  Howard Wolowitz (que al menos tiene un "máster") deciden probar la seguridad de un sistema de reconocimiento de retina en la Temporada 10, episodio 2.

Figura 3: Big Band Theory S10x02

Aunque mi favorita es la parte en la que prueban a darle las retinas al revés, yo no he llegado a tanto, pero sí a hacer pareados dobles, dobles enfundados - al más puro estilo Altered Carbon - y reemplazo de cascos y baterías, e intento de localizar uno de los cascos perdidos. Y os voy a ir contando qué es lo que he ido descubriendo, que es curioso. 

1.- El caso del casco perdido y el punto medio

Este primer incidente me sucedió cuando haciendo mi ruta en bicicleta por la Casa de Campo de Madrid, en un pequeño salto por una piedra mientras descendía a unos 40 kilómetros por hora, el casco de mi oreja izquierda saltó y se me cayó a la pista, rebotando en la bici en el suelo y perdiéndolo de mi vista.

Horror. Con lo que cuestan no estaba dispuesto a perderlo, así que frené la montura, me quité las calas y paré el Endomondo. Batir record era menos importante que encontrar la mitad de mis Air Pods Pro. Así que empecé a buscarlo y nada. Entre la caída del casco y la frenada en mitad de la bajada podia haber fácilmente unos 20 metros y el casco podía haber rebotado y terminado en cualquier sitio.

Después de un rato buscándolo y sin verlo decidí hacer un experimento, me puse el casco que quedaba en la oreja, y le di al Play a Spotify. Y comencé a andar hacia arriba. Hasta que se paró la música. ¿Por qué? Pues porque había detectado la pérdida de conexión BLE con el otro casco. Di marcha atrás unos pasos y volvió la música.

Desde ese punto empecé a andar hacia abajo contando los pasos hasta que la música volvió a pararse. Me había alejado demasiado demasiado por el otro lado y había vuelto a perder la conexión con el casco.Así que desandé la mitad de los pasos y centré mi búsqueda en ese área. Como había sospechado, el casco se encontraba en esa zona.

Ahí aprendí tres cosas:

a.- Prueba de goma: Que antes de usar los AirPods hay que revisar correctamente las gomas de ajuste. Para ello hay una pequeña utilidad en las opciones BlueTooth de los AirPods. 

Figura 4: Probar que te encaja la goma del audífono perfectametne

Yo lo había hecho y llevaba la correcta, pero aún así lo revisé para entender si la caída del casco podía haber sido debido a ello. Quería comprobar si había habido algún cambio en la goma. 

b.- Protector de Seguridad: Yo vengo de usar los PowerBeats, y estos vienen con unas gomas de sujeción para la oreja. Pues bien, también se pueden comprar para los AirPods Pro. Así que me hice con unos de ellos para cuando salgo con ellos en la bicicleta. 

Figura 5: EarHooks para AirPods. Úsalos si te los llevas a hacer deporte

d.- Detección de eventos: Los AriPods Pro paran la música en el dispositivo cuando notan que te los has quitado de la oreja, pero también, cuando uno de los dos cascos se desconecta. En este caso esta característica me sirvió para encontrar el casco caído.

2.- Doble conexión de audífonos a dos dispositivos en paralelo

Estos días de confinamiento estoy todos los días conectados al ordenador y uso mi AirPods Pro también en el iPhone para hacer algunas llamadas, así que me paso todo el día conectándolos manualmente a uno o a otro según lo necesite. La gracia es que ellos guardan una histórico de la última conexión, por lo que solo se conectan automáticamente al equipo que se conectaron la última vez. Si no, debes hacerlo manualmente.

Esto abrió una pregunta en mi cabeza, ¿podría conectar un audífono al ordenador y otro al iPhone al mismo tiempo y en el mismo espacio de conexión BLE? Al final, la conexión de los cascos es algo que pide inicializar el equipo - ya sea el iPhone o el MacBook Pro - y si el casco ya ha está pareado, se realiza perfectamente.

Para ello primero hay que responder a la pregunta de si funcionan los cascos solos. Y la respuesta es sí. Basta con que guardes un casco en la funda-batería-cargador, y conectes el otro. Podrás escuchar música y usarlo como micrófono. Es decir. si los usas para vídeo conferencias como hago yo, y no te aguantan la batería, podrías utilizar solo uno mientras el otro está cargando y utilizarlos de forma alterna. 

Y ahora, la pregunta,  ¿podría tener los dos cascos conectados por separado cada uno a un dispositivo y cada uno escuchando música distinta y usarlos a la vez? ¿O tener, por ejemplo, el casco izquierdo con audio/micro para el iPhone y el audífono derecho con el altavoz y el micro del MacBook Pro? La respuesta es sí, pero para hacer la prueba tuve que usar un truco de los que ya me conozco tras haber escrito el libro de Hacking iOS: iPhone & iPad (2ª Edición) y de haber hecho nuestro querido DirtyTooth. Jugar con iPhone: "I love it".

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

Para hacer la prueba use dos iPhones y un audífono para cada uno de ellos. Puse música en uno en una sala y me fui lejos con el otro casco metido en la batería para conectarlo al otro iPhone lejos. Lo conecté y regresé, pero cuando volví a juntarlos, el primer audífono estaba reproduciendo la música que traía en el segundo. ¿Por qué? Pues porque al habérmelo quitado de la oreja se desconectó del primer iPhone y cuando el segundo audífono lo detectó forzó la conexión del primero al primer dispositivo. 

Para solucionarlo, necesitaba otra oreja. Así que nada, con Mi Hacker en un iPhone y yo en el otro, lejos de distancia BLE (BlueTooth Low Energy), cada uno conectamos el audífono de AirPods Pro y nos llamamos por teléfono. Nos fuimos acercando hasta que estuvimos en la misma sala. Sin quitárnoslos de las orejas, pusimos música y me pasó su audífono a mí. Desconecté la llamada y el resultado fue tener cada audífono conectado a un dispositivo escuchando música distinta.

Por supuesto, no parece una gran habilidad, pero tal vez un día quieras dejar un audífono a un hijo, y otro para ti, o dejárselo a dos niños y que cada uno pueda escuchar su música. En ese momento, puede que este truco te sea de utilidad. Con esta prueba aprendí:

e.- Conexión LIFO: Es decir, tus AirPods Pro se conectan al último dispositivo pareado que los ha utilizado y uno conecta al otro cuando aparece en la distancia. 

f.- Se pueden usar individualmente:Si pierdes un casco, siempre podrás utilizar al menos el que te queda como micro y audio para llamadas o vídeo conferencias. No creo que para música sea útil.

g.- Doble conexión: Si lo quieres - o necesitas -, puedes hacer un doble conexión en paralelo entre dispositivos.

En las próximas partes os contaré más experimentos, que me ha dado juego esto de revisar la seguridad del dispositivo, y seguridad personal del dueño haciendo diferentes tests. A mí me han sido muy útiles y sobre todo sirven para terminar con las recomendaciones de Safety & Security que os dejaré en la última parte.

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)

Hacking Things with Bluetooth Low-Energy (BLE)

Llegó la edición número XI de RootedCON. Recientemente conté que es una semana especial, llena de muchas horas intensas entre formación y charlas, preparación, exposición, lugar de encuentro con viejos y nuevos amigos. Este año volvía a dar una charla, que llamamos "Hackeando el mundo exterior a través de BLE BlueTooth Low-Energy", en esta ocasión junto a mi compañero Álvaro Nuñez.

Figura 1: Hacking Things with Bluetooth Low-Energy (BLE)

La temática de la charla era BLE o Bluetooth Low-Energy, sobre el que en este último año hemos trabajado y echado horas. Una de las herramientas donde se fue integrando el trabajo fue HomePWN. La charla tenía una estructura y un objetivo claro. El objetivo era mostrar qué es BLE, que lo tenemos alrededor a través de muchos dispositivos con los que interactuamos en nuestro día a día, mostrar los precedentes en seguridad en BLE de los últimos años, evaluar la seguridad de tipos de dispositivos y mostrar ataques a la tecnología BLE y, por último, hablar sobre la fortificación pensando en la gente que diseña dispositivos y que necesita de BLE en éstos.

Figura 2: HomePWN en GitHub

Queríamos darle un enfoque práctico y mostrar también con qué tipo de cosas hemos estado trabajando, por lo que fuimos siendo prácticos y mostramos alguna demo que otra, incluida una en directo.

Introducción a BLE

Queríamos empezar dando a conocer los detalles técnicos más importantes de BLE para que todo el mundo entendiera su funcionamiento. De la forma más sencilla y de la forma que nos permitiera encajar después ciertas noticias o ciertos ataques con los conceptos vistos en la introducción. Conceptos cómo explicar el por qué aparece BLE, qué aporta en la tecnología inalámbrica, cuál es su ámbito de juego, es decir, cuáles son sus canales (37 de datos y 3 de anuncio), etcétera.

Figura 3: 37 canales de datos y 3 de anuncio en BLE

Además, la explicación de conceptos claves como los que siguen:

• Access Address.
• ¿Cómo se realiza el salto entre canales?
• Channel Map
• Hop Interval
• Hop Increment
• Tipos de algoritmo de salto

Tras explicar también los tipos de paquetes BLE o los tipos de cabeceras, que indican qué tipo de paquete ‘advertisement’ tenemos entre manos, nos centramos en el paquete de tipo CONNECT_REQ.

Figura 4: Salto de canales en BLE

En la captura de figura siguente se puede ver cómo tras capturar un paquete de éstos, podemos ver los conceptos que se habían presentado previamente, tanto gracias a la herramienta Btlejack, como gracias a Wireshark.

Figura 5: Paquete BLE capturado con BTLEJack y visto con WireShark

El objetivo era dar una breve introducción de diez minutos sobre los aspectos relevantes de un protocolo que está entre nosotros y que diariamente estamos utilizando. Como comenté en la sala, todos los que allí se sentaron, de una forma u otra, están utilizando diariamente esta tecnología.

Precedentes

En la parte de precedentes en incidentes de seguridad y vulnerabilidades se habló de diferentes casos:

• Ejemplos sobre gadgetbridge.
• El hackeo de MiBand3 y MiBand4.
• Casos reales con trackers.

Figura 6: Hacking los buscatodo con BLE

• BluedIoT, del cual ya se habló en el blog de la mano de Gerard Fuguet.
• El caso de la vulnerabilidad CVE-2019-12500 y el bloqueo de motor de un patinete.

Figura 7: El caso del bloqueo de Xiaomi dio la vuelta al mundo

En el repositorio de CamiAlfa se puede encontrar ingeniería inversa sobre el patinete de Xiaomi. Nos encontramos con cosas curiosas, ya que podemos ver un “no se” sobre algunas acciones a las que se hicieron de ingeniería inversa.

Figura 8: Un "no sé" en el reversing del patinete de Xiaomi

• Por último, se habló de Sweyntooth. Es una familia de 12 de vulnerabilidades, la cual se encuentra en la implementación de BLE en el SDK. Hay una serie de vendedores afectados como son: Texas Instruments, NXP, Cypress, Dialog Semiconductors, Microchip, STMicroelectronics y Telink Semiconductor.

Ataques a BLE

En el apartado de evaluación de seguridad se mostraron una serie de ataques, de los cuales se fueron comentando y explicando:

• Sniffing: Como técnica para capturar lo que circula por el medio de compartición, en este caso, el aire.

• Replay: La técnica de replay se explicó con una imagen de gattack.io, en la que se muestra de forma clara qué es un replay. Se hizo hincapié en que el coche no es el mejor ejemplo para BLE, pero sí un buen ejemplo de la acción de replay.

Figura 9: Ataques de Replay BLE para abrir automóviles

• Hijacking: Es el secuestro de una conexión existente. Se hace uso del access address y del timeout para lograr el secuentro de la conexión. En la siguiente imagen se puede ver el esquema del ataque:

Figura 10: Esquema de un ataque de Hijacking BLE

En el siguiente video se puede ver un secuestro de sesión (hijack) con Btlejack. El ataque responde al esquema anterior y puede secuestrar la conexión gracias al conocimiento del access address.

Figura 11: PoC de Hijacking BLE Sessions

• Jamming: El concepto de Jamming abarca la interferencia de la señal o generación de ruido con el objetivo de que la señal original no llegue al receptor. Esto no ocurre con la aplicación de btlejack, que utiliza más bien el esquema del hijacking, sin llegar a secuestrar la conexión, pero sí haciendo perder la comunicación.

• MITM: En la imagen de gattack.io podemos ver un ejemplo claro y sencillo de un MITM. No hace falta mucha descripción sobre un MITM hoy en día. El esquema es sencillo: descubrimiento del dispositivo víctima. Conexión con el dispositivo víctima para que no se anuncie más. Anunciar el mismo dispositivo y redirigir los datos cuando se tenga una nueva conexión.

Figura 12: Ejemplo de ataque MITM BLE de gattack.io

• Ataques al cifrado: En algunas ocasiones las comunicaciones van cifradas. Mostramos como poder realizar ataque sobre una captura cifrada cuando se dan ciertas condiciones. La herramienta utilizada fue CrackLE.

Figura 13 Demo de Crackle para descifrar tráfico BLE cifrado

Queremos agradecer a todas las personas que se acercaron el sábado a las 10.00 de la mañana a ver la charla y que llenaron la sala. Solo podemos deciros:

Gracias.

Autor: Pablo González Pérez (@pablogonzalezpe), escritor de los libros "Metasploit para Pentesters", "Hacking con Metasploit: Advanced Pentesting" "Hacking Windows", "Ethical Hacking", "Got Root",  “Pentesting con Powershell” 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

Figura 14: Contactar con Pablo González