Español | English
rss facebook linkedin Twitter

IDS en sistemas SCADA

Como todos sabéis los Sistemas de Detección de Intrusiones (IDS) resultan de gran utilidad a la hora de detectar anomalías en el funcionamiento de una red o un host y que podrían ser indicios de la presencia de un atacante en nuestro perímetro de seguridad. Para aquéllos que quieran realizar un rápido repaso sobre estos sistemas les recomiendo la lectura de este artículo de nuestro compañero Aitor Corchero.

Hacía tiempo que quería compartir con todos vosotros algunas ideas sobre el uso de estos sistemas en los entornos SCADA. DigitalBond, empresa puntera en la seguridad en SCADA y responsable de la organización del congreso S4, hace tiempo que ya proporciona firmas para Snort que permiten detectar posibles intentos de ataque que aprovechan las carencias de seguridad de protocolos SCADA estándar. Como ya sabéis, estos protocolos estándar y también una gran mayoría (por no decir la totalidad) de los protocolos de comunicaciones utilizados en sistemas SCADA no proporcionan mecanismos para la autenticación de los mensajes, el cifrado de los datos o la firma de los mismos. Por lo tanto no garantizan la integridad, la autenticidad ni la confidencialidad en las comunicaciones.

Pero, y ¿qué ataques pueden ocurrir para cada uno de estos protocolos?, ¿es posible detectar estos ataques con un IDS?, ¿en qué se basan las firmas para hacerlo? A continuación voy a analizar los fundamentos de algunas de estas firmas y después os contaré algunas consideraciones interesantes que se comentaron dentro del congreso S4.

Voy a centrarme en uno de los protocolos más simples, Modbus, como punto de partida para contaros en qué se basan las firmas que permiten detectar alguno de los ataques posibles para este protocolo. Modbus es un protocolo de nivel de aplicación que se basa en el principio maestro/esclavo, donde solo el dispositivo maestro inicia una transacción (petición y respuesta a/de un dispositivo esclavo). Los comandos de control de este protocolo se denominan funciones y las hay de siete tipos: lectura/modificación del valor de una o varias bobinas (salida digital), lectura del estado de una/varias entradas digitales, lectura/escritura de registros de entrada/salida (valores analógicos), tests de diagnóstico, de programa, control del sondeo realizado por el dispositivo maestro y reset.

A continuación os expongo tres ejemplos de posibles ataques aprovechando las carencias de seguridad de Modbus y cómo deberían plantearse las firmas de un IDS para detectarlos:

Comando ilegítimo de "forzado del modo de solo escucha (listen-only mode)": Esta función es una función de diagnóstico que se usa muy raramente durante la instalación de un nuevo componente o también a la hora de resolver algunos fallos. Básicamente hace que el dispositivo esclavo no ejecute ningún comando que reciba con posterioridad y no se generen respuestas de tipo alguno (Ej. envío de las lecturas de un sensor que mide la presión en una tubería). Imaginemos ahora un atacante que consiga introducir un cliente Modbus en la red SCADA y que envíe a todos los dispositivos de la red este comando generando una denegación de servicio en cada uno de ellos; el caos sería total. Una posible firma consistiría en detectar mensajes Modbus que incorporasen el código y subcódigos de función correspondientes (código 08 – función de diagnóstico, subcódigo 04 – forzado del modo de solo escucha). Esto generaría una alerta que el operador de seguridad debería validar para descartar falsos positivos.

Reinicio de las comunicaciones: Un operador, para devolver el estado normal a un dispositivo al que se le ha enviado un comando de solo escucha debería enviar un comando de este tipo: reinicio de comunicaciones. Pero, ¿y qué ocurriría si fuera un atacante quien lo hiciera y de manera repetitiva contra cada uno de los dispositivos esclavos? Básicamente, lo mismo que en el caso anterior: una denegación de servicio permanente. En este caso el código de función a detectar es de nuevo el 08, por ser una función de diagnóstico y el subcódigo el 01, que indica el reinicio.

Solicitud de escritura en una dirección de memoria no válida: Imaginemos que se envía un comando de este tipo para modificar el valor de un registro de mantenimiento (holding register) al que está conectado el selector de voltaje de un transformador en una subestación eléctrica. Si resulta que la dirección seleccionada no es la correcta, la RTU esclava se "queja" enviando un mensaje de excepción con código 02 (dirección ilegal). No es lógico detectar un mensaje de este tipo en una red que está en producción puesto que los comandos de supervisión se envían desde un HMI en el que las acciones están más que acotadas y donde las direcciones de memoria sobre las que se puede actuar en cada equipo de la red están perfectamente definidas. Así pues, lo lógico es que el IDS que incorpore esta firma genere una alerta para que se tenga en cuenta por el responsable de seguridad de la instalación.

Existen muchas otras firmas posibles, que por no alargar indefinidamente el post dejaré para vuestra imaginación. No obstante, antes de terminar querría compartir con vosotros otra técnica para la generación de alarmas por un IDS de red para SCADA que pudimos ver durante el S4 del pasado mes de enero. En realidad tiene que ver con las limitaciones que impone la interfaz humana (HMI) en cuanto a tiempos entre mensajes de control. Un cliente ilegítimo instalado en la red podría intentar enviar comandos de control de supervisión a alguna unidad remota de manera automática. Los tiempos entre mensajes, si estos se generan automáticamente, estarán determinados por el propio programa y serán de un orden de magnitud muy pequeño, comparando con los tiempos entre mensajes de un operador que se dedica a mandar la misma secuencia de comandos desde su interfaz gráfica (haciendo primero click para seleccionar el dispositivo, posteriormente seleccionando de un desplegable la acción y finalmente presionando al botón de "ejecución"). En realidad esta técnica de detección es fácil de burlar: basta con saber los tiempos y modificar el código de tu cliente Modbus para que introduzca los retardos adecuados entre cada comando.

Esto es todo de momento. ¿Se os ocurre alguna otra firma posible para SCADA? ¿Consideráis que los falsos positivos pueden suponer más quebraderos de cabeza que una ventaja desde el punto de vista de la seguridad?


 

Elyoenai Egozcue

S21sec labs


 


(+34 902 222 521)


24 horas / 7 días a la semana



© Copyright S21sec 2013 - Todos los derechos reservados


login