¿Qué riesgos tomamos al instalar el sistema de "casa inteligente"? El que maneja bombillas y un hervidor de agua desde la aplicación en el teléfono inteligente, dentro de la red local y de forma remota. Si la seguridad y la administración de bloqueos están vinculadas a un sistema inteligente (como en el caso de Amazon Key), entonces está claro cuáles. De lo contrario, teóricamente es posible imaginar el peligro de falla del software de una máquina de café con un incendio posterior. Pero es mejor no fantasear, sino estar seguro.
Los especialistas del equipo ICS CERT de Kaspersky Lab decidieron realizar una prueba de campo en el hogar inteligente de uno de los empleados de la compañía (
noticias ,
publicación de blog ,
artículo técnico). La piratería fue exitosa: la cafetera no sufrió, pero fue posible obtener el control del sistema, aunque con un par de suposiciones (bastante realistas) durante el experimento. Una de las consecuencias desagradables de este ataque fue la filtración de datos personales: las coordenadas de la casa y, lamentablemente, la geolocalización del teléfono inteligente. Sin embargo, el experimento terminó con una nota positiva: el fabricante del sistema de hogar inteligente cerró con éxito las vulnerabilidades.
Interpretación artística de las consecuencias de la piratería.En un artículo técnico, se dedica bastante espacio a puntos relativamente aburridos, pero importantes: lo que NO logró piratear, y cómo el análisis del sistema de hogar inteligente fue por posibles vulnerabilidades. Antes de comenzar el experimento, los investigadores ya conocían al fabricante del sistema. Resultó ser
Fibaro , que produce una variedad de sus propios dispositivos para un hogar inteligente moderno, además de proporcionar integración con dispositivos de terceros. Además, el propietario dio una pista importante: una IP permanente para ingresar al panel de administración. Por cierto, Fibaro no recomienda abrir el acceso al controlador a través de IP, solo a través del sistema en la nube. En este experimento, esta escapatoria dejada deliberadamente por el propietario desempeñó un papel.
Teóricamente, dicho sistema puede ser atacado en tres direcciones principales: intente hackear el dispositivo de control de una forma u otra, busque vulnerabilidades en la parte de la nube del servicio o ataque los dispositivos IoT conectados al controlador. En el último caso, es necesario estar cerca de ellos, por lo que las dos primeras opciones parecen más prometedoras.
El siguiente paso es analizar el firmware del dispositivo y WebAPI. Por lo general, en dicho análisis, todo termina y las noticias salen en el estilo "se detecta una contraseña cableada en el dispositivo". Pero en el caso de Fibaro, no había agujeros de seguridad obvios. Pero se recibió información útil sobre la implementación de parte de la lógica de control en PHP. Sin autorización, el controlador solo da el número de serie del dispositivo, y para hackear una pieza de hierro esta información es inútil. Pero, como resultó, te permite hackear la parte de la nube del servicio.
El acceso a la nube, a su vez, le permite obtener copias de seguridad de la base de datos SQLite que contienen todas las configuraciones del dispositivo sin autorización y cargar la suya propia. Teóricamente, omitir la autorización hizo posible (antes de corregir la vulnerabilidad) descargar copias de seguridad de todos los usuarios del sistema en la nube. El análisis de la base real del dispositivo atacado proporcionó acceso a información privada, incluidas las coordenadas de la casa y el teléfono inteligente en el que está instalada la aplicación de control. Esto ya es un problema grave, ya que (con algunas limitaciones) le permite determinar cuándo el propietario del sistema no está en casa.
Además, la base de datos tenía información completa sobre los dispositivos IoT conectados, así como una contraseña para acceder a la configuración, pero ha sido agregada con "sal". El análisis del firmware mostró que la "sal" no es aleatoria, sino que está firmemente cosida en el dispositivo. Teóricamente, se puede descifrar una contraseña muy simple, pero en este caso no funcionó. La base SQLite también contenía contraseñas abiertas para conectarse a otros dispositivos dentro de la red: si estas contraseñas coincidían con la principal, el controlador también podría descifrarse fácilmente.
Pero nuevamente no funcionó: el propietario del sistema estaba familiarizado con las recomendaciones básicas de seguridad y no usó la misma contraseña para diferentes dispositivos. Por lo tanto, tuve que aplicar la ingeniería social. Una vulnerabilidad en el sistema en la nube que permite realizar una serie de acciones sin autorización, conociendo solo el número de serie del dispositivo (que se da "gratis" si hay acceso al panel de administración desde el exterior), hizo posible el siguiente escenario. Se cargó en la "nube" una copia de seguridad preparada del dispositivo en el que se insertó el script malicioso. Se envió al propietario un mensaje sobre la necesidad de "actualizar" el dispositivo a través de las capacidades regulares del sistema en la nube (por correo electrónico y SMS).
Como el propietario del sistema conocía el experimento, se dio cuenta de inmediato de que no era un parche real. Pero en general, este es un escenario muy real cuando un usuario recibe un mensaje plausible a través de un canal de comunicación familiar, por lo que se ha instalado una copia de seguridad. El código malicioso se ejecutó con derechos del sistema debido a un descuido en el código PHP que provocó la ejecución del script bash:
Aquí, el parámetro establecido por el usuario (en condiciones normales, incluso el administrador del sistema no tiene privilegios de superusuario en el dispositivo) entra en el argumento de la línea de comando. La verificación insuficiente de los argumentos nos permitió ejecutar código arbitrario con privilegios de root y finalmente obtener el control total sobre el dispositivo. Paralelamente, se encontró la posibilidad de inyección SQL, pero no se utilizó:
Los investigadores no planearon romper una cafetera en una casa real, por lo que cambiaron la melodía del despertador como un "hola". Se cerraron las vulnerabilidades mencionadas en el sistema en la nube y en el código del controlador. Por razones obvias, los métodos específicos de elusión de la protección no se divulgan en un artículo técnico, para evitar su uso por parte de atacantes reales en dispositivos que aún no se han actualizado. Pero en este experimento, lo que generalmente se deja fuera de los titulares se muestra bien en este experimento: hay muchas formas de investigar la protección del dispositivo, la mayoría de las cuales terminan en nada. En la experiencia real, tanto el fabricante del dispositivo como su propietario pudieron evitar los errores de seguridad más simples, como las contraseñas integradas y reutilizables. Sin embargo, se identificó un número suficiente de problemas que podrían provocar al menos una fuga de datos privados y, en el peor de los casos, eludir los sistemas de seguridad.
Descargo de responsabilidad: las opiniones expresadas en este resumen pueden no coincidir siempre con la posición oficial de Kaspersky Lab. Los estimados editores generalmente recomiendan tratar cualquier opinión con escepticismo saludable.