Amenazas sobre ICS (Parte I)

Como hemos podido comprobar en estos últimos años el número de ataques a Infraestructuras Críticas e Instalaciones Industriales ha ido en aumento. Aquellos buses de campo que hace tiempo atrás quedaban aislados de las redes empresariales poco a poco han ido incorporándose a ellas gracias a la implementación de protocolos de basados en TCP/IP. Si bien las funcionalidades y posibilidades han crecido esto ha generado a su vez que queden expuestas a actividades hostiles por parte de personas físicas o malware concreto para IACS. Así pues, esta visibilidad hace que debamos tomar más precauciones.

Inicialmente se hablaba del “air-gap” como medida de protección. Si bien puede resultar efectiva en algunos entornos, la implementación de ciertos servicios como monitorización y recolección de datos de los equipos de Automatización y Control obliga que éstos estén accesibles desde los sistemas SCADA y a su vez por los agentes y personal encargado de visualizar los datos en ellos representados. De esta manera, ha habido que adaptarse e implementar el concepto de “Defensa en Profundidad” como medida que más puede reducir los riesgos de que un ataque pueda ser satisfactorio.

En cualquier caso al margen de la estrategia de protección empleada cuanto más, expuestos estén nuestros sistemas de control, la amenza es mayor. Entendiendo por amenaza la posibilidad de que un evento o una acción determinada ocurra produciendo un daño material o inmaterial sobre los componentes de un sistema o un conjunto de ellos. Esto es, daños a nivel físico como lógico.

A modo general podríamos catalogar a estas amenazas en dos grandes grupos, intencionadas y no intencionadas. Si bien la mayor parte de ellas son de carácter no intencionado, aunque existe una claro aumento de las intencionadas.

Amenazas no intencionadas.

Las amenazas no intencionadas, podemos decir son todas aquellas que no son dirigidas deliberadamente contra el  sistema de control y automatización, pero que, por una u otra causa aún y así pueden ser un peligro para éstos. Normalmente, las amenazas no intencionadas están relacionadas con fenómenos que están fuera de nuestra capacidad de gestión.

Así pues es posible marcar una división entre aquellas que tienen un origen humano y las que no, estableciéndose entre todas, cuatro grandes grupos:

  1. Safety
  2. Fallos de equipamiento
  3. Desastres Naturales
  4. Humanos

FALLOS DE “SAFETY”

Por “safety” entendemos todas aquellas medidas que ayudan a evitar de un accidente, relacionándolo con términos como prevención, seguridad en el proceso, figuras de ingenieros industriales. Al tratarse de instrumentación mecánica y/o electrónica debido al uso, fatiga o deterioro de materiales, pueden provocarse daños en los sistema de control y automatización y por tanto, en el propio proceso industrial.

Estos fallos de los sistemas de “safety” no sólo incluyen los problemas que pueden tener los sistemas de protección tanto del equipamiento físico controlado (por ejemplo: interruptores,  dispositivos de emergencia, detectores de posición, etc.) sino también el personal que lo manipula (por ejemplo: técnicos de mantenimiento, retenes, etc.). Aquí os dejo un artículo publicado por INCIBE donde lo explica muy bien, picha aquí.

FALLOS DE EQUIPAMIENTO

Al igual que sucede con los sistemas de safety, los dispositivos de automatización y control son elementos hardware con muchos componentes electrónicos. Si bien se caracterizan por una gran robustez y durabilidad no están exentos de sufrir fallos como pueden ser avería de la fuente de alimentación, módulos de comunicaciones, agotamiento de recursos de memoria, etc. Sea cual sea la causa, la operatividad y disponibilidad de las instalaciones puede verse afectada hasta el punto de quedar inutilizable total o parcialmente.

DESASTRES NATURALES

Aquí quedan recogidos todos aquellos sucesos medioambientales con consecuencias graves o incluso fatales y cuyo origen difícilmente se puede predecir. Por citar alguno podríamos hablar de inundaciones, terremotos, incendios, o condiciones climatológicas fuera de lo habitual. Todos recordaremos el tsunami que azotó la costa oriental de Japón en el año 2011 en la que la central nuclear Fukushima se vio dañada con las consecuencias que aparejó. También en esa ocasión un gran número de servicios de Telecomunicaciones, presas hidroeléctricas, aeropuertos, y demás Infraestructuras Críticas se vieron gravemente afectadas o destruidas.

ERROR HUMANO

Suelen decir que la fortaleza de una cadena radica en el eslabón más débil.  Dentro de la estrategia de protección el ser humano juega un papel determinante y muchas veces con nuestras confianzas, descuidos o desidia, podemos comprometer toda la seguridad de nuestra protección. Ese USB que nos pasan y lo pinchamos sin haberlo pasado primero un antivirus o ese software descargado que viene con el “crack” y aparte de la licencia nos trae otro “regalito”. Así pues, dentro de este grupo hemos de considerar los fallos producidos por descuidos o negligencias. Hablamos de memorias, pero no nos olvidemos de la existencia de otro tipo de dispositivos como los teléfonos móviles… Ya el error no es esa nota autoadhesiva con el usuario y contraseña debajo del teclado. Pero todo no son imprudencias, también puede ocurrir que sin, quererlo, nos podamos equivocar en la parametrización de un elemento  o en la carga de un fichero que no corresponde con el dispositivo en cuestión, y como es de esperar no funcione como se espere.

