ICSSPLOIT, PROFINET-DCP

No hace mucho hablábamos de ICSSPLOIT como herramienta para ayudarnos en labores de auditoría y pentesting en entornos industriales. En concreto veíamos la posibilidad de parar y arrancar tanto la CPU como un módulo de comunicaciones CP de un autómata SIEMENS S7-300.

Además del módulo de “exploits” y “creds”, disponemos de un tercero denominado “scanners” destinado como podéis imaginar a la obtención de información. Sin embargo, en esta ocasión, se emplea  para ello el estándar de comunicaciones basado en tecnología Ethernet, PROFINET.

A continuación citaremos algunos de los aspectos más relevantes de dicho estándar:

En lo que respecta a las comunicaciones, se consideran 3 tipos dependiendo de las necesidades del entorno y precisión de proceso. Hablamos de:

  1. Standard TCP/IP, emplea para tareas en las que la latencia de 100 ms puede ser aceptable como pueden ser la comunicaciones con sistemas IT.
  1. RT (Real Time), son aquellas en las que los tiempos de latencia pueden oscilar hasta 10 ms o son de carácter determinista.
  1. IRT (Isochronous Real Time), comunicaciones en los que los tiempos son inferiores a 1 ms.

Para lograr la identificación de los dispositivos, al estar basado en Ethernet, el direccionamiento dentro de viene dado por la dirección MAC, IP y nombre del dispositivo.

Por otro lado, ya  dentro del estándar, encontramos varios tipos de protocolos según sea el uso y contexto sobre el que valla a utilizarse. Podremos hablar de:

PROFINET-IO, destinado a comunicaciones entre dispositivos de campo, entradas y salidas.

PROFINETMRP, para su uso en entornos de alta disponibilidad en topologías en anillo. A continuación se muestra una captura de un switch Siemens X208 en el que se reflejan dichos parámetros.

Config HA Switch_01

PROFINET-RT, transferencia de datos en tiempo real.

PROFINET-IRT, transferencia de datos en tiempo real isócrono.

PROFINET-PTCP, sincronización de señales temporales como reloj y tiempo entre dispositivos.

PROFINET-PTCP

PROFISAFE, aplicación de PROFINET a funcionalidades relativas a la protección de personas bajo el término “Safety”.

Y aqui es donde llegamos al punto que nos interesa para la entrada de hoy…

PROFINET-DCP, esto es PROFINET Discovery and Configuration Protocol, PN-DCP. Se trata de un protocolo basado en la Capa de Enlace, L2, empleado para descubrir dispositivos, identificar información relativa a éstos y configurar parámetros como nombres y direcciones IP dentro de una red PROFINET.

Dentro de su funcionalidad, ofrece varios servicios y métodos de comunicación segúyn sea la aplicación como “Identify All (multicast service/ Group)”,  “Identify (multicast service)”, “Set (unicast service)”, “Set / Reset to Factory (unicast service)”, “Set / Flash (unicast service)”, “Get (unicast service)” y “Hello (multicast service)”.

¿Ahora bien, cómo encaja ICSSPLOIT en todo esto? Como decía al principio, el framework en cuestión trae consigo una herramienta dentro del módulo “Scanners” que permite obtener el nombre, valores de direccionamiento IP y modelo del equipo por medio de PROFINET-DCP. En el video que se muestra a continuación veremos el resultado.

Y por último en la captura siguiente se puede apreciar cómo desde una máquina virtual se solicita información de un equipo “Siemens” cuya dirección MAC aparece sombreada.

ICSSPLOIT PROFINET-DCP

Una vez procesada, dicha estación PROFINET responde con los valores que aparecen en el video, esto es, dispositivo (S7-300); nombre, (pn-io) y direccionaminto IP (192.168.0.1; 255.255.255.0; 192.168.0.1)

ICSSPLOIT PROFINET-DCP

Con la entrada de hoy hemos visto la manera de recolectar información empleando tanto ICSSPLOIT como PROFINET-DCP, eso sí dentro de la misma subred.

Muchas gracias, nos vemos en la próxima.

Un saludo.

Edorta

ICSSPLOIT, paro de PLCs S7-300 y S7-400

Hola de nuevo. Siguiendo en la línea de herramientas orientadas a redes industriales, hoy le toca turno a ICSSPLOIT.

