Inversores solares IoT y vulnerabilidades de goteo

3 de septiembre de 2019, por Jos Wetzels, consultor principal de seguridad de Bureau Veritas Cybersecurity

Omniksol

Omnik es un fabricante chino-alemán de inversores fotovoltaicos (FV) y accesorios muy popular en los Países Bajos, Alemania y Bélgica.

Los inversores Omnik disponen de dos puertos RJ-45 a través de los cuales se pueden conectar en serie hasta 50 inversores para permitir la configuración y la transferencia de datos a través de RS-485. Además, hay disponibles módulos de conectividad Wi-Fi y GPRS como tarjetas internas o kits externos (conectados al inversor a través de RS-485) para la supervisión remota del estado, el registro de datos y la configuración de toda una cascada de inversores.

Tenga en cuenta que éstas son sólo las cuentas públicas y sólo las visibles en el portal Omnik. Otras marcas que revenden la solución SolarMAN podrían utilizar sus propios portales.

Además del mapa anterior de usuarios del kit Wi-Fi, podemos encontrar decenas de ellos expuestos públicamente en Internet utilizando los motores de búsqueda Shodan y Censys:

El kit Wi-Fi SolarMAN / iGEN

Muy bien, echemos un vistazo más de cerca al kit Wi-Fi. Lo primero que hay que observar es que el AP abierto es la opción por defecto. Aunque la configuración le permite "ocultar" el AP, establecer el cifrado WEP / WPAPSK / WPA2PSK y cambiar el nombre de usuario y la contraseña del servidor web, no requiere que el usuario final lo haga y, como tal, el dispositivo parece típicamente desplegado inseguro desde el principio. Además, si el AP abierto sólo se utiliza para la configuración inicial del dispositivo no se desactiva después dejándolo abierto en muchos dispositivos de "configurar y olvidar".

Entonces, ¿qué podemos hacer con el acceso al AP aquí? Bueno, en primer lugar nos permite interactuar con los inversores fotovoltaicos a través de varias interfaces sobre las que hablaremos más adelante. En segundo lugar, el kit Wi-Fi necesita poder conectarse a Internet para comunicarse con el backend en la nube de SolarMAN, que ingiere los datos de los inversores y los pone a su disposición a través de una aplicación móvil. Para ello, el kit se conecta a una red interna, ya sea mediante un cable Ethernet o un AP Wi-Fi (para el que es necesario introducir el SSID y las credenciales en la interfaz de configuración web). Aparte del hecho de que esto significa confiar al backend de la nube tanto los datos de su inversor fotovoltaico como potencialmente sus credenciales Wi-Fi personales, también significa que el propio AP del kit actúa ahora como punto de entrada a su red privada. Un riesgo que afecta a muchos dispositivos IoT.

Para hacerme una mejor idea de la postura de seguridad del kit, decidí echar un vistazo a sus diversos servicios. Un rápido escaneo nmap revela que la dirección MAC corresponde a la empresa Drogoo Tecnología Co. con sede en Shenzhen y que los siguientes servicios están expuestos:

* 53/UDP, DNS
* 80/TCP, HTTP
* 8899/TCP, Información del registrador de datos
* 48899/UDP, Interfaz AT HF

Interfaz web (80/TCP)
En el puerto 80 encontramos un servidor web que, tras superar una solicitud de autenticación básica HTTP, proporciona una interfaz de configuración que admite las opciones de configuración típicas (ajustes para la red inalámbrica y por cable, datalogger, servidor en la nube, comunicaciones serie), así como la posibilidad de cambiar el nombre de usuario y la contraseña de la interfaz web y actualizar tanto el firmware del kit Wi-Fi como el del inversor.

Información del registrador de datos (8899/TCP)
El servicio en este puerto se utiliza para las comunicaciones del datalogger para las que existen varios scripts de la comunidad de código abierto pero desde el punto de vista de la seguridad este servicio no es terriblemente interesante por lo que decidí no investigar más.