Como hemos podido ver, no siempre las amenazas vienen de la mano de personas o sistemas con ánimo de provocar un daño sobre nuestra organización. Muchas veces sin desearlo podemos sufrir accidentes, que cuyas consecuencias pueden ser mayores que un ataque dirigido y estudiado durante meses.

Como era de esperar próximamente hablaré de esas otras amenazas, las intencionadas, donde hablaremos esas sí que sí están hechas con premeditación, alevosía y “nocturnidad”.

Un saludo nos vemos en la próxima!

Virtual Patching en funcionamiento (Parte II)

Siguiendo la entrada anterior Virtual Patching en funcionamiento (Parte I) vamos a seguir viendo los efectos del Virtual Patching pero en el caso frente a un escáner de vulnerabilidades.

Lo que vamos a hacer es lanzar uno desde una máquina virtual con Kali Linux hacia un Windows XP vulnerable. ¿Por qué un XP? Porque este sistema operativo está aún muy presente en muchos equipos en entornos industriales y debido al largo ciclo de vida de las estaciones o instalaciones que gobiernan, siguen funcionando a pleno rendimiento. Sin embargo, como sabemos ya no hay soporte y muchos de ellos no están parcheados, lo cual les convierte en un objetivo muy apetecible a malware y usuarios malintencionados. Ni qué hablar de Windows 2000 que también los he visto… Buenos, el esquema era el siguiente:

Como decía, en el post anterior trataba los resultados tras hacer un escaneo con Nmap. Ahora toca pasar a la siguiente etapa dentro de una supuesta intrusión, o auditoría. Encontrar vulnerabilidades para ser explotadas. Para ello se utiliza un escáner que en nuestro será “Nessus”, pudiendo encontrarse otros como OpenVAS y Nexpose.

Kali Linux no lo trae por defecto, así que lo hemos descargado de la página del producto, obtenido el código correspondiente, instalado y actualizado los plugins. Luego creamos el proyecto y definimos los perfiles que queremos utilizar. En mi caso he dejado sólo los relacionados con plataformas Windows para que sea algo más rápido. No obstante os dejo otro de mis post donde hablaba de la metodología del Pentesting. Lo podéis encontrar aquí.

Por otro lado la configuración de reglas en el Fortinet Fortigate Rugged 60D quedaría como sigue:

Como se puede ver se permite todo el tráfico entre las interfaces “Wan1” y “Wan2”, pero se someterá a los motores Antivirus, Control de Aplicación e IDS/IPS. Lo sé, lo sé, habría que restringir el tráfico sólo al imprescindible pero para la prueba lo dejaré así. En la vida real, ni se os ocurra hacer esto. En el caso de este último, el IDS, se ha configurado para que bloquee “Block” todo aquél tráfico que coincida con alguna de las reglas en él definidas.

Tras lanzar el escáner vemos que el resultado es el siguiente. El Fortigate ha bloqueado los paquetes desde el escáner:

Si a continuación hacemos un reporte de las vulnerabilidades encontradas vemos que sólo se han encontrado un total de 8 de nivel informativo.

Así pues el supuesto atacante apenas podría haber obtenido información del objetivo, con lo que tendría más complicado a la hora de lanzar un exploit concreto cara a aprovechar una vulnerabilidad. Aunque no se aprecie en la imagen, los datos ofrecidos no son relevantes cara a este fin, la intrusión. En cambio, si deshabilitamos dicha protección, esto es:

Y lanzamos de nuevo el escáner, el resultado sería bien distinto:

Aquí veremos que sí se obtienen datos sobre el equipo con Windows XP y por tanto sería exitoso el ataque como el que se podría llevar a cabo en el punto siguiente. Entre ellas hay un total de 3 vulnerabilidades “Critical”, 2 “Medium”, y 20 “Info” destacando entre ellas la que figura a continuación.

34477 (1) – MS08-067: Microsoft Windows Server Service Crafted RPC Request Handling Remote 

Code Execution (958644) (uncredentialed check) 

Synopsis

Arbitrary code can be executed on the remote host due to a flaw in the ‘Server’ service.

Description

The remote host is vulnerable to a buffer overrun in the ‘Server’

service that may allow an attacker to execute arbitrary code on the remote host with the ‘System’ privileges.

See Also

http://technet.microsoft.com/en-us/security/bulletin/ms08-067

Solution

Microsoft has released a set of patches for Windows 2000, XP, 2003, Vista and 2008.

Risk Factor

Critical

CVSS Base Score

