Español | English
rss facebook linkedin Twitter

Protocolos SCADA y seguridad

Dedicaremos estas líneas a una de las partes mas vulnerables de las redes SCADA: los protocolos de comunicación.

A pesar de su función crítica raramente incorporan mecanismos de seguridad. Los protocolos están diseñados para ser eficientes y determinísticos, pero no seguros. Tradicionalmente la “seguridad por oscuridad” ha sido su mejor protección al ser protocolos muy especializados. Esto nunca ha sido buena idea, menos aún hoy en día debido a la progresiva migración hacia protocolos estandarizados y bien documentados.

Casi ningún protocolo de comunicación industrial incorpora en su especificación mecanismos de seguridad. Esto hace que desde el punto de vista de la intrusión, la confidencialidad o la integridad, las redes SCADA sean inseguras por su propia naturaleza.

A esto hay que añadir que los protocolos SCADA están sujetos al mismo tipo de técnicas de ataque que por ejemplo SMTP, HTTP o FTP: DoS, buffer overflows, etc…. Ningún fabricante de dispositivos SCADA está exento de tener los mismos errores de programación que Cisco o Microsoft.

La robustez en la implementación del protocolo es esencial a la hora de implementar redes seguras, algo no siempre tenido en cuenta en el diseño de equipamiento SCADA. El tratamiento de los errores suele ser deficiente y ello deriva en reinicios o denegaciones de servicio como consecuencia de, por ejemplo, escaneos o auditorías.

Existe en la industria una gran variedad de protocolos que permiten comunicar los dispositivos SCADA entre sí y con los centros de control. A continuación comentaré cuatro de los mas usados actualmente y algunas consideraciones respecto de la seguridad:

DNP3: Es un protocolo diseñado específicamente para su uso en aplicaciones SCADA. Permite a las Unidades Centrales ó MTU (Master Terminal Unit) obtener datos de las RTU (Remote Terminal Unit) a través de comandos de control predefinidos. El protocolo no fue diseñado teniendo en cuenta mecanismos de seguridad, por tanto carece de cualquier forma de autenticación o cifrado. Puede ir encapsulado sobre TCP/IP.
Una nueva versión del protocolo llamada DNPSec ha sido diseñada para incluir confidencialidad, integridad y autenticación sin mucho impacto en las implementaciones DNP3 ya existentes. Para su implementación sería necesario establecer, a semejanza de IPSec, directivas de seguridad que identifiquen algoritmos criptográficos y de autenticación, así como parámetros comunes para la comunicación entre aplicaciones.

ICCP (IEC 60870-6): Este protocolo es uno de los mas usados en los sistemas SCADA/DCS de compañías de generación y distribución de energía. Es un protocolo especialmente adaptado a las necesidades de comunicación de las compañías eléctricas. Proporciona conectividad entre subestaciones y centros de control y supervisión. El intercambio de datos consiste típicamente en monitorización en tiempo real, datos de control, valores de medida, programación, contabilidad y mensajes de operador.
Tradicionalmente vulnerable a ataques DoS debido a deficiencias en el código de la pila ICCP de muchos servidores. Al igual que la mayoría de los protocolos actuales SCADA, también es atacable por spoofing.
Un servidor ICCP con una vulnerabilidad, permitiría a un atacante tomar control del servidor de la organización y de todos los servidores ICCP que se comunican con él.

Modbus: Protocolo de la capa de aplicación empleado sobre RS-232, RS-422, RS-485 o TCP/IP. La principal ventaja es su simplicidad y es ampliamente usado en procesos de control de sistemas SCADA.
Para el caso de redes Ethernet existen dos especificaciones: MODBUS Plus y MODBUS/TCP. A destacar en el modelo de arquitectura MODBUS/TCP el módulo ‘Access Control Module’, pensado para restringir el acceso a servidores desde determinados clientes en entornos críticos. Se basa en listas de IP autorizadas.
Una de las vulnerabilidades aprovechables por los atacantes es la posibilidad de hacer fingerprinting a través de su puerto standard TCP/502. Mediante la función 43 del protocolo puede leerse el registro de identificación de PLCs y conseguir información del tipo de dispositivo, fabricante, versión y otras informaciones útiles para posteriores ataques.

