volver volver
Qué es y cómo tramitar la firma digital de forma gratuita

POR:
Habib Gramondi
(Cybersecurity Researcher)

COMPARTIR

Twitter Facebook Linkedin
REFERENCIAS

⦁ Stevan A. Milinkovi, Member, IEEE and Ljubomir R.
Lazi, Member, WSEAS “Industrial PLC security issues”,
Serbia, Belgrade, November 20-22, 2012.

⦁ G. P. H. Sandaruwan, P. S. Ranaweera, Vladimir A.
Oleshchuk “PLC Security and Critical Infrastructure
Protection”, Dept. of Information and Communication
Technology, University of Agder (UiA),
N-4898 Grimstad, Norway

⦁ Abraham Serhane, · Mohamad Raad · Raad Raad
· Willy Susilo “Programmable logic controllers
based systems (PLC‑BS): vulnerabilities and threats”,
International University of Beirut,
146404 Mazraa, Beirut, Lebanon. University
of Wollongong, Northfields Ave,
Wollongong, NSW 2522, Australia.

Comprendiendo las redes industriales antes de atacarlas

Introducción:

A finales de los años 60, los Controladores Lógicos Programables (PLCs) fueron diseñados para eliminar el alto costo de los sistemas de control basados en relés, entendemos al relé como un pequeño componente eléctrico/electrónico con un comportamiento similar al del interruptor que cualquiera de nosotros tiene en su hogar para encender la luz, solo que se acciona mediante una señal externa sin la necesidad de que una persona lo active. El grupo Schneider Electric puede considerarse como protagonista de la llamada tercera revolución industrial junto a su Modicon, reconocido como el primer controlador lógico programable, su historia empezó cuando un pequeño grupo de jóvenes ingenieros que habían creado una pequeña ingeniería llamada Bedford Associates, dirigida por Dick Morley, decidieron presentarse a una convocatoria lanzada por la automovilística General Motors con el objetivo de buscar procesos de producción más eficientes.

Dick Morley junto a su equipo tuvieron una gran idea: reemplazar los relés que mencionamos anteriormente por tarjetas electrónicas, lo que permitiría programar nuevas funciones sin necesidad de recablear o cambiar el hardware. Obviamente, fue el proyecto ganador y es así como nació hace más de cincuenta años Modicon(MOdular DIgital CONtroler), al que denominaron 084 porque era precisamente el proyecto de Bedford Associates nº 84. Esta empresa vendió Modicon en 1977 a Gould Electronics, posteriormente fue adquirida por la alemana AEG en 1989.

imagen ilustrativa

El Modicon 084, es el primer PLC del mundo introducido en 1969. Imagen cortesía de Allen-Bradley, Rockwell


Para los años 80, los Sistemas de Control Distribuido (DCS) lograron popularidad dentro de entornos de plantas industriales ahora cada vez más automatizadas, teclados y estaciones de trabajo reemplazaban a los grandes gabinetes de control individuales. Líneas de producción enteras y procesos podrían estar conectados a través de redes de cable/bus industrial para proporcionar monitoreo y control desde el escritorio de un supervisor.
Los sistemas disponibles en ese momento eran, en todo sentido, propietarios, es decir distintas marcas intentaban capturar una cuota de mercado al mantenerse incompatibles con sistemas competitivos. A principios de los 80, surgió una estrategia para descentralizar a estos sistemas y se dio lugar a las al nacimientos de estándares de comunicación entre dispositivos como lo fue Fieldbus entre otros. Así comenzó el desenrollamiento de las estrategias de control central con una visión hacia el aumento de la inteligencia en cada dispositivo de campo y la utilización de tecnología no propietaria.

Actualidad:

Hoy en día, casi todos los controladores de PLC, DCS, Unidades Terminales Remotas (RTU) o Sistemas Integrados de Seguridad (SIS) en el mercado tienen un sistema operativo comercial como podemos ver en las siguiente tabla:

imagen ilustrativa

Las vulnerabilidades de Windows son abundantes y se informan en varias fuentes en Internet. Lo mismo ocurre con Linux y QNX. En cuanto a Microware OS-9 y VxWorks, estos sistemas operativos no son tan famosos como los anteriores, y en consecuencia sus errores y vulnerabilidades son menos conocidos. Sin embargo, las vulnerabilidades siguen existiendo y hablaremos de ellas más adelante.