10.0 (CVSS2#AV:N/AC:L/Au:N/C:C/I:C/A:C)

CVSS Temporal Score

8.7 (CVSS2#E:H/RL:OF/RC:C)

STIG SeverityI

References 

BID 31874

CVE CVE-2008-4250

XREF OSVDB:49243

XREF MSFT:MS08-067

XREF IAVA:2008-A-0081

XREF CWE:94

Exploitable with

CANVAS (true)Core Impact (true)Metasploit (true)

Plugin Information:

Publication date: 2008/10/23, Modification date: 2015/06/18

Hosts

XX.XX.XX.17 (tcp/445)

Queda bastante claro la funcionalidad de estos motores. A pesar de no restringir el tráfico mediante reglas de firewall tradicionales y dejar pasar todo, algo que obviamente NO DEBE HACERSE BAJO NINGÚN CONCEPTO, nos proporcionan un grado de protección evidente.

En este ejemplo lo hemos hecho sobre un Windows XP vulnerable, pero esto también podríamos emplearlo como elemento de seguridad perimetral sobre Sistemas de Control y Automatización Industrial u otros dispositivos con capacidades limitadas para la implementación de medidas de seguridad. Su protección en este caso radicaría en el Fortigate Rugged 60.

Así hemos terminado por hoy. En la próxima entrada veremos cómo comprometer el Windows XP mediante Metaesploit gracias a la vulnerabilidad anterior.

Como en otras ocasiones os animo a que dejéis vuestro comentario, tanto si es positivo como si no lo es. Todo sirve para mejorar.

Lo dicho, un saludo, nos vemos en la próxima!!

Virtual Patching en funcionamiento (Parte I)

Siguiendo con el tema de Virtual Patching ahora toca ver cómo funciona y los beneficios que puede aportarnos.

Para ello he creado un entorno con dos PCs interconectados por medio de un Fortinet Fortigate Rugged 60D configurándolo con motores Antivirus, IDS/IPS y Control de Aplicación. La parte de firewall la he dejado con un “permit any any any” (IP origen, destino y puerto, respectivamente) Hay que recordar que cada una de ellos lo podemos configurar en dos modos, “Monitor” o “Block”. Con el primero, en caso de que se detecte algún patrón que puda quedar recogido dentro de las reglas y firmas, no se tomará ninguna acción, sólo se registrará el evento y se dejará pasar. En cambio con “Block”, valga la redundancia se bloqueará y la amenaza será paralizada.

Luego, estas características han de aplicarse, o no, a las reglas de Firewall en él configuradas.

En cada uno de estos PCs he virtualizado un total de 3 máquinas.

Una con Kali Linux desde la cual simularemos la actividad de un atacante. Lanzaremos un escaneo de puertos con Nmap, escáner de vulnerabilidades con Nessus, intento de intrusión con Metaesploit y Armitage y por último copiar en un recurso de red el fichero EICAR.

Otra con un Windows XP vulnerable, el objetivo. Se ha elegido este ya que posee vulnerabilidades que para un ejemplo pueden ser fácilmente explotables. Aparte porque su uso en entornos industriales y o vida prolongada es aún bastante común.

Por último un Fortinet FotiManager con funciones FortiAnalyzer desde donde gestionaremos el equipo Fortigate Rugged 60D. Lo he querido utilizar ya que con un despliegue de varios equipos resulta aconsejable no sólo por la gestión centralizada sino porque nos permite almacenar los logs, analizar tráfico, sacar informes, ver registros, etc.

Todo queda resumido de la siguiente manera:

 

En la imagen siguiente se muestra cómo el equipo Fortigate bloquea un total de 9965 amenazas catalogadas en un total de 1993 incidentes, provenientes de la IP XX.XX.XX.15 de la máquina Kali Linux. Esto es debido a que la aplicación Nmap envía sucesivamente paquetes para que en función de las respuestas obtenidas se pueda determinar si un equipo está activo, o no, puertos abiertos; versiones de aplicaciones, servicios; etc.

Para conocer un poco más recomiendo la siguiente lectura, pincha aquí.

En esta otra se puede ver que el equipo destino tiene la IP XX.XX.XX.17.

En la siguiente imagen se muestra las “sondas” enviadas desde el equipo Kali Linux identificando alguna aplicación que otra:

Como se puede apreciar éstas han sido bloqueadas no pudiéndose obtener datos sobre el equipo objetivo, el XP. Esto mitigaría la etapa inicial de recolección de información que un atacante llevaría a cabo y poder, a partir de ahí, realizar otro tipo de acciones sobre nuestros sistemas.

Obviamente habría que configurar las reglas del firewall del modo más restrictivo posible y sobre el tráfico que dejamos pasar aplicar el análisis de los motores Antivirus, IPS y Control de Aplicación. Sin embargo para este ejemplo se ha querido dejar así para ver el comportamiento de la aplicación Nmap y qué es lo que sucede si no empleamos un cortafuego. Pero como como digo, siempre, siempre, siempre, ha de restringirse el tráfico sólo al estrictamente permitido por medio de estos firewalls.

Esto es todo por hoy, pero os debo las siguientes entradas sobre escáner de Vulnerabilidades, Metaesploit y EICAR Test File.

No s vemos en la próxima, y como siempre digo, se agradece cualquier comentario al respecto.

Muchas gracias!