Interfaz AT HF (48899/UDP)
Supongamos que el usuario final configuró una contraseña segura para la interfaz web y que no queremos ir por el camino de la explotación de la corrupción de memoria en ninguno de los servicios expuestos. En ese caso, esta interfaz, a la que he llamado "interfaz HF AT" (por razones que quedarán claras más adelante), parece nuestra mejor baza.

La interfaz se utiliza para el descubrimiento de redes respondiendo con información identificativa a mensajes de difusión UDP específicos que contienen la cadena "WIFIKIT-214028-READ", como puede verse al realizar ingeniería inversa en la aplicación móvil SolarMAN:

La identificación FCC parece pertenecer al módulo Wi-Fi integrado HF-A11 fabricado por Shanghai Hi-Flying Tecnología. La presencia de este módulo, que se basa en la arquitectura MIPS y ejecuta el RTOS eCos, puede observarse en la placa de circuito impreso del kit tras abrir la carcasa:

Además, un rápido análisis del firmware del kit confirma que ejecuta eCos en MIPS y muestra cadenas Hi-Flying y HF-A11:

Hi-Flying

Shanghai High-Flying Electronics Tecnología Co., Ltd es un fabricante de productos de comunicaciones inalámbricas y proveedor de servicios en la nube que produce diversos módulos y dispositivos IoT. Estos módulos y dispositivos también son vendidos por otros vendedores como USR IOT y son adoptados por varios ODM y OEM de IoT de bajo coste en una amplia variedad de productos que van desde bombillas inteligentes como la conocida MiLight, enchufes inteligentes, cámaras web, cafeteras y alarmas de seguridad hasta RTU industriales, convertidores serie-ethernet, pasarelas y registradores de datos de inversores solares, todos ellos de nuevo rebautizados por extensas redes de nombres de empresas.

Una diapositiva de una presentación del perfil de la empresa Hi-Flying muestra algunos clientes internacionales destacados (entre ellos Omnik) y una amplia cartera de módulos:

Estos módulos suelen constar de un chip de comunicaciones inalámbricas comercializado (por ejemplo, el MediaTek MT5931) junto con un RTOS (por ejemplo, eCos, FreeRTOS, Contiki, ARM mbed) o Linux, varias bibliotecas de comunicaciones y redes, servidores web, ftp y telnet integrados y funciones propias de detección de redes, configuración remota y actualización de firmware OTA. Los módulos tienen la capacidad de funcionar como punto de acceso (AP) y/o estación (STA) y se puede interactuar con ellos a través de una interfaz de comandos UART AT.

Parece haber dos protocolos de configuración / OTA diferentes, ambos con una interfaz en el puerto 48899/UDP:

* Interfaz AT HF (también denominada SmartConfigure Smart Link), utilizada por los módulos de las series HF-A, HF-LPT, HF-LPB, etc.
* IOTService / IOTManager, utilizado por los módulos de las series Eport y Wport

Además, algunos módulos (como el HF-LPB125 y el HF-LPT330) son compatibles con WeChat AirKiss que es, como se documenta en la guía Espressif ESP-TOUCH, esencialmente una interfaz de canal encubierto para configurar ajustes Wi-Fi en dispositivos integrados que no disponen de otras interfaces. Para ello, hace que el dispositivo se inicie en modo de captura de paquetes y que la aplicación AirKiss envíe una serie de paquetes UDP al AP Wi-Fi, codificando el SSID y la contraseña en los campos de longitud del paquete. Como el campo de longitud no está codificado, el nodo a la escucha puede analizar el SSID y la contraseña y unirse a la red Wi-Fi, tras lo cual puede comenzar la configuración. Aunque normalmente AirKiss sólo está activo durante la configuración inicial, el enfoque sigue siendo fundamentalmente un riesgo para la seguridad.

Interfaz AT HF / Enlace inteligente SmartConfigure

