lunes, octubre 24, 2022

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.

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,

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:
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.
Si os interesa, podéis echar un vistazo a la PoC que permite conseguir la BLE LTK que hemos publicando en el GitHub siguiente:

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.
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,



No hay comentarios:

Entrada destacada

Tokenomics 101: Una explicación con gráficos

He tenido que explicar muchas veces por qué alguien va a pagar algo por un Token . Es verdad que cuando se habla de Tokens , es muy diferent...

Entradas populares