Archivo de la categoría: Herramientas

Software y recursos para aprendizaje, auditoría, hacking y pentesting.

Visibilidad y detección de anomalías, Parte I

Posted on por
Anuncios

El progresivo aumento de buses de campo y protocolos basados en tecnología Ethernet y otros sistemas, hace que nuestros activos tecnológicos estén cada vez más visibles por la red que los une. Sin duda, esto trae consigo múltiples beneficios, pero también riesgos que deberemos mitigar, reducir o transferir hasta un punto en el que sean asumibles por las organizaciones. El riesgo cero no existe y la seguridad al 100% tampoco.

Con la llegada de Ethernet, la superficie de exposición aumenta, y lo hace para poder ganar acceso y recolectar información de los dispositivos sobre los cuales se basa el tan citado “proceso”. Sin embargo, esto sucede tanto para bueno como para lo malo. Y es que, para ganar flexibilidad, escalabilidad, interoperabilidad y prestaciones, tenemos que pagar un precio.

Adicionalmente, vemos cómo las amenazas y acciones malintencionadas sobre los sistemas de control, y otros coligados a éstos, van en aumento. Y lo hacen, entre otras razones, por el beneficio económico que éstas pueden generar para el que la lleva a cabo. Aparte de la propia idea del sabotaje, por supuesto. Y claro, entre que la seguridad no ha sido un requisito, el continuo reporte de vulnerabilidades, las dificultades por corregirlas, la posibilidad de acceder de forma local o remota por red, y falta de medidas de seguridad hace que se genere una situación de lo más propensa.

Es por ello que sea necesario que, una vez acometidas las acciones necesarias a nivel de red como Separación y Segmentación y Deep Packet Inspection, o a nivel de equipo final en PLCs o equipos basado en arquitectura PC basado en Whitelisting, debamos tener visibilidad de lo que pasa en nuestro entorno de planta. Es decir, monitorizar su comportamiento y por tanto tener un mecanismo de alerta temprana ante anomalías.

Como ya comentamos existen en el mercado distintas soluciones entre ellas Nozomi Guardian. Con su versión 20.0 recién lanzada al mercado y en la que introducen numerosas mejoras respecto a su predecesora, veremos algunos ejemplos sobre su necesidad y ejemplos de utilidad. Para ello se partiremos del siguiente esquema.

En él hay representado un autómata virtualizado SIEMENS S7-300 con IP 10.10.201.102; un equipo portátil con IP 10.10.201.103 y una RTU 10.10.201.102. La sonda estará conectada a un puerto espejo donde se replicará el tráfico de los anteriores. La administración de la sonda Nozomi Guardian se realizará en otra del rango 10.10.101.10/24 donde se ubica el servidor que recolecta información de ambos, RTU y PLC. Sí, lo sé, las redes de administración deberían tener su propio segmento pero esto es un entorno de laboratorio. Como se puede apreciar el rango 10.10.201.0/24 pertenece a la de planta y 10.10.101.0/24 iDMZ.

Conviene recordar que en el momento de su despliegue hemos de establecer un período de aprendizaje en que la herramienta hará un perfilado de sobre los activos y comportamiento. A partir de aquí, empleará esta información para indicar la aparición de un nuevo activo, nodo, protocolo, variable, entre otros. La duración dependerá de varios factores como la ocurrencia de eventos que deban ser recogidos, tamaño de la red, equipos implicados, entorno, etc.

En este sentido para generar las alertas, se ha decidido establecer un período de aprendizaje “Learning” de aproximadamente, más o menos, 5 minutos para luego configurar en modo ”Protecting”.

Así pues, durante ese tiempo el sistema detecta los siguientes equipos:

A lo largo de sucesivas entradas iremos ejemplarizando distintos escenarios de riesgo a través de la herramienta Guardian de Nozomi Networks y de cómo se convierten en una necesidad una vez alcancemos un nivel de madurez mínimo.

Ahora bien, no pensemos que esto funciona solo. Deberemos tener un conocimiento mínimo de nuestra red para poder hacer una correcta gestión de las alertas que se nos generan y apoyarnos en otros como los cortafuegos. En ese sentido, y salvo que estos últimos operen en Capa 2 o tengan la capacidad de filtrar las comunicaciones dentro de la misma subred, no detectarán comunicaciones entre segmentos. Si no sabemos lo que es legítimo difícilmente podremos identificar lo anómalo, y por tanto tomar medidas correctoras para neutralizarlo.

¡Nos vemos en la próxima!

¡Un saludo!

 

 

Tools: s7scan

Posted on por
Anuncios

A lot of time has passed since the last time I wrote an article in English. So, it is about time!

Everybody knows that the first step to carry out an audit, pentesting or, in the worst case, an adversary; is to gather information about our target. This process, in OT environments, is not different respecting IT world. However, we must take into account some considerations about the kind of devices that we can find on a plant or shop floor. Be sure that you will find computers and other PC based systems, but there are a lot of other devices such as PLCs, HMIs, gateways, and many more. In addition, the lifecycle is higher so neither the hardware cannot respond in the same way nor it has the same resources that a new one.

All of them have a lot of different characteristics such as hardware, firmware, operating system, lifecycle… and, a simple network scan, could stop or impact on the normal operation. For this reason, we must try to run them in a lab environment, just the opposite of what an adversary would do.  Anyway, there are a lot of tools available that we can use locally or remotely to collect the information that we need.

Nmap is the most famous, but as you will see there are some specific for ICS environments. Obviously nmap as well.

