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.
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 .
Y su arranque:
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.
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 .
El pasado viernes 27 de noviembre Siemens ha publicado una advertencia de seguridad sobre sus módulos de comunicaciones para autómatas S7-300 y S7-400.
Al parecer existe una vulnerabilidad de evasión de autenticación en módulos de comunicación de la familia SIMATIC CP 343-1, TIM 3V-IE, TIM 4R-IE, y CP 443-1.; permitiendo a usuarios no autenticados realizar operaciones administrativas bajo ciertas condiciones. Para ello el atacante debería cumplir con los siguientes requisitos :
Tener acceso a la red donde se encuentra algún dispositivo afectado.
Los datos de configuración pertenecientes al módulo procesador de comunicaciones deben estar almacenados en la CPU.
La funcionalidad de cortafuegos para los módulos de comunicación deben estar inactivos en el puerto 102/TCP.
INCIBE ha publicado la siguiente nota informativa:
Para corregir el problema para el caso de la CP-343-1 proponen actualizar el firmware a la versión V3.0.44. Para el resto de productos aún no hay una versión disponible con lo que recomiendan:
Activar la funcionalidad del cortafuegos en el módulo procesador de comunicaciones Advanced y rechazar las comunicaciones S7 por el puerto afectado.
Aplicar el concepto protección en celdas.
Utilizar comunicaciones VPN entre celdas para proteger la red.
Aplicar defensa en profundidad.
Sobre este último punto os dejo un enlace hacia otras entradas sobre las cuales ya he hablado:
