Nuevo Fallo De Seguridad De Bluetooth ‘BLESA’ Pone En Riesgo A Multitud De Dispositivos

El nuevo ataque BLESA actúa sobre el proceso de reconexión de Bluetooth en vez de sobre el de emparejamiento, como la mayoría de las vulnerabilidades descritas previamente.

Multitud de dispositivos IoT, además de teléfonos inteligentes, tabletas y portátiles, utilizan módulos de software Bluetooth que son vulnerables a un fallo de seguridad identificado este verano y que ha sido denominado como BLESA (Bluetooth Low Energy Spoofing Attack – Ataque de suplantación de identidad de Bluetooth de baja energía). Esta vulnerabilidad afecta a aquellos dispositivos que ejecutan el protocolo Bluetooth de baja energía (BLE).

BLE es una versión más ligera del estándar Bluetooth original diseñado para reducir al máximo el consumo energía mientras se mantienen activas las conexiones Bluetooth, con el objetivo de maximizar el tiempo de funcionamiento autónomo de los dispositivos. Precisamente, debido a esta capacidad de ahorro de batería, BLE se ha adoptado últimamente de forma masiva, convirtiéndose en una tecnología muy extendida en casi todos los dispositivos que funcionan sin conexión a la red eléctrica. Como resultado de esta amplia adopción, los investigadores y académicos de seguridad buscan constantemente fallos de seguridad en BLE, habiéndose encontrando ocasionalmente problemas importantes.

La mayoría de las vulnerabilidades descubiertas se producían durante la fase de emparejamiento, debido fundamentalmente a que es la parte del protocolo BLE considerada más sensible, y por tanto, más analizada por los investigadores de seguridad. No obstante, se deben seguir investigando el resto de partes del protocolo BLE en busca de posibles fallos de seguridad, como por ejemplo, el proceso de reconexión.

Un grupo de investigación de la Universidad de Purdue ha investigado el proceso de reconexión, que tiene lugar tras la autentificación del cliente y servidor BLE durante la operación de emparejamiento. Una vez emparejados los dispositivos, si estos se salen del radio de alcance, al volver a estar a alcance, se producirá la reconexión. En ese momento, se volverán a verificar las claves criptográficas de los dispositivos emparejados previamente negociadas, para volver a conectarse y continuar con el intercambio de datos vía BLE.

Durante el análisis de seguridad, se detectó que la especificación oficial de BLE no describe correctamente el proceso de reconexión, y se han descrito dos problemas en las implementaciones de software BLE:

La autentificación durante la reconexión del dispositivo no es obligatoria, sino opcional.
Se podría eludir la autentificación si el dispositivo del usuario no logra forzar al dispositivo de IoT a hacerlo.

Estos problemas podrían permitir la ejecución de un ataque BLESA, de modo que un atacante cercano omitiría las autentificaciones de reconexión y enviaría datos falsificados a un dispositivo BLE, induciendo a los usuarios o a los procesos automatizados a tomar decisiones erróneas.

No obstante, este fallo en la descripción del protocolo BLE no se encuentra en todas las implementaciones disponibles. Los investigadores encontraron que BlueZ (dispositivos IoT basados en Linux), Fluoride (Android) y la versión para iOS (CVE-2020-9770) eran vulnerables a los ataques BLESA, mientras que la versión para dispositivos Windows no.

El principal problema identificado con la aplicación de parches de seguridad para remediar esta vulnerabilidad está relacionado con la limitación de recursos de los dispositivos IoT, no disponiendo de sistemas de actualización incorporados muchos de ellos, por lo que no se podrá resolver la vulnerabilidad en estos dispositivos.

Mientras que los ataques realizados durante el proceso de emparejamiento se pueden evitar simplemente realizando el emparejamiento en un entorno seguro, defenderse de los ataques que se pueden producir durante el proceso de reconexión es una tarea mucho más compleja dado que la operación de reconexión se produce frecuentemente mientras el dispositivo IoT esté operativo. Por ejemplo, bastaría un ataque de denegación de servicio para forzar una reconexión bajo demanda, momento en el que se podría ejecutar un ataque BLESA.

Más información: