Miles de millones de teléfonos inteligentes, tabletas, computadoras portátiles y dispositivos de IoT están utilizando pilas de software Bluetooth que son vulnerables a una nueva falla de seguridad revelada durante el verano.

Llamada BLESA (Bluetooth Low Energy Spoofing Attack), la vulnerabilidad afecta a los dispositivos que ejecutan el protocolo Bluetooth de baja energía (BLE). El nuevo ataque se produce después del proceso de reconexión de Bluetooth que a menudo se ignora, a diferencia de las vulnerabilidades anteriores, la mayoría de las cuales se encuentran en la operación de emparejamiento.

BLE es una versión más delgada del estándar Bluetooth (Classic) original, pero está diseñada para conservar la energía de la batería mientras mantiene activas las conexiones Bluetooth el mayor tiempo posible. Debido a sus características de ahorro de batería, BLE se ha adoptado masivamente durante la última década, convirtiéndose en una tecnología casi omnipresente en casi todos los dispositivos que funcionan con baterías.

Como resultado de esta amplia adopción, los investigadores y académicos de seguridad también han investigado repetidamente BLE en busca de fallas de seguridad a lo largo de los años, a menudo encontrando problemas importantes.

Los académicos estudiaron el proceso de "reconexión" de Bluetooth

Sin embargo, la gran mayoría de todas las investigaciones anteriores sobre los problemas de seguridad de BLE se han centrado casi exclusivamente en el proceso de emparejamiento e ignoraron grandes partes del protocolo BLE.

En un proyecto de investigación en la Universidad de Purdue, un equipo de siete académicos se propuso investigar una sección del protocolo BLE que desempeña un papel crucial en las operaciones BLE diarias, pero que rara vez se ha analizado por problemas de seguridad. Su trabajo se centró en el proceso de "reconexión". Esta operación tiene lugar después de que dos dispositivos BLE (el cliente y el servidor) se hayan autenticado durante la operación de emparejamiento.

Las reconexiones tienen lugar cuando los dispositivos Bluetooth se mueven fuera del alcance y luego vuelven a estar dentro del alcance más tarde. Normalmente, al volver a conectarse, los dos dispositivos BLE deben verificar las claves criptográficas del otro negociado durante el proceso de emparejamiento, y volver a conectarse y continuar intercambiando datos a través de BLE.

Pero el equipo de investigación de Purdue dijo que descubrió que la especificación oficial de BLE no contenía un lenguaje lo suficientemente fuerte para describir el proceso de reconexión. Como resultado, dos problemas sistémicos se han abierto camino en las implementaciones de software BLE, a lo largo de la cadena de suministro de software:

• La autenticación durante la reconexión del dispositivo es opcional en lugar de obligatoria.
• La autenticación se puede eludir potencialmente si el dispositivo del usuario no logra hacer cumplir el dispositivo IoT para autenticar los datos comunicados.

Estos dos problemas dejan la puerta abierta para un ataque BLESA, durante el cual un atacante cercano omite las verificaciones de reconexión y envía datos falsificados a un dispositivo BLE con información incorrecta, e induce a los operadores humanos y los procesos automatizados a tomar decisiones erróneas. Vea una demostración trivial de un ataque BLESA a continuación.

Varias pilas de software BLE afectadas

Sin embargo, a pesar del lenguaje vago, el problema no ha aparecido en todas las implementaciones de BLE en el mundo real. Los investigadores de Purdue dijeron que analizaron múltiples pilas de software que se han utilizado para respaldar las comunicaciones BLE en varios sistemas operativos.

Los investigadores descubrieron que BlueZ (dispositivos IoT basados ​​en Linux), Fluoride (Android) y la pila BLE de iOS eran vulnerables a los ataques BLESA, mientras que la pila BLE en los dispositivos Windows era inmune.

"A partir de junio de 2020, aunque Apple asignó el CVE-2020-9770 a la vulnerabilidad y la solucionó, la implementación de Android BLE en nuestro dispositivo probado (es decir, Google Pixel XL con Android 10) sigue siendo vulnerable", dijeron los investigadores en un artículo publicado el mes pasado.

En cuanto a los dispositivos de IoT basados ​​en Linux, el equipo de desarrollo de BlueZ dijo que desaprobaría la parte de su código que abre los dispositivos a los ataques de BLESA y, en su lugar, usará código que implemente los procedimientos de reconexión BLE adecuados, inmune a BLESA.

Otro infierno para parchear

Lamentablemente, al igual que con todos los errores de Bluetooth anteriores, parchear todos los dispositivos vulnerables será una pesadilla para los administradores del sistema, y parchear algunos dispositivos podría no ser una opción.

Algunos equipos de IoT con recursos limitados que se vendieron durante la última década y que ya se implementaron en el campo hoy en día no vienen con un mecanismo de actualización incorporado, lo que significa que estos dispositivos permanecerán permanentemente sin parches.

Defenderse contra la mayoría de los ataques Bluetooth generalmente significa emparejar dispositivos en entornos controlados, pero defenderse contra BLESA es una tarea mucho más difícil, ya que el ataque se dirige a la operación de reconexión que ocurre con más frecuencia.

Los atacantes pueden usar errores de denegación de servicio para hacer que las conexiones Bluetooth se desconecten y activen una operación de reconexión bajo demanda, y luego ejecuten un ataque BLESA. Es imposible proteger los dispositivos BLE contra desconexiones y caídas de señal.

Para empeorar las cosas, según las estadísticas de uso de BLE anteriores, el equipo de investigación cree que la cantidad de dispositivos que utilizan las pilas de software BLE vulnerables es de miles de millones. Todos estos dispositivos están ahora a merced de sus proveedores de software, que actualmente esperan un parche.

Los detalles adicionales sobre el ataque BLESA están disponibles en un documento titulado "BLESA: Spoofing Attacks against Reconnections in Bluetooth Low Energy" [PDF, PDF]. El documento se presentó en la conferencia USENIX WOOT 2020 en agosto. A continuación se incluye una grabación de la presentación del equipo de Purdue.

Fuente: ZDNet