De aspersores a motocicletas: Lo que hackeamos

En ciberseguridad, las pruebas son la clave. Nuestros pentesters simulan ataques del mundo real para identificar los puntos débiles antes de que lo hagan los delincuentes. Mediante la ingeniería inversa de sistemas y productos, descubren fallos críticos. Esto proporciona a los clientes la información necesaria para solucionar los problemas y reducir los riesgos.

En este artículo, desglosamos cuatro proyectos en tres preguntas: ¿Por qué lo pirateamos? ¿Qué hemos encontrado? ¿Cuál fue el impacto?

PROYECTO

Controlador de aspersores con soporte BLE y aplicaciones móviles

preocupaciones del cliente

Con la incorporación de la compatibilidad con Bluetooth Low Energy (BLE), los programadores actualizados del cliente se diseñaron para permitir a los usuarios controlar el sistema de forma remota a través de aplicaciones móviles. El cliente necesitaba asegurarse de que esta nueva conectividad no introdujera vulnerabilidades, que potencialmente podrían exponer los dispositivos de los clientes a accesos no autorizados.

LA MISIÓN: POR QUÉ LA HACKEAMOS

El cliente estaba integrando BLE en su controlador de aspersores IoT de próxima generación. BLE es una tecnología habitual en los dispositivos IoT, pero también es un objetivo frecuente de los piratas informáticos debido a sus fallos de seguridad.

El cliente necesitaba garantías de que la nueva conectividad no abría vías para que los atacantes pusieran en peligro los dispositivos, manipularan los ajustes de los aspersores u obtuvieran acceso no autorizado a las redes de los usuarios. Nuestro objetivo era detectar a tiempo cualquier fallo de seguridad, asegurándonos de que los hogares y jardines de los clientes no estuvieran en peligro por las ciberamenazas.

EL DESGLOSE: LO QUE ENCONTRAMOS

Abordamos la revisión de la seguridad utilizando dos metodologías:

• OWASP Top 10 para aplicaciones móviles: Evaluó la aplicación móvil en busca de vulnerabilidades como el almacenamiento inseguro de datos, la insuficiente protección de la capa de transporte y la autenticación incorrecta.
• Pruebas IoT para la configuración BLE: Examinó cómo se había implementado y configurado BLE para garantizar que no había errores de configuración comunes como la falta de autenticación o la transmisión de datos sin cifrar.

DURANTE LAS PRUEBAS DESCUBRIMOS VARIOS PROBLEMAS CRÍTICOS

• Fallos de diseño en el Proceso de Emparejamiento BLE: Los débiles mecanismos de emparejamiento facilitaban a los posibles atacantes la escucha o la interferencia.
• Vulnerabilidades en el manejo de datos de la aplicación móvil: Los datos sensibles se almacenaban sin el cifrado adecuado, lo que hacía posible que un atacante con acceso al dispositivo los extrajera y utilizara indebidamente.
• Comandos del dispositivo expuestos: Varios comandos BLE utilizados para controlar los ajustes de los aspersores no estaban debidamente protegidos, lo que dejaba margen para manipulaciones no autorizadas.

AL SOLUCIONAR ESTOS PROBLEMAS, EL CLIENTE PUDO

• Asegurar el proceso de emparejamiento BLE, garantizando que sólo los usuarios legítimos pudieran controlar el dispositivo.
• Implementar métodos de almacenamiento y transmisión seguros para la información sensible dentro de las aplicaciones móviles.
• Bloquear los comandos del dispositivo, reduciendo la probabilidad de manipulación maliciosa.

Como resultado, los controladores de aspersores del cliente compatibles con BLE no sólo eran más seguros, sino que también proporcionaban tranquilidad a los usuarios finales, que podían confiar en que sus sistemas inteligentes eran sólidos frente a posibles ciberamenazas. Este security testing proactivo permitió al cliente salir al mercado con confianza, convirtiendo un riesgo potencial en una ventaja competitiva.

PROYECTO

Ingeniería inversa del sistema de control de encendido (ICS) de motocicletas

PREOCUPACIONES DEL CLIENTE

El sistema de control del encendido (ICS) de la motocicleta gobierna la sincronización de la chispa para encender la mezcla de combustible y aire del motor. El cliente necesitaba saber si se podía aplicar ingeniería inversa al sistema para modificar el rendimiento de la motocicleta, por ejemplo, aumentar la potencia ajustando la sincronización de la chispa o alterando los límites de revoluciones.

LA MISIÓN: POR QUÉ LO PIRATEAMOS

