msgbartop
Asociado al gabinete del Doctor Caligari
msgbarbottom

06 jul 19 Hacking lab sobre Modbus TCP. Elementos configurados

Esta entrada es la parte 2 de 4 de la serie Hacking Lab Modbus TCP

En el artículo anterior se hacía referencia al objeto del hacking lab y se daba una visión general de la arquitectura implementada. En este artículo se va a entrar en un mayor detalle de los elementos que forman parte de dicha arquitectura: HMI, PLC, actuador TCP y plataforma de ataque.

HMI de control de luces LED
El HMI de control simula un sistema SCADA. Está implementado mediante Node-Red, sistema software que permite la programación basada en flujos para desarrollar sistemas para Internet de las Cosas. A fin de poder realizar la implementación del sistema de control industrial, se ha hecho uso de las siguientes librerías:

  • Modbus,que permite implementar un sistema de comunicación basado en Modbus TCP y Modbus Serie.
  • Dashboard, que permite crear cuadros de mandos y aplicaciones web para interactuar con los flujos de control.

El sistema desarrollado consta de dos partes:

  • El cuadro de mandos es una simple botonera que permite encender la iluminación LED rojo, verde y azul mediante interruptores individuales. Estos interruptores, al actuar sobre ellos, envían una señal MODBUS TCP al PLC simulado, para cambiar el estado de la bobina que corresponda a cada color, y muestra el resultado final del mismo en pantalla.
  • Captura de la interfaz de control

    Captura de la interfaz de control

  • La lógica de interacción del HMI con el PLC se ha desarrollado para leer cada 500 ms el estado de las 3 bobinas del PLC, y desplegar en la botonera el estado de las mismas. Si el usuario cambia uno de los interruptores, el sistema envía al PLC mediante MODBUS sobre TCP una orden para escribir un cambio de estado en la bobina correspondiente. El flujo de control corresponde al siguiente diagrama:
  • Flujo de control HMI-PLC

    Flujo de control HMI-PLC

PLC de control de luces
El PLC que actúa como Master MODBUS se ha desarrollado igualmente haciendo uso de Node-Red con la librería MODBUS. En este caso se ha implementado la funcionalidad de Master Modbus, escuchando en el puerto 1502/TCP (frente al habitual 502/TCP por razones de permisos) de la Raspberry Pi que despliega los servicios de Node-Red.

PLC simulado con Raspberry Pi

PLC simulado con Raspberry Pi

El flujo Node-Red definido es el siguiente:

Flujo Modbus TCP del PLC simulado

Flujo Modbus TCP del PLC simulado

Este flujo realiza dos funciones: la primera es levantar el servidor Master MODBUS, que escucha en la IP 192.168.0.39 por el puerto 1502/TCP. La segunda inyecta los valores por defecto en las 3 bobinas (posiciones de memoria 1 a 3) que se han definido para almacenar los valores de la iluminación LED RGB. En este caso, las tres bobinas se inicializan a cero (FALSE lógico).

Actuador TCP
El actuador TCP se ha implementado como un esclavo Modbus que consulta al PLC el estado de las tres bobinas que controlan el estado de los LED RGB. En función de la lectura realizada del valor de dichas bobinas, enciende o apaga la iluminación LED. Al ser tres las bobinas implementadas, la iluminación puede tomar un máximo de 8 valores combinados (considerando “apagado” como uno de los estados posibles).
La implementación del actuador se ha realizado mediante un dispositivo NodeMCU, que permite su programación mediante el IDE Arduino, con capacidades de conectarse a una red WiFi. Se ha hecho uso de la librería Modbus-Arduino para la implementación del cliente.

Actuador desarrollado con NodeMCU

Actuador desarrollado con NodeMCU

Actuador con iluminación en azul

Actuador con iluminación en azul


Actuador con iluminación en rojo

Actuador con iluminación en rojo

Kali Linux
Para simular la intrusión de un atacante externo se ha hecho uso de una Raspberry Pi con la distribución Kali Linux instalada. Kali Linux es una distribución de Linux especialmente pensada para servir de herramienta para realizar tests de intrusión en el ámbito del hacking ético y auditorías de seguridad de sistems de información.