En lugar de utilizarse simplemente para el descubrimiento de la red, este servicio expone realmente la interfaz AT del módulo a través de UDP y funciona de la siguiente manera:

* Escanea la red con una cadena de difusión UDP en el puerto 48899
* Los nodos responderán con IP,MAC,MID
* Responde con "+ok", el nodo entra en modo AT
* Ahora podemos ejecutar comandos AT arbitrarios
* Mantener un nodo en modo comando enviando AT+W a intervalos de 1 min, el nodo no aceptará otras peticiones de conexión durante 1 min
* Envíe AT+Q para salir del modo de comandos AT

La interfaz AT proporciona acceso a varios tipos de funcionalidades sensibles como:

* Actualización del firmware
* Obtener / Configurar datos de configuración Wi-Fi (incluyendo claves)
* Obtención/configuración de credenciales de servicio (por ejemplo, servidor web)
* Obtener / Configurar la configuración 'usuario' (información específica del dispositivo)
* Configurar el estado de los pines GPIO
* Navegar a URLs de forma similar a un proxy

Además, los fabricantes de equipos originales pueden añadir comandos específicos del dispositivo (como la actualización del firmware de los módulos o dispositivos conectados al módulo Wi-Fi, como el inversor fotovoltaico en el caso del kit SolarMAN).

La única protección para este servicio es una "contraseña" que hace las veces de cadena de descubrimiento de la red. La contraseña está codificada en el firmware y no puede modificarse y, dado que forma parte del protocolo de descubrimiento, no puede considerarse confidencial. Por defecto, esta contraseña es 'HF-A11ASSISTHREAD'.

En algunos casos (por ejemplo, los kits y tarjetas WiFi Omniksol) los OEM han cambiado esta contraseña, pero eso añade poca seguridad adicional, ya que basta con que un atacante obtenga una imagen del firmware del dispositivo, la aplicación móvil o la pasarela de integración y extraiga la contraseña. Los OEM pueden cambiar la contraseña en las nuevas versiones de firmware, pero esto rompería la compatibilidad con ciertas apps y herramientas que utilizan la interfaz para la detección de dispositivos y el atacante puede simplemente repetir el truco.

Extraer la contraseña AT para una imagen de firmware de un dispositivo basado en HF es sencillo e implica descomprimir el firmware (extraer el blob comprimido LZMA de la imagen U-boot) y obtener la contraseña hardcodeada de la imagen descomprimida. Esto puede hacerse de una forma "inteligente" (cargándola en IDA, identificando la función de autenticación de la interfaz AT con una firma FLIRT y encontrando la referencia a la contraseña) o de una forma fácil que utiliza el hecho de que para las imágenes basadas en eCos la contraseña siempre está encajada entre las mismas dos cadenas:

Como tal, el siguiente oneliner es suficiente para obtener la contraseña AT de una imagen de firmware basada en HF eCos:

Para las imágenes basadas en FreeRTOS, Contiki o mbed, el siguiente patrón parece venir después de la contraseña:

Lo que nos da el oneliner:

Resulta que los problemas con esta interfaz han sido descubiertos de forma independiente por múltiples partes que analizaban diferentes productos IoT en los últimos años, como los enchufes inteligentes CSL y Orvibo S20 y las bombillas Wi-Fi Flux, LimitlessLED y Zengge, con algunos trabajos previos que mostraban cómo cosechar SSID y claves de dispositivos basados en Hi-Flying orientados a Internet y luego geolocalizar las redes en cuestión.

IOTService / IOTManager

El protocolo IOTService es utilizado por la herramienta y la aplicación IOTService para descubrir y configurar los dispositivos Hi-Flying basados en Eport y Wport. Es muy similar a la interfaz AT y esencialmente expone la CLI de HF, que también puede estar disponible a través de telnet, envuelta en JSON en el puerto 48899/UDP sin autenticación. La comunicación la inicia un cliente que envía un mensaje de descubrimiento de difusión, tras lo cual los nodos responden con la información de su dispositivo y el cliente puede empezar a enviar comandos CLI envueltos en JSON. La funcionalidad expuesta es similar a la de la interfaz AT y permite volcar y cambiar las credenciales Wi-Fi y de servicio, modificar el firmware, etc.