OPC (OLE for Process Control): Es una interfaz estándar de comunicación usada en la industria de control de procesos. Está pensada para garantizar la interoperabilidad entre equipamiento de distintos fabricantes. Permite la comunicación entre aplicaciones de control y de supervisión con independencia de la red que haya por medio. Requiere que cada fabricante proporcione un driver genérico OPC. La mayoría de los fabricantes de HMI incluyen soporte para OPC.
Se basa en los estandares de Microsoft OLE, DCOM y RPC. El problema viene porque estos componentes de Microsoft han sido tradicionalmente fuente de agujeros de seguridad. Aunque los actuales esfuerzos de estandarización tienden a protocolos basados en web independientes del Sistema Operativo, la mayor parte de lo ya instalado se basa en el original ‘OLE for Process Control’ de Microsoft.
Un atacante que sepa del uso de OPC intentará aprovecharse de alguna de las conocidas vulnerabilidades de los servicios DCON y RPC. Mas aún sabiendo de la dificultad de los sistemas de control industrial para implementar actualizaciones.

En conclusión, una red SCADA será tan segura como mecanismos de seguridad incorporen sus protocolos o puedan aplicarse a los mismos. De nada sirve un firewall si no puede actuar sobre un determinado protocolo; como tampoco querer autenticar o cifrar el intercambio de datos sin la existencia de mecanismos intrínsecos de intercambio de claves.

Aquí he hecho referencia solamente a una pequeña parte de los protocolos utilizados en infraestructuras críticas. Todos ellos con sus propias particularidades en cuanto a comunicación cliente/servidor, temporizaciones, codificación y formateo de datos. De aquí la complejidad a la hora de dar soluciones genéricas de seguridad a este tipo de redes.

César Fernández Lorenzana

S21Sec Labs

4 comentarios:

Julio Cesar Fort dijo...

(En primer lugar, lo siento por mi español)

César, como usted deve saber hay firewalls específicos para Modbus y otros protocolos SCADA. Entoces, "De nada sirve un firewall si no puede actuar sobre un determinado protocolo" es incompleta, no?

Saludos!

Anónimo dijo...

Estimado César, creo que aun te queda mucho que aprender de SCAD, para empezar puedes ver el pst de Daniel http://blog.s21sec.com/2008/12/ideas-errneas-en-sistemas-scada.html y entonces podrás darte cuenta de que aun no tienes claro que es un firewall de aplicacion y que tipo de aplicaciones son capaces de analizar.
Para ser un becario estas algo verde, creo que S21 merece mas nivel en su blog.

Elyo dijo...

La frase que Julio cree incompleta a mi entender sí es acertada. De poco o de nada sirve instalar un firewall de nivel de red que sólo sea capaz de filtrar el puerto 502 (Modbus/TCP) si no es capaz de filtrar por el contenido del protocolo Modbus, es decir, si no sabe interpretar este protocolo.

Es cierto que en la actualidad ya existen extensiones en firewalls de aplicación que permiten inspeccionar estos paquetes, pero creo que la frase no quería entrar a tratar este tema. Os dejo un link que puede resultaros interesante: http://modbusfw.sourceforge.net/

Anonimo, da la sensación de que piensas que la solución pasa por los firewalls a nivel de aplicación. No hay que olvidar que no todos los protocolos SCADA están a nivel 7, por lo que los firewalls de aplicación no son suficientes. Por ejemplo DNP3 es un protocolo que actúa principalmente a nivel 2, es decir, a nivel de control del enlace. De hecho realiza control de errores, direccionamiento a nivel 2, multiplexado, etc. Para un caso así, el firewall primero debería saber interpretar el tráfico.

Luis dijo...

interesante tema quien diria que los sistemas SCADA son vulnerables ... con que finalidad se apoderarian de un proceso???

interesante el tema


(+34 902 222 521)


24 horas / 7 días a la semana



© Copyright S21sec 2013 - Todos los derechos reservados


login