Por otro lado la automatización industrial es uno de los términos más populares que se han discutido en la última década, las conexiones entre dispositivos ya no solo se limitan a una misma región geográfica, volviendo al ejemplo anterior, ahora el supervisor podría estar monitoreando a kilómetros de la planta desde su escritorio gracias a internet, este avance de arquitectura se conoce como la cuarta revolución industrial o industria 4.0 sin embargo junto a ella se abrieron las puertas a nuevas brechas de seguridad que iremos viendo a lo largo de este post.

La automatización es un aspecto importante cuando se trata de la industrialización. El objetivo de esta es minimizar la participación humana tanto física como mentalmente. La mayoría de la infraestructura crítica en el mundo se ha automatizado mediante dispositivos y sistemas electrónicos. Los ejemplos más comunes son los ascensores, las escaleras mecánicas y los trenes.

La infraestructura industrial depende en gran medida de los sistemas de control industrial (ICSs) automatizados que han alcanzado los más altos estándares en términos de eficiencia y rendimiento. Los ICSs consisten en sistemas de Control y Adquisición de Datos de Supervisión (SCADA), Sistemas de Control Distribuido (DCSs) y PLCs. Las principales funciones de tales ICS son detectar (recopilar datos), monitorizar, gestionar y realizar acciones (toma de decisiones basada en los datos recopilados).

En el siguiente diagrama podemos observar el modelo Purdue que fue adoptado de la Arquitectura de referencia empresarial de Purdue de ISA-95 y utilizado como modelo conceptual para la arquitectura ICS. Esta se puede resumir de la siguiente forma:

  • Enterprise
  • Level 5: Enterprise network
  • Level 4: Site business and logistics
  • Industrial Demilitarized zone.
  • Manufacturing zone (also called the Industrial zone):
  • Level 3: Site operations
  • Level 2: Área supervisory control
  • Level 1: Basic control
  • Level 0: The process

imagen ilustrativa

Arquitectura de referencia basada en ISA-95

Muchos creen que los PLCs son dispositivos seguros debido a su aislamiento de las redes externas del sistema. Sin embargo los ataques como Stuxnet (un peligroso gusano informático creado para atacar infraestructuras físicas donde su primer objetivo fue comprometer la infraestructura de las centrifugadoras de las instalaciones de enriquecimiento de uranio en Irán) han demostrado la incorrección de tales pensamientos. Los “virus informáticos” son ineficaces con los PLC. Pero los eventos recientes sugieren que los sistemas SCADA están en un riesgo significativo aunque estén aislados de la red principal de la planta.


En los años 2000, una planta de gestión de residuos de Queensland fue atacada por un ex empleado donde se arrojaron 800.000 litros de aguas residuales sin tratar en áreas públicas de la ciudad. Esto sucedió en Australia solo usando una computadora portátil y una radio inalámbrica(este hecho fue tomado como ejemplo por MITRE para desarrollar una nueva metodología respecto a las ICSs).

imagen ilustrativa

Planta de tratamiento de aguas residuales Maroochydore

En 2003 hubo un mal funcionamiento en dos sistemas importantes de monitoreo en la planta nuclear Ohio Davis-Besse debido a un ataque que penetró en las computadoras . Este tipo de mal funcionamiento también podría llevar a la pérdida de vidas civiles. Los incidentes ocurridos en 1999 y 1992 en Bellingham y Brenham, Texas, respectivamente, causaron tres muertes y grandes daños a la infraestructura debido a un mal funcionamiento del sistema de distribución de gas. Hubo dos trenes metropolitanos que chocaron en 2009, lo que resultó en muertes y lesiones a los pasajeros. Aunque ocurrieron tales incidentes, no hubo ningún entusiasmo entre la comunidad científica para explorar las preocupaciones de seguridad en sistemas automatizados relacionados con PLC hasta el pasado reciente.

Como mencionamos anteriormente luego del malware Stuxnet en 2010, hubo un interés especial entre los productores y usuarios de PLC para determinar las vulnerabilidades de seguridad asociadas en sistemas basados en PLC ya que este logró un nuevo nivel muy sofisticado de ataque. Fue el primero en incluir un rootkit, pudo espiar maliciosamente, comprometer o incluso explotar otras máquinas para iniciar ataques en otros sistemas. Demostró un ataque de ciberseguridad real y sofisticado que afectó catastróficamente varios sistemas como las interfaces de operarios, las pantallas de visualización, el código fuente dentro de los PLCs, aprovechándose de Zero Days de windows. En otras palabras, Stuxnet abrió un camino para redes diseñadas de PLC seguras. Los productores de PLC como Hitachi, Mitsubishi, Panasonic, Samsung y Siemens han estado trabajando con productores de antivirus como Kaspersky y Symantec para determinar soluciones para tales vulnerabilidades e ineficiencias en sistemas PLC.

