msgbartop
Winter is coming…
msgbarbottom

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: , , , , , , , ,

26 may 16 Comunicación serie con dispositivos ATtiny mediante TinyDebugSerial

Una de las dificultades a las que hay que enfrentarse a la hora de trabajar con dispositivos ATtiny (84/85, etc…) es la carencia de un dispositivo de comunicación serie, como se tiene con los Arduinos convencionales. Esto lleva a que sea difícil en ocasiones realizar tareas de diagnóstico de errores y resolución de problemas. Sin embargo, existe una (varias, en realidad) manera de comunicar mediante conexión serie con los ATtiny. La que yo he podido comprobar que funciona a la perfección es el uso de un adaptador USB a TTL.

Como requisitos previos para que esta solución funcione podemos distinguir los siguientes:

  • Utilización de los cores Arduino Tiny (http://code.google.com/p/arduino-tiny/)
  • Uso de un adaptador USB-TTL. En mi caso, estoy haciendo uso del adaptador SKU145351, que se puede encontrar a un precio muy reducido por Ebay. El mío monta el chip Silicon Labs CP2102.

Con estos componentes es posible hacer uso de comunicación TinyDebugSerial. Esta opción sólo permite la comunicación TX, es decir, el envío de información serie desde el Attiny al PC, pero para labores de resolución de errores es perfectamente válida.

Un ejemplo de comunicación básica sería el siguiente:

void setup() {
Serial.begin(9600);
}

void loop() {
Serial.println("Testing..");
}

Las conexiones con los ATtiny se realizarían haciendo uso de los siguientes puertos:

Attiny85: PIN PB3 (Pin físico 2)
Attiny84: PIN PB0 (Pin físico 2)
Attiny2313: PIN PD1

…además de los habituales puertos VCC y GND.

Conexión serie USB al ATiny

Conexión serie USB al ATiny

Nótese que no hay diferencias en el código con el que se cargaría en un Arduino convencional, y no se necesitan librerías añadidas. También es importante tener en cuenta que esta comunicación será válida para frecuencias de reloj de 8 MHz o inferiores.

Bibliografía:
Serial communication with the Tiny’s
Added TinyDebugSerial to attiny85

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

Etiquetas: , , , , , ,

12 dic 15 Attiny85: módulo RF a 433 MHz, modo de bajo consumo, y cómo despertarlo con interrupciones

Hace ya bastante tiempo escribí algo acerca de un sistema de riego controlado por WhatsApp que estuve desarrollando. Se basaba en el uso de una Raspberry Pi que actuaba como cerebro del sistema de riego y de comunicaciones, permitiendo el control de todo el sistema mediante mensajería por WhatsApp. La Raspberry, a su vez, se comunicaba con los los relojes de riego mediante módulos de radiofrecuencia a 433 MHz, un sistema de comunicación barato y razonablemente efectivo. En el otro lado, como se comentó en su momento, la válvula de riego se controlaba con un chip Attiny85, programado mediante Arduino.

Como se vio en su momento, el sistema funcionaba razonablemente bien. Sin embargo, varios problemas me llevaron a un callejón sin salida. El principal de ellos, y del que hablaremos hoy, era el consumo del receptor Attiny85. Sobre el papel es un sistema de muy bajo consumo, óptimo para este tipo de funciones. Sin embargo, el sistema de control de la válvula de riego no dejaba demasiado espacio para una batería, así que la alimentación disponible era, como poco, reducida. Pronto se demostró el que el Attiny con el sistema de radiofrecuenca devoraba la batería. Ésta apenas duraba unas 48-72 horas. Y esto, en un sistema que se supone que ha de ser autónomo y con un bajo mantenimiento, era sencillamente inaceptable, sobre todo si lo comparamos con relojes de riego de jardón convencionales, que con un par de pilas AA o una pila cuadrada de 9v pueden funcionar de manera ininterrupida durante meses.

Probé varias soluciones, desde el uso inicial de una batería recargable de 9v hasta el uso de un panel solar con una batería de móvil incorporada. Éste último caso consiguió producir mejoras, llegando el sistema a funcionar durante una semana de manera ininterrumpida. Pero en cualquier caso, no era una gran mejora. Tocaba afrontar el problema de base: un exceso de consumo.

Batería cuadrada de 9v y panel solar con regulador

Batería cuadrada de 9v y panel solar con regulador

En efecto, el problema estaba provocado por un exceso de consumo. Tal y como estaba diseñado, el sistema estaba permanentemente a la escucha de señales por RF, en un bucle sin fin, dado que la señal de encender o apagar la válvula de riego podía darse en cualquier momento. Esta aproximación era, como poco, inadecuada desde el punto de vista del consumo.

Para mejorar esto, probé varias alternativas: desde emitir sólo en determinadas ventanas de tiempo, hasta desconectar la alimentación al módulo de radiofrencuencia y activarlo sólo durante varios segundos cada minuto. Opciones bastante malas, la verdad, ya que se basaban en la precisión de un reloj interno que, como es conocido, no es un prodigio de la precisión.

Otra posibilidad hubiera podido ser un método en el que el Attiny consultara a la Raspberry si había algún comando por ejecutar. Pero por desgracia, los módulos RF de 433 MHz son unidireccionales, por lo que hubiera sido preciso incorporar un emisor al Attiny y un receptor a la Raspberry, complicando de manera innecesaria todo el sistema. Finalmente, la solución vino de mano de dos elementos presentes en el Attiny. El modo sleep y el uso de interrupciones.

El Attiny85 dispone de varios modos de bajo consumo (sleep mode) que sirven para reducir el consumo del chip cuando está a la espera de algún evento. En el caso del Attiny85, puede reducir el consumo hasta en un 90%. Pero no se trataba sólo de dormir al chip, sino de ser capaz de despertarlo cuando se recibiera una recepción de datos en el módulo de RF. Y para ello, nos encontramos con las interrupciones.

Las interrupciones son eventos que provocan un cambio en el estado de reposo o ejecución de un programa -en este caso, un programa cargado en el Attiny85-. Hay interrupciones tanto hardware como software, siendo las hardware las provocadas por un evento externo al programa en sí. Dentro de las interrupciones hardware, en el caso de Arduino, podemos distinguir las interrupciones Externas, y las provocadas por un Cambio en el Pin. El nombre es un poco confuso, pues ambas son externas al chip en sí, pero mientras las Externas están limitadas a un número concreto de patillas en el chip, las de Cambio en Pin pueden ocurrir en cualquiera de las patillas. En el caso concreto del Attiny85, las Externas sólo se producen en el Pin2 (INT0, patilla 7), mientras que las de Cambio en Chip se pueden producir en cualquier otra patilla.

De hecho, es factible despertar al Attiny85 del modo de bajo consumo mediante el uso de interrupciones. En el caso concreto del artículo enlazado, se usa el Pin3 (patilla 7) -luego se usa el modo de Cambio de Pin- para despertar al chip del modo de bajo consumo, como he podido comprobar personalmente (el ejemplo se basa en el uso de un botón conectado a 5v). Sin embargo, a la hora de probarlo con el módulo de RF a 433 MHz el sistema no funcionaba. No era capaz de realizar cambios en el sistema.

A modo de recordatorio, el sistema de control de la válvula consiste básicamente en un relé que activa o desactiva la válvula en función del tiempo que se desea mantener activo el riego. Este relé está controlado por una de las patillas del Attiny, protegida mediante un optoacoplador.

Tras varias pruebas, pude averiguar que el problema estaba causado por una particularidad en el receptor del módulo RF. Sólo he sido capaz de hacerlo comunicar con el chip Attiny a través del del pin de Interrupción Externa (Pin2, INT0), por lo que el ejemplo referenciado anteriormente no resultaba válido. En mi caso, ha sido necesario hacer uso de la patilla INT0:

#include
#include
#include

RCSwitch mySwitch = RCSwitch();
const int rele = 4;
const int dataPin = 0; //INT0, PCINT2
void setup() {
pinMode(dataPin, INPUT);
digitalWrite(dataPin, HIGH);
pinMode(rele, INPUT);
mySwitch.enableReceive(dataPin);

// Flash quick sequence so we know setup has started
for (int k = 0; k < 10; k = k + 1) {
if (k % 2 == 0) {
pinMode(rele, OUTPUT);
}
else {
pinMode(rele, INPUT);
}
delay(250);
} // for
}

void sleep() {

GIMSK |= _BV(PCIE); // Enable Pin Change Interrupts
PCMSK |= _BV(PCINT2); // Use PB3 as interrupt pin
ADCSRA &= ~_BV(ADEN); // ADC off
set_sleep_mode(SLEEP_MODE_PWR_DOWN); // replaces above statement

sleep_enable(); // Sets the Sleep Enable bit in the MCUCR Register (SE BIT)
sei(); // Enable interrupts
sleep_cpu(); // sleep

cli(); // Disable interrupts
PCMSK &= ~_BV(PCINT2); // Turn off PB2 as interrupt pin
sleep_disable(); // Clear SE bit
ADCSRA |= _BV(ADEN); // ADC on

sei(); // Enable interrupts
} // sleep

ISR(PCINT0_vect) {
// This is called when the interrupt occurs, but I don't need to do anything in it
}

void loop() {

if (mySwitch.available()) {

sleep();
int value = mySwitch.getReceivedValue();

if (value == 0) {
// Serial.print("Unknown encoding");
} else {

pinMode(rele,OUTPUT);
delay(10000);
pinMode(rele,INPUT);
}
mySwitch.resetAvailable();
}
}

(Explicación rápida del ejemplo: Se declaran INT0 como receptor de RF, y el Pin4 como control del relé. Se realiza un ciclo de encendido y apagado del relé al inicio para mostrar que el programa ha iniciado, se declara la interrupción del modo de bajo consumo con INT0, y se pasa al bucle principal. Se espera a una interrupción, se comprueba que la señal RF recibida es correcta, y se enciende el relé durante 10 segundos)

Resultado: ¡éxito! No sólo el sistema funciona, sino que he podido comprobar una gran mejora en el consumo del sistema. Durante la fase activa del programa, en la que el relé está activo y se ha recibido la señal de radiofrecuencia, todo el sistema consume unos 9 mA. Cuando está en modo de bajo consumo, a la espera de recibir la señal, baja a niveles inferiores a 1 mA.

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

Etiquetas: , , , ,

21 sep 14 Solución a la lentitud del IDE Arduino en Windows 7

Desde hace algunas semanas vengo notando una exasperante lentitud a la hora de hacer uso del IDE de Arduino en Windows 7. El tiempo de carga inicial es exagerado, pero aún lo es más el uso del menú de Herramientas (Tools). Y todo ello especialmente si lo comparamos con la respuesta del IDE en Debian, en una máquina mucho más limitada.

Por suerte, tirando del hilo he podido encontrar este artículo: Slow Arduino IDE, en el que explican que la causa del problema reside en una librerñia para comunicarse con los puertos de comunicación (rxtx), que al ser el IDE es un proyecto de plataforma cruzada, da algunos problemas en Windows, tanto Vista, como 7 en adelante.

¿La solución? Reemplazar la dichosa librería por una optimizada para Windows. Y aunque el artículo es antiguo, el mismo autor ha realizado una actualización este verano, indicando que la solución sigue siendo válida.

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

Etiquetas: , ,

22 mar 14 Riego de jardín con WhatsApp y radiofrecuencia

Llevo unas cuantas semanas sin escribir, y es que entre el trabajo y diversas ocupaciones no he podido ponerme a darle a la tecla. Sin embargo, no he estado ocioso todo este tiempo. Y este vídeo es la prueba de ello:

Como se puede ver (aunque un poco oscuro), se trata de un reloj de riego de jardín controlado por WhatsApp. Los mensajes son enviado por WhatsApp y recibidos por una Raspberry Pi, que activa el reloj de riego mediante radiofrecuencia.

El reloj, por otro lado, está controlado por un chip Attiny85, programado con Arduino. El conjunto está alimentado por una batería de 9v. Con un regulador se baja el voltaje a 5v, que proporciona alimentación tanto al sistema attiny como al propio motor de riego. El esquema básico de funcionamiento es el mismo que el de este diagrama…

Diagrama de control RF del sistema de riego con Raspberry y Arduino

…pero reemplazando el arduino por el attiny.

Otro día, con más tiempo, doy más detalles del funcionamiento.

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

Etiquetas: , , , , , ,