El objetivo de esta publicación es mostrar
cómo simular una comunicación industrial tipo cliente-servidor, y capturar el tráfico con WireShark, esto con el fin de identificar posibles vulnerabilidades que pueden tener un protocolo industrial.
El protocolo
industrial elegido es
MODBUS, este
protocolo es ampliamente usado en sistemas de automatización y control.
MODBUS puede implementarse en redes basadas en ETHERNET, RS-485 y otros.
Los programas necesarios son:
Modbus Poll,
Modbus Slave,
CommView 6.5 (o
RawCap) y
Wireshark, los dos primeros pueden descargarse desde la página oficial
http://www.modbustools.com/download.asp
CommView (o RawCap) son necesarios para capturar el
tráfico local.
Durante la instalación de CommView se selecciona “Enterprise Mode” esto
con el fin de usar el modo “Loopback”. Al inicializar el programa
preguntará si se desea instalar un controlador, por lo general nos
encontraremos sobre LAN o ADSL, así que la repuesta es no.
En el caso del software RawCap, se trata de un ligero sniffer que
no requiere la instalación de drivers, sin embargo si requiere la
librería WinPcap. Su uso es tan sencillo como copiar el fichero y
ejecutarlo. En cuanto a su funcionamiento el RawCap trabaja con dos
argumentos, la dirección IP (de la interfaz) y el fichero destino.
Una de las características más importantes es que permite
capturar “loopback”, conexiones PPP o Wireless. Sin embargo no es
compatible con Windows Vista y Windows 7, ya que el método para capturar
“raw sockets” en estos sistemas es distinto y solamente deja almacenar
los paquetes que se reciben (Windows 7) o los que se envían (Windows
Vista).
Entorno Virtual
2 máquinas virtuales (Master y Slave) con direcciones IP en el mismo segmento de red, en este caso:
- Master
- Windows 7 Professional Media Center Edition x64
- IP: 192.168.1.35
- Slave
- Windows 7 Home x64
- IP: 192.168.1.36
Posterior a la instalación de ambas máquinas virtuales es necesario comprobar la comunicación entre ambas.
Configuraciones
En la virtual “Slave”. Se instala el software “Modbus Slave” y se
ejecuta, se pulsa F3 (aparecerá una ventana indicando que se trata de
“trial”, se debe pulsar “Register Later”), y se establece la opción
“Connection:” en “Modbus TCP/IP”, el resto de los campos de define por
defecto.
En el otro ordenador se debe instalar y ejecutar “Modbus Poll”, luego
oprimir F3 y continuar de similar manera a lo anterior, con la opción
“Connection:” en “Modbus TCP/IP”, y el resto por defecto.
En este punto se observa cómo va ascendiendo los valores de la
transmisión (Tx) en el Master (Modbus Poll). Desde “setup” podemos
cambiar diferentes opciones, a simple vista se observa: log, resetear el
contador, podemos variar el “Scan Rate”, etc.
En el caso de “Slave”, se puede escoger la primera “ID” y definir el
alias que se desee (humedad ambiental, velocidad del viento, caudal,
presión, etc), y establecer un valor deseado, teniendo en cuenta que
existe la opción para incrementar este valor automáticamente cada cierto
tiempo que pasa. No sólo asciende en Slave, sino que también lo
veremos en el Master.
Pruebas realizadas
Ahora empezamos con la captura de datos de la siguiente manera:
Abrir CommView (elegí este programa por razones de compatibilidad, se puede usar también RawCap), luego ir a “capturar datos”.
En el programa al lado de” play” y “stop” se selecciona “Loopback”,
para capturar el tráfico local, luego se selecciona la pestaña “Reglas”,
y se elige “Puertos “, “Agregar registro – Ambos a 502“, de esta forma
sólo se ve lo que entra y sale de ese puerto, dicho puerto corresponde
al protocolo Modbus.
Con Modbus en funcionamiento, se debe seleccionar play y posteriormente se obtendrá un resultado similar al siguiente:
Se observa como en Modbus Master comienza a incrementar el número de
paquetes transmitidos (Tx), por otro lado se van actualizando los dos
registros al mismo tiempo que se incrementan los registros en Modbus
Slave. Por lo que, si se modifica el valor de uno de los registros en el
Master se actualiza el valor del registro en el Slave.
Si se desconecta Modbus Slave, se observa cómo se producen errores
“Write Error” en el Modbus Poll. Para ello se selecciona desconectar en
Modbus Poll, luego se selecciona desconectar en el Modbus Slave.
Es posible observar el inicio y finalización de la conexión TCP así como
las tramas Modbus, dentro de las tramas se encuentra el campo “data
vga” en el mismo se aprecia sucesivos envíos y los cambios de valor en
los registros.
Una vez guardados los datos, estos pueden visualizarse en Wireshark, se
observan los números aleatorios incrementándose, los cuales fueron
definidos anteriormente.
Los parámetros capturados se muestran en la siguiente imagen:
Conclusiones
Los paquetes transmitidos bajo el protocolo Modbus son ligeros en
comparación a los protocolos tradicionales. Esto es perfectamente
entendible teniendo en cuenta que se necesita un “
Delay” muy bajo en sistemas industriales, donde la precisión en términos de tiempo (microsegundos), es muy importante.
Al ser las tramas cortas, los datos se transmiten casi instantáneamente.
Los datos son transportados en TEXTO CLARO. Este hecho indica la falta
de algoritmos criptográficos, lo cual ayuda a acelerar la transmisión
por razones de funcionalidad.
No obstante, esa simplicidad en las comunicaciones también implica una
gran vulnerabilidad a cierto tipo de ataques así como la
lectura/escritura de datos por parte de terceros (MITM por ejemplo).
Cualquier incidencia en uno de los dos equipos, ya sea un fallo del
protocolo de comunicaciones, hardware de red o un “cuelgue” momentáneo
debido a un gran consumo de CPU o RAM, tanto del cliente como del
servidor, puede originar afectar negativamente a la sincronización o
incluso una pérdida de datos, lo que conllevaría a un mal funcionamiento
de dispositivos industriales. Se debe tomar en cuenta también que una
amenaza no necesariamente puede ser una persona, existe la posibilidad
de que un malware especialmente diseñado pueda recolectar y manipular
las comunicaciones industriales de tipo MODBUS, tal y como fue el caso
de STUXNET.
Un saludo y muchas gracias a
SecurityByDefault por brindarme un espacio.
Artículo cortesía de César Cuenca (@ccuencad)