Aunque los PLC son dispositivos confiables ya que garantizan su correcto funcionamiento en largos periodos de tiempo y en condiciones extremas. Un malware muy personalizado dirigido a sistemas SCADA de Siemens como Stuxnet es solo una amenaza típica que estos dispositivos podrían enfrentar; especialmente si hay ataques de ciber guerra. Stuxnet, si bien es uno de los más reconocidos se llevaron a cabo muchos otros ataques por otras amenazas como Flame, Guass, Duqu, Wiper y BlackEnergy malware. Se han descubierto más de 50 nuevos ataques que acechan los sistemas SCADA. Desde la aparición de Stuxnet, los PLC han atraído la atención de la comunidad de hackers.

imagen ilustrativa

Descubrimiento de vulnerabilidades SCADA por año - Vulnerabilidades SCADA’s y en otros componentes

Dispositivos dentro de una red Industrial

En esta sección del post veremos algunas definiciones básicas de dispositivos y términos que usaremos para plantear vulnerabilidades en dichos sistemas.

imagen ilustrativa

Arquitectura de referencia basada en ISA-99

PLCs

Los PLCs (Controladores Lógicos Programables) proporcionan uno de los controles principales de los sistemas SCADA. Cómo son dispositivos en tiempo real, los PLCs son responsables de automatizar la producción o un proceso mediante el monitoreo y control de la interacción en tiempo real con los dispositivos de campo a través de redes industriales. Los PLCs pueden manejar miles de entradas (estatus o retroalimentación de sensores, HMIs, otros PLCs, etc.) y salidas o comandos por segundo. Los PLCs utilizan ciertos programas, que residen dentro de ellos. Respecto al software dentro de los ellos consiste en lo siguiente:

Firmware

Los PLCs contienen un sistema operativo (SO) en tiempo real integrado, llamado firmware, como vimos anteriormente (OS-9 o VxWorks). Por lo general, se almacena en la memoria interna del PLC o en EEPROM (memoria de solo lectura programable y borrable eléctricamente). Si un atacante compromete el SO, todo el dispositivo controlado por los PLCs puede ser completamente tomado; abriendo la puerta a diversas amenazas y ataques maliciosos. Debido a su naturaleza y entorno, los PLCs, en general, carecen de características de seguridad como la criptografía o la detección de intrusiones mediante los tiempos de respuesta esperados en condiciones de operación normales.

Lenguaje PLC

Es un conjunto de métodos de lenguaje de programación, código, que el programador escribe para comunicar información al PLC. El código de los programas PLC se puede escribir utilizando cinco lenguajes estandarizados por la norma internacional IEC 61131, que es una norma internacional abierta. RSLogix5000, por ejemplo, es un software utilizado para escribir, editar y compilar códigos de lógica en escalera. El software cumple con las normas IEC 61131. Los lenguajes son los siguientes:

Diagrama en escalera (LD): Es una representación de instrucciones, símbolos, dispuestos en escalones que imitan esquemas de cableado.

imagen ilustrativa

Diagrama de Bloques de Funciones (FBD): Es una representación de bloques gráficos interconectados representan el flujo del proceso y los parámetros.

imagen ilustrativa

Gráfico de Función Secuencial (SFC): Es un lenguaje gráfico que consiste en estados o pasos (con acciones asociadas) y transiciones (con condiciones asociadas) utilizadas para pasar de un estado actual al siguiente. Los programas LD, FBD y ST se pueden escribir en la estructura SFC.

Texto Estructurado (ST): Es un lenguaje de alto nivel que se parece a "C" o "Pascal".

Lista de Instrucciones (IL): Es un lenguaje de bajo nivel que utiliza instrucciones mnemónicas y se asemeja al Assembler.

HMIs y otros terminales

Estos son paneles de interfaz de usuario o tableros que conectan a los operadores con los dispositivos de campo; para monitorear o controlar. Las HMIs solían ser paneles simples, aislados y dedicados que consistían en botones eléctricos, luces, interruptores, etc. Las HMIs, por ejemplo, permiten a los operadores poner el PLC en "Automático" o "Manual", abrir o cerrar válvulas, reconocer alarmas, detener ciertos dispositivos, etc. En la actualidad, las HMIs son más sofisticadas y complejas. Están construidas en sistemas operativos ampliamente conocidos como Windows y ejecutan programas basados en Windows. Pueden estar equipados con pantallas táctiles, ActiveX, bases de datos y capacidades de acceso remoto; y algunos incluso son servidores o basados en la web. La necesidad de monitorear, visualizar, archivar o incluso acceder remotamente a datos relacionados, ha llevado a las HMIs a un estado avanzado altamente diferente. En la actualidad, las HMIs se han desarrollado más hacia soluciones basadas en computadoras; por ejemplo, WinCC y FactoryTalk.
Las interfaces de máquina humana (HMIs) facilitan el acceso a cualquier proceso o evento industrial, evitando que los operadores tengan que revisar el código de lógica de escalera. Pueden utilizarse como terminales independientes, basadas en PC o incluso como aplicaciones de teléfonos inteligentes. Las HMIs admiten protocolos de red industrial líderes como Ethernet, PROFINET, Modbus, ControlNet, etc. Se pueden utilizar para controlar grandes sistemas y la mayoría de los dispositivos relacionados con PLCs. Además, muchas HMIs basadas en computadoras están equipadas con todo el software y herramientas de PLC necesarios, como TIA y RSLogix. Estas HMIs permiten a los usuarios acceder, monitorear, modificar o incluso programar cualquier código de PLC asociado; en línea o fuera de línea.

  • Las unidades de terminal de visualización (DTUs) permiten a los operadores controlar y monitorear procesos de producción, eventos o alarmas asociados. Muestran el estado de la información recopilada gráficamente. Son similares a las HMIs pero menos sofisticadas. Funcionan en sistemas operativos conocidos como Windows CE. Windows CE, por ejemplo, viene con controles ActiveX, conectividad remota a través de Ethernet, VNC y FTP.
  • Las unidades de terminal de historiadores (HTU) son dispositivos de registro que se basan en servidores o unidades de PC. Se utilizan para registrar o archivar (eventos, alarmas, actividades, etc.), monitorear dispositivos y actividades relacionadas con PLC. Son computadoras típicas de TI y, por lo tanto, sufren las mismas vulnerabilidades.

Periféricos y dispositivos de I/O

Los dispositivos de I/O (in/out), suelen estar interconectados a través de redes industriales de comunicación o conexión punto a punto física para monitorear o controlar actividades. Por lo general, constan de:

  • Sensores: proporcionan el estado de un dispositivo o proceso (como temperatura, caudal, posición, etc.) como entradas al PLC convirtiendo la información física en señales eléctricas.
  • Actuadores: convierten las señales eléctricas recibidas en acciones físicas. Ejemplos de actuadores: válvulas, solenoides, motores paso a paso, relés de potencia, etc.
  • Otros dispositivos que tienen operaciones físicas: robots industriales (soldadura, manipuladores de materiales, robots de visión, sellado, etc.), ascensores, etc.

Redes

La comunicación de datos entre PLC y dispositivos de campo puede establecerse a través de redes de comunicación industrial. Esas redes deben ser confiables, en tiempo real y precisas para manejar el monitoreo de datos y la controlabilidad de datos entre varios dispositivos. Las redes originalmente industriales comenzaron como enlace de comunicación punto a punto, limitado y directo. Un buen ejemplo de eso es una conexión por puerto serie.

imagen ilustrativa

Se utiliza una señal para transmitir (llevada desde el PLC a otros dispositivos o actuadores, es decir, una salida) o recibir (enviada al PLC desde un sensor, es decir, una entrada) a través de una conexión punto a punto o tarjetas terminales. Aunque está limitado, un enlace de comunicaciones serie punto a punto es menos vulnerable a las amenazas de seguridad. Sin embargo, con el avance de la tecnología y las necesidades emergentes, las redes industriales evolucionaron a un nivel más complejo. LAN (Red de área local) y WAN (Red de área amplia) son buenos ejemplos. Algunas redes industriales pueden manejar diagnósticos y encender dispositivos relacionados interconectados además de transportar señales desde/hacia PLC a través de módulos de I/O o escáneres como DeviceNet. Los dispositivos de campo, por ejemplo, como los dispositivos o módulos de I/O, se han vuelto más interconectados y basados en software (firmware). Los dispositivos de módulo de I/O ahora están conectados local o remotamente a redes industriales para obtener una mejor modularidad, reducir costos, reducir el cableado, instalación o mantenimiento fáciles y rápidos y buenos diagnósticos.

imagen ilustrativa

Algunas de las redes industriales actuales y ampliamente utilizadas son: Modbus, PROFINET, PROFIBUS, DeviceNET, ControlNet, EtherNet/IP. En general, las redes industriales consisten en dispositivos de I/O, módulos de escáner y cables de red. Un PLC se comunica con otros sensores, actuadores o dispositivos a través de una de las redes mencionadas anteriormente. DeviceNet, que se usa ampliamente, sería un buen ejemplo de tales avances. DeviceNet consta principalmente de los siguientes módulos: DNET Scanner, Armor-Block/ArmorPoint y Flex I/O, como pudimos ver en los gráficos anteriores. Cada módulo tiene su propio firmware que podría ser vulnerable a amenazas de seguridad.

imagen ilustrativa

Amenazas y vulnerabilidades

En esta sección del post veremos conceptos básicos sobre vulnerabilidades de los dispositivos mencionados anteriormente.

Vulnerabilidades de código del PLC

La atención a las vulnerabilidades del código PLC no ha sido una gran preocupación como la de los relacionados con la red. Eso es porque empresas, desarrolladores y programadores asumen que los códigos que se ejecutan dentro de los PLC son seguros y están protegidos como siempre y cuando no haya intrusos en la red. Pero ese no es el caso. PLC códigos pueden llevar dentro de sus propias amenazas destructivas y vulnerabilidades que pueden ser explotadas por piratas informáticos o usuarios descontentos. Las vulnerabilidades provienen de la forma en que el código está escrito o diseñado. Los siguientes son algunos ejemplos típicos:

  • Manejo incompleto de fallas o alarmas: Un código malicioso puede deshabilitar o silenciar ciertas alarmas. Básicamente, el código lógico manipulado no maneja ni escanea todos fallos críticos, alarmas, código lógico relacionado o parámetros. Por eso los operadores no notarán el problema ya que un código malicioso va de manera sigilosa y desapercibida; es decir, reconocer las amenazas después de que se produzca el daño.

  • Resultados falsos: Ocurre cuando el código del PLC salta ciertos peldaños o parámetros; por ejemplo el uso inapropiado de MCR (Reinicio de control maestro) que normalmente solía ignorar instrucciones no retentivas una vez habilitadas.

  • Código de espionaje: Un usuario puede utilizar ciertas instrucciones, como la instrucción "ADD ON", que puede ser explotada para registrar o monitorear algunos datos o parámetros confidenciales. Esas instrucciones se pueden agregar a cualquier código lógico y pasar desapercibido.

  • Overflow: Ocurre cuando una instrucción o un operando la longitud del parámetro de entrada o salida no coincide lo que espera el PLC. Eso suele ocurrir porque de programadores no calificados o cuando un ataque malicioso manipula parámetros

  • Instrucciones duplicadas: Para algunas instrucciones, como la que se muestra en el siguiente gráfico, si se duplican en más de un peldaño, sus valores serán impredecibles, afectando el código lógico y el proceso controlado por esto. Además, eso hará que sea más difícil depurar el código. y encontrar o identificar el problema.

  • imagen ilustrativa

  • Etiquetas no utilizadas: La definición de etiquetas en la base de datos del controlador que no se utilizan en la lógica podría aumentar el nivel de amenazas; especialmente si las etiquetas no están impulsadas por una lógica de escalera bien definida.

  • Faltan de ciertas bobinas o instrucciones: Estas pueden resultar en un comportamiento no deseado. Un usuario puede explotar tal situación para agregar una salida incorrecta que podría afectar severamente el código lógico y el hardware controlado asociado. Por ejemplo, si las salidas, definidas como Y1, Y11, e Y2 en la base de datos del controlador—se utilizan en el código, pero el valor de Y2 nunca ha sido impulsado por la lógica, un usuario puede explotar esta instrucción definida para ataques maliciosos dentro del código lógico.
  • imagen ilustrativa

    El siguiente gráfico muestra una forma de corregir tal escenario; asegurándose el valor de Y2 está impulsado por una lógica clara y bien definida

    imagen ilustrativa

  • Instrucciones anuladas (Bypass): Cuando se anula una instrucción por una rama paralela vacía, afecta la condición de salida de renglón. Cuando los piratas informáticos o el desarrollador habitual usar tales técnicas, pasaría desapercibido cuál hace que sea difícil de depurar y detectar a menos que haya una advertencia clara del compilador que a menudo se ignora. Además, los pases podrían hacerse por puentes mal colocados (JMP) o saltar a subrutinas (JSR).

  • imagen ilustrativa

  • Valores hardcodeados: En determinadas situaciones, el uso de parámetros codificados en instrucciones como comparativa unos podrían aumentar las vulnerabilidades. Los parámetros utilizados en la instrucción de comparación pueden ser manipulado por usuarios, atacantes o código malicioso sin ser notado o sobrescrito constantemente por el valor legítimo adecuado.

  • imagen ilustrativa

  • El siguiente gráfico muestra una solución para proteger el valor "SourceB" moviendo constantemente el valor en tiempo real del contador .

  • imagen ilustrativa

  • Ejecuciones: Ramas, llamadas o instrucciones extraviadas pueden conducir a resultados inconsistentes. La lógica se va a comportar de una manera no deseada basada en el resultado imprevisto de ejecuciones, en el siguiente gráfico, “tmr1.DN”, que es un estado del temporizador “tmr1”, se coloca justo antes de las bifurcaciones paralelas creando un escenario de ejecución entre el cronómetro o energizando “Válvula 01”. Para evitarlo, las instrucciones o las ramas deben colocarse correctamente.

  • imagen ilustrativa

    El siguiente gráfico muestra la ubicación adecuada de la instrucción para prevenir cualquier ejecución.

    imagen ilustrativa

  • Advertencias del compilador: Los programadores de PLC prestan mucha atención a los errores del compilador, pero a menudo pasan por alto las advertencias. Las advertencias del compilador podrían tener un gran valor que podría arrojar luz sobre códigos o instrucciones inapropiados que podría ser explotado por ataques maliciosos.

  • imagen ilustrativa

  • Denegación de Servicio (DoS): Un PLC se puede comprometer usando código malicioso dentro de su propia implementación o realizando una programación incorrecta. Los siguientes son algunos escenarios: Bucles infinitos, usando JSR (Jump to Subroutines) instrucciones, instrucciones JMP, temporizadores anidados, etc. Y fallas fatales, que desencadenan ciertas fallas que podrían causar que el programa del PLC no responda correctamente.


Vulnerabilidades de los PLCs

Como mencionamos al comienzo del post cuando mostramos la tabla de los sistemas operativos (SO) más utilizados hablamos de Microware OS-9 y aquí hay algunos ejemplos:

Este es un sistema operativo tipo UNIX, multiusuario y multitarea. Se ha demostrado que es susceptible a ataques que utilizan redireccionamientos ICMP. Un atacante podría falsificar paquetes de redireccionamiento ICMP y posiblemente alterar las tablas de enrutamiento del host y subvertir la seguridad causando que el tráfico fluya en un camino que el administrador de la red no pretendía.

VxWorks (producto de Wind River Systems, adquirido por Intel en 2009) es un sistema operativo en tiempo real embebido más famoso. Se ha utilizado para alimentar desde puntos de acceso Apple Airport Extreme y BMW iDrive hasta los rovers de Marte y el avión C-130 Hercules. Desafortunadamente, tiene dos fallas graves:

La primera falla se refiere a un servicio de depuración de VxWorks expuesto (WDB Agent). Este servicio se ejecuta sobre el puerto UDP 17185 y permite acceso completo al dispositivo, incluida la capacidad de manipular la memoria, robar datos y, en última instancia, secuestrar todo el sistema operativo. Este servicio fue dejado accidentalmente expuesto por más de 100 vendedores diferentes y afecta al menos a 250000 dispositivos conectados a Internet hoy en día.

La segunda falla se relaciona con una implementación débil de hash de contraseñas en el sistema operativo VxWorks. Cualquier dispositivo que utilice la biblioteca de autenticación incorporada para manejar la autenticación de Telnet y FTP puede ser comprometido. La falla ocurre porque solo hay 210000 posibles salidas de hash para todas las contraseñas posibles. Un atacante simplemente puede recorrer los rangos más comunes de salidas de hash de alrededor de 8000 contraseñas similares para obtener acceso a un dispositivo VxWorks. Usando el protocolo FTP, este ataque tomaría sólo unos 30 minutos para probar todas las permutaciones de contraseñas comunes.

Los dispositivos Schneider Modicon son historias aparte. Se puede ver fácilmente directamente desde el firmware de Schneider que hay una gran cantidad de cuentas codificadas en los dispositivos. Estas cuentas permiten que un usuario haga cualquier cosa con el dispositivo, es decir, todas tienen los mismos privilegios. Por ejemplo, se puede cargar un nuevo firmware en el dispositivo y usar el módulo Ethernet en un Modicon como una computadora de propósito general. Incluso se puede ejecutar Linux en él. Schneider dejó símbolos de depuración en el firmware, que son bastante fáciles de revertir.

Otro problema es que las amenazas no se abordan adecuadamente y no se informan ampliamente. Esto se debe a redes aisladas, problemas no documentados o amenazas no rastreables. Es difícil, por ejemplo, actualizar una vulnerabilidad del firmware o informarla a los proveedores si los PLCs no están conectados directamente a la red o al internet de los proveedores.

Los proveedores no van a rastrear los problemas ocurridos y obtener suficientes detalles. Esto hace que el parcheo e incluso la retroalimentación de validación sean difíciles, especialmente cuando los PLCs tienen variedades de plataformas.

Subida sin restricciones: Tener un punto de acceso a un PLC permite al usuario subir cualquier código malicioso al PLC, manipular el que se está ejecutando actualmente o incluso subir un nuevo firmware. Los PLCs normalmente no comprueban si el código subido proviene de una fuente verificada y de confianza o no. Además, los PLCs no tienen capacidad para saber si el código subido es malicioso o no; siempre y cuando esté compilado sin errores, se puede subir y sobrescribir el que se está ejecutando actualmente.

Modo desbloqueado: Los PLCs están, en la mayoría de los casos, desbloqueados y no están protegidos por ninguna contraseña. Esto permitiría a otros acceder al código de lógica en ejecución, monitorear etiquetas, manipular el código o incluso descargar una lógica totalmente equivocada o no relacionada. Algunos proveedores ofrecen una llave de seguridad física para bloquear el PLC, como girar la llave a "Ejecutar". Un PLC bloqueado impide cualquier modificación, actualización o descarga de código.

El código de los PLCs puede ser explotado por malware para lanzar ataques a otros PLCs que se encuentran en la misma red.

Vulnerabilidades de las IHM y los DTUs

Las IHM, los DTUs y los HTUs son cada vez más accesibles de forma remota y se interconectan con otras redes y dispositivos. Como cualquier otro ordenador, son vulnerables a cualquier amenaza dentro de la red y heredan todas las vulnerabilidades del sistema operativo en el que se basan. Por ejemplo, las IHM se han convertido en productos de software genéricos o de “estantería” que se basan en sistemas informáticos comunes o de TI (tecnología de la información) como Windows OS, ActiveX, Java, etc. Por esto mismo se están convirtiendo en dispositivos más vulnerables; ya que los atacantes las consideran PCs regulares o simplemente otro sistema operativo vulnerable en la red infectada accesible.

Atacar cualquier IHM, incluida su base de datos relacionada, podría tener consecuencias graves en el software (eliminar o manipular códigos, alarmas o registros de base de datos), así como en el hardware; especialmente porque los PLC son sistemas inmediatos en tiempo real. Los ataques al software suelen aprovecharse de redes no seguras o dispositivos infectados para crear manipulaciones de software o robar información confidencial. Las vulnerabilidades de software pueden ser explotadas por ataques sofisticados de ciberseguridad que afectan a dispositivos PLC, tales como IHMs, codificadores, variadores de frecuencia, motores, etc. Los ataques de software se resumen de la siguiente manera:

Malware externo: Puede ser desplegado a través de internet, la red de la compañía o localmente por los usuarios -por ejemplo, insertando un USB infectado en una IHM, servidor o PC que está en la red PLC-BS. El malware puede espiar y dañar sistemas industriales, retrasar o bloquear redes e incluso incluir rootkits de PLC.

Ataques de engaño: Incluyen una identidad no autorizada e equivocada de un dispositivo emisor de comandos que puede permitir el acceso remoto y causar daños fatales en el software y hardware.

Inyección SQL: Afecta a HMI basados en web y servidores con aplicaciones de bases de datos (algunas HMI o servidores). Es una forma tomar el control de un sistema o insertar un inesperado sentencias SQL en una consulta para manipular una base de datos.

Vulnerabilidades de dispositivos de campo

