SweynTooth: el Bluetooth en el punto de mira

Introducción a trabajos previos de Bluetooth

El protocolo Bluetooth se ha tratado anteriormente en el blog de INCIBE-CERT, abarcando los aspectos de ciberseguridad que afectan a este protocolo y los posibles ataques que pueden ejecutarse aprovechando sus vulnerabilidades. En el artículo “Analizando Bluetooth” se comentaban las diferentes tecnologías relacionadas con Bluetooth, su uso dentro de los sistemas de control, algunos problemas de seguridad y sus posibles mitigaciones. Completando la información aportada por este primer artículo se publicó “Seguridad en Bluetooth: fortalezas y debilidades” donde, a través de pruebas de laboratorio, se efectuaban diferentes ataques a las comunicaciones Bluetooth para terminar exponiendo unos consejos de seguridad.

Pero todas las medidas de seguridad expuestas en esos dos artículos, o en la guía “Ciberseguridad en las comunicaciones inalámbricas en entornos industriales” y todas las configuraciones de seguridad que pueda tener el protocolo, no tienen validez si el problema se da por un fallo en la implementación de la tecnología en los propios chips de comunicaciones. Este es el origen de un conjunto de vulnerabilidades agrupadas bajo el nombre SweynTooth y que afectan a la tecnología BLE (Bluetooth Low Energy - Bluetooth de baja energía).

Explicación de vulnerabilidades SweynTooth

Hace relativamente poco tiempo, una serie de investigadores de la Universidad de Diseño y Tecnología de Singapur han publicado el informe “SweynTooth: Unleashing Mayhem over Bluetooth Low Energy” en el que se recogen las deficiencias y vulnerabilidades de Bluetooth, y clarifican que, a menos que se solucionen estas vulnerabilidades, el protocolo corre gran peligro de quedarse obsoleto y en desuso.

SweynTooth se compone de un total de 12 vulnerabilidades que afectan al SDK (Software Development Kits – Kits de desarrollo de software) de seis de los principales fabricantes de chips Bluetooth, que a su vez son usados por multitud de fabricantes en sus dispositivos. Dentro del mundo industrial se han identificado dispositivos afectados por estos problemas en el sector médico (con fabricantes como VivaCheck Laboratories, Syqe Medical o Medtronic) y en la automatización de edificios (Eve Systems o August Home, además de casi todos los fabricantes de dispositivos IIoT) principalmente, aunque otros sectores también se han visto afectados.

Las vulnerabilidades que aquí se recogen se clasifican en fallos dentro de los flujos de tráfico, errores de conexión o la evasión de métodos de seguridad. Las vulnerabilidades en detalle son las que se muestran a continuación, ninguna es explotable de forma remota. (Fuentes: ASSET Research Group y CISA):