ICSSPLOIT es un framework dirigido a sistemas y protocolos de control industrial que puede sernos de utilidad en tareas como auditorías y labores de pentesting. Escrito en Python, presenta un aspecto similar al Metasploit, conservando la interfaz y la forma de interacción. Se trata de un software Open Source pudiéndolo descargar desde su sitio en Github. Allí podremos ver el conjunto de scanners, exploits, protocolos y clientes que soporta, y que esperemos vaya creciendo con el tiempo. Veamos un resumen.

ICSSPLOIT

La herramienta viene preparada para Kali Linux incluyendo lo necesario para su funcionamiento. Sin embargo, si algo nos faltase, podríamos mirar su fichero “requirements” y llevar a cabo la instalación de los paquetes mediante:

pip install -r requirements

Así pues qué mejor manera que verla en acción con un ejemplo. En otras entradas he trabajado con simuladores pero en esta ocasión lo haré con un PLC Siemens S7-300 real. Por supuesto, en un entorno de laboratorio. Por si fuera poco, además lo haré en formato vídeo. Una novedad que he querido introducir gracias al creciente número de visitas que ha ido teniendo el blog. Así pues, a continuación, veremos cómo llevar a “STOP” tanto la CPU como el una tarjeta CP del autómata para luego revertir el proceso. Todo de forma remota. Ahí va!

Como decía, también es válido para los S7-400. A continuación muestro la captura con Wireshark sobre los paquetes enviados y recibidos. Comentar que el PLC tiene IP 192.168.0.1 y el PC 192.168.0.100 .

ICSSPLOIT Stop S7-300

Y su arranque:

ICSSPLOIT Start S7-300

Hasta aquí la entrada de hoy. Corta, pero que con el vídeo espero haya sido ilustrativa y hayamos descubierto esta nueva herramienta que sin duda va a ser de mucha utilidad para los profesionales de la seguridad. En sucesivas entradas iremos descubriendo nuevas funcionalidad, poco a poco.

¡Un saludo, nos vemos en la siguiente!

Edorta

Controlando nuestros Proveedores, Parte II.

Hola de nuevo. Siguiendo con la entrada anterior “Controlando nuestros Proveedores, Parte I” en el día de hoy vamos a ver la manera en cómo trabaja el binomio FortiGate + FortiClient.

Si bien la protección es en tiempo real, al hacer un análisis antivirus vemos la forma en la que detecta malware según la base de firmas del fabricante. Para ver su funcionamiento he dejado en el escritorio un fichero de EICAR.

Control de Proveedores en entornos industriales OT

No obstante, para que no fuese un típico ejemplo, también tenía una carpeta con el software incluido en el repositorio Pengowin y que desde aquí, dicho sea de paso, recomiendo dicho proyecto.

Control de Proveedores en entornos industriales OT

Viendo los logs:

Control de Proveedores en entornos industriales OT

en total fueron 55 detecciones:

Control de Proveedores en entornos industriales OT

Para terminar la desinfección es posible que se solicite un reinicio del sistema.

Control de Proveedores en entornos industriales OT

Como se puede ver, también en el escritorio tenía el simulador del protocolo S7 de SIEMENS, Snap7 del que hablaba en la entrada “Snap7 suite de PLCs y comunicaciones Siemens”. Al ejecutar el cliente para hacer una lectura del supuesto PLC, esto es “clientdemo.exe”, como el protocolo “ICMP” y “S7 Protocol” no están permitidos vemos su bloqueo, al igual que otros relacionados con el sistema operativo.

Control de Proveedores en entornos industriales OT

Si actualizásemos el perfil del control de aplicación correspondiente, ya podríamos acceder al mismo, en la IP 192.168.0.1.

Snap7

También disponemos de un “Filtro Web”, funcionalidad que no he utilizado pero también útil si necesitamos tener acceso a una interfaz Web. ¡Ojo! Hablo de equipos locales, no accesos a Internet.

Como decía en el post anterior es compatible con los “Security Profiles” configurables en cada una de las reglas del Firewall, con lo que a nivel de red también podríamos ejercer un control adicional. Configurar los perfiles de qué se puede ejecutar, o no, en un PC puede llegar a ser complejo y laborioso en función de cada proveedor. Con lo que llegado el momento, podríamos llegar a ser más permisivos en este sentido en cuanto a consentir toda la categoría “Industrial” o “Servicios de RED” y denegar “Botnet”, “Game”, “P2P”, etc. y luego apoyarnos en reglas y “Security Profiles” como indicaba en las entradas:

También destacar la visibilidad que podemos tener desde el Fortigate a la hora de monitorizar los FortiClients conectados y de si cumplen, o no, con las políticas establecidas. Para ello deberemos ir a “Monitor – FortiClient Monitor”.

Control de Proveedores en entornos industriales OT

Ya por último comentar que en este caso hemos hecho uso de un Firewall Fortigate para la gestión de los endpoint. Sin embargo, Fortinet dispone de un producto específico para la gestión de este software denominada FortiClientEMS (Enterprise Management Server) con lo que podremos realizar un control centralizado y una gestión más pormenorizada de todos ellos.  Aquí os dejo un video presentación y enlaces con información al respecto.

Integración de Fortigate y FortiClientEMS.

Como hemos visto nuestros proveedores pueden ser no sólo un punto de entrada sino también el origen de un problema mucho mayor. Los habrá que sean estrictos con el uso de sus equipos sin embargo, esto no es razón para pensar que nada malo pueda suceder. Los entornos industriales no son para nada similares a los de Oficina o IT tradicionales. Los ciclos de vida son mayores con lo que la posibilidad de encontrarnos con Sistemas Operativos y Hardware viejo u obsoleto, es bastante común. Con ello, falta de soporte del fabricante y vulnerabilidades incapaces de corregir, y aun existiendo parches, según actividad de la compañía, desarrollos de software propios, o cierre, hacen que muchas veces sea inviable. A esto hay que sumar la existencia de empresas proveedoras de servicios que necesitan conectarse a nuestras instalaciones para llevar a cabo las tareas para las cuales han sido contratadas, y que no hace posible desplegar su software sobre otro equipo de la organización en el que sí tenemos control y conocimiento de su estado.

Con esta entrega hemos visto cómo con los NGFW FortiGate y endpoint FortiClient podemos llevar a cabo un control y permitir qué equipos de terceros puedan conectarse a nuestra red. De esta manera reducimos los riesgos  de que algo, o alguien, pueda comprometer la disponibilidad de nuestras instalaciones. No pretende ser un manual, ni mucho menos, sino una visión sobre de qué manera podemos ejercer dicho control y supervisión.

Obviamente existen en el mercado otros fabricantes, con otras soluciones que de igual manera puedan satisfacer nuestras necesidades, pero resulta interesante ver esta en concreto por su integración junto con el hardware de red. Como hemos visto, desde hace relativamente poco tiempo, los fabricantes de equipos de control y automatización tipo SIEMENS, Phoenix Contact, entre otros, incluyen ya características relacionadas con la Ciberseguridad, cosa con los equipos más antiguos o bien, o no disponen o son débiles. Por tanto, delegar en la electrónica de red y seguridad perimetral aspectos de la seguridad sigue siendo un hecho que durará por mucho tiempo ya que la renovación de PLCs, Robots, o cualquier otro por motivos puramente de seguridad, no es una razón de peso o prioridad.

Un saludo a todos, nos vemos en la siguiente y no te olvides que puedes seguirnos también en @enredandoconred .

Edorta

 

Controlando nuestros Proveedores, Parte I.

Hace unos días hablaba acerca de la necesidad de gestionar los proveedores externos e incluirlos en nuestras políticas de seguridad, claro está, orientadas a su actividad. Muy particularmente en grandes corporaciones, éstas se ven obligadas adquirir a terceros equipos, productos y servicios especializados para la actividad de la misma. Luego, cara a garantizar una respuesta o asesoramiento, firman contratos de soporte con el fin de obtener ayuda en caso de ser necesario. Como veíamos en la entrada “Proveedores Externos, posible punto de entrada…” ha de establecerse un procedimiento tanto administrativo como técnico que regule cómo han de conectarse y qué requisitos deben reunir sus equipos antes, durante y después de conectarse a nuestra red de control.

A diferencia del post que citaba anteriormente, hoy hablaré sobre cómo podemos controlar técnicamente dichos equipos. Es un ejemplo, obviamente no dará respuesta a todas las necesidades ni a todas las casuísticas que sin duda serán muy particulares dependiendo de tecnologías, industrias, equipos, actividad, o cualquier otro factor.

El objetivo será llevar a cabo un control sobre el PC de un proveedor que necesariamente ha de conectarse, sí o sí, a nuestra red OT para llevar a cabo tareas de soporte o mantenimiento. Estos PC contendrán el software necesario sin embargo, no tendremos ni su control, ni conocimiento alguno del estado de actualización de sistema operativo, aplicaciones; firmas antivirus (si las hubiera); vulnerabilidades; etc. etc. Habrá quien piense que una alternativa pueda ser instalar las herramientas en PCs de la propia organización sobre los que sí tendríamos aquello que ahora nos falta. No le quito razón, sin embargo, la realidad nos muestra una serie de inconvenientes:

  1. Coste de licenciamiento de Software. ¿Nueva instalación, nueva licencia? ¿reasignación de licencias?
  2. Necesidad de probar aplicaciones en PCs de la organización para garantizar pleno funcionamiento.
  3. Dada el ciclo de vida mayor, probabilidad de uso en Sistemas Operativos con distintas versiones.
  4. Desarrollo de herramientas a medida y bajo condiciones concretas, diferentes a los empleados en la organización.

Por tanto, con todo en contra, lo que sí podríamos hacer es obligar a nuestros proveedores a cumplir nuestras normativas y marcarles las vías de cómo hacerlo. De hecho, es algo que las políticas de seguridad deben contemplar. Me refiero a que una vez implementadas todas las herramientas y medidas, todo nueva sistema, instalación o equipo debe cumplir con aquello especificado para el nuevo “ciberseguro” escenario. Para algo lo hemos hecho, ¿no?

Para ello emplearemos la aplicación endpoint FortiClient de Fortinet con el que podremos identificar y remediar equipos vulnerables, o comprometidos, reduciendo así la superficie de ataque. Luego podremos integrarlo en otras soluciones del mismo fabricante, aspecto que no abordaremos en este post.

Para la Prueba de Concepto he creado el siguiente ejemplo:

Como vemos en la figura, un proveedor ha de conectarse a la red Control para llevar a cabo determinadas tareas. Tiene dedicada una VLAN con un direccionamiento 192.168.254.0/24 a la que deberán conectarse todos los equipos de proveedores. Así pues, todas las comunicaciones deberán pasar por el Firewall (NGFW) que bien podría ser el de Separación o de Segmentación dependiendo de cómo tenga definida la arquitectura la organización. Luego, en función de cómo configuremos el mismo, dejaremos pasar el tráfico necesario hacia la red 192.168.0.0/24, esto es, la de Control.

Control de Proveedores en entornos industriales OT

Para ello emplearé la versión 5.4.4 de FortiClient y un equipo FortiGate 61E con FortiOS 5.4.5.

Lo primero que deberemos hacer será definir una subred, VLAN para nuestros proveedores y que el Gateway, por ejemplo, sea el Fortigate.

Control de Proveedores en entornos industriales OT

En ella deberemos habilitar por un lado la detección de Dispositivos y el control de acceso basado en Forticlient. Ni qué decir que desde la red de proveedores no puede existir la posibilidad de acceso a los Firewalls….

Control de Proveedores en entornos industriales OT

El siguiente paso será definir qué Aplicaciones vamos a dejar permitir ejecutar a los proveedores en sus equipos. Para ello deberemos ir a “Security Profiles – Application Control” y definir uno con los parámetros que creamos convenientes. Os dejo dos entradas que os pueden orientar en las que hablaba de esto mismo:

Con ello listo, iremos a “Security Profiles – FortiClient Profiles” y crearemos el que a posteriori será el que se aplicará sobre los endpoints.

Control de Proveedores en entornos industriales OT

Allí deberemos especificar algunos parámetros como: la red sobre la que se aplicará, en nuestro caso la 192.168.254.0/24, “LAB_RED PROVEEDORES”; acción en caso de no cumplimiento, “Block – Warning – Auto-update”; el tipo de dispositivo, “ALL”; Versión mínima del software FortiClient, “5.4.1”; comportamiento del motor Antivirus, “Realtime Protection, Up-to-date signatures”; y por último el perfil de Firewall de Aplicación, el que hemos definido anteriormente, “LAB_APP-CONTROL_S7”.

Aquí quizás puede llevarnos a confusión el concepto de Control de Aplicación, pero que en este caso se aplica de dos maneras distintas. Una cosa es el Control de Aplicación que se  ejecuta sobre las aplicaciones del PC y que lo regula en el endpoint FortiClient; y otro distinto el que podemos aplicar sobre el tráfico de red en cada una de las reglas configuradas y definidas dentro de la columna “Security Profiles”.

Si en estos instantes alguien quisiera acceder a algún recursos de la red no podría ya que no cumple con los requisitos. Si por ejemplo abriésemos un navegador y pretenderíamos navegar aparecería el siguiente mensaje:

Control de Proveedores en entornos industriales OT

La instalación del endpoint es sencilla. Lo único que tendremos que tener en cuenta es realizar una instalación completa, en lugar de sólo la funcionalidad de VPN. Una vez finalizada se comenzará a descargar los distintos componentes.

Control de Proveedores en entornos industriales OT

Si abrimos el cliente veremos una pantalla con los distintos apartados del endpoint.  Si nos fijamos a “Firewall de Aplicación” veremos los “Overrides” autorizados relacionados con el protocolo S7.

Control de Proveedores en entornos industriales OT

Control de Proveedores en entornos industriales OT

Hasta aquí hemos visto la manera en la que configuramos, de forma resumida, todo lo necesario para comenzar a ejercer el control del que hablábamos. Con todo listo, será en la próxima entrada, cuando comprobemos los resultados y por tanto su eficiencia.

Un saludo a todos, nos vemos en la siguiente y no te olvides que puedes seguirnos también en @enredandoconred .

Edorta

 

Simulador de protocolo ModBus

Una de las características que presentan los Sistemas de Control Industrial y SCADA es la gran cantidad de protocolos de comunicaciones existentes. Esto es debido a que muchos fabricantes han desarrollado los suyos propios, aparte de los ya estandarizados. Éstos los podemos encontrar bien en formato serie mediante RS-422, RS-485 o Ethernet siendo la tendencia es que sea este último el medio predominante ya que permite la integración en redes tradicionales e implementar servicios bajo TCP/IP. Esto resulta algo indispensable cara al despliegue de tecnologías dentro de la Industria 4.0. la cual requiere, aparte de la funcionalidad conocida de equipos SCADA, recolectar otro tipo de datos para sistemas ERP e BI, herramientas Big Data, Analítica Avanzada o incluso simulación.

La premisa que acompaña a estos protocolos es que han sido diseñados para ser funcionales. No se ha contemplado la seguridad en el inicio, a excepción de algunas variantes de DNP3 u OPC. Sin embargo, el uso de protocolos sin medidas de seguridad nativas es amplísima, lo cual obliga a externalizar en otros equipos la protección de la información que viaja en los paquetes.

Uno de estos protocolos es Modbus. Fue creado a finales de la década de los 70 para comunicaciones serie, y en 1999 para comunicaciones TCP/IP. Bajo el nombre ModbusTCP/IP, presenta una arquitectura Maestro/Esclavo en el que el Maestro representa el cliente y el Esclavo el Servidor. Esta característica propició su consolidación como protocolo de control industrial lo que justifica su presencia en todo tipo de entornos y sectores, incluyendo infraestructuras críticas.

En el día de hoy vamos a ver cómo podremos representar su funcionamiento, lo que nos ayudará a entender mejor cómo puede ser interceptado, manipulado y, por ende, necesariamente protegido.

En esta labor nos apoyaremos de un simulador Modbus. Por un lado Modbus Master (Maestro) y Modbus PAL (Esclavo) siendo este último un fichero para plataformas basadas en Java. En la siguiente imagen podremos ver, en la parte izquierda, “el Master”, y derecha el “Slave”. Como hemos dicho anteriormente maestro equivale a “cliente” y esclavo Servidor”. El maestro, (cliente) es quien controla las comunicaciones con los esclavos (servidores) y por el contrario los esclavos (servidores) se limitan a devolver los datos solicitados o bien, ejecutar la acción indicada por el maestro.

modbus_simulator_01

Por defecto el “Master” aparece configurado para operar en conexiones tipo serie, por lo que deberemos configurarlo para hacerlo bajo TCP. En este modo el puerto por defecto que emplea es el 502. Para ello iremos a “Option” y seleccionaremos “Modbus TCP…”.

modbus_simulator_02

