Cabecera blog ciberseguridad

Contadores Inteligentes – Evaluando el riesgo del concentrador

Un elemento clave en toda infraestructura de telegestión es el concentrador.  Este dispositivo, ubicado entre la red PLC a la que se conectan los contadores inteligentes y la red IP de la distribuidora, realiza las siguientes funciones:

  • Detección de los contadores en cada una de sus fases (los concentradores suelen disponer de alimentación trifásica)
  • Recepción de datos de consumo
  • Envío de órdenes y solicitudes de informe a los contadores
  • Conexión con el servidor FTP de almacenamiento de medidas
  • Aceptación de órdenes de telegestión (STG-DC)

Este dispositivo no suele estar expuesto a Internet. En particular, se suele encontrar en las casetas de los centros de transformación de los barrios donde haya contadores inteligentes, conectados a una red privada responsabilidad de la empresa distribuidora. Esto quiere decir que, para comprometer la seguridad lógica de estos concentradores se debe comprometer primero la seguridad física de estas casetas. Desgraciadamente, esto último no se puede considerar una medida de seguridad en absoluto.

Asumiendo que el atacante ha podido acceder físicamente al concentrador, podemos repetir la misma metodología para dar una cota inferior de los riesgos de este tipo de dispositivo.

Respecto de la detección de contadores, el riesgo principal tendría que ver bien con los ataques de denegación de servicio (algo que se podría hacer desde la propia red PLC del hogar si los contadores no cuentan con las adecuadas medidas de filtrado) o con la introducción de contadores ficticios.  

El riesgo, para un contador en particular, es en general alto o crítico debido a la naturaleza de los despliegues PLC: una fuente de alimentación conmutada mal diseñada puede inundar el cable de armónicos de la conmutación, muchos de los cuales entrarán en las bandas CENELEC por las que discurren este tipo de comunicaciones, convirtiéndose en un jammer accidental. Para toda la red, el riesgo se puede evaluar como medio debido a que hace falta estar relativamente cerca del concentrador y controlar las tres fases en las que trabaja. Aún así, debido a la inexistencia de un aislamiento adecuado en las líneas de suministro, inyectar ruido en la línea mediante acoplamiento inductivo sigue siendo posible. 

Respecto de la recepción de medidas de consumo, el riesgo principal estaría relacionado con la inyección de medidas falseadas, tanto desde el atacante como suplantando la identidad de otros contadores. Desde el punto de vista de la privacidad, existe también el riesgo de que un atacante capture las medidas de consumo de otros contadores. 

Respecto de la conexión al servidor FTP, el principal riesgo es el FTP mismo. FTP es en general un protocolo inseguro, y los riesgos pasarían desde el robo de las credenciales del servidor, hasta la suplantación de la identidad del servidor FTP, incluyendo riesgos no sólo a la privacidad de los datos sino también a la integridad de los mismos.

Y respecto de la aceptación de órdenes de telegestión, existiría el riesgo de un acceso no autorizado a este servicio. Nótese que el protocolo del sistema de telegestión (STG-DC) desarrollado por Iberdrola obedece a un estándar cerrado, y cuya especificación debe ser solicitada explícitamente a esta compañía.

La pregunta que cabe hacerse ahora es, ¿cuántos de estos riesgos se pueden convertir en amenazas reales? Para responder esta pregunta tendremos que acudir a nuestro pequeño laboratorio y auditar el concentrador. Vamos a ello.

Auditando un concentrador

Como se dijo antes, un concentrador dispone (como mínimo) de conectividad en dos extremos: un extremo PLC utilizado para interactuar con los contadores, y un extremo IP para comunicarse con la distribuidora. La prueba más evidente que se puede hacer es, simplemente, introducirse en el enlace módem-concentrador, y realizar un escaneo de puertos contra el concentrador mediante nmap. En el caso del concentrador Telecon TL-3001 encontramos un resultado como este:

nmap concentrador red electrica

Lo cual revela un mínimo de 4 líneas de investigación: 

Puertos SSH

El puerto Ethernet del concentrador expone varios servicios, entre los que se encuentra un servidor SSH en funcionamiento contra el cual la autenticación no ha sido posible. Se ha podido evidenciar también que el servidor SSH hace validación de la clave pública del cliente. Como este servicio no está documentado y no hay forma de establecer esta clave desde el portal de administración, es posible que se trate de un servicio de mantenimiento reservado al fabricante. Sin embargo, la presencia del mismo no debería ser evidente: un bastionado adecuado debería ocultar la presencia de este servicio a un atacante.