Se ha realizado el siguiente flujo de ataque:

  1. Reconocimiento: Mediante ingeniería social (fuera del laboratorio) se ha determinado la existencia de un sistema de iluminación LED basado en Modbus.
  2. Escaneo: Una vez conseguido un equipo en la red, se ha procedido a un escaneo de la red en busca del dispositivos que escuchen en el puerto Modbus(habitualmente 502/TCP, pero para este caso se ha hecho uso de 1502/TCP) con ZenMap, cliente gráfico para NMAP.
  3. Ganar acceso: Una vez identificado el equipo Master Modbus, se ha realizado un proceso de escucha mediante modbus-cli, una herramienta desarrollada en Ruby disponible para Kali, que permite escanear y escribir sobre sistemas MODBUS. En una primera fase se ha escuchado hasta determinar las bobinas que controlan el sistema de iluminación, y en una segunda fase, se han realizado cambios sobre la misma.
  4. Para el laboratorio no se han realizado el resto de fases del hacking (mantener acceso ni borrar huellas).

En el siguiente artículo se detallarán los resultados obtenidos en el laboratorio.

VN:F [1.9.20_1166]
Rating: 10.0/10 (1 vote cast)

Etiquetas: , , , , , ,

08 jun 13 Copia de seguridad y compresión de tarjetas SD en Linux

Hoy traigo un mini-tutorial de cómo hacer imágenes comprimidas de memorias externas (SD, USB…) en Linux.
Para crear las imágenes:

dd if=/dev/sdX | gzip -9 > /ruta/a/backup.img.gz

…siendo sdX el dispositivo a clonar.

Para restaurar las imágenes:

gzip -dc ruta/a/backup.img.gz | dd of=/dev/sdX

…siendo iguamente sdX donde restaurar la imagen.

Pero si queremos ser creativos, podemos hacer esto mismo, enviado las imágenes a un tercer servidor:

dd bs=1M if=/dev/sdX | ssh user@host ‘gzip -9 > /ruta_remota/a/backup.img.gz’

…algo sumamente útil si, por ejemplo, estamos haciendo diabluras con una Raspberry Pi y contamos -obviamente- con poco espacio en el sistema local.

VN:F [1.9.20_1166]
Rating: 0.0/10 (0 votes cast)

Etiquetas: , , , , ,

13 oct 09 Monitorizar el uso de memoria en linux en tiempo real

Algunas veces es necesario realizar monitorizaciones en tiempo real del uso de memoria en linux, y nuestro viejo amigo top se queda algo escaso. En realidad, la mejor manera de ver el uso de memoria en un sistema linux es leer el fichero /proc/meminfo. Lo malo es que esto sólo nos proporciona una imagen estática del sistema. Para solucionar este inconveniente, podemos hacer uso del comando watch. Este programa nos lanza el comando que le indiquemos de manera periódica. Por ello, si ejecutamos la siguiente línea de comandos:

$ watch -d 'cat /proc/meminfo'

…podremos ver cada dos segundos los cambios en el fichero /proc/meminfo, con las diferencias producidas remarcadas (opción “-d”). Gracias a Strato_cuervo por darme la pista.

He encontrado también una entrada muy interesante de cómo crear gráficas de uso de memoria en linux: Gráficos del uso de memoria en Linux A esta entrada ya le dedicaremos más tiempo otro día.

Por cierto, agradecería recomendaciones de manera eficientes de medir el uso de recursos en linux… con lo que pueda venir en una instalación por defecto en una máquina convencional. Nunca se sabe cuándo tienes que monitorizar una máquina instalada en el año del poncio…

VN:F [1.9.20_1166]
Rating: 10.0/10 (3 votes cast)

Etiquetas: , , ,

15 jun 09 Streaming de webcam para monitorización remota