El sistema de control del encendido de esta motocicleta, una Suzuki Katana, estaba siendo investigado para un posible ajuste de su rendimiento. El sistema estaba integrado en una caja sellada y controlaba la sincronización de las chispas de encendido mediante un microcontrolador. El cliente quería aplicar ingeniería inversa al sistema para modificar el rendimiento del motor. El objetivo era conocer mejor el ICS y determinar si podía reprogramarse para aumentar el rendimiento sin comprometer la fiabilidad.

EL DESGLOSE: LO QUE ENCONTRAMOS

Abordamos el proceso de ingeniería inversa de la siguiente manera

• Deconstrucción del hardware: Intentamos acceder físicamente y sondear la placa de circuitos dentro del sistema de control de encendido sellado para entender cómo funcionaba.
• Identificación del microcontrolador: Identificó el microcontrolador que gobernaba el sistema, a pesar de las dificultades causadas por el sellado de protección, y buscó interfaces de depuración o reprogramación.

DURANTE LAS PRUEBAS DESCUBRIMOS VARIOS PROBLEMAS CRÍTICOS

• Mecanismo de protección del sellado: El sistema estaba fuertemente sellado con materiales diseñados para impedir la ingeniería inversa, lo que provocó algunos daños al intentar acceder a la placa.
• Ausencia de interfaz de depuración: A pesar de las pruebas exhaustivas de las posibles interfaces, no había ningún método directo para reprogramar el microcontrolador o extraer el firmware.
• Accesibilidad limitada al firmware: El microcontrolador utilizaba ROM de máscara, lo que significaba que el firmware estaba codificado y no podía extraerse sin técnicas avanzadas como el descapsulado.

AL SOLUCIONAR ESTOS PROBLEMAS, EL CLIENTE PUDO

• Pivotar el enfoque hacia las pruebas de caja negra: Mediante la simulación de las entradas y la medición de las salidas (por ejemplo, la posición del árbol de levas y el acelerador), el cliente dedujo con éxito los algoritmos de sincronización del encendido.
• Construir un simulador personalizado: El cliente creó un sistema de microcontrolador personalizado para imitar el comportamiento del ICS y explorar las posibilidades de ajuste del rendimiento.

Como resultado, el cliente obtuvo una comprensión más profunda de cómo el ICS controlaba el rendimiento del motor y pudo empezar a construir un nuevo sistema programable para mejorar la potencia y la eficiencia. Aunque la reprogramación directa no fue posible, el enfoque de caja negra proporcionó valiosos conocimientos sobre cómo modificar la sincronización del encendido para mejorar el rendimiento.

PROYECTO

Seguridad de los productos sanitarios

PREOCUPACIONES DEL CLIENTE

Los dispositivos médicos automatizados que se conectan a las redes hospitalarias y a los servicios en la nube presentan retos de seguridad únicos. En este caso concreto, el objetivo era un sistema integrado que permitía al personal del hospital autenticarse en estaciones de trabajo mediante Bluetooth Low Energy que realizaba una detección de presencia activa y un seguimiento del usuario. Al cliente le preocupaba que las posibles vulnerabilidades pudieran permitir el control no autorizado del dispositivo o de la estación de trabajo, la manipulación de datos o la exposición de información sensible de los pacientes. El objetivo era assessment the device's resilience to cyberattacks and ensure compliance with industry regulations.

LA MISIÓN: POR QUÉ LO HACKEAMOS

Se encargó a Bureau Veritas Cybersecurity que evaluara el software, el hardware integrado, las conexiones de red y las prácticas de gestión de datos del dispositivo médico. La misión consistía en identificar las brechas de seguridad que podrían explotarse para comprometer la seguridad de los pacientes o interrumpir los procedimientos médicos.

EL DESGLOSE: LO QUE ENCONTRAMOS

Nuestra assessment de seguridad implicó:

• Pruebas de vulnerabilidad de la red: Evaluamos las conexiones a las redes del hospital y de la nube en busca de puntos débiles que pudieran permitir un acceso no autorizado.
• Análisis de la integridad de los datos: Evaluó cómo se almacenaban y transmitían los datos de los pacientes, centrándose en la encriptación y la prevención de manipulaciones.
• Simulación de ataques de hardware: Se utilizaron Ubertooth One y NRF51 para olfatear el tráfico BLE entre los componentes objetivo del hardware del cliente y la aplicación. Se utilizó Gatttool para descubrir, leer y escribir en las características BLE disponibles.
• Simulación de control de dispositivos: Se simularon posibles escenarios de ataque para comprobar si era posible el control remoto del dispositivo.

hallazgos clave incluidos

