msgbartop
Lasciate ogne speranza, voi ch’intrate
msgbarbottom

10 jul 19 Hacking lab sobre Modbus TCP. Proceso de intrusión en el sistema

Esta entrada es la parte 3 de 3 de la serie Hacking Lab Modbus TCP

El tercer capítulo de esta serie describe el proceso a seguir para lograr una intrusión en el sistema. Para realizar este proceso, se han seguido los pasos descritos en la metodología de hacking ético desarrollados por el Centro de Ciberseguridad Industrial. En concreto, las fases realizadas son las siguientes:

Fase de Reconocimiento

La fase de reconocimiento consistió en determinar qué equipo de la red de sistema escuchaba tráfico MODBUS. Para ello, se hizo uso de ZenMap, interfaz gráfica para NMAP. Se realizó un escaneo a la red entre los puertos 1 y 2000, para el segmento 192.168.0.0/24, determinándose que el equipo con IP 192.168.0.39 escuchaba en el puerto 1502/TCP. Ninguno de los demás equipos descubiertos en la red escuchaba en dicho puerto.

Resultado del comando NMAP ejecutado en Zenmap

Resultado del comando NMAP ejecutado en Zenmap

Comando ejecutado: nmap -p 1-2000 -T4 -A -v 192.168.0.0/24

El resultado de nmap para dicho servidor fue el siguiente:

Initiating SYN Stealth Scan at 23:24
Scanning 192.168.0.39 [1 port]
Discovered open port 1502/tcp on 192.168.0.39
Completed SYN Stealth Scan at 23:24, 0.30s elapsed (1 total ports)
Initiating Service scan at 23:24
Scanning 1 service on 192.168.0.39
Completed Service scan at 23:25, 68.99s elapsed (1 service on 1 host)
Initiating OS detection (try #1) against 192.168.0.39
WARNING: RST from 192.168.0.39 port 1502 -- is this port really open?
WARNING: RST from 192.168.0.39 port 1502 -- is this port really open?
WARNING: RST from 192.168.0.39 port 1502 -- is this port really open?
WARNING: RST from 192.168.0.39 port 1502 -- is this port really open?
WARNING: RST from 192.168.0.39 port 1502 -- is this port really open?
WARNING: RST from 192.168.0.39 port 1502 -- is this port really open?
NSE: Script scanning 192.168.0.39.
Initiating NSE at 23:25
Completed NSE at 23:25, 0.04s elapsed
Initiating NSE at 23:25
Completed NSE at 23:25, 0.04s elapsed
Nmap scan report for 192.168.0.39
Host is up (0.00023s latency).
PORT STATE SERVICE VERSION
1502/tcp open shivadiscovery?
Warning: OSScan results may be unreliable because we could not find at least 1 open and 1 closed port
Device type: general purpose
Running: Linux 2.4.X
OS CPE: cpe:/o:linux:linux_kernel:2.4.21
OS details: Linux 2.4.21
Network Distance: 0 hops

Se puede apreciar cómo se ha encontrado abierto el puerto 1502/tcp en el elemento de red 192.168.0.39, que según nuestro diagrama, corresponder al PLC simulado que recibe los comandos para encender y apagar las luces.

Fase de escaneo

Una vez determinado el equipo que actúa como PLC recibiendo comunicaciones Modbus, se utilizó la herramienta modbus-cli disponible en Kali con el fin de intentar determinar las bobinas que controlaban el sistema de iluminación. Se hizo una lectura de las 20 primeras direcciones de memoria del PLC identificado. Tras sucesivas pruebas, se pudo determinar que los valores que variaban eran las relativas a las direcciones de memoria 2 a 4:

Resultados de los escaneos con modbus-cli

Resultados de los escaneos con modbus-cli

De acuerdo a la especificación del protocolo Modbus, los primeros 9999 registros de memoria corresponden a bobinas con valores TRUE o FALSE (1 o 0):

Tipos de registros de memoria en función de su dirección

Tipos de registros de memoria en función de su dirección

Una vez determinados estos valores, pudo pasarse a la siguiente fase del ataque.

Fase de ganado de acceso
En el caso de protocolo Modbus, al ser un protocolo que no tuvo en cuenta en su fase de desarrollo ninguna medida en especial de seguridad, es tremendamente sencillo acceder al sistema para realizar cambios. Se trata tan sólo de inyectar los valores correspondientes mediante las oportunas señales de control, ya que no se hace verificación alguna de origen, identidad, permisos, ni se realiza autenticación alguna. En este caso, basta con ejecutar el mismo modbus-cli en modo escritura para alterar los valores registrados en el PLC:

# modbus write -p 1502 192.168.0.39 2 0 0 0

Sucesivos comandos de cambio de estado

Sucesivos comandos de cambio de estado

Estado final del sistema de iluminación

Estado final del sistema de iluminación

El resultado de dichos comandos fue, en primer lugar, el apagado completo de la iluminación, y posteriormente, el encendido de la iluminación en verde, controlada por la bobina 3. Estos cambios se vieron reflejados en la interfaz HMI del sistema, por lo que un operador podría haber determinado la existencia de un comportamiento anómalo del sistema.

Interfaz HMI reflejando el cambio de estado

Interfaz HMI reflejando el cambio de estado

Sin embargo, no es tan sencillo introducir valores fuera de rango. Al intentar inyectar valores distintos de 0 o 1 en las bobinas, la herramienta devolvió un mensaje de error, y no se alteró el funcionamiento del sistema:

root@raspberrypi:/home/pi# modbus write -p 1502 192.168.0.39 2 10 10 10
ERROR: parameter 'VALUES ...': Value should be in the range 0..1

See: 'modbus write --help'

En lo referente a las dos últimas fases (Mantener Accesso y Borrar Huellas) excedía el ámbito de lo buscado en este piloto, por lo que no se han desarrollado de manera explícita.

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

Etiquetas: , , , , , , ,

06 jul 19 Hacking lab sobre Modbus TCP. Elementos configurados

Esta entrada es la parte 2 de 3 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: 0.0/10 (0 votes cast)

Etiquetas: , , , , , ,

03 jul 19 Hacking lab sobre Modbus TCP. Introducción

Esta entrada es la parte 1 de 3 de la serie Hacking Lab Modbus TCP

Por temas relacionados con un máster de ciberseguridad industrial que estoy cursando he tenido que preparar una serie de ejercicios para el mismo, entre los que se encuentra la realización de un hacking lab. La idea de un hacking lab es preparar un entorno controlado en el que poder hacer ataques a un sistema para aprender posibles vulnerabilidades, técnicas para desvelarlas, y herramientas que se pueden utilizar para ello, a fin de ser capaz en un futuro de proteger un entorno real con las lecciones aprendidas en el entorno de pruebas.

Para la realización de este hacking lab opté por preparar un escenario en el que se pudiera realizar un ataque a un entorno de control industrial que hiciera uso de comunicaciones basadas en Modbus sobre TCP. Modbus es un protocolo de comunicación industrial desarrollado en 1979, y que constituye un estándar de facto en los sistemas de producción industrial. El objetivo general es perturbar el funcionamiento de un sistema de iluminación LED cuyo sistema de control está implementado empleando Modbus sobre TCP. El mismo consta de los siguientes elementos:

  • Una red plana que simula una red de control industrial. En este caso es una red del rango 192.168.0.0/24. Si bien en un caso real sería una red cableada, para este escenario de prueba es una red mixta cableada y WiFi, con un enrutador proporcionando conectividad a los distintos elementos de la misma.
  • Un PLC que actúa como Master Modbus, y que permite controlar, mediante el uso de tres bobinas (coils), el encendido y apagado de un sistema de iluminación LED de colores rojo, verde y azul. Este PLC, al no tener disponible ningún dispositivo real disponible, se simula mediante el aplicativo Node-RED de IBM con una librería Modbus desarrollada al efecto. Este PLC (virtual) tiene la IP 192.168.0.39, y escucha en el puerto 1502 (por razones de privilegios en el dispositivo, no se ha hecho uso del puerto estándar 502/TCP de Modbus).
  • Un actuador físico como Slave Modbus, que en base a las lecturas que realiza de los valores de las bobinas del Master Modbus, enciende y apaga los LEDs del sistema de iluminación. Este actuador físico se ha implementado con un dispositivo ESP8266 programado mediante Arduino IDE y librerías específicas. Las comunicaciones con el Master Modbus se realizan mediante protocolo Modbus sobre TCP. El actuador tiene la IP 192.168.0.34.
  • Un HMI de control de las luces, que permite controlar el encendido y apagado de las mismas mediante una aplicación web tipo SCADA. Este HMI se ha desarrollado mediante el aplicativo Node-RED de IBM y las librerías gráficas para desplegar cuadros de mando, así como una librería MODBUS desarrollada al efecto. EL HMI tiene la IP 192.168.0.31.
  • Un dispositivo atacante, que tiene como objeto descubrir sistemas Modbus en la red desplegada, e interferir los valores normales de operación de los mismos. Este dispositivo es una Raspberry Pi con Kali Linux instalado, teniendo la IP 192.168.0.99.

El siguiente diagrama de red muestra el sistema desarrollado:

Diagrama de la red

Diagrama de la red

En siguientes artículos iré dando mayor detalle de los dispositivos del entorno, así como de los pasos dados en el hacking lab, además de las conclusiones obtenidas de la puesta en marcha del mismo.

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

Etiquetas: , , , , , , , ,

21 jun 17 Emulador software de teclado mecánico IBM Model M

Un compañero de trabajo me ha pasado un enlace a un proyecto Github que promete ser una verdadera herramienta del mal: un emulador por software del sonido de un teclado mecánico IBM Model M.

Su instalación es extremadamente sencilla: está incluido en los repositorios de Debian y Ubuntu, no da mucha guerra para instalarlo en otras distribuciones, además de estar disponible para Mac y Windows. Puedo atestiguar que el efecto es tremendamente realista:

Y sé que es algo completemante psicosomático, pero me da la impresión de que escribo más cómodo en mi portátil desde que lo he instalado. Eso sí, ni Ana ni mis compañeros de trabajo -aparte del enajenado fanático de los teclados mecánicos que me lo ha pasado- creo que aprecien este descubrimiento en demasía. :mrgreen:

VN:F [1.9.20_1166]
Rating: 6.5/10 (2 votes cast)

Etiquetas: , ,

15 jun 17 Mitigación de los problemas de sobrecalentamiento de la Orange Pi Zero

En fechas recientes he adquirido un par de Orange Pi Zeros para algunos proyectos personales. Para quien no las conozca, las Orange Pi Zero son una interesante copia china de las Raspberry Pi, con un precio casi imbatible de 15$ contando el modelo de 512 MB de RAM y cuatro cores, junto con un módulo de expansión de puertos y una carcasa bastante maja.

Placa Orange Pi Zero

Placa Orange Pi Zero

El problema es que montan un procesador ARM que funciona a 1200 MHz, que tiene una irritante tendencia a sobrecalentarse más que una plancha de acero a pleno sol en Córdoba un 15 de agosto. En Irlanda, con una temperatura ambiente que rara vez sube de los 22 grados ya es problemático, así que cuanto más en Córdoba, donde tengo una de las Zero:

83ºC... ¡y sin hacer nada, por la mañana, y a la sombra en interior!

83ºC… ¡y sin hacer nada, por la mañana, y a la sombra en interior!

Así que para no acabar con una bonita fogata quad-core, toca tomar medidas. La solución más básica es empezar por procedimientos mecánicos. Un disipador, vaya. El problema es que la Zero es pequeña, muy pequeña. El procesador central tiene este tamano:

OPi Zero y su tamaño relativo

OPi Zero y su tamaño relativo

En efecto, el procesador es del tamaño de una moneda de 1 céntimo de Euro. Genial para construir sistemas pequeños, no tanto si tienes que encontrar un disipador de su tamaño. Puedes encontrarlos en Amazon o en Aliexpress, pero tardan un tiempo en llegar. En mi caso, al final, acabé canibalizando un viejo router, de donde pude sacar un disipador adecuado. Eso sí, de añadir un ventilador, más vale irse olvidando. Ya sólo el disipador me dio guerra para encajarlo en la caja:

OPi Zero con disipador

OPi Zero con disipador

De todas maneras, es una solución bastante razonable. En mi Orange Pi de Irlanda conseguí bajar la temperatura de unos 72ºC a unos 62ºC. El problema vino con la de Córdoba. A las 11 de la noche alcanzaba una temperatura de unos 85ºC. Vale que había unos 32ºC de temperatura ambiente (¡sí, a las 11 de la noche!), pero aun así, con disipador y todo, seguía resultando demasiado. Así que tocaba tomar medidas adicionales. En este caso, medidas software. Por suerte, el procesador que monta (SunXi H2+, una versión capada del H3) dispone de una utilidad para controlar diversos aspectos del procesador, como velocidad de proceso, número de cores activos, posibilidad de desactivar la tarjeta gráfica o la WiFi. En mi caso, y siguiendo las recomendaciones del enlace anterior, he optado por desactivar un par de cores, dejando sólo 2 activos, así como la GPU y la WiFi. La mejora ha sido considerable. En el caso del equipo de Córdoba, he conseguido moderar la temperatura (en plena mañana en Córdoba) desde más de 85ºC a menos de 75ºC. No es que sea la panacea, pero es una mejora notable.

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

Etiquetas: ,