Una de las grandes ventajas de los sistemas linux es su flexibilidad: permiten desde realizar instalaciones estándar de escritorio hasta realizar instalaciones de grandes servidores de procesos de datos. Hoy voy a hablar de una posibilidad que permiten: realizar un sistema de monitorización remota mediante webcam. Esta aplicación respondería al siguiente esquema:

  • Una estación remota, con un sistema linux básico con una instalación en modo consola, y una webcam añadida. Idealmente este equipo debería ser de pequeño formato, como un Pico-ITX, pero cualquier equipo sería válido. Con una instalación básica de consola sería más que suficiente.
  • Un equipo de escritorio, dedicado a la monitorización. Este equipo, en desde el que se va a realizar el control de la estación remota, requeriría disponer de un entorno gráfico, a discreción del usuario

El sistema operativo, obviamente, tendría que ser linux. Cualquier distribución valdría, pero por mis preferencias personales he de recomendar Debian, una magnífica distribución con la flexibilidad suficiente como para permitir una sencilla instalación de estos dos entornos tan diferentes.

La piedra angular de esta instalación es el programa netcat, la navaja suiza de los administradores de sistemas. Esta herramienta tiene como principal característica es su capacidad para abrir puertos TCP/IP y redireccionar flujos de datos del sistema operativo por ellos. También tiene una función trascendental los túneles SSH, que permiten enlazar puertos en una máquina remota (a la que se realiza la conexión SSH) con otra máquina que esté en la red local del sistema cliente (esto también incluye, obviamente, la propia máquina cliente).

Otra suposición de la que partimos es que el cliente y el servidor NO se encuentran en la misma red local, sino que se encuentran en redes separadas, ya sea porque hay algún elemento como un cortafuegos interpuesto, o bien porque se encuentran enlazadas por una red WAN. En cualquier caso, algo impide impide que se pueda acceder a cualquier puerto entre el cliente y el servidor, estando limitado a accesos por puertos bien conocidos, como SSH.

En primer lugar, habría que configurar el sistema operativo del servidor para que reconozca la webcam. Esta tarea queda fuera de este mini-tutorial, por lo que me remito a internet para realizar esta labor. Sin embargo, en un sistema linux reciente, tendría que ser más que suficiente con instalar Video For Linux 2, ya que los módulos necesarios suelen venir por defecto en el kernel. Esto debería provocar que la webcam, al ser conectada al servidor, haga aparecer el dispositivo /dev/video0 (o algo por el estilo).

Una vez hecho esto, la idea en el servidor es la siguiente: recoger el flujo de datos de la webcam a través del dispositivo correspondiente (/dev/video0,o el que corresponda), y mediante netcat, abrir un puerto (por ejemplo, el 2000) y dirigir el flujo de datos anterior a este puerto, que estará preparado para recibir conexiones. Esto se haría mediante el siguiente comando:

$ cat /dev/video0 | nc -l -p 2000

Por otro lado, en el cliente, habría que realizar la siguiente operación: realizar un túnel SSH al servidor, de tal manera que se enlace el puerto que hemos abierto en el servidor (en este caso, el 2000) con un puerto en la máquina cliente (en este caso, el 270001). A continuación, con netcat se recoge el flujo de datos del puerto 27001; por último, mediante un pipe, se recoge la salida del comando anterior (que sería mostrada por la salida estándar) hacia un programa de visualización de vídeo adecuado, como mplayer o xine. La sucesión de comandos sería la siguiente:

ssh -f -L 27001:127.0.0.1:2000 usuario@servidor sleep 10; nc 127.0.0.1 27001 | xine -

Un cutre-esquema de lo expuesto anteriormente sería el siguiente:

Diagrama de la instalación

Diagrama de la instalación

Con toda esta película conseguiríamos visualizar desde el equipo cliente la webcam del servidor.

Una pequeña variación de lo anterior permite, por otro lado, hacer streaming de ficheros de vídeo (o audio). Con el siguiente comando abriríamos el puerto local 2000 para accesos desde un servidor remoto, que leerían del fichero video.avi:

nc -l -p 2000 < video.avi

Por la parte del cliente seguiríamos usando el comando anterior.

Existen algunos corolarios a este mini-tutorial. Uno de ellos consistiría en lograr que el acceso al servidor sea sin contraseña, basándonos en el uso de certificados de usuario. Pero eso ya quedará para otro día.

VN:F [1.9.20_1166]
Rating: 5.0/10 (1 vote cast)

Etiquetas: , , , , , ,