• Cifrado de datos insuficiente: Se descubrió que ciertas transmisiones de datos estaban protegidas de forma inadecuada, lo que suponía un riesgo de interceptación y manipulación.
• Características BLE sin restricciones: La configuración insegura de Bluetooth Low Energy (BLE) dejaba el seguimiento de proximidad vulnerable a la manipulación, lo que permitía la supervisión no autorizada de la actividad del usuario y la interferencia con las operaciones previstas.
• Autenticación defectuosa: Las interacciones y los protocolos entre componentes eran inseguros, lo que podía permitir un ataque de interferencia que eludiera la autenticación del sistema.
• Ataques piggybacking: El MITM en la conexión Bluetooth permitía capturar los UUID, MAC y otros valores para añadirlos a otra aplicación sin consentimiento.
• Vías de acceso no autorizadas: Se identificaron vías que podían permitir a los atacantes hacerse con el control del dispositivo o acceder a los datos de los pacientes.
• Lagunas normativas: Destacó áreas en las que las medidas de seguridad no se ajustaban a las normativas del sector, lo que afectaba al cumplimiento de las mismas.

AL SOLUCIONAR ESTOS PROBLEMAS, EL CLIENTE PUDO

• Mejorar el cifrado de datos: Implantar normas de cifrado exhaustivas para salvaguardar los datos de los pacientes.
• Asegurar el acceso a la red: Cerrar las vías de acceso no autorizadas y reforzar las medidas de autenticación.
• Lograr la conformidad: Alinee los protocolos de seguridad de los dispositivos con las normas del sector para cumplir los requisitos normativos.

Estas mejoras aumentaron significativamente la seguridad y fiabilidad del dispositivo médico, garantizando la seguridad del paciente y la protección de sus datos.

PROYECTO

Robot Aspirador

PREOCUPACIONES DEL CLIENTE

Las aspiradoras robóticas conectadas introducen riesgos relacionados con la exposición de datos y el uso indebido del dispositivo. En este caso, el dispositivo utilizaba Bluetooth y servicios basados en la nube, con funciones de control vinculadas a una aplicación móvil. El fabricante quería saber si los atacantes podían hacer un uso indebido del sistema para rastrear los movimientos, manipular las acciones del dispositivo o extraer datos confidenciales. El objetivo era evaluar los riesgos técnicos e identificar los puntos débiles del diseño.

LA MISIÓN: POR QUÉ LO HACKEAMOS

Se nos pidió que revisáramos el dispositivo en todas sus capas: hardware, firmware, aplicaciones móviles, protocolos de comunicación y almacenamiento local. La misión consistía en descubrir problemas que pudieran explotarse para acceder a los datos o hacerse con el control del dispositivo.

EL DESGLOSE: LO QUE ENCONTRAMOS

Nuestro equipo utilizó múltiples herramientas, scripts personalizados y métodos de prueba probados para examinar el dispositivo.

Las actividades clave incluyeron:

• Validación de firmware y actualizaciones: Se revisaron los procedimientos de actualización y se realizaron pruebas para detectar usos indebidos.
• Pruebas de la aplicación móvil: Se evaluó cómo interactuaban los usuarios con el dispositivo y se buscaron funciones ocultas o no vigiladas.
• Pruebas de comunicación: Se investigó cómo se enviaban los datos entre el dispositivo, la aplicación y los sistemas backend.
• Revisión del almacenamiento de datos: Examinó cómo y dónde se almacenaba la información localmente.

HALLAZGOS CLAVE INCLUIDOS

• Seguridad de la comunicación deficiente: Ciertas transmisiones no estaban bien protegidas, lo que permitía captar datos de localización y registros de limpieza.
• Riesgos de actualización del firmware: El Proceso de actualización carecía de comprobaciones de firma digital, lo que abría la puerta a la inyección de firmware alterado.
• Funciones de la app sin restricciones: Los fallos de la aplicación móvil exponían las funciones de prueba internas y podían permitir un uso indebido de las funciones del dispositivo.
• Riesgos de acceso remoto: Los atacantes podrían explotar estos problemas para controlar el aspirador u observar el comportamiento del usuario.

AL SOLUCIONAR ESTOS PROBLEMAS, EL CLIENTE PUDO

• Mejorar los controles de acceso en la aplicación móvil para bloquear el uso indebido de las funciones internas.
• Corregir las lagunas en la comunicación para evitar la interceptación del tráfico.
• Aplicar cambios criptográficos para proteger los datos almacenados y transmitidos.
• Introducir una fuerte verificación para las actualizaciones del firmware.
• Añada salvaguardas contra el uso indebido automatizado de la aplicación móvil.
• Formar a los equipos técnicos en prácticas seguras de desarrollo móvil y de IoT.

Estas acciones ayudaron al fabricante a reducir el riesgo en todos los ámbitos y a obtener una visión más clara de cómo los atacantes podían acercarse al sistema. Los resultados respaldaron las mejoras del producto a largo plazo y una postura más sólida para futuros dispositivos.