También haremos lo propio en el apartado “Modbus Mode” – “TCP”.

modbus_simulator_04

También definir la IP del Master. Puesto que tanto uno como otro corren en el mismo equipo configuraremos la de Loopback, 127.0.0.1.

modbus_simulator_03

Hecho esto, ahora toca configurar los esclavos. En “Modbus slaves” seleccionamos “Add” y allí definiremos el nuestro, identificado con “1” y con el nombre “Test_Blog”.

modbus_simulator_05

Abriremos el editor (icono con aspecto de ojo) y configuraremos en la pestaña “Coils” del 1 al 8, configurando los 4 primeros con un “1” y los 4 segundos con un “0”.

modbus_simulator_06

Aprovecharemos para configurar también el apartado “Holding registers” esta vez del 1 al 4, y con los siguientes valores.

modbus_simulator_07

Por último, pincharemos en “Run” para iniciar el esclavo. Si abrimos un “cmd” veremos que en nuestro equipo se nos ha abierto un socket en el puerto TCP-502.

modbus_simulator_08

Ahora deberemos ir a nuestro “Master” y conectarnos al “Esclavo” pinchando en el icono marcado.

modbus_simulator_13

Para hacer una lectura o escritura seleccionaremos el icono situado a la derecha del que empleamos para conectarnos, viendo a continuación los resultados. Esto es cuatro “unos” y cuatro “ceros”.

modbus_simulator_09

Que se realice una lectura y escritura dependerá también del “Function Code”. En el caso anterior teníamos “Read Coils (0x01)”, sin embargo si esto lo cambiamos por “Read Holding Registers (0x03)” veremos el otro resultado . Ojo, que en este caso el “Number of Registers” ahora es 4, valor que ha cambiado del “8” del número de “Coils“ configurados.

modbus_simulator_10

Para ello cambiaremos la “Function Code” por “Write Multiple Registers (0x10)” y en campo inferior por valores como 999, 888, 777, 666. Luego a continuación pincharemos sobre “Read/Write” y veremos cómo cambian los valores en el esclavo.

modbus_simulator_12

Aunque no se haya comentado el simulador también permite:

Master

  • Realizar de forma continuada lecturas o escrituras sin necesidad de hacerlo manualmente.
  • Posibilidad de ejecutar tanto Maestro como Esclavo en distintos equipos y poder hacer pruebas adicionales con equipos de red tales como cortafuegos, IDS/IPS, router, etc.
  • Una ayuda e información sobre el protocolo.
  • Almacenar en un fichero de texto los logs generados de la herramienta.
  • Monitor de los paquetes enviados y recibidos.

Slave

  • Guardar el proyecto
  • Grabar la actividad y poder reproducirlo a posteriori.
  • Modificar el puerto a la escucha en lugar del 502 por defecto.

Así pues, este simulador nos puede ayudar a entender no sólo el funcionamiento de Modbus sino la creación de un laboratorio para pruebas y  tomar conciencia de los débiles que pueden llegar a ser los protocolos existentes en entornos de control y automatización presentes en gran cantidad de áreas, sectores e instalaciones.

Espero que os haya gustado, nos vemos en la siguiente.

Un saludo a todos, nos vemos en la siguiente y no te olvides que puedes seguirnos también en @enredandoconred .

Nmap Scripting Engine para ICS

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.

  1. Nmap Scripting Engine
  2. Nmap sobre SCI sí, pero con cuidado…

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.

redpoint_01

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.

zenmap-redpoint-scripts_01

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:

zenmap-redpoint-scripts_02

Analizando la información podemos seguir buscando y ver las características de los equipos que responden a ese perfil, como puede ser:

nae-55xx_01

Y mira por dónde, yendo un poco más allá localizar vulnerabilidades de ese fabricante:

jhonson-vulnerability_01

Por otro lado, en el siguiente ejemplo podemos observar otro resultado.

zenmap-redpoint-scripts_03

Al igual que el caso anterior localizamos que se trata de un equipo del fabricante Kieback & Peter cuya web es la siguiente:

kieback-peter_01

Y vemos que se trata de un equipo destinado al control de estaciones de ventilación, refrigeración de edificios pequeños y medianos:

kieback-peter-ddc420

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”.

github-scripts-drainware_01

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.

github-scripts-drainware_02

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.

¡Un saludo, nos vemos en la próxima!