Para ilustrar cómo se puede abusar de este protocolo elegí como objetivo el convertidor / pasarela serie Hi-Flying HF2211.

Los convertidores / pasarelas serie se utilizan en diversos entornos (como la automatización industrial y de edificios) como interfaz entre diferentes protocolos serie (por ejemplo, buses de campo sobre RS-232 o RS-485) y Ethernet, y suelen conectarse a equipos de automatización (como PLC) o dispositivos de campo. Estos convertidores han sido históricamente muy inseguros y los productos de Hi-Flying no son una excepción en este sentido.

El HF2211 se basa en la serie de módulos Wport y, al igual que otros dispositivos basados en Hi-Flying, configura por defecto un AP abierto denominado 'HF2211_XXXX', donde XXXX son los 2 últimos bytes de la MAC. El HF2211 ejecuta eCos en un SoC Ralink RT5350f MIPS y expone los siguientes servicios:

* 23/TCP, Telnet (Eport/Wport CLI)
* 53/UDP, DNS
* 80/TCP, HTTP
* 8899/TCP, Servicio de convertidor serie
* 48899/UDP, IOTService

Utilizando la herramienta de gestión IOTService e interceptando el tráfico (no autenticado, en texto plano) podemos analizar el protocolo y construir nuestros propios scripts para volcar las credenciales WiFi o modificar el firmware del convertidor para llevar a cabo ataques MITM eficientes sobre el tráfico serie procesado (y afectar así negativamente a los procesos industriales controlados por él).

Acerca de esos inversores

Muy bien, volvamos a esos inversores solares que iniciaron esta investigación. Como vimos, un atacante con acceso a una de las interfaces de gestión del kit WiFi puede descargar una nueva imagen de firmware a los inversores conectados a través de la conexión serie. Y dado que no hay ningún mecanismo de autenticación del firmware en el inversor podemos realizar modificaciones arbitrarias, que van desde brickearlos hasta acciones más sofisticadas.

Afectar a la estabilidad de la red eléctrica

Los inversores solares existen para convertir la salida variable de corriente continua (CC) de los sistemas fotovoltaicos en una corriente alterna (CA) de frecuencia de servicio que pueda alimentar una red eléctrica comercial o una red eléctrica local "aislada". La energía así generada puede inyectarse directamente en la red eléctrica, como sería el caso de un parque solar comercial, o puede utilizarse para abastecer las demandas de consumo eléctrico de los hogares, ya sea directamente, inyectando en la red sólo la energía sobrante, o indirectamente, haciendo que los equipos de medición neta ayuden a liquidar la factura.

El equilibrio entre la oferta y la demanda de energía es crucial para el buen funcionamiento de la red a fin de evitar la inestabilidad. Los sistemas fotovoltaicos influyen en el equilibrio de la red en forma de disminución de la demanda y aumento de la oferta, normalmente alimentando directamente las necesidades locales y vertiendo el exceso de energía a la red. Los inversores solares son fundamentales en este caso para mantener el equilibrio entre la generación de CC del conjunto o conjuntos solares y la carga de CA del hogar y de la red eléctrica. Los picos o caídas de tensión debidos a eclipses solares, nubosidad, averías temporales o picos de producción (por ejemplo, a mediodía) se solucionan mediante una combinación de planificación anticipada por parte de las empresas de suministro, provisión de amortiguadores y capacidad de intervención, e inversores que se aseguran de que la tensión, la frecuencia y la fase de la onda sinusoidal de CA de la red coincidan con precisión, suavizan las fluctuaciones y proporcionan capacidad antiisla desconectándose de la red si ésta se cae para garantizar la seguridad de los trabajadores de la empresa de suministro.

