Un investigador de la empresa de ciberseguridad Rapid7 descubrió recientemente un par de peligrosos errores de seguridad en un producto de seguridad para el hogar.
El primer error, informado en mayo de 2021 y denominado CVE-2021-39276, significa que un atacante que conozca la dirección de correo electrónico con la que se registró el producto, puede usar el correo electrónico como contraseña de manera efectiva para emitir comandos al sistema, incluido apagar completamente la alarma.
El producto afectado pertenece a la empresa Fortress Security Store, que vende dos configuraciones de seguridad para el hogar, el S03 Wifi Security System el más barato, que comienza en 130 $, y el más caro S6 Titan 3G / 4G WiFi Security System, a partir de 250 $.
El investigador, Arvind Vishwakarma, adquirió un sistema de arranque S03, que incluye un panel de control, mandos de control remoto, un sensor de puerta o ventana, un detector de movimiento y una alarma interior.
(La empresa también vende llaveros y sensores adicionales, alarmas para exteriores, que presumiblemente son más potentes, y detectores de movimiento “inmunes a las mascotas”, que asumimos son menos sensibles que los normales).
Desafortunadamente, Vishwakarma no tardó mucho en comprometer el sistema y descubrir cómo controlarlo sin autorización, tanto local como remotamente.
RESTfulness
Al igual que muchos productos modernos de Internet de las cosas (IoT), los productos de Fortress Security, utilizan servidores basados en la nube con fines de control y supervisión, accediendo a la nube de Fortress a través de lo que se conoce en la jerga como API, abreviatura de application programming interface (interfaz de programación de aplicaciones).
Y, como la mayoría de las API modernas, Fortress usa un estilo de programación conocido como REST, donde los datos se envían a la API a través de comandos HTTP POST y se recuperan usando comandos GET, usando un conjunto de datos estáticos y URLs bien definidas que actúan programáticamente como “llamadas a funciones” basadas en la web.
En los viejos tiempos, las API a menudo integraban los datos que querían enviar y recibir en la propia URL, junto con los datos necesarios, incluidas las contraseñas o los tokens de autenticación, agregados al final como parámetros, como este:
GET /functions/status?id=username&password=W3XXgh889&req=activate&value=1 HTTP/1.1 Host: example.com
Pero construir una URL única cada vez es complicado para los servidores y tiende a filtrar datos confidenciales en archivos de registro, porque los historiales de acceso a URL a menudo se almacenan para solucionar problemas u otros fines y, por lo tanto, se debe evitar tener datos específicos de consultas codificados en ellos.
(Los buenos firewalls y los servidores web preocupados por la seguridad hacen todo lo posible por ocultar la información confidencial de las URL antes de registrarlas, pero es mejor no tener datos confidenciales en las URL).
Las API RESTful, como se las llama comúnmente, utilizan una lista de URL para activar funciones específicas y, por lo general, empaquetan sus parámetros cargados y descargados en el resto de la solicitud HTTP, manteniendo así las URL libres de datos potencialmente confidenciales.
Por ejemplo, si estás utilizando Sophos Intelix (¡hay cuentas gratuitas disponibles!) para realizar búsquedas de amenazas en vivo, primero debes autenticarte con tu nombre de usuario y contraseña, lo que te proporciona una contraseña de sesión llamada access_token que funciona durante 60 minutos.
Solo hay una URL de autenticación RESTful, y tu nombre de usuario y contraseña (Intelix solo acepta solicitudes HTTPS, para garantizar que los datos se intercambien de forma segura) se envían en la solicitud, así:
POST https://api.labs.sophos.com/oauth2/token HTTP/1.1 Host: api.labs.sophos.com Authorization: [REDACTED - username and password supplied here] Content-Type: application/x-www-form-urlencoded, Connection: close grant_type=client_credentials
La API de Fortress funciona de manera similar, pero Vishwakarma descubrió rápidamente que no necesitaba pasar por una etapa de autenticación por adelantado.
En cambio, pudo enviar una solicitud de esta forma:
POST https://fortress.[REDACTED].com/api? HTTP/1.1
Host: fortress.[REDACTED].com/api?
Content-Type: application/json
Connection: close
{ cmd=GETINFO [...], user_name="XXXXXX" }
A pesar de que solo proporcionó un nombre de usuario en la solicitud, recibió una respuesta que contenía una cadena JSON etiquetada como IMEI, un acrónimo que generalmente se usa en el contexto de teléfonos móviles y abreviatura de identidad internacional de equipos móviles.
Cada teléfono, ya sea que tenga una tarjeta SIM insertada o no, tiene un IMEI que es grabado en el dispositivo por el fabricante (marca el número *#06# para ver el tuyo), y los operadores de telefonía móvil lo usan para rastrear el dispositivo en la red y para bloquear teléfonos robados.
IMEI considerado peligroso
Debido a que el IMEI es exclusivo de tu dispositivo, recomendamos encarecidamente que no lo reveles a nadie más.
Ciertamente, no debe usarse el IMEI como si fuera un nombre de usuario o un identificador público, y las aplicaciones móviles en mercados online como Google Play y Apple App Store no pueden recopilarlos, porque se consideran aplicaciones de captura de IMEI maliciosas por defecto.
Aunque el producto de seguridad para el hogar S03 de nivel de entrada no requiere una tarjeta SIM y solo funciona a través de una red Wi-Fi, parece que Fortress identifica de forma única cada dispositivo con un código numérico que se refiere al IMEI.
(Suponemos que esto es para que el S03 pueda compartir el código fuente con el producto S6 Titan más caro, que tiene una ranura para tarjeta SIM y, por lo tanto, un IMEI incorporado propio).
Desafortunadamente, este IMEI se usa no solo como un nombre de usuario, que sería desaconsejado por sí solo, sino como una contraseña completa que se puede usar como un token de autenticación permanentemente válido en futuras solicitudes a la API web de Fortress.
En otras palabras, simplemente conociendo tu nombre de usuario de Fortress, Vishwakarma podría conseguir el IMEI de su dispositivo, y luego, simplemente conociendo el IMEI, podría emitir comandos autenticados a tu dispositivo, por ejemplo como este:
POST https://fortress.[REDACTED].com/api? HTTP/1.1
Host: fortress.[REDACTED].com/api?
Content-Type: application/json
Connection: close
{ cmd=ACTIVATE [...], imei="KNOWNVALUE", op=0, user_name="XXXXXX" }
En el comando anterior, el elemento de datos op parece significar operando, el nombre comúnmente dado a los datos que se suministran a una función de computadora o instrucción de código de máquina. (En una línea de código de ensamblador como ADD RAX, 42, los valores RAX y 42 son los operandos).
Y el valor cero dado como operando al comando ACTIVATE, como se muestra arriba, hace exactamente lo que podría esperar: ¡apaga la alarma!
Por supuesto, para averiguar el KNOWNVALUE del IMEI / contraseña de su cuenta, un atacante primero necesitaría conocer los valores de XXXXXX.
Lamentablemente, como descubrió Vishwakarma, XXXXXX es simplemente la dirección de correo electrónico, o más precisamente la dirección de correo electrónico que se utilizó al configurar el sistema.
En resumen: adivina la dirección de correo electrónico ==> obtén el código de autenticación permanente ==> desactiva la alarma de forma remota a voluntad.
Los mandos a distancia también derrotados
Vishwakarma también echó un vistazo a la seguridad de los mandos a distancia (los botones del control remoto, como el botón que abre la puerta de su garaje o desbloquea su automóvil) que vienen con el sistema.
Vishwakarma utilizó una configuración conocida como SDR, abreviatura de radio definida por software, un sistema de transmisor y receptor reprogramable que se puede adaptar para funcionar en una amplia gama de frecuencias diferentes y para emular todo tipo de equipos de radio diferentes.
Se necesitaría una configuración SDR de gama alta para manejar dispositivos de muy alta frecuencia como Wi-Fi (a 5 GHz y 2,4 GHz), pero un dispositivo que cuesta menos de 50 $ tiene un rendimiento suficiente para “escuchar” transmisiones a 433 MHz, la banda de frecuencia comúnmente utilizada por dispositivos de control remoto como llaveros.
En teoría, un SDR correctamente configurado puede registrar de manera confiable y fácil la señal de radio exacta emitida por un llavero cuando está bloqueando o desbloqueando un automóvil, el garaje o el sistema de seguridad de su hogar.
El mismo SDR podría reproducir una transmisión idéntica más adelante.
En ese sentido, un SDR funciona como un bloque de cera o una pastilla de jabón con una llave, mediante la cual un atacante (o un detective privado en una novela policíaca) podría sacar una impresión de la llave de tu puerta hoy y luego crear una copia propia para usar mañana.
Sin embargo, un llavero digital tiene una ventaja significativa sobre una tecla tradicional, a saber, que puede “cambiar de forma” entre cada pulsación de botón.
Al utilizar un algoritmo criptográfico para variar los datos reales que transmite cada vez, al igual que los códigos 2FA en constante cambio que producen las aplicaciones de seguridad para teléfonos móviles, un llavero bien diseñado debería ser resistente a lo que se conoce como un ataque de reproducción.
Ese tipo de recálculo de código dinámico, generalmente basado en un secreto digital que se comparte de forma segura entre el llavero y la unidad de control cuando el llavero está configurado, significa que un código de radio grabado hoy no será útil mañana, o incluso en dos minutos.
Lamentablemente, como probablemente ya hayas adivinado, Vishwakarma descubrió que los mandos a distancia de Fortress S03 no producían códigos de una sola vez cada vez que se pulsaban, sino que simplemente usaban el mismo código una y otra vez, una vulnerabilidad ahora denominada CVE-2021-39277.
En resumen: acércate a la casa de alguien ==> captura la transmisión de “alarma desactivada” del mando a distancia ==> desactiva la alarma más tarde a voluntad.
¿Qué hacer?
Según Rapid7, Fortress decidió no responder a estos errores, cerró el informe en mayo de 2021 y no se opuso a la divulgación de vulnerabilidades propuesta por la empresa a finales de agosto de 2021.
Por lo tanto, parece que la empresa no está planeando ningún tipo de actualización de firmware, ya sea para sus unidades de control o mandos a distancia, y por lo tanto, estas vulnerabilidades no serán reparadas, al menos en sistemas que ya se han vendido.
Por lo tanto, si tienes uno de estos sistemas, o un sistema de apariencia similar con una marca diferente que sospechas que puede provenir del mismo proveedor de equipos, hay dos soluciones que puedes utilizar:
- Utiliza una dirección de correo electrónico que es poco probable que un atacante conozca o adivine. Los servicios de correo web como Outlook y Gmail, por ejemplo, permiten tener varios alias de correo electrónico para tu cuenta principal, simplemente agregando texto como + ABCDEFG al final de tu nombre de correo electrónico habitual. Por ejemplo, si usas nickname@example.com como tu dirección de correo electrónico habitual, los mensajes a nickname+random5XXG8@example.com deben enviarse al mismo buzón, aunque las dos direcciones no coincidan. Ten en cuenta que este es un ejemplo de seguridad por oscuridad, por lo que no es una solución ideal, pero dificulta las cosas para un atacante o un amigo o familiar con intenciones maliciosas.
- Evita usar los mandos a distancia. Esto significa que siempre necesitarás tener tu portátil o móvil a mano, o hacer todo directamente desde el panel de control, pero si nunca configuraste tus mandos a distancia para que funcionen con tu propia unidad de control, no pueden revelar ningún secreto que un atacante podría utilizar en posteriores ataques de reproducción.
Aviso a todos los programadores
Una vez más, como parece que decimos tan a menudo cuando hablamos de seguridad IoT: si eres un programador, no tomes atajos que sabes que son malos.
Como mencionamos muchas veces, los identificadores de dispositivos como direcciones MAC, UUID e IMEI no son adecuados como secretos criptográficos o contraseñas, así que no los uses para ese propósito.
Y el material criptográfico que se transmite o se muestra sin cifrar, ya sea un código 2FA de una aplicación de autenticación, un vector de inicialización para un archivo cifrado o una ráfaga de radio de un mando a distancia, nunca debe reutilizarse.
Incluso hay un término de jerga para este tipo de datos: se conoce como nonce, abreviatura de “número usado una vez”, y significa exactamente lo que dice.