Una de las principales vulnerabilidades que se pueden explotar para manipular y amenazar la integridad y confiabilidad del PLC es la que proviene de un estado de hardware incorrecto o falso, ya sea de entradas o de comandos de salida. La amenaza ocurre cuando los valores físicos de un dispositivo de hardware se manipulan enviando o recibiendo valores o señales falsas. Alterar cualquier valor, incluso un bit, de una entrada o salida engañaría al PLC y llevaría a resultados no deseados en el programa de lógica de escalera, poniendo en peligro los equipos, la productividad, el medio ambiente y la vida humana. Esto se logra comprometiendo la red asociada, lo que ocurre inadvertidamente y sin modificar ningún código o firmware de lógica de escalera del PLC. Además de falsificar sus entradas/salidas, los dispositivos de hardware pueden ser vulnerables si los programas PLC relacionados se ven comprometidos; ya sean relacionados con el HMI o los del PLC, como el código de lógica de escalera o la base de datos. A continuación, se presenta un resumen de las vulnerabilidades de hardware:

Entradas falsas: Estado, parámetros o valores de los sensores o dispositivos de entrada comprometidos (por ejemplo, fotocélulas, sensores de presencia de piezas, paradas de emergencia de seguridad, VFD - variadores de frecuencia, interruptores regulares y de seguridad, etc.). Además, estas vulnerabilidades pueden llevar a entradas falsas realizadas desde el HMI al PLC, por ejemplo, selección manual del operador, datos ingresados por el operador, etc.

Salidas falsas: Estado, parámetros o valores de los actuadores o dispositivos de campo comprometidos (por ejemplo, válvulas, VFD, codificadores, motores paso a paso, etc.). Las salidas de PLC o HMI también se pueden falsificar, lo que afecta a otros dispositivos relacionados.

Al igual que en todos los casos anteriores los dispositivos de campo heredan las vulnerabilidades de sus compañeros.

Vulnerabilidades de la red

En la actualidad, la mayoría de las arquitecturas de redes PLC distribuyen sus funcionalidades a través de protocolos comunes o abiertos, como WAN y LAN; Ethernet/IP, DeviceNet, ControlNet, Profibus, PROFINET y Modbus. La falta de mecanismos de seguridad en los protocolos hace que la red sea vulnerable a:

  • Manipulación de paquetes (latencia, falsificación, espionaje, eliminación, etc.)
  • Ataques en la pila de comunicación: capa de red, capa de transporte, capa de aplicación y la implementación de protocolos (TCP/IP, OPC, ICCP, etc.).
  • Ataques a dispositivos de campo remotos o locales; Dispositivos Electrónicos Inteligentes (IEDs).
  • Suplantación de dirección de Protocolo de Resolución de Direcciones (ARP), ataque de contraseña y denegación de servicio (DoS).
  • Puertas traseras y agujeros en los límites de la red.
  • Ataques a la base de datos.
  • Interferencias, bloqueos o secuestros de las comunicaciones; ataque de hombre en el medio (MITM).
Vulnerabilidades de segmentación de red

Muchas empresas todavía asumen que están seguras si sus redes industriales están desconectadas de internet o aisladas. Aún hay quienes creen que segmentar una red mantiene seguros y a salvo sus PLC. Suponen que la red de control industrial (ICS), que es una forma de segmentación, asegura todos los PLC y los dispositivos de campo asociados a ellos, incluidos los HMI. Pero segmentar la red de ICS de esta manera no es suficientemente por las siguientes razones:

  • Amenazas USB: el ataque malicioso podría ser desplegado por un USB infectado.

  • Heredado: un ataque malicioso puede ser llevado a cabo por otra computadora o HMI infectado que esté conectado a la misma red PLC-BS. Además, algunos gusanos pueden pasar de un PLC a otro si están en las mismas redes.

  • Empleados descontentos: un empleado disgustado puede causar daños y perjuicios importantes. Él o ella puede sabotear el código, infectar HMIs o PC, escribir código malicioso latente dentro de la lógica de escalera o incluso abrir ciertos puertos a los atacantes.

  • Mala práctica de código: un programador podría inadvertidamente escribir piezas de código que podrían dañar ciertas máquinas o crear DoS; por ejemplo, bucles infinitos.

  • Acceso sigiloso: algunas vulnerabilidades podrían tardar años en ser detectadas. Su trabajo no es crear daño directo. Solo están allí para espiar, recolectar y robar información y datos confidenciales.

Próximos pasos

En este post, hemos proporcionado una descripción general de los PLC (lenguaje y hardware), además de una descripción general de redes industriales asociadas, dispositivos de campo, HMI, y DTU. También hemos resumido las principales vulnerabilidades de dispositivos basados en PLC. Ahora que asimilamos estos conceptos sobre redes industriales y sus elementos asociados, te invitamos a seguirnos en las próximas publicaciones, en donde haremos referencia a casos reales en donde se aplica esta teoría. Otros links y lecturas de interés: