Los dispositivos habilitados para la web se han convertido desde hace tiempo en compañeros indispensables en muchas empresas y hogares. Los asistentes de voz inteligentes, la tecnología de edificios inteligentes y los sistemas de comunicación digital prometen mayor comodidad y eficiencia. Sin embargo, las APIs a través de las cuales se comunican estos útiles ayudantes suelen tener serias brechas de seguridad.
Para habilitar las funciones inteligentes, los dispositivos IoT no solo están equipados con un sofisticado sistema de control y, a menudo, con decenas de aplicaciones diferentes, sino que también suelen estar conectados a un servidor del respectivo fabricante. Esto garantiza que los datos de todos los dispositivos activos se recojan y evalúen de forma centralizada en las aplicaciones en la nube. Esto confiere a sistemas que en realidad son bastante simples una especie de inteligencia artificial que utiliza los valores empíricos de todos los dispositivos para optimizar los procesos de trabajo individuales.
Esto es precisamente lo que puede causar problemas, como muestra un caso actual del equipo de investigación de Checkmarx. Los investigadores, que en el pasado han descubierto vulnerabilidades de seguridad en Alexa de Amazon, en la cámara de los smartphones de Google y Samsung y en la tableta infantil LeapPad, han documentado ahora lo peligrosos que pueden ser los supuestamente inofensivos sistemas de hogar y oficina inteligentes. Anteriormente, los investigadores de seguridad habían examinado dispositivos IoT en el hogar, incluido el robot aspirador Ironpie M6 de Trifo. El robot aspirador controlado por la app tiene una cámara integrada que permite a los usuarios mirar en su propia casa en cualquier momento a través de la app. El equipo de Checkmarx encontró graves vulnerabilidades en las interfaces de programación de aplicaciones (API) entre el dispositivo, la aplicación Android y la conexión con el servidor backend.
Las vulnerabilidades en detalle
En la investigación, los investigadores no solo encontraron varias vulnerabilidades a la vez, sino que también documentaron prácticas de codificación inseguras. Mientras que algunas vulnerabilidades sólo tienen un bajo potencial de riesgo en la práctica, otras ya deben clasificarse como bastante más graves. Esto es especialmente cierto teniendo en cuenta que el robot aspirador se sigue comercializando como un producto de seguridad.
En la investigación, se encontraron lagunas en los tres componentes del sistema:
- en la aplicación Android
en la interacción con el sistema de la nube en el backend
- en el propio aspirador
Actualización insegura
En cuanto a su programación, la aplicación Android de Trifo (Trifo Home) puede clasificarse definitivamente como segura. Cumple con las directrices actuales y su codificación también está sólidamente ejecutada. Según los investigadores, su punto débil reside en el procedimiento de actualización. La actualización no se realiza a través de la Google Play Store, como suele ser habitual, sino a través de un servidor de terceros mediante peticiones HTTP. Los atacantes pueden interceptar la solicitud y utilizarla para instalar código malicioso en el ordenador del usuario. Las posibilidades de una app manipulada de esta manera son entonces casi ilimitadas para los ciberdelincuentes.
El acceso remoto MQTT abre la puerta a los hackers
MQTT (Message Queuing Telemetry Transport) es un protocolo de ahorro de datos que permite a los dispositivos IoT transmitir datos de telemetría incluso en redes de banda estrecha. En el caso del robot aspirador, los servidores MQTT que lo soportan actúan como puente entre el aspirador Trifo, los servidores backend y la aplicación Trifo Home. Los servidores se utilizan para procesar los eventos de los robots de vacío desplegados, que luego se transmiten a la interfaz gráfica de usuario de la aplicación Trifo Home correspondiente. El problema: el sistema no tiene un mecanismo de autenticación suficientemente seguro. Esto permite a un atacante conectarse a los servidores MQTT. Para ello, solo necesita un ID de cliente arbitrario, que se puede extrapolar con relativa facilidad a partir de los datos existentes.
Mientras que la aplicación Android del fabricante utiliza MQTT a través de SSL, el propio robot aspirador se conecta primero a los servidores MQTT a través de una conexión no cifrada e intercambia algunos paquetes abiertamente. Sólo entonces se encripta la carga útil real de MQTT. Esto es problemático, porque es precisamente esto lo que permite a los atacantes calcular cualquier ID de cliente. Con este conocimiento, puede monitorizar el tráfico de datos del Ironpie para hacerse con cualquier dirección MAC y así redirigir los datos a sus propios sistemas. Estos datos también incluyen la llamada dev_key, que puede utilizarse para descifrar todo el tráfico. Con esta información, el hacker es capaz de hacerse pasar por un servidor MQTT y obtener el control total del hoover.
Conocimiento completo
A través de MQTT, el atacante tiene entonces acceso completo a casi toda la información. Esto incluye, por ejemplo, el SSID de la red a la que está conectado el robot aspirador, su dirección IP interna, su dirección MAC y otros datos. Esto permite a un atacante generar una clave que le permite acceder a la transmisión de vídeo de todas las aspiradoras Ironpie activas, independientemente de su ubicación. Ahora nada se opone a espiar edificios enteros y a sus ocupantes y a crear planos de las casas de otras personas.
Aunque Checkmarx ya ha informado al fabricante sobre las vulnerabilidades, éstas aún no han sido corregidas. Los proveedores y fabricantes deben centrarse más en la seguridad de sus dispositivos para proteger de forma fiable a los usuarios y sus datos.
Conclusión
En el transcurso de la digitalización y el IoT, el número de dispositivos inteligentes habilitados para la web en entornos privados y profesionales está aumentando rápidamente. Sin embargo, los fabricantes no deben renunciar a la seguridad del software y las interfaces de los dispositivos para poder sacar sus productos al mercado con rapidez. Para detectar y eliminar las lagunas de seguridad en el código en una fase temprana, es especialmente importante seguir las directrices de buenas prácticas de la OWASP en el ámbito de la seguridad de las API. En entornos críticos con grandes volúmenes de código, también es aconsejable utilizar una plataforma de seguridad de software dedicada que supervise el código y los componentes de código abierto integrados a lo largo de todo el SDLC.
Acerca del autor: Brad Wolfe es director de ingeniería de ventas en el proveedor de seguridad de software Checkmarx.