Como se señala en trabajos anteriores sobre este tema (https://www.mdpi.com/1996-1073/12/4/725/pdf), (https://horusscenario.com/), un atacante con suficiente control sobre la funcionalidad de un inversor (por ejemplo, mediante la descarga de firmware modificado) podría manipularlo para afectar potencialmente a la estabilidad de la red. Un atacante podría tratar de manipular la potencia de salida del inversor (y afectar potencialmente al sistema de gestión de la batería) para provocar una caída del suministro global, así como afectar negativamente a la(s) compensación(es) financiera(s) individual(es) recibida(s) por la potencia suministrada a la red o tratar de inyectar una potencia excesiva y/o manipular la tensión para amplificar estados indeseables de la red.

Por supuesto, no hay que subestimar la complejidad de este tipo de ataques. Además de la presencia defensiva de los sistemas de protección de la red y de la intervención de los operadores, un ataque de este tipo requeriría escala y coordinación. Estos factores, a su vez, se ven influidos por el grado de penetración de la energía solar en las fuentes de generación de energía de la red general y el control de los atacantes sobre una parte significativa de los inversores fotovoltaicos, influido este último, a su vez, por la heterogeneidad y la exposición de la solución del inversor.

En cualquier caso, incluso en ausencia de demostraciones reales de viabilidad en bancos de pruebas representativos, el endurecimiento de los sistemas conectados que sustentan diversos recursos energéticos distribuidos (DER) como la energía solar, eólica, de biomasa y pequeñas centrales hidroeléctricas es de crucial importancia para los esfuerzos de endurecimiento de la red general.

Afectar a la seguridad de los inversores

Otro escenario potencialmente malicioso implicaría que un atacante modificara el firmware del inversor para afectar negativamente a la seguridad, por ejemplo provocando un incendio. Queda por demostrar si es posible o no provocar de forma fiable un incendio en un inversor únicamente a través de medios de software y, como tal, se requiere cautela a la hora de juzgar el realismo de este escenario, pero dado el grado típico de control del firmware del inversor sobre los ventiladores internos, los monitores de temperatura de ajuste de voltaje, etc. un escenario como ese no está fuera del ámbito de las posibilidades.

Las causas más comunes de los incendios de inversores son la formación de arcos y el calentamiento resistivo (ya sea como precursor de la formación de arcos o por sí mismo, que suelen ser el resultado de una fabricación y/o instalación deficientes, las condiciones ambientales y el envejecimiento de los componentes. Para afectar negativamente a la seguridad de los inversores sería necesario que un atacante indujera artificialmente una avería en los materiales (por ejemplo, mediante calentamiento resistivo y altas temperaturas ambiente) como precursor del arco o como causa directa de la ignición, además de superar mecanismos de seguridad como los detectores de fallos de arco y la supervisión de la temperatura.

Funcionamiento interno del firmware de los inversores Omnik

Existen varias líneas diferentes de inversores Omnik pero, en términos generales, todos disponen de firmware para un módulo CPU maestro, un módulo CPU esclavo y un módulo de visualización. Para ilustrar las partes internas del firmware, echemos un vistazo al inversor trifásico sin transformador Omniksol-13k/17k/20k-TL.

Los módulos maestro y esclavo se basan en el TMS320F2802x que ejecuta el RTOS Micrium µC/OS-II, con cadenas en el firmware que insinúan una relación de cadena de herramientas con el módem de comunicación de línea de potencia de frecuencia única (SFPLC) TMS320C2000. El módulo de visualización se basa en el microcontrolador AT91SAM9261 que ejecuta Windows CE.

Como podemos ver en los fragmentos de desmontaje anteriores, el firmware tiene un control granular sobre una amplia gama de funcionalidades, desde el ventilador, la salida del inversor y varios aspectos de la sincronización con la red hasta el seguimiento del punto de máxima potencia (MPPT), lo que permite a un atacante capaz de modificar el firmware ajustar maliciosamente las operaciones del inversor de forma muy precisa. Si esto es realmente suficiente para lograr los resultados deseados requeriría más investigación.

Conclusión

Aunque el impacto potencial de las vulnerabilidades comentadas en los inversores solares conectados y los convertidores en serie es preocupante, no son el verdadero problema de esta historia. Es (o debería ser) de dominio público que la mayoría de los sistemas integrados conectados (ya sean de consumo o industriales IoT) suelen ser lamentablemente inseguros y en la última década también ha aumentado la awareness sobre los "ataques ciberfísicos", en los que los problemas de seguridad en el mundo digital afectan directamente al ámbito físico.

En mi opinión, el aspecto más preocupante aquí es la ilustración de los efectos perjudiciales de la opacidad de la cadena de suministro sobre la gestión de la vulnerabilidad. Las complicadas cadenas de suministro en los sistemas integrados conectados implican a muchos actores a través de muchos niveles que suministran e integran diferentes componentes de hardware y software, desde SoC y bibliotecas hasta el mismo producto que acaba en múltiples OEM diferentes que realizan una personalización mínima antes de pasarlo a otra capa de revendedores que básicamente le ponen un nuevo logotipo. Una vulnerabilidad en cualquier componente y a cualquier nivel puede "filtrarse" por una cadena de suministro cada vez más opaca hasta acabar en equipos ICS, terminales de punto de venta y muñecas conectadas a Internet por igual, y cuanto más arriba se originan las vulnerabilidades en la cadena de suministro, más amplia es la gama de productos a los que tienden a ir a parar y más difícil resulta rastrearlas y mitigarlas sin la colaboración activa de todas las partes implicadas. Un ejemplo: si cree que vulnerabilidades como Broadpwn, Blueborne, Devil's Ivy, Shellshock o Heartbleed ya no pueden encontrarse en la naturaleza porque las partes directamente responsables del código vulnerable publicaron un parche, se llevaría una desagradable sorpresa.

Dado que no hay una única entidad que supervise todo el ciclo de vida de desarrollo y mantenimiento del software, a menudo no existe un conjunto único y coherente de requisitos de seguridad y cuanto más se asciende en la cadena (como los vendedores de SoC o RTOS), más amplia es la base de clientes a la que hay que atender y eso suele significar atender al mínimo común denominador en términos de capacidades, gastos generales y limitaciones de costes. Además de eso, no existe una entidad única clara que tenga la capacidad de emitir parches de forma directa y centralizada para cualquier vulnerabilidad dada en el producto final. En su lugar, los fabricantes de equipos originales tienen que esperar a que sus proveedores (o los proveedores de sus proveedores) emitan sus propios parches y los integren en nuevas versiones de firmware que luego pueden distribuir a sus clientes, quienes a menudo se ven obligados a aplicarlos manualmente a todos los productos afectados (o confiar en algún pequeño proveedor de IoT con capacidades arbitrarias de actualización de firmware en un montón de dispositivos de sus redes, lo que podría ser peor.

En resumen, lo que se necesita es un enfoque más holístico de la seguridad de la IO que abarque todos los aspectos relevantes del ciclo de vida del producto y garantice que los productos cumplen una línea de base mínima común.

Calendario de divulgación de vulnerabilidades:

* 6 de octubre de 2018 - Primer informe a Hi-Flying
* 26 de mayo de 2019 - Informes a SolarMAN y Omnik, así como a NCSC-NL
* 26 de mayo a 22 de julio de 2019 - NCSC-NL intentó ponerse en contacto con los fabricantes pero no hubo respuesta, escalada a CNCERT/CC
* 15 de agosto de 2019 - Aún sin respuesta de ningún fabricante, decisión de publicar

Gracias a Peter-Jan Pinxteren por detectar los AP abiertos originales y establecer el vínculo con los kits de conectividad Omnik.