Llevamos tiempo trabajando con varios proyectos en Ideas Locas, el departamento de pre-innovación del área CDO de Telefónica. Hay uno del que esperamos pronto daros novedades, aunque será después del verano. En este proyecto trabajamos algunas cosas con Bluetooth Low Energy o BLE. Bluetooth es un tema que siempre me ha llamado la atención, aunque no siempre he tenido el tiempo para dedicarle.
Es cierto que a BlueTooth le hemos dado caña en estos años y tienes pruebas de ello en este blog, donde encontrarás desde el ya achifamoso DirtyTooth que ha hecho que todos los iPhone ahora te pregunten si quieres compartir tu agenda de contactos con ese dispositivo al que te acabas de conectar, hasta las pruebas de Hacking WebBlueTooth que hizo nuestro colega Enrique Rando. Y por supuesto, lo usamos tanto en Rubika donde nos apoyamos BLE como forma de comunicación entre nuestro cubo impreso en 3D y la web de autenticación, como en la implementación de nuestra solución de Second Factor Web Browsing.
Pero ahora que tenía un poco de tiempo, centrándome en BlueTooth Low Energy, me dio por mirar ciertas cosas, su funcionamiento, su estructura y, ¿por qué no? sus debilidades. Leyendo el post de BluedIoT de este blog me gustó la simplicidad del ataque y las posibilidades en el mundo de los dispositivos que nos rodean y que cada vez más tienen BLE. Antes uno tiene que documentarse sobre Bluetooth Low Energy y ver cómo funciona en la teoría y en la práctica.
BLE: BlueTooth Low Energy
BLE está disponible desde la versión 4.0 de Bluetooth. El objetivo es sencillo: conseguir que los dispositivos disminuyan drásticamente el consumo de energía. Además, aporta un soporte interesante para el mundo IoT. Estamos uniendo un paradigma, el IoT, donde en muchos casos la seguridad brilla por su ausencia, con el BLE, el cual no tiene la mayor seguridad que podamos imaginar.
La estructura básica en BLE es GATT o Generic Attribute Profile. Este se encarga de la transferencia de datos. Tenemos tres posibilidades:
La vulnerabilidad en el Bluetooth del M365 Scooter
Otra noticia que llamó mucho mi atención fue la de la aparición de una vulnerabilidad en el patinete de Xiaomi en su modelo M365 scooter. La vulnerabilidad consistía en que cualquier usuario se podía conectar al patinete vía Bluetooth sin ningún tipo de contraseña y podía, entre otras cosas, bloquear el motor del dispositivo. No digo nada, pero el "boss" tiene uno de esos que espero haya actualizado - prometo que no me interesé en este bug porque tuviera en mente nada... de verdad. -
En el vídeo se puede ver un ejemplo de lo que podía ocurrir. Un usuario mediante el uso de Bluetooth podía conectarse al dispositivo y enviar una trama a la característica X con el valor Y concreto que le dijera al patinete que el bloqueo de motor está activo. En el momento que el usuario del patinete quiere volver a iniciar la marcha, el patinete está bloqueado y no le responde como se espera.
Figura 4: PoC e Bug en Xiaomi M365 Scooter
También se comentaba que se podía subir un firmware malicioso al patinete debido a la baja seguridad en la manipulación e interacción, o al menos eso decían algunos medios. La gente de Zimperium publicó un post sobre la vulnerabilidad con gran detalle. Además, publicaron código sobre la vulnerabilidad que permitía bloquear cualquier patinete que no estuviera actualizado. Esto hace que sea de vital importancia actualizar el patinete.
Por lo que se puede ver o entender se puede cambiar parámetros fácilmente, por ejemplo, encender o apagar la luz, cambiar velocidad de crucero, etcétera. Buscando un poco por Github uno puede encontrar ingeniería inversa como ésta sobre el uso del BLE del M365.
El segundo dispositivo tenía un poco más de “miga”. Tenía un formato más amplio y utilizaba un byte para la velocidad del sonido, otro byte para el número de pitidos, pudiendo ser 256 pitidos seguidos, es decir, una locura. Haciendo pruebas se pudo ir sacando estos parámetros curiosos.
Saludos,
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" y “Pentesting con Powershell”, Microsoft MVP en Seguridad y Security Researcher en el equipo de "Ideas Locas" de la unidad CDO de Telefónica.
 |
| Figura 1: Hacking in your life: Jugando con los “encuentra-cosas en el mundo BLE o BlueTooth Low-Energy |
Es cierto que a BlueTooth le hemos dado caña en estos años y tienes pruebas de ello en este blog, donde encontrarás desde el ya achifamoso DirtyTooth que ha hecho que todos los iPhone ahora te pregunten si quieres compartir tu agenda de contactos con ese dispositivo al que te acabas de conectar, hasta las pruebas de Hacking WebBlueTooth que hizo nuestro colega Enrique Rando. Y por supuesto, lo usamos tanto en Rubika donde nos apoyamos BLE como forma de comunicación entre nuestro cubo impreso en 3D y la web de autenticación, como en la implementación de nuestra solución de Second Factor Web Browsing.
Pero ahora que tenía un poco de tiempo, centrándome en BlueTooth Low Energy, me dio por mirar ciertas cosas, su funcionamiento, su estructura y, ¿por qué no? sus debilidades. Leyendo el post de BluedIoT de este blog me gustó la simplicidad del ataque y las posibilidades en el mundo de los dispositivos que nos rodean y que cada vez más tienen BLE. Antes uno tiene que documentarse sobre Bluetooth Low Energy y ver cómo funciona en la teoría y en la práctica.
BLE: BlueTooth Low Energy
BLE está disponible desde la versión 4.0 de Bluetooth. El objetivo es sencillo: conseguir que los dispositivos disminuyan drásticamente el consumo de energía. Además, aporta un soporte interesante para el mundo IoT. Estamos uniendo un paradigma, el IoT, donde en muchos casos la seguridad brilla por su ausencia, con el BLE, el cual no tiene la mayor seguridad que podamos imaginar.
La estructura básica en BLE es GATT o Generic Attribute Profile. Este se encarga de la transferencia de datos. Tenemos tres posibilidades:
• Perfil: Nos indica el tipo de dispositivo basándose en el servicio.
• Servicio: Indica qué función tiene el dispositivo. Por ejemplo, un servicio tendrá un montón de características, siendo un montón de 1 a N.
• Característica: Es utilizado para el envío o recepción de datos. Tenemos permisos: lectura, escritura, notificación…). Esto será con lo que interactuaremos al final para enviar o recibir información.Los servicios y las características tienen un UUID con el que se les identificará unívocamente. Otro valor importante y qué veremos en las tramas será el handle. Los servicios tienen un rango de manejadores (handlers) y este rango se asocia con un UUID.
La vulnerabilidad en el Bluetooth del M365 Scooter
Otra noticia que llamó mucho mi atención fue la de la aparición de una vulnerabilidad en el patinete de Xiaomi en su modelo M365 scooter. La vulnerabilidad consistía en que cualquier usuario se podía conectar al patinete vía Bluetooth sin ningún tipo de contraseña y podía, entre otras cosas, bloquear el motor del dispositivo. No digo nada, pero el "boss" tiene uno de esos que espero haya actualizado - prometo que no me interesé en este bug porque tuviera en mente nada... de verdad. -
En el vídeo se puede ver un ejemplo de lo que podía ocurrir. Un usuario mediante el uso de Bluetooth podía conectarse al dispositivo y enviar una trama a la característica X con el valor Y concreto que le dijera al patinete que el bloqueo de motor está activo. En el momento que el usuario del patinete quiere volver a iniciar la marcha, el patinete está bloqueado y no le responde como se espera.
Figura 4: PoC e Bug en Xiaomi M365 Scooter
También se comentaba que se podía subir un firmware malicioso al patinete debido a la baja seguridad en la manipulación e interacción, o al menos eso decían algunos medios. La gente de Zimperium publicó un post sobre la vulnerabilidad con gran detalle. Además, publicaron código sobre la vulnerabilidad que permitía bloquear cualquier patinete que no estuviera actualizado. Esto hace que sea de vital importancia actualizar el patinete.
 |
| Figura 5: Código para manejar por BLE el M365 en GitHub |
Por lo que se puede ver o entender se puede cambiar parámetros fácilmente, por ejemplo, encender o apagar la luz, cambiar velocidad de crucero, etcétera. Buscando un poco por Github uno puede encontrar ingeniería inversa como ésta sobre el uso del BLE del M365.
Tramas Bluetooth en un PCAP
La ingeniería inversa de un protocolo de red se puede hacer a través del estudio del tráfico que genera el protocolo, y leyendo bien el RFC. Aquí necesitamos algo parecido. Necesitamos un sniffer que nos ayude a generar ese PCAP de las tramas que se están enviando a través del Bluetooth.
Uno puede usar diferentes elementos para hacer esas capturas, por ejemplo, un UbertTooth. Si tenemos un móvil Android a mano con una versión superior a la 4.4 podremos utilizar éste para sniffar el tráfico Bluetooth generado desde el dispositivo y las respuestas que éste obtiene.
 |
| Figura 6: Activar BlueTooth HCI snoop log en Android 4.4 |
Esto genera un fichero llamado btsnoop_hci_[números] en la carpeta, generalmente, /Android/Data o en la raíz del almacenamiento interno. Yo compré una serie de “encuentra-todo” en Aliexpress. Esperábamos que su seguridad fuera baja y que cualquier usuario que conociera o pudiera sniffer tráfico BLE encontrara un patrón repetitivo.
La teoría se cumplió. A estos “encuentra-todo” se les puede hacer Replay. Analizando las tramas capturas con el móvil Android vemos cómo se repite el patrón cuando se activa la búsqueda del dispositivo, pero...
¿Qué es un “encuentra-todo”?
Es un pequeño dispositivo Bluetooth que puede ser utilizado como llavero o puede ser introducido en una cartera, en una mochila, o en cualquier sitio que queramos tener “controlado”. Si en algún momento lo perdemos podemos intentar buscarlo accionando, desde nuestro móvil, un pitido. Además, tienen otras características como búsqueda de la última ubicación GPS conocida o, ¿por qué no? permite accionar la cámara para tomarnos un "selfie".
¿Qué es un “encuentra-todo”?
Es un pequeño dispositivo Bluetooth que puede ser utilizado como llavero o puede ser introducido en una cartera, en una mochila, o en cualquier sitio que queramos tener “controlado”. Si en algún momento lo perdemos podemos intentar buscarlo accionando, desde nuestro móvil, un pitido. Además, tienen otras características como búsqueda de la última ubicación GPS conocida o, ¿por qué no? permite accionar la cámara para tomarnos un "selfie".
 |