Nmap sobre SCI si, pero con cuidado [ES]

Nmap Scripting Engine para ICS [ES]

Today I will talk about S7Scan. Created by Kaspersky, with S7Scan you can enumerate and collect information about Siemens S7-300, S7-400 PLCS. In GitHub website you can get more general and precise information. Please click here.

First of all, we must access the “help” menu to explore S7scan options to run it accordingly to the scenario:

Having the target IP address, we can execute the tool with the following command if our target is on another public or private network.

 python s7scan.py –tcp [IP ADDRESS]

Optionally we can define the path to store results.  By default, a new folder will be created in the same directory where we execute it if we do not specify it.

There, we can find two text files, one of them is “scan_log.txt” which stores the gathered information about the targets.

Here we can see the communication module:

 

 

As we see, we can get data about internal IP address, PLC name, Orden number, model module, and more.

In the picture below, it is shown the information about the PLC CPU:

In the same way, we get information about firmware, order number, etc. and other interesting details. For example, there is a MMC card inserted and which communication is supported.

From this point we can start checking different websites where we can find announced vulnerabilities, technical specifications, etc. that permit us to move forward to the next steps.

Such as other scenarios, this information have been gathered remotely, this is by TCP/IP network. Long time ago I talked about which are the first measures to take; separation and segmentation of both environments, IT & OT. Please click here. So, in the next picture we can see how a Fortinet Fortigate Next Gereration Firewall can detect this kind of activity.

To prevent this scan, we could permit exclusively these operations from those stations that need access to PLCs and apply layer 7 analysis to generate logs according to that. It is important to restrict access, but It is more important to detect unusual behavior that can show us that somebody, or something, is trying to do actions that are not permitted.

See you in the next post!

 

Kind regards!

Recolectando tráfico con Nozomi Guardian

Posted on por
Anuncios

Aunque en entornos industriales hay, y seguirá, habiendo por mucho tiempo comunicaciones basadas en protocolos serie, existe una clara tendencia hacia el uso de aquéllos basados en Ethernet. Este hecho que, aunque no resulta fácil por el impacto y consumos de recursos de tiempo, dinero y humanos aporta, entre otras, una escalabilidad e interoperabilidad mucho mayor.

Sin embargo, esto tiene su parte negativa ya que la superficie de exposición aumenta exponencialmente. Es por ello que resulta necesario implementar medidas capaces de reducir los riesgos de sufrir un incidente y por ende alterar el normal funcionamiento de la instalación.

Al igual que sucede en las redes de datos tradicionales, también en este tipo de entornos es necesario llevar a cabo una captura de tráfico para realizar un análisis a bajo nivel. Para conseguirlo recurrir a un puerto espejo alguno de los switches o un dispositivo TAP tal y como hablábamos en las dos siguientes entradas.

Puerto espejo, un aliado a veces olvidado

TAP Devices, SIEMENS TAP 104

Luego le llegará la hora de la parte software. Si bien la herramienta estrella es Wireshark la cual cuenta con la capacidad de analizar el contenido de protocolos industriales, también podremos recurrir a otras como Grassmarlin ya en su última versión 3.2.

Sin embargo, existen otras soluciones propietarias que también tiene la capacidad de recolección y análisis. Hace unos meses hablaba en concreto de la del fabricante Nozomi y su producto Guardian.

Monitorización redes industriales, SCADAGuardian

Este producto gracias al desarrollo de nuevas capacidades, mejoras, acuerdos con compañías líderes del sector ha hecho que tenga una gran presencia en el mercado situándose como la de referencia en el mercado.

Una vez desplegada la sonda en el segmento en cuestión, ésta comenzará a analizar y procesar el tráfico recibido para luego opcionalmente recolectarlo para una descarga estudio posterior. Para ello deberemos aplicar un filtro concreto, como puede ser una dirección de origen, destino, protocolo, puerto o cualquier otro paraámetro que pueda ser proporcionado o soportado.

Dicho lo cual, para hacerlo, dentro del menú principal, deberemos de acudir al menú “admin – Other actions”.

Allí deberemos de seleccionar “Continous trace” y acceder al menú correspondiente.

El siguiente punto, tal y como indicábamos anteriormente, habrá  indicar el filtro que queremos aplicar. En nuestro caso será lo relativo con la dirección 192.168.1.XX. Tras seleccionar “Start” comenzará la captura y que veremos en la parte inferior en la imagen siguiente.

A medida que se vaya cumpliendo la condición especificada, Nozomi Guardian irá almacenando el tráfico que más tarde podremos descargar. Para ello deberemos seleccionar el cuarto de los iconos de la parte inferior. Allí aparecerán todos los ficheros generados hasta ese entonces. A partir de aquí,  como decíamos, bien con Wiresahrk o cualquier otra herramienta podremos analizarlo con detalle.

No obstante, también podremos hacerlo son la misma herramienta. Para ello deberemos ir a “Administration – System – Upload PCAPs” tal y como viene indicado en la imagen siguiente:

Allí bastaría con subir la captura y reproducirla presionando en el icono que se indica.

Como podemos comprobar este tipo de herramientas además de informarnos de los activos, comunicaciones, integración con SIEM, informarnos de anomalías, potenciales vulnerabilidades, entre otras muchas más opciones, también nos permite recolectar el tráfico que pueda capturar. Esto resulta de gran importancia y vitalidad ya nos permitirá analizar a bajo nivel los flujos de comunicaciones y detectar anomalías de distinta índole.

 

Un saludo, nos vemos en la siguiente!