La recolección de información es una de las fases iniciales de cualquier auditoría de seguridad para determinar no sólo el grado de exposición de nuestros equipo, redes y sistemas sino también sus vulnerabilidades.
Hace unos años hablaba del uso de la conocida herramienta NMAP y su funcionalidad NSE las cuales podéis encontrar en las entradas siguientes.
Tradicionalmente se ha aplicado sobre sistemas operativos de propósito general o adaptados a requisitos de Tiempo Real, sobre los cuales se ejecuta distinto tipo de software bien para interactuar sobre los procesos controlados por PLCs, pantallas de visualización, puestos de operador, entre otros.
Sin embargo, esta fase de recolección de información debe llevarse a cabo también sobre equipos de nivel 1 del Modelo Purdue, esto es PLCs, PAC, o controladores de distinta índole.
NMAP permite mediante NSE descubrir información relativa a ellos. A continuación, se citan algunos ejemplos sobre los productos de algunos fabricantes y protocolos:
OMRON
Ethernet/IP
En estos casos además podemos obtener la dirección IP de la red local siendo 192.168.XXX.XXX y 10.XXX.XXX.XXX
Estos son algunos ejemplos, pero podría haber más a partir de los scripts que podemos encontrar en la herramienta. Lo importante aquí es que no debemos fijar, solo, nuestra atención a los equipos basados en PC. Debemos tener presente los componentes y sistemas de control con lógica programable que, pudiendo estar expuestos en las redes de planta, presentan vulnerabilidades o fallos de diseño que puedan comprometer las operaciones.
Muchos sabemos que Nmap es una de las herramientas estrella para identificar host, servicios, redes y poder llevar a cabo tareas de recolección de información (Information Gathering) dentro de procesos de auditoría o pentesting. Hablando más concretamente de entornos industriales, hemos de tomar ciertas precauciones ya que podremos afectar a la operativa del equipo, algo que en ningún caso puede producirse. Nmap posee además algunas funcionalidades extra de la mano de su motor NSE (Nmap Scripting Engine) que nos permite llevar a cabo tareas más concretas. Éste se basa en un conjunto de scripts que se organizan en distintas categorías dependiendo de la finalidad, como son:
auth
broadcast
brute
default
discovery
dos
exploit
external
fuzzer
intrusive
malware
safe
version
vuln
Hace un tiempo hablé sobre algunos aspectos de Nmap, tanto de su motor de Scripting NSE como de sus uso sobre sistemas de control industrial. Por no repetir contenido os dejo los enlaces para que las podáis consultar.
Sin embargo, en el día de hoy voy a hablar de una serie de Scripts dirigidos específicamente a identificar y enumerar dispositivos y aplicaciones que pueden ser encontrados en entornos de control y automatización. Para ello se basan en protocolos y comandos de la propia aplicación para obtener información del objetivo. Sólo se trata de “recolectar”, no de “explotar”.
El primer conjunto de ellos podemos encontrarlo en el siguiente enlace de Github. Los mismos han sido desarrollados dentro de un proyecto de investigación llamado “Redpoint” de Digital Bond, consultora fundada en 1998 por Dale Peterson especializada en seguridad en entornos industriales.
Para un mejor uso podemos descargarlos y copiarlos en la carpeta de “Scripts” que emplea nmap y que en la distribución Kali Linux está ubicados en:
/usr/share/nmap/scripts
Luego es necesario actualizar la base de datos para que podamos verlos por ejemplo con la interfaz gráfica “Zenmap”.
root@kali:/usr/share/nmap/scripts# nmap –script-updatedb
Starting Nmap 7.25BETA2 ( https://nmap.org ) at XXXX-XX-XX 07:00 EST
NSE: Updating rule database.
NSE: Script Database updated successfully.
Nmap done: 0 IP addresses (0 hosts up) scanned in 1.37 seconds
Para diferenciarlos los he renombrado como “Redpoint_XXXXXXXX.nse” y así identificarlos más claramente.
Nmap cuenta de forma nativa con algunos scripts orientados a estos fines como Modbus, OMRON, incluso alguno creado por el propio “DigitalBond” como puede ser para el protocolo “BACnet”. Como ejemplo utilizaré esté último para ver los resultados arrojados y hacernos una idea. Para facilitar la tarea he hecho una primera búsqueda con ZoomEye, del que hablaba en mi último post llamado “Buscando ICS en la red, ZoomEye”.
En el primero de los ejemplos podemos ver los siguiente:
Analizando la información podemos seguir buscando y ver las características de los equipos que responden a ese perfil, como puede ser:
Y mira por dónde, yendo un poco más allá localizar vulnerabilidades de ese fabricante:
Por otro lado, en el siguiente ejemplo podemos observar otro resultado.
Al igual que el caso anterior localizamos que se trata de un equipo del fabricante Kieback & Peter cuya web es la siguiente:
Y vemos que se trata de un equipo destinado al control de estaciones de ventilación, refrigeración de edificios pequeños y medianos:
El segundo de los repositorios también lo encontramos en GitHub en el siguiente enlace, haciendo referencia sólo a productos del fabricante SIEMENS. Los mismos han sido desarrollados por la empresa DrainWare, apreciándose que el nombre de la cuenta de GitHub coincide con su fundador “jpalanco”.
El funcionamiento es similar a lo planteado en los casos anteriores, con lo que explicado uno, explicados todos. Sí que es cierto que dependiendo del script que ejecutemos deberemos especificar uno u otros puertos, pudiendo indicar además ciertos argumentos asociados a HTTP o SMB y así perfeccionar la ejecución.
La idea en el día de hoy es ofrecer cómo ampliar y ajustar las funcionalidades de Nmap para su uso concreto sobre sistemas de control y automatización, mediante la inclusión de Scripts específicos ya desarrollados. Como decía, son especialmente útiles cara a realizar labores de auditoría o pentesting ya que permite, no sólo, la recolección y enumeración de información sino definir la forma y modo de hacerlo mediante la parametrización de la herramienta para que sea más o menos intrusiva.
No obstante, conviene recordar que el uso ha de hacerse teniendo en cuenta el equipo final sobre el que lancemos los scripts ya que podremos afectar a su funcionamiento. Esto es debido a los limitados recursos hardware que poseen con lo que es probable dejarlos “offline”, por lo que resulta necesario, o al menos aconsejable, hacerlo en un entorno controlado o de pruebas. Me refiero por supuesto a equipos de sistema de control y automatización. En cualquiera de los casos mucho, mucho cuidado.
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.