| Figura 7: Tramas de comandos BLE |
En la captura se puede ver dos peticiones “write” ese flujo de datos va desde nosotros hacia el dispositivo con BLE. La petición es aceptada, y el dispositivo empieza a pitar. Esto hizo que pudiéramos observar las tramas que activaban el pitido del dispositivo.
Jugamos con dos dispositivos y cada uno era distinto. Uno era muy simple, recibía una trama con un valor para activar el pitido y otra trama con un valor diferente para desactivarlo. Podemos ejemplificarlo con value=0x00 activar y value=0x01 para desactivar. Muy simple.
Jugamos con dos dispositivos y cada uno era distinto. Uno era muy simple, recibía una trama con un valor para activar el pitido y otra trama con un valor diferente para desactivarlo. Podemos ejemplificarlo con value=0x00 activar y value=0x01 para desactivar. Muy simple.
 |
| Figura 8: Trama BLE para controlar los pitidos |
El segundo dispositivo tenía un poco más de “miga”. Tenía un formato más amplio y utilizaba un byte para la velocidad del sonido, otro byte para el número de pitidos, pudiendo ser 256 pitidos seguidos, es decir, una locura. Haciendo pruebas se pudo ir sacando estos parámetros curiosos.
¿Cómo podemos enviar las pruebas?
Hay muchas aplicaciones que permiten utilizar BLE. Por ejemplo, en macOS puedes utilizar Bluetility. No es la mejor herramienta, pero permite hacer las pruebas. Por otro lado, desde un dispositivo móvil LightBlue o nRF Connect son buenas soluciones. Nosotros trabajamos en algo que ya os presentaremos, y hasta aquí podemos leer. Para esta prueba utilizamos nRF Connect para iOS. Con un simple escaneo se puede encontrar diferentes dispositivos en un rango cercano.
Hay muchas aplicaciones que permiten utilizar BLE. Por ejemplo, en macOS puedes utilizar Bluetility. No es la mejor herramienta, pero permite hacer las pruebas. Por otro lado, desde un dispositivo móvil LightBlue o nRF Connect son buenas soluciones. Nosotros trabajamos en algo que ya os presentaremos, y hasta aquí podemos leer. Para esta prueba utilizamos nRF Connect para iOS. Con un simple escaneo se puede encontrar diferentes dispositivos en un rango cercano.
 |
| Figura 9: Escaneo de dispositivos nRF Connect |
Vemos que es conectable, por lo que nos conectamos con el dispositivo. Una vez conectados vemos los servicios, por ejemplo, podemos ver la batería que tiene ese dispositivo sin necesidad de ninguna autenticación.
Analizando el PCAP anterior, miramos qué características son escribibles, entrando dentro de los servicios. Esto es importante, porque si la característica sólo es de lectura, no es la que estamos buscando. El handle nos ayude a identificar qué estamos buscando.
 |
| Figura 10: Lista de dispositivos encontrados |
En este caso, encontramos la característica que buscábamos, y vemos que podemos escribir valores. La herramienta nos da a elegir en un formato de texto o de byte array, y si queremos enviar comandos o peticiones. Como se puede ver en la imagen escribimos el valor en hexadecimal y enviamos el comando. Esto hará sonar al dispositivo, como se verá en el video posteriormente.
 |
| Figura 11: Envío de valores para las características |
Ahora os dejamos un pequeño video dónde se puede ver. Lo interesante es entender el procedimiento de cómo se puede observar y entender el funcionamiento del BLE con los dispositivos que nos rodean.
Por supuesto, no siempre es tan fácil, ya que dependiendo de la implementación esto puede ser más complejo o no ser vulnerables a ataques de replay. Por desgracia este comportamiento lo podemos encontrar en más sitios y dispositivos de lo que nos gustaría.
Figura 12: Demo de envío de comandos por BLE
Por supuesto, no siempre es tan fácil, ya que dependiendo de la implementación esto puede ser más complejo o no ser vulnerables a ataques de replay. Por desgracia este comportamiento lo podemos encontrar en más sitios y dispositivos de lo que nos gustaría.
Saludos,
No estaría mal poder realizar estos ataques a esos altavoces gigantes bluetooth que te fastidian el día en una de esas magnificas piscinas naturales de las que podemos disfrutar en este pais .
ResponderEliminarPoder bloquearlo y hacer que se enmudezca aunque sea solo en la hora de la siesta.