Intentan envenenar agua de un planta depuradora en UK

Los ataques a los sistemas SCADA utilizados en el control industrial es algo que puede tener consecuencias graves si no se han hecho los deberes de seguridad adecuados. Los sistemas industriales utilizados en estos entornos están formados por una buena cantidad de componentes de distintos fabricantes, PLCs, protocolos especiales y sistemas que a veces pasan muchos años antes de ser cambiados - o tan siquiera actualizados -. Y por supuesto, tienen vulnerabilidades que aparecen en sistemas PLCs [PLCs exponen passwords, PLCs vulnerables a Brute-Force]  en el equipamiento utilizado en la construcción del sistema y en el software que se haya desarrollado a medida para dicha plataforma.

Figura 1: Intentan envenenar el agua en una planta depuradora en UK

Es un ecosistema complejo del que hay que preocuparse con cariño. Nuestro compañero en Eleven Paths Claudio Caracciolo (@holosec) conoce a la perfección estos entornos por su experiencia trabajando con ellos,  y nos explicó en detalle cómo funciona en la charla que impartió dentro de las Eleven Paths Talks y que puedes ver online ya.

Figura 2: Comprendiendo la seguridad en sistemas industriales

Dicho esto, hoy quería centrarme en un caso explicado en el último informe Data Brech Digest publicado por Verizon, en el que cuentan cómo fue la investigación para descubrir el ataque que se había producido a un planta depuradora de agua de un distrito en Reino Unido. Los equipos de gestión del funcionamiento de la planta depuradora se dieron cuenta de que algo había pasado cuando saltaron las alarmas de control que vigilan que nada vaya mal en la planta al detectarse que la mezcla de componentes químicos que se estaba usando podría dañar la salud de las personas que la bebieran.

Figura 3: Intento de configurar agua "no potable" variando los compuestos químos

Esto sucede porque los sistemas SCADA se crearon para ayudar a los ingenieros a tomar las decisiones de seguridad más adecuadas, pero además del sistema informatizado y automatizados existen controles que verifican que ningún fallo provoque una situación no deseada, como la de que el agua que se entrega a los usuarios sea de mala calidad y nociva para su salud.

Errores en la gestión de la seguridad de la planta depuradora

Tras la investigación realizada por el Equipo de Respuesta ante Incidentes, la explicación resulto ser la acumulación de una serie de BASICS de seguridad no realizados por la empresa que gestiona el IT de la planta de seguridad y que os paso a resumir a continuación.

1) Arquitectura no segmentada de la red

La empresa cuenta con una aplicación web/mobile a la que los clientes se pueden conectar para la gestión de sus cuentas y sus pagos. Esto está alojado en un servidor web, pero que tiene conexión directa con el servidor SCADA, basado en un AS/400 (que también debería fortificarse). Este servidor AS/400, además, tenía conexión de a Internet, por lo que una vez llegado a él se podría sacar datos. Llegando a un servidor, es fácil acceder a las credenciales de acceso a otros servicios, incluso acceder a las passwords de gestión de los PLCs e incluso mucho más fácil, ya que puede que haya sistemas PLC sin passwords o fácilmente saltables.

Figura 4: Arquitectura de red de los sistemas de la planta. Desde el AS/400 acceso a todo.

2) Aplicación de pagos con mala gestión de identidades

Cualquier cliente de la empresa se podía conectar al sistema de pagos con un sistema de credenciales basado en usuario y contraseña, sin que hubiera ninguna protección de Segundo Factor de Autenticación o Autenticación Robusta, lo que permitía a un atacante hacerse fácilmente con alguna cuenta de usuario con ataques simples de phishing, troyanos, etcétera.

3) Aplicación de pagos con vulnerabilidades en el código del backend

La aplicación de pagos no estaba correctamente auditada y desde la sesión de un usuario era posible explotar bugs en el backend que permitieran acceder a los ficheros del servidor. No se sabe si la vulnerabilidad permitía subir una shell, era un ataque de LFI, o un Directory listing, pero con este fallo se podía acceder a los ficheros del servidor.

4) Credenciales de acceso al sistema SCADA en AS/400 sin 2FA

De nuevo, el acceso al sistema SCADA utilizaba usuarios y contraseñas sin ninguna protección de Segundo Factor de Autenticación, así que cualquiera que se hiciera con las credenciales podría entrar a manipular el servidor.

5) Credenciales almacenadas en el servidor de la aplicación de pagos

Como sucede en muchos casos, las herramientas de adminsitración de servidores permiten guardar información de las conexiones que realizan los técnicos para que sea cómodo acceder a ellos a golpe de clic. Según parece, en el servidor de la aplicación de pagos había un fichero .INI con las credenciales del sistema SCADA, así que una vez accedido a los ficheros del servidor fue fácil obtener el acceso al sistema SCADA.

Figura 5: Cúmulo de fallos en la gestión de las credenciales de acceso a los sitemas

6) Reutilización de credenciales en distintos sistemas

Al final, los atacantes se pudieron llevar la base de datos de los usuarios, ya que las credenciales funcionaban en otros sistemas conectados, como el servidor que hospedaba la aplicación financiera de la planta.

Por suerte, al manipular las cantidades de productos químicos con las que se hace la depuración del agua, las alertas de seguridad de la planta levantaron las alertas. De nuevo, un caso en el que el cúmulo de errores de seguridad lleva a que casi Security se convierta en Safety y haya un verdadero problema para los clientes de esta planta. Hay que agradecer que las Infraestructuras Críticas aplican conceptos de defensa en profundidad para no depender totalmente de un sistema informatizado y, en este caso, ha evitado una catástrofe.

Saludos Malignos!