• Desbordamiento de longitud de la capa de enlace (CVE-2019-16336, CVE-2019-17519): Un atacante podría llevar a cabo una condición de denegación de servicio al modificar la longitud del campo capa de enlace (LL, Link Layer). Los atacantes podrían llegar a hacer ingeniería inversa del firmware y realizar una inyección de comandos.
• Bloqueo en la capa de enlace LLID (CVE-2019-17061, CVE-2019-17060): Un atacante podría manipular los paquetes hasta hacer que la implementación del SDK descarte todos los paquetes recibidos por el dispositivo del usuario, concluyendo en una denegación de servicio al no realizar un correcto tratamiento de la información.
• L2CAP Truncado (CVE-2019-17517): Un atacante podría enviar una secuencia de comandos concreta a un dispositivo hasta conseguir escribir en posiciones de memoria cercanas al búfer de L2CAP, y con ello generar una condición de denegación de servicio.
• Desbordamiento de longitud silencioso (CVE-2019-17518): Este desbordamiento es similar al anterior. En este caso, un periférico responde al dispositivo del usuario con paquetes de longitud LL no esperada. Las consecuencias serían una denegación de servicio, aunque también es posible la ejecución de comandos.
• Fallo no espetado en la clave pública (CVE-2019-17520): Esta vulnerabilidad se produce al utilizar un protocolo de gestión de la seguridad (SMP, Secure Manager Protocol) antiguo. El dispositivo que utiliza este SMP envía la clave pública antes de que el procedimiento de emparejado comience. Es posible que se genere un fallo en la memoria del dispositivo que conlleva una condición de denegación de servicio.
• Bloqueo por secuencia ATT (CVE-2019-19192): El envío de dos peticiones ATT (Attribute Protocol) de forma secuencial en cada conexión puede bloquear un dispositivo. Si no existe un mecanismo tipo watchdog para resetear en caso de bloqueo, el dispositivo quedará en estado bloqueado originando una denegación de servicio.
• Petición de conexión invalida (CVE-2019-19193): Los códigos de petición en la fase de establecimiento de conexión no son interpretados adecuadamente, y los periféricos pueden quedar en estado de “espera” por el dispositivo del usuario. Si no se gestiona adecuadamente ese estado en los dispositivos, estos pueden quedar permanentemente en dicho estado sin tratar de hacer una nueva conexión.
• Instalación de cero LTK (CVE-2019-19194): Se trata de una variación del desbordamiento por tamaño de clave. En esta ocasión se envía una petición de cifrado fuera de las opciones con LTK (Long Term Key) a cero. Entonces, se produce una validación de las claves por parte del dispositivo del usuario, permitiendo saltarse los mecanismos de seguridad de autenticación establecidos.
• Fragmento L2CAP inválido (CVE-2019-19195): El tamaño mínimo y máximo de los paquetes L2CAP está definido. Sin embargo, es posible enviar un tamaño diferente (tamaño igual a 1) y provocar un fallo en el receptor y, como consecuencia, una condición de denegación de servicio.
• Desbordamiento por tamaño de clave (CVE-2019-19196): El origen de esta vulnerabilidad de debe a varias deficiencias en el sistema de emparejamiento. La primera es la aceptación de un tamaño de clave mayor del máximo establecido (16 bytes), para rechazarlo posteriormente con un comportamiento anómalo. La segunda se trata de la utilización del procedimiento de cifrado LL, previamente al procedimiento de emparejado.

Protección y mitigación de las vulnerabilidades

Los principales afectados por este problema ya están tratando de poner medidas y desarrollando parches de seguridad para corregir y solucionar todas las vulnerabilidades.

No obstante, es aconsejable seguir algunas medidas de protección y mitigación para el caso de que nuestros dispositivos de control pudieran estar afectados. A continuación, se muestran algunos puntos a seguir por todos los sectores industriales, especialmente sanidad y automatización de edificios:

• Contactar con los fabricantes de los dispositivos que hacen uso de Bluetooth, y de aquellos que disponen de esta tecnología, aunque no hagan uso de ella, para determinar cuáles pueden estar afectados.
• Hacer seguimiento de las páginas web de los fabricantes para conocer los últimos parches o versiones de firmware publicados,
• Monitorizar los dispositivos para detectar comportamientos anómalos o inusuales.
• Realizar un análisis de riesgos para determinar el impacto y poder priorizar actuaciones.

En el caso concreto de dispositivos médicos, la gran mayoría son implantes o dispositivos que utilizan los pacientes, por lo que también es conveniente hacer un seguimiento de ellos:

• Informar a los pacientes e identificar aquellos que puedan disponer de un equipo vulnerable.
• Los pacientes deben notificar cualquier comportamiento anómalo en su dispositivo.
• Los pacientes traten de aislarse de entornos con otras emisiones Bluetooth.

Hasta que se desarrollen los parches correspondientes y se puedan instalar en los dispositivos, siguiendo los procedimientos de instalaciones de parches adecuados, tal como se explicó en “Gestión de parches en sistemas de control”, es conveniente valorar la necesidad de utilizar las comunicaciones Bluetooth y su posible desactivación y sustitución por otros protocolos equivalentes.

Conclusión

Las comunicaciones inalámbricas favorecen enormemente la operación en determinados entornos. Es labor de cada industrial configurar en cada dispositivo las opciones de seguridad requeridas para asegurar al máximo su infraestructura, pero poco pueden hacer los clientes finales frente a una debilidad de los propios fabricantes.

Este tipo de vulnerabilidades pone de manifiesto la debilidad de algunos test de funcionamiento que se hacen a dispositivos, siendo necesaria la incorporación de controles de seguridad en estos test, no solo pruebas funcionales. La norma IEC 62443-4-2, ayudaría a mejorar los test de seguridad de todos los productos a integrar en un sistema de control.