Servicio FTP

El objetivo de este servicio FTP es el de ofrecer una interfaz simple al hipotético sistema de telegestión para poder acceder a las medidas acumuladas del conjunto de contadores conectados al concentrador.  Sin embargo, la presencia de un servicio FTP es una debilidad en sí misma: FTP es un protocolo antiguo y en texto plano, en el que ni la autenticación está protegida. Toda la seguridad está delegada en la red a la que pertenece. Si esta red no está protegida, un simple MITM realizado en un ciclo de 24 horas bastaría para obtener dichas credenciales.

Aún así, no hay indicios de que este servicio sea un estándar: es posible que distintos fabricantes implementen el acceso a estas medidas de distinta forma, lo cual aportaría cierto margen de elección a las distribuidoras a la hora de decidir el concentrador que mejor se adecúa a sus requisitos. 

Viejos conocidos

Interfaz de administración y credenciales por defecto

En el mismo puerto Ethernet, se expone el portal de la interfaz de administración del contador, autenticada por usuario y contraseña. Las credenciales por defecto son los ya conocidos admin:admin:

panel de autenticación del concentrador

Afortunadamente y como cabría esperar, estas credenciales pueden ser modificadas de acuerdo a la política de contraseñas de la distribuidora.

El misterioso protocolo de STG-DC

El protocolo STG-DC (Sistema de Telegestión – Data Concentrator) es un protocolo propietario diseñado por una distribuidora española, basado en SOAP, que permite la gestión remota de contadores por parte de la distribuidora comunicándose directamente con el concentrador. La especificación de este protocolo se encuentra en el documento “STG – DC Interface specification”, de acceso restringido a fabricantes. 

En principio, este protocolo mediaría entre el concentrador y un hipotético sistema de telegestión (provisto por terceros) el cual ofrecería a las distribuidoras una interfaz sencilla para poder efectuar estas tareas de forma integrada con su sistema de facturación y telemedida.

comunicación contador y distribuidora STG-DC

En el campo de la ciberseguridad, la correlación entre especificaciones cerradas y deficiencias en la seguridad es bien conocida, siendo el concepto de “seguridad por oscurantismo” algo terriblemente extendido en este tipo de protocolos. Por esta razón y la propia criticidad del protocolo, STG-DC se hace especial merecedor de un análisis de seguridad exhaustivo.

Para acercarnos a este protocolo partiremos de la siguiente hipótesis de trabajo: los endpoints SOAP se encuentran tras un servidor web, y este servidor web está expuesto a la red IP del concentrador. Efectivamente, si hacemos un escaneo de puertos sobre el concentrador, se puede encontrar un servidor web en el puerto 9090, diferente al portal de administración habitual.

escaneo de puertos concentrador

Aunque se desconoce la sintaxis exacta de las solicitudes de este protocolo, sí que se conocen las respuestas XML/SOAP a las mismas (las cuales se pueden encontrar incluso en el manual impreso del concentrador). En el caso más desfavorable, esto nos da una pista sobre su sintaxis y nos servirá de semilla para hacer bruteforcing del protocolo.

petición HTTP Soap

Tras varias pruebas mediante diccionario, se ha podido derivar las sintaxis de una solicitud de información a un concentrador y realizar una consulta con éxito. Como era de esperar, el protocolo no acepta ningún tipo de autenticación y responde a estas solicitudes sin problema.

Descubre nuestro trabajo y nuestros servicios de ciberseguridad en www.tarlogic.com/es/

En TarlogicTeo y en TarlogicMadrid.

Más artículos de la serie Contadores Inteligentes

Este artículo forma parte de una serie de articulos sobre Contadores Inteligentes

  1. Contadores Inteligentes – El escenario español y el sistema de Telegestión.
  2. Contadores Inteligentes – Amenazas a los contadores y ataques PRIME
  3. Contadores Inteligentes – Una prueba de concepto: secuestrando un contador
  4. Contadores Inteligentes – Evaluando el riesgo del concentrador
  5. Seguridad en las redes PRIME – Estado actual
  6. PLCTool, la navaja suiza de los contadores inteligentes
  7. Soporte para plugins en PLCTool