Archivo de la categoría: Herramientas

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

Snap7, suite para de PLCs y comunicaciones Siemens.

Posted on por
Anuncios

En lo que a comunicaciones se refiere, si en algo se caracterizan los Sistemas de Control Industrial es por la gran cantidad de protocolos existentes.  Según sean las operaciones a llevar a cabo estos pueden dividirse, principalmente, en dos grades grupos: “Fieldbus” y “Backend”. Dentro de “FieldBus” encontramos aquellos relacionados con tareas vinculadas a operaciones de proceso y control; mientras que en “Backend” los vinculados a funciones de supervisión, como lo son servidores y sistemas SCADA. Algunos ejemplos son:

Fieldbus:

  • Profibus
  • Devicenet
  • Canbus
  • Profinet
  • Ethernet/IP
  • CC-Link
  • SERCOS

Backend:

  • OPC
  • DNP3

En cualquiera de los casos el abanico existente es muy amplio y por si fuera poco a éstos hay que sumar los que cada fabricante desarrolla para sus propios productos. Tal es el caso de S7 de SIEMENS, objeto en día de hoy, aunque como podéis imaginar, no el único.

Fabricante Protocolo
OMRON FINS
HITACHI HI-Protocol
ROCKWELL RS-Logix
SCHNEIDER Unitelway
HONEYWELL UDC

Dicho lo cual, aunque tengamos que hacer una referencia al protocolo en sí, nos vamos a centrar en una suite llamada Snap7 con la que podremos imitar ciertas comunicaciones y comportamientos de igual modo que lo hicimos con Modbus en la entrada “Simulador de Protocolo MODBUS”.

Snap7 es un software multi plataforma para comunicarse de igual manera que lo harían de forma nativa PLCs del fabricante SIEMENS empleando tecnología Ethernet y protocolo S7.

Entre sus características principales destacan:

  • Arquitectura diseñada para 32 y 64 bits.
  • Software Open Source.
  • Soporte para varios sistemas operativos, Windows, Linux, MacOSX, etc.
  • Soporte para varios tipos de CPU.
  • No son necesarios librerías de terceros.
  • No es necesaria su instalación.
  • Modelos de transmisión de información síncrona como asíncrona.
  • Se incluyen algunas demos para su uso directo.

A día de hoy da soporte parcial a CPUs más nuevas como 1200 y 1500 y más antiguas como 200. Dentro de su estructura se definen 3 componentes principales los cuales son “Client”, “Server” y “Partner”.

Como digo, la aplicación está orientada para ser utilizada en comunicaciones Ethernet y  S7, no siendo necesario ningún adaptador especial.

La implementación del protocolo S7, base de las comunicaciones entre dispositivos SIEMENS, se soporta sobre una ampliación del protocolo TCP recogida en la RFC 1006 y titulada como “ISO Transport Service on top of TCP”. Esto es necesario ya que TCP esta orientado al envío de datos  no transmitiendo información sobre la longitud de la información contenida o sobre cuándo empiezan o terminan. Sin embargo, en aplicaciones de automatización, es indispensable operar orientado a mensajes. Esto es, enviar bloques de datos en los que el receptor sea capaz de reconocer, ahora sí, dónde terminan y finalizan cada uno de ellos. Con RFC 1006, se logra esto último ya que se incluye una cabecera que lo define, y por tanto, garantiza el proceso. Resumiendo, RFC 1006 es una aplicación dirigida a mensajes pero basada en TCP que está basado en datos.

Una vez descargada la aplicación, conviene leer el Manual de Referencia para conocer las capacidades, características, usos y otras cuestiones técnicas.

En mi caso voy a utilizar las «Demos» para Sistemas Operativos Windows los cuales encontraremos junto con el resto de versiones en:

snap7-full-1.4.2\rich-demos

snap7-full-1.4.2\rich-demos\x86_64-win64\bin

Allí encontramos tres aplicaciones:

  • clientdemo
  • serverdemo
  • PartnerDemo

Como se puede entender, hacen referencia a los dispositivos «Cliente» (Workstation, HMI o FieldPG), «Servidor» (PLC) y «Partner» (Comunicaciones entre PLCs); donde, los clientes sólo preguntan, los servidores sólo responden y los partner que pueden hablar de forma bidireccional bajo su propia iniciativa. En cualquiera de los casos, desde el punto de vista hardware, no importa cómo se lleven a cabo estas comunicaciones. Es indiferente de si se trata de un puerto de comunicaciones en la propia CPU 3XX-PN o CPU4XX-PN o un módulo tipo CP343 o CP443.

Para este ejemplo iniciaremos el serverdemo y tras configurar la IP (0.0.0.0 si lo corremos en la propia máquina) pincharemos en “Start”. En la parte inferior se puede ver un espacio donde se registran los eventos que a su vez pueden ser habilitados en la la parte superior.

Por otra parte arrancaremos el software cliente, donde deberemos especificar la IP del serverdemo. Puesto que ambas están en el mismo equipo la IP será la de loopback, 127.0.0.1.

Y pinchando en “Connect”…. Voila! Estamos conectados, en teoría, a un PLC de la serie 300.

Luego exploraremos el contenido de las pestañas, como por ejemplo “Security”.

Para comprobar la manera en la que podremos interactuar debemos irnos a la pestaña “Control”. Como podemos ver, actualmente el PLC están “RUN”, pero si presionamos en “Stop” podríamos pararlo.

En el lado del serverdemo:

Y en el clientdemo:

La herramienta contiene otras muchas funcionalidades que viene reflejadas en el Manual de Referencia que podéis encontrar en el mismo paquete, aparte de distintas casuísticas y topologías. Sin duda Snap7 es un excelente recurso con el que aprender el funcionamiento no sólo de los PLCs del fabricante SIEMENS sino la manera en la que se comunican y explorar técnicamente todo lo que nos ofrecen. Muchas veces nos ceñimos a la parte teórica, buscamos información en uno y otro sitio, pero tener la posibilidad de montarnos nuestro propio laboratorio y simular un escenario por muy simple que sea nos permitirá aplicar todo lo leído y ayudarnos a entender mejor los Sistemas de Control. Así pues ahora toca ponerse manos a la obra.

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

Posted on por
Anuncios

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.

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

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

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.

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

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

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

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.

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

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

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.

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.

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

Posted on por
Anuncios

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.

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.

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