Snap7, suite para de PLCs y comunicaciones Siemens.

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.

ServerDemo_01

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.

ClientDemo_01

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

ClientDemo_02

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

ClientDemo_03

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.

ClientDemo_04

En el lado del serverdemo:

ServerDemo_03

Y en el clientdemo:

ClientDemo_05

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

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 .

Conpot, Honeypot para ICS (Parte II)

Continuando la entrada anterior hoy vamos con esas pruebas que he hecho contra Conpot y de cómo éste se ha comportado.

A continuación veremos lo sucedido cuando he accedido por el puerto 80 desde un navegador.

conpot_07

A partir de aquí los log que revelan nuestro acceso.

conpot_08

Hasta aquí podríamos interpretarlo como algo relativamente común. Pero en el ejemplo que sigue requiere conocimientos técnicos y una buena dosis de premeditación y alevosía. Si desde otro equipo ejecutamos un escáner para detectar servicios sobre la IP ejecutando conpot:

conpot_10

Como podemos comprobar el honeypot recoge información como el tipo de paquete, datos del contenido del mismo, IP de origen, etc.

conpot_11

¿Un equipo enviando un paquete a un Honeypot bajo protocolo S7comm? Esto chirría un poco…

 

Otra de las posibilidades que tenemos es ejecutar alguno de los escáneres disponibles en Metaesploit en auxiliary/scanner/scada

conpot_12

Aquí detectaremos el servicio de Modbus en lugar de S7comm.

conpot_13

conpot_14

Finalmente otras de las pruebas que hice fué sobre SNMP. Desde Metaesploit lancé una enumeración mediante este protocolo.

conpot_16

Y sus respectivos logs.

conpot_15

También podríamos cambiar un OID de SNMP. Por ejemplo la dirección de correo:

conpot_17

Y registro de ello.

conpot_18

Como podemos comprobar Conpot puede ser de gran ayuda para detectar comportamientos anómalos en nuestra red y que vayan dirigidos específicamente a nuestros sistemas de control. Obviamente esta es una Prueba de Concepto y cara a su despliegue en nuestras instalaciones deberemos personalizarla para dar una mayor credibilidad en los resultados.

Con el creciente aumento de las amenazas y publicaciones de vulnerabilidades que afectan a entornos con estos equipos, tener un Honeypot que simule uno de ellos es necesario cara a localizar posibles brechas de seguridad. Obviamente trabajamos para no tenerlas y minimizar los riesgos, pero no estamos exentos de que algo, o alguien, pueda acceder a nuestra red y lleve a cabo algún tipo de acción malintencionada. Para esos casos, aquí tenemos un aliado.

Como es lógico, esta herramienta no nos protege de nuestras vulnerabilidades, pero sí nos avisa. El uso más común será detectar tráfico y comportamientos fuera de lo común en este tipo de redes pero no estaría de más poner uno en la red de oficinas. No sea cosa que el enemigo nos venga por ahí.  También nos puede ayudar cara a la realización de auditorias detectando posibles actividades no conocidas en las instalaciones de nuestros clientes y que puedan poner en peligro la disponibilidad de sus instalaciones.

En mi caso he utilizado una máquina virtual pero hay quién lo ha instalado en una RasperryPi, lo cual ya veis los recursos técnicos y económicos que requiere…

Aquí os dejo un enlace del SANS donde encontraréis una guía sobre cómo diseñar e implementar un Honeypot en un entorno SCADA.

Enlace

En fin, espero que os haya gustado la entrada de hoy. Como siempre, os invito a dejar vuestros comentarios.

Un saludo!

Conpot, Honeypot para ICS (Parte I)

Saber las técnicas que emplean los atacantes contra nuestras infraestructuras y sistemas es clave para saber cómo protegernos. Nos da una idea de los métodos, vías, lugares y procedimientos que siguen para alcanzar sus propósitos y desvelar vulnerabilidades, errores en configuraciones, políticas de seguridad mal implementadas y un largo etcétera.

Para ello, una de las estrategias que podemos seguir en la instalación de los que conocemos como “Honeypot” o “Tarro de miel” en la lengua de Cervantes. Un Honeypot es un equipo o software cuya finalidad es atraer a los atacantes simulando ser un equipo vulnerable registrando la actividad llevada a cabo sobre él. Tras un análisis posterior, u online,  podremos obtener información sobre los distintos puntos enumerados en el párrafo anterior.

Con la llegada de protocolos basados en Ethernet y servicios basados en TCP/IP en las comunicaciones industriales, la exposición que han sufrido los Sistemas de Control Industrial ha ido en aumento. Esto provoca que haya que adoptar nuevas medidas de seguridad que antes no se contemplaban. Prueba de ello es el paso de estrategias como el “Air gap” a la “Defensa en profundidad”. Dichos sistemas no están exentos de poseer vulnerabilidades que permitan a un atacante llevar a cabo algún tipo de acción que los comprometa, o deniegue su servicio aprovechándose de recursos hardware más limitados. Pero ojo, sin olvidarnos de las estaciones que los gobiernan. PCs con sistemas operativos tradicionales de los que, por un lado pueden no tener soporte, y que si lo tienen no cuentan con los últimos parches; y por otro, software a veces innecesario y si lo es, también no está a la última versión.

Es por esto que hoy hablaremos de un Honeypot para Sistemas de Control Industrial, Conpot. Conpot, como indica la página web del proyecto, es un servidor interactivo de Sistemas de Control Industrial diseñado para ser fácil de desplegar, modificar e implementar, proporcionando un amplio rango de protocolos que permiten construir tu propio entorno capaz de convencer a tu “adversario” de que está frente un enorme y complejo sistema industrial. Para mejorar las capacidades de engaño también se proporciona la capacidad de simular una HMI personalizable y ampliar así la superficie de ataque. El tiempo de respuesta de los servicios también puede ser alterado para imitar el comportamiento de un equipo frente a un aumento de la carga y consumo de recursos. Gracias a una completa pila de protocolos, Conpot puede ser accesible por HMI reales o ampliado el hardware real. Finalmente, todo ello bajo el amparo de Honeynet Project

A continuación os dejo el video presentación:

En el siguiente ejemplo he instalado Conpot en una distribución Kali Linux 2016.1, aunque podremos utilizar la que más nos guste aunque primero debemos resolver algunas dependencias. En mi caso he tomado las requeridas para Ubuntu 14.04 LTS y Debian.

Para empezar añadí los repositorios de la versión Kali 2.0 para poder instalar los paquetes snmp-mibs-downloader que con los que vienen por defecto para 2016.1 no lo hace. Entiendo que al ser “non-free” o los instalamos a mano o recurrimos a otras vías como ésta. Entre una cosa y otra al final el fichero  /etc/apt/sources.list quedó con el siguiente contenido:

deb http://http.kali.org/kali kali-rolling main non-free contrib

deb-src http://http.kali.org/kali kali-rolling main non-free contrib

deb http://http.kali.org/kali sana main non-free contrib

deb http://security.kali.org/kali-security sana/updates main contrib non-free

Luego resolveremos las siguientes dependencias:

apt-get install git cython python python-dev python-pip build-essential libxml2-dev libxslt1-dev libevent-dev snmp-mibs-downloader sqlite sqlite3 libsmi2ldbl libsmi2ldbl python-pip libmysqlclient-dev python-mysqldb pkg-config libvirt-dev smistrip 

Actualizamos otros mediante pip.

pip install –upgrade gevent pysnmp lxml bottle jinja2 beautifulsoup4 requests sphinx libtaxii xlrd crc16 

E instalamos, si no lo tenemos ya: 

pip install modbus-tk

pip install argparse 

Es posible que sólo debamos actualizarlos.

Para instalar Conpot podremos hacerlo también con pip

pip install conpot

En mi caso he descargado el software desde:

https://github.com/mushorg/conpot 

e instalado manualmente. 

Descomprimimos el fichero y mediante el siguiente comando lo instalamos:

python setup.py install 

Los distintos ficheros y directorios los encontraremos en:

conpot_01

Para su funcionamiento se cuenta con un fichero de configuración nombrado conpot.cfg donde podremos definir, entre otros, algunos parámetros como por ejemplo cambiar la dirección MAC en la interfaz de red que elijamos, o indicar un servidor Syslog para consolidad todos los logs generados en un servidor y así poder llevar a cabo las labores de análisis forense. Al fin y al cabo esta es una de las funciones para las que está pensado, ¿no?

 

Luego, dentro de las carpetas “templates”  encontraremos los distintos escenarios que nos vienen por defecto y que podremos simular.

conpot_02

Para mi ejemplo voy a utilizar el “default” que simula un PLC S7-200, con acceso vía HTTP, Modbus, s7comm y SNMP. A continuación indico el enlace donde se detallan las configuraciones que podremos hacer sobre los mismos bajo este “template”.

Enlace

Esta herramienta también nos da la posibilidad de hacer de un HMI accesible por HTTP y que nuestro Honeypot lo represente, bien creando una nosotros o copiándola de otra ya creada (hmi_crawler). Las instrucciones las podemos encontrar aquí:

Enlace

Como decía, en el siguiente caso he utilizado el template “default”. Sin embargo he cambiado algunos  parámetros dentro del fichero “template.xml” para darle un toque más personal.

conpot_03

conpot_04

Para que sean visibles vía web deberemos editar el fichero index.html dentro de templates/default/http/htdos e incluir los valores que acabamos de configurar.

conpot_05

Para “lanzar” el honeypot ejecutaremos:

conpot –t default conpot_06

También podemos ver los sockets abiertos:

conpot_09

A partir de aquí lo que hagamos contra nuestro equipo ficticio quedará registrado en un fichero denominado conpor.log o bien en uno distinto mediante el parámetro –l. 

Hasta aquí la entrada de hoy. Para la próxima mostraré los efectos de distintas acciones sobre el honeypot y los resultados obtenidos.

Lo dicho, nos vemos en la próxima, por ahora a instalar conpot y familiarizarse con su capacidades.

Un saludo!