Atacando redes industriales (Siemens)

Hace una semana en la primera parte de este post pudimos visualizar una descripción general de los PLC (lenguaje y hardware) y algunas vulnerabilidades, además de una descripción general de redes industriales asociadas, dispositivos de campo, HMI, y DTU. Ahora que asimilamos estos conceptos sobre redes industriales y sus elementos asociados, vamos a entrar en detalle de cómo se comunican.

Este post presenta un análisis en el entorno PLC de Siemens, en particular el protocolo de comunicación conocido como S7CommPlus. Este protocolo permite la comunicación entre endpoints de Siemens como TIA Portal (el software de ingeniería del fabricante), y PLCs como el S7 -1211C que se ha utilizado para los experimentos realizado por Hui, H., McLaughlin, K., & Sezer, S. El análisis utiliza las herramientas WinDbg y Scapy. Se investiga el mecanismo anti repetición utilizado en el protocolo, incluida la identificación de los bytes específicos necesarios para crear paquetes de red válidos. A partir del análisis experimental, se identifican nuevos exploits, incluida la manipulación de claves criptográficas.

Posteriormente, se demuestran exploits que permiten impersonar una sesión de comunicación existente, negar la capacidad de un ingeniero para configurar un PLC, realizar cambios no autorizados en los estados del PLC y otras violaciones potenciales de la integridad y la disponibilidad. También se propondrán varias recomendaciones de mitigación teniendo en cuenta los conceptos vistos anteriormente.

A continuación, se efectuará una explicación breve pero detallada de cada una de las partes de esta definición:

Introducción

Siemens es uno de los vendedores líderes en el mundo, y para este análisis se investigó el controlador S7-1211C. Como recordamos el ataque Stuxnet demostró cómo los PLC comprometidos podrían causar un impacto físico. El gusano se propagó primero desde una unidad extraíble dentro de una planta de enriquecimiento de uranio en Irán e infectó una máquina de la red "air-gapped". A continuación, el gusano se propagó por la red utilizando cuatro vulnerabilidades zero-day y firmas digitales de dos empresas legítimas. Aparte de los sofisticados mecanismos de infección y propagación utilizados por Stuxnet, un aspecto clave desde el punto de vista de los ICS fue que solo se centró en algunos modelos concretos de PLC, concretamente los Siemens S7 315 y 417, que se utilizaban para controlar las centrifugadoras del proceso de enriquecimiento. Stuxnet determinaba si un objetivo era un PLC de Siemens comprobando el número de modelo, los detalles de configuración y descargando el código de programa del dispositivo. Si la comprobación fallaba, Stuxnet no realizaba ningún otro ataque, posiblemente para evitar que sus acciones fueran detectadas. En caso contrario, procedía a actualizar el bloque de ciclo principal del PLC con código malicioso para aumentar la frecuencia de rotación de las centrifugadoras conectadas hasta niveles perjudiciales, al tiempo que engañaba al operador inyectando datos falsos en la HMI. El ataque cambió la forma en que la industria veía la seguridad.

Investigaciones relacionadas

Para programar o configurar un PLC suele ser necesario un software propietario del fabricante. Los dispositivos de una red de control de procesos pueden comunicarse con los PLC mediante conexiones serié o, más recientemente, por Ethernet, a través de protocolos basados en TCP/IP. Mientras que los protocolos utilizados durante las operaciones normales pueden estar abiertamente estandarizados por ejemplo, Modbus TCP o ser específicos de un proveedor.

En el siguiente gráfico se ve una cronología con el lanzamiento de varios modelos de PLCs junto a vulnerabilidades descubiertas y sus exploits y las versiones de protocolo específicas.

Beresford demostró una serie de ataques al PLC S7-1200, por ejemplo, ataque de repetición, derivación de autenticación, arranque o parada de un PLC, etc. El trabajo se basaba en el firmware v2 del PLC, que no incluye ningún mecanismo de seguridad en el protocolo de comunicación.

"PLC inject" explota el protocolo S7Comm (la última generación del protocolo de Siemens, en el que no se incluye un mecanismo anti-replay) y tiene la capacidad de añadir códigos al ciclo de programa principal de un PLC sin interrupción de los servicios. También se demostró que era posible introducir un proxy de red en un PLC Siemens S7-300 como puerta trasera a la red de control de procesos.

Spenneberg demostró un ataque similar a un gusano, denominado PLC Blaster, que puede propagarse entre PLCs. El gusano explota vulnerabilidades del protocolo S7CommPlus, y en una versión más reciente del protocolo con un mecanismo anti-replay. El programa malicioso se carga en un PLC mediante un cable Ethernet. La carga también incluye los bytes de los paquetes de red necesarios para programar otros PLC. A continuación, el PLC afectado explora automáticamente la red y se conecta a otros PLC e intenta cargar en ellos el código malicioso.

En 2017, L. Martín-Liras presentó un análisis comparativo entre tres protocolos propietarios utilizados por PLC. Los tres protocolos implicados fueron el protocolo S7Comm , el protocolo UMAS (utilizado por PLCs Modicon) y el protocolo Opto Comm (utilizado por PLCs Opto). Se investigó la información existente sobre las vulnerabilidades de los protocolos. El análisis también investigó la posibilidad de realizar varios ataques a los PLC, incluyendo DoS, alteración de firmware y cambio de programa de usuario, etc. Una publicación más reciente en 2018 de L. Ghaleb documentó una investigación sobre las vulnerabilidades del protocolo S7 específicamente, en la que se demostró el ataque Man-in-the-Middle, la modificación de comandos y el ataque de repetición en un PLC S7-400 que utiliza el protocolo S7Comm.

En 2018 los autores publicaron un trabajo preliminar relacionado con la investigación que se tomo como referencia para realizar este post. Se demostró que era posible realizar un ataque de red general, basado en ARP-poisoning, en el PLC S7 -1211C (firmware 4) y TIA Portal. Los autores también demostraron que un paquete "S7-ACK" de 7 bytes, "03 00 00 07 02 f0 00", puede ser explotado para robo de sesión y ataque DoS.

En 2019, Biham profundizó en la investigación de los protocolos S7 de Siemens y demostraron ataques para reprogramar PLCs S7, que recibieron el nombre de Rogue7.

Protocolo S7Commplus

El protocolo S7CommPlus facilita la transferencia de información operativa y de configuración crítica, como la lógica del PLC, información de diagnóstico, detalles de configuración y valores de bloques de datos entre los PLC y el software de ingeniería. La siguiente imagen muestra la pila de protocolos diseccionada de un paquete que transporta datos S7CommPlus visto en Wireshark.


El puerto TCP 102 se utiliza para todas las comunicaciones del S7. El protocolo se ejecuta en ISO sobre TCP (TPKT), y Protocolo de Transporte Orientado a la Conexión (COTP). Si un operador inicia una conexión con un PLC desde TIA-Portal, lo haría por pulsando el botón "Conectarse"


Luego de presionarlo internamente se producen los siguientes pasos:

• El Portal TIA emite un paquete "Identify All" del Protocolo de Descubrimiento y Configuración Básica Profinet (PN -DCP) a la red.
• Todos los PLC o dispositivos responden al Portal TIA con un paquete PN-DCP "Identify OK"
• TIA Portal inicializa un handshake TCP con el PLC, y el PLC responderá.
• El Portal TIA y el PLC intercambian información de conexión COTP.
• El Portal TIA envía el primer paquete S7. (request de coneccion desde TIA)



• El PLC responde con un paquete que contiene un Challenge anti-replay de 1 byte y otro de 20 bytes.



• TIA Portal responde con un paquete que contiene un byte anti-replay y una matriz de 132 bytes, que es la respuesta anti-replay en sí misma.

(Representación de posiciones de los bytes)

  • El TIA Portal envía paquetes con la acción solicitada al PLC, junto con una comprobación de integridad de 20 bytes en cada paquete

En las imágenes del paso 5-7 se muestran el Portal TIA y el PLC intercambiando paquetes S7 de petición, desafío y respuesta, en los que intervienen bytes especiales en el proceso. Por ejemplo 1C9C381. Si alguno de los paquetes S7CommPlus no incluye los bytes anti-replay o los valores de comprobación de integridad correctos, el otro extremo de la conexión enviará un paquete de restablecimiento TCP y la sesión finalizará.

Una vez pulsado el botón "Conectarse" en el portal TIA como se vio anteriormente, se iniciará una sesión utilizando el protocolo S7. El operador puede cargar programas personalizados, diagnosticar problemas relacionados con el PLC, ver datos en tiempo real de los bloques de datos del PLC, configurar la comunicación entre el PLC y otros dispositivos, etc. Durante un periodo en línea con el PLC S7 -1211C, se envían varios paquetes al TIA Portal durante el tiempo de inactividad especificando detalles y estado en vivo del PLC, por ejemplo, tiempo de ciclo, uso de memoria, etc.


Byte Anti-Replay

El protocolo S7CommPlus utiliza un valor de 1 byte en el mecanismo anti repetición, que se ha venido utilizando desde la versión 3 del firmware S7-1200. Cuando el TIA Portal inicia una conexión con un PLC, este envía un byte de desafío en el rango 0x06 a 0x7f. El TIA Portal responderá al PLC con una respuesta que se calcula añadiendo el valor 0x80 al challenge. Por ejemplo, si el reto del PLC es 0x08, la respuesta del TIA Portal sería 0x08 + 0x80 = 0x88, como se muestra en el paso 6 y 7. El desafío se encuentra en la posición del byte 25 y la respuesta en los bytes 24 y 29 de los respectivos paquetes.

Cifrado en el paquete de respuesta

Desde la versión 4 del firmware, el paquete de respuesta de TIA Portal tiene que incluir varios bytes además del único byte anti-replay comentado anteriormente. En 2017 Cheng descubrió dos cifrados de 16 bytes implicados en el paquete, donde el segundo cifrado depende del primero. Los dos valores de 16 bytes comienzan en los bytes 235 y 291 del paquete de respuesta S7, como se muestra en el paso 7. La primera encriptación es una operación XOR, mientras que la segunda se genera mediante un algoritmo más complejo.

Función del Paquete “Cifrado”

Después de enviar el paquete de respuesta al PLC, el TIA Portal comenzará a enviar bytes relacionados con las funciones del TIA Portal, que se denominan "paquetes de función". Todos estos paquetes tienen que incluir un valor de 32 bytes de "encriptación", como se muestra en el paso 8. Se descubre que este "cifrado" es una comprobación de integridad facilitada por el Código de Autenticación de Mensajes Basado en Hash (HMAC) y está relacionado con el byte anti-replay. Cheng propuso la posibilidad de iniciar y detener un PLC explotando el protocolo, pero sin embargo no proporciona detalles que describen las vulnerabilidades del protocolo, y se limita a señalar que la función de comprobación de la integridad de los paquetes es un "cifrado". Posteriormente, Biham identificó el mecanismo subyacente utilizado en el protocolo S7 como un HMAC y descubrió que la clave para el HMAC se intercambia mediante un intercambio de claves de tipo curva elíptica ElGamal.

Sin embargo, no se describieron los mecanismos específicos del protocolo, por ejemplo, cada campo de la respuesta anti-replay se identifica vagamente con pseudocódigo, mientras que falta el detalle de la ejecución algorítmica. Del mismo modo, en la función de cálculo de paquetes HMAC, se descubren dos conjuntos de HMAC con dos claves diferentes que no se habían identificado previamente.

Análisis del protocolo S7CommPlus

Se realizó un análisis manual utilizando herramientas como Scapy y WinDbg para examinar la comunicación entre el Portal TIA y los PLCs durante varias sesiones de comunicación diferentes. En el primer experimento, inspeccionando manualmente los paquetes, incluyendo la manipulación de bytes usando Scapy, se descubrió que los bytes etiquetados en los pasos 5-8 servían para una serie de propósitos específicos, que ahora se explicarán. A modo de ejemplo, los pasos 5-7 muestran el Portal TIA y el PLC intercambiando paquetes S7 de petición, desafío y respuesta, mientras que en el 8 muestra un "paquete de función" posterior. Véase también el paso 4, que muestra los intercambios generales en una sesión.

En el paso 5, 1C9C381M indica un número de sesión de servidor que genera TIA Portal cada vez que se inicia una sesión de comunicación. Sin embargo, este número puede ser reutilizado y no es comprobado por el PLC. En 16 2913981 hay otro número de sesión, o número de sesión "PC", que se genera cada vez que se abre TIA Portal (es decir, la primera vez que se abre TIA Portal o después de reiniciar el ordenador, de ahí el nombre de número de sesión "PC"). Este número también puede reutilizarse.

01 c9 c3 81 es el valor de la sesión del servidor repetido directamente en hexadecimal. El segmento resaltado en el paso 5, en contraste con otros bytes del mismo paquete, es significativamente diferente para cada sesión. Parece más probable que haya sido generada por una función hash o pseudoaleatoria. El PLC comprueba estos tres bloques los segmentos de 9 y 8 bytes 132 bytes respectivamente del paso 7 y envía inmediatamente un paquete TCP con un indicador de reinicio si los bloques de bytes no son lo que el PLC esperaba; de lo contrario, la comunicación continúa. Estos bytes son generados por un algoritmo específico. Tras la respuesta del TIA Portal, si se acepta la conexión, el PLC envía un paquete S7CommPlus. El paquete S7CommPlus contendrá información relacionada con las funciones proporcionadas por TIA Portal.

Los atacantes sofisticados podrían identificar estos bytes y utilizar esta información para explotar aún más el protocolo.

Análisis de TIA-Portal

Se utilizó WinDbg para realizar un análisis de TIA Portal en esta sección se describe en resumen el proceso realizado durante los experimentos. Se utilizó para esto la función que ejecuta una búsqueda de dispositivos accesibles en TIA Portal para generar tráfico S7CommPlus.

Diagrama de referencia Análisis de TIA-Portal

Para apoyar el análisis, se establecieron varios puntos de interrupción durante la comunicación entre el software y el PLC. Un proceso de análisis manual identificó que el byte array cambia significativamente cada vez que TIA Portal realiza una petición. Este bloque de 20 bytes no tiene ninguna relación obvia con la carga útil del paquete de solicitud de conexión, como se confirmó enviando exactamente el mismo paquete de solicitud de conexión al PLC utilizando Scapy.

El primer reto para quien lleve a cabo este análisis es identificar la parte del ecosistema susceptible de ser atacada y el punto de entrada del análisis, para lo cual se dan a continuación algunos tips.

Para iniciar el análisis, se utiliza una vez la función de búsqueda del TIA Portal sin ningún punto de ruptura y se genera una sesión completa de comunicación (finalizada por un paquete de reinicio TCP del PLC). Iniciando manualmente una ruptura mediante WinDbg en el software, y utilizando después el comando "s" para buscar los 20 bytes del PLC en la memoria, se puede identificar la dirección de memoria que contiene este bloque de 20 bytes. Esta dirección de memoria podría localizarse con una sola búsqueda "s", o a menudo sólo se localiza el área que almacena todo el paquete de desafío S7 recibido.

Otra búsqueda debe hacerse utilizando un punto de interrupción en acceso y rastrear la dirección específica en la que se escribe esta matriz de 20 bytes. Una vez identificada esta dirección, no cambiará hasta que se reinicie el TIA Portal. Se establecerá un punto de interrupción en acceso, "punto de interrupción A", en esta dirección. Después de inicializar otra comunicación S7 utilizando el TIA Portal, se encontró que el punto de interrupción A fue accedido por dos lugares diferentes, ambos de los cuales son funciones que implican copiar el bloque de 20 -bytes a otra dirección. La primera función copia la dirección señalada por el punto de ruptura A , mientras que la segunda función copia los bytes a una dirección específica. Por lo tanto, para continuar la investigación, se establecieron otros dos puntos de interrupción de acceso, el punto de interrupción B y el punto de interrupción C, para cada una de las dos direcciones identificadas.

Se descubrió que el punto de ruptura B apunta a la dirección del 3er byte y el punto de ruptura C almacena del 3er al 18º byte de la matriz de 20 bytes . Se ha descubierto que este valor de 16 bytes (bytes 3 a 18), o "matriz de desafío", juega un papel importante para el resto del proceso de generación de bytes. Además, se ha descubierto que las dos posiciones de memoria a las que apuntan los puntos de interrupción B y C participan en la generación de bytes para la respuesta y el paquete de funciones de S7CommPlus, respectivamente.

Es en este punto donde aparece por primera vez la dll, "OMSp_core_managed.dll" y las direcciones apuntadas por el punto de ruptura A, B y C están dentro del rango de esta dll. Durante el análisis, se confirmó que, este módulo, o dll, es donde toda la generación de los bytes anti-replay tiene lugar.

Los invitamos a leer Vulnerability Analysis of S7 PLCs: Manipulating the Security Mechanism el paper completo sobre la investigación en la que se basa este post y conocer en detalle el trabajo sobre TIA-Portal, lo podrán encontrar en las referencias.

En él se abordan en detalle temas como:

• Paquete de respuesta S7 del portal TIA
• Bytes manipulables
• Primera encriptación
• Segunda encriptación
• Algoritmo de Incremento de campo Finito
• Algoritmo A480
• Paquetes de funciones de TIA-Portal
• Comprobación de Integridad

HMAC

Después de intercambiar los paquetes de challenge y respuesta de S7, se enviarán los paquetes de función de S7. Estos paquetes incluyen el propósito y el detalle de la comunicación y como se vio en el paso 8 se muestra uno de los paquetes que contiene información de control enviada por TIA Portal. Cada paquete debe incluir los 32 bytes de "Encriptación" (como los llama Cheng) antes de la carga útil, como se muestra en el byte delineado. Se encontró en este análisis que este bloque de 32 bytes es en realidad una verificación de integridad HMAC para el paquete. Esta verificación de integridad sirve para dos propósitos: asegurarse de que las cargas útiles no sean manipuladas; y autenticar al remitente (ya que las claves para HMAC solo son conocidas por los anfitriones que están involucrados en la conexión). Para generar este valor de 32 bytes, se encontraron dos cálculos HMAC.

El primero se utiliza para generar la clave para todos los HMAC posteriores. El segundo se utiliza para firmar todos los paquetes de función. Ambos HMAC se basan en el mismo algoritmo de hash que el resto del mecanismo. El siguiente gráfico muestra cómo ambos HMAC generan los bytes de integridad.


Primer HMAC

El cálculo del primer HMAC se realiza antes de enviar el paquete de respuesta S7 al PLC. El texto plano del HMAC consiste en un valor de 8 bytes y la matriz de desafío de 16 bytes, leída desde el punto de interrupción C

A Continuación una muestra de pseudocódigo para la generación de 8 bytes, que es fundamental para la comprobación de la integridad de la función S7. Este algoritmo no está identificado como un algoritmo estandarizado, por lo que el pseudocódigo se genera mediante un análisis del código assembler. Este análisis es instructivo desde el punto de vista de la seguridad, ya que el algoritmo de generación de 8 bytes es una parte esencial para la generación del byte de integridad.


A continuación, el valor combinado de 24 bytes se firma utilizando una clave de 24 bytes generada en el sector Ⓕ del diagrama de referencia de TIA-Portal. La salida de 32 bytes del HMAC se reducirá a un valor de 24 bytes, que se almacenará y utilizará como clave del segundo HMAC.

Segundo HMAC

El segundo HMAC se utiliza para generar los bytes de comprobación de integridad reales, que se insertan en el paquete de función enviado por ambas partes. Aquí se ha identificado por primera vez cómo la clave del segundo HMAC es el resultado del primer HMAC , y además qué parte de la carga útil del paquete de función S7 se utiliza como entrada del segundo HMAC. La longitud del paquete de funciones no siempre es la misma, pero el HMAC de 32 bytes del paquete siempre comienza en el 13° byte del paquete. La entrada de este HMAC comprende todos los bytes que siguen al HMAC en el paquete, es decir, a partir del 45º byte, excluyendo el pie de página del paquete que normalmente son los últimos cuatro bytes (por ejemplo, en el punto 8 es "72 03 00 00" al final del paquete). Como la longitud de cada paquete y la información que contiene pueden variar, la longitud y el contenido del pie de página varían en consecuencia. Sin embargo, para reproducir el paquete, dado que se conoce la clave, un simple método de ensayo y error podría identificar qué byte se necesita como entrada del HMAC.

Explotaciones potenciales

El análisis anterior del protocolo S7CommPlus y del Portal TIA revela la posibilidad de explotar el protocolo y el software. A continuación se analizan varios exploits validados, así como posibles ataques adicionales que podría llevar a cabo un atacante suficientemente motivado para seguir analizando los descubrimientos presentados anteriormente y proceder a desarrollar exploits maliciosos.

Cambios no autorizados en el estado de PLC

Dado que todas las acciones realizadas en el Portal TIA se envían al PLC utilizando el protocolo S7, utilizando los descubrimientos de esta investigacion puede ser posible causar interrupciones en una serie de procesos, incluyendo: reprogramar un PLC, cambiar el valor de una variable del PLC, establecer la contraseña de un PLC, y cambiar el estado del PLC (de estado de ejecución a estado de parada, y viceversa). Para fines de demostración, el alcance del trabajo actual se ha centrado en si es posible cambiar a distancia el estado de un PLC, es decir, detener un PLC en funcionamiento. Los experimentos han demostrado que esto se puede conseguir utilizando dos paquetes de función S7 además de la respuesta anti-replay, que incluye los 132 bytes identificados en el paso 7.


En esta imagen se muestra uno de los paquetes de función spoofed necesarios para detener un PLC. El paquete spoofed se genera basándose en los descubrimientos documentados en la sección de Análisis a TIA-Portal. Aparte del byte anti-replay (paso 6), los bytes de comprobación de integridad y el número de secuencia, todos los demás bytes son iguales en los dos paquetes (uno normal y otro falsificado). Vale la pena mencionar de nuevo que incluso en diferentes sesiones S7, todos los bytes anti-replay pueden ser generados para cualquier paquete falsificado basándose en las mismas claves de cifrado y bytes requeridos que permanecerán constantes basándose en los hashes en Ⓓ y cajas Ⓔ y Ⓕ en el Diagrama de referencia de TIA-Portal.

Como se mencionó, también es posible reprogramar un PLC utilizando el protocolo S7. Aunque existe un mecanismo de protección contra copias incorporado, siempre y cuando el atacante pueda identificar la relación entre el número de serie del PLC que se envía a lo largo de la lógica del PLC y la propia lógica del PLC, un ataque para reprogramar la lógica puede ser factible.

Comunicación DoS

Aparte de explotar la funcionalidad normal proporcionada a través de TIA Portal, se ha demostrado que los hallazgos permiten un ataque DOS mediante el envío de paquetes crafteados que establecen y mantienen una nueva sesión S7 a un PLC. Esto evitará que el portal TIA se conecte al PLC. Este exploit es posible porque el S7-1211C no permitirá que se inicie una nueva sesión si ya existe una sesión previa.

Para aplicar este exploit se asume que no existe una sesión actual entre el PLC y el TIA Portal. Un host en la misma LAN que el PLC puede iniciar una conexión TCP con el PLC mediante el handshake habitual y el intercambio de paquetes COTP. Respondiendo al paquete de challenge del PLC con un paquete crafteado que contenga los bytes anti-replay apropiados, seguido de paquetes "S7-ACK", el atacante puede prevenir una conexión genuina desde el TIA Portal. Para mantener viva una sesión normal, por ejemplo para pedir al otro extremo que esperar mientras se ejecuta un proceso, cualquiera de las conexiones finales puede responder con un paquete S7 -ACK de este tipo, aparentemente de forma indefinida.

Este exploit es posible porque el paquete "S7-ACK", "03 00 00 07 02 F0 00", carece de funciones anti-replay o de comprobación de integridad, y puede ser utilizado para responder a cualquier paquete S7. Por lo tanto, la sesión puede mantenerse viva sin que el atacante obtenga ninguna información adicional. Aunque el PLC seguirá ejecutando la lógica pre programada, no es posible detenerlo, reconfigurarlo o reprogramarlo. Un reinicio manual puede terminar la sesión existente, sin embargo un host o dispositivo comprometido en la red podría reiniciar una nueva sesión DOS. Este ataque podría ser crítico por sí solo, pero también podría permitir un ataque a mayor escala.

Secuestro de sesión

El exploit descrito anteriormente asume que no existe conexión entre el TIA Portal y el PLC objetivo. Sin embargo, este exploit podría combinarse con un ataque de red tradicional, usando paquetes de exploit crafteados junto con ARP poisoning, para secuestrar una sesión al PLC y causar un DOS de forma que el TIA Portal no pueda reconectarse. Los autores han documentado previamente como el robo de sesión mediante envenenamiento ARP puede funcionar en este contexto. Esto puede lograrse dejando caer activamente todos los paquetes desde el software de ingeniería después de robar la sesión S7, lo que provoca que el lado del TIA Portal de la conexión se termine. Al mismo tiempo, el lado PLC de la sesión puede ser mantenido vivo por un atacante creando y enviando paquetes S7-ACK. Durante tal ataque, una opción es usar respuestas ARP excesivas para abrumar cualquier otro paquete ARP después de que la sesión es robada. Sin embargo, para evitar generar demasiado "ruido" ARP, la sesión S7 robada podría ser terminada y reemplazada por una nueva sesión DOS, como se describe en la sección anterior. Con este ataque se consiguen dos cosas:
1) Se generaría una "huella" de red más pequeña en comparación con el robo de sesión mediante envenenamiento ARP.
2) Es posible realizar el ataque DOS sin esperar a que la sesión legítima termine, ya que una sesión DOS tampoco puede iniciarse si existe una legítima.

Eliminación del programa principal

Se ha encontrado un nuevo exploit basado en el protocolo S7CommPlus que puede manipular la lógica del PLC e eliminar el bloque Objeto principal de los PLC S7 -1200 y hace que TIA-Portal proporcione información incompleta o incorrecta de los PLC. Se puede producir mediante la reproducción de paquetes S7 capturados bajo un caso de uso anormal.

A continuación se describen los pasos de reproducción del exploit, incluyendo la generación de paquetes, la reproducción de los paquetes y el comportamiento esperado partir de la generación de los paquetes que serán reproducidos como el exploit:

• Cree un nuevo proyecto en TIA-Portal y añada un PLC al proyecto con la versión de firmware del PLC de destino (que puede obtenerse mediante la difusión LLDP del PLC o iniciando una sesión con el PLC).
• Cargue un proyecto predeterminado (que solo tenga un bloque de objetos Main vacío) en el PLC de prueba (un PLC que tenga la misma versión de firmware que el PLC de destino).
• Asegurarse de que el PLC está en estado de Parada.
• Elimine el bloque Objeto principal en el proyecto e inicie una captura de redy, a continuación, cargue el proyecto con la opción "Software (cambios)". Finalice la captura después de que el PLC termine la sesión utilizando un paquete TCP con las banderas Reset y Finish activadas .
• Extraer todo el paquete enviado por el TIA-Portal para su uso en el script, que fue enviado en la comunicación anterior.

El envío (reproducción) de estos paquetes capturados a un PLC de destino, que tiene la misma versión de firmware, que está en el estado de parada, causará comportamientos anormales. Los paquetes capturados de diferentes firmware, causarán diferentes comportamientos en una versión de firmware diferente. Este exploit fue probado en S7-1211C DC/DC/DC, versiones de firmware v4.1.3 y v.4.2.3.

Para v4.1.3, la captura puede ser reproducida tal cual, y el PLC reiniciará la conexión después de que los paquetes crafteados sean enviados a los PLCs. El exploit puede tener los siguientes comportamientos, dependiendo de la configuración y el estado del PLC:

• Al conectarse al PLC infectado, el PLC no puede ponerse en estado de ejecución. Si un usuario intenta descargar el código personalizado desde TIA-Portal al PLC, el portal indicará que el programa entre el PLC y el, es el mismo sin mostrar ningún error. Sin embargo, el PLC está funcionando sin Main Object Block , es decir, no realiza ninguna acción . Una posible solución es desconectarse y descargar las configuraciones completas al PLC utilizando la opción de descarga "Hardware y Software (sólo cambios)". Se mostrará una ventana para sincronizar el programa antes de la descarga, mostrando que hay diferencias entre la lógica en el PLC y el proyecto en TIA Portal.
• Al conectarse, el PLC no puede ponerse en estado run. Si un usuario intenta descargar el código personalizado al PLC, se mostrará una ventana de sincronización antes de la descarga. Además, no se mostrará ningún error o se mostrará un error diciendo "El bloque de objeto principal no existe".
• Al conectarse, el PLC puede ponerse en estado de ejecución. Sin embargo, en realidad no se ejecutará ninguna lógica en el PLC, y todos los bloques de programa se mostrarán como "solo existen offline" en TIA-Portal. Es necesario sincronizar antes de descargar.

El usuario puede poner el PLC en estado de ejecución. Sin embargo, no se ejecutará ninguna lógica en el bloque de objetos principal, pero la interrupción cíclica o la interrupción de hardware pueden seguir ejecutándose. Si el usuario intenta activar la "monitorización" en el bloque de objetos principal mientras está en línea (una opción de TIA-Portal que proporciona información de diagnóstico de los PLC en tiempo real), aparecerá el error "Error interno del sistema (código de error:0xCF000AF0700008002)... Error interno: UnFunctionalObject referenciado no existe".

Una posible solución es descargar el proyecto al PLC, y será necesaria la sincronización manual del programa personalizado.

Durante las pruebas, en dos ocasiones el PLC entró en un estado irrecuperable después de que varias capturas se reprodujeran en el dispositivo repetidamente. La única solución viable en esta situación es un restablecimiento de fábrica.

Lamentablemente, no se guardaron capturas de las secuencias exactas de paquetes necesarias, ya que el comportamiento parece ser algo aleatorio e impredecible.

Recomendaciones

Como vimos, al menos dos hashes desempeñan un papel importante en el mecanismo anti-replay. Se descubrió que la entrada de estos hashes podía manipularse modificando la memoria utilizada por el software. Esta vulnerabilidad permite a un atacante generar una sesión S7 que requiera solo 17 de los 150 bytes “anti repetición” del paquete de respuesta S7CommPlus en lugar de 150 bytes (los bloques de 132 bytes, 8 bytes y 9 bytes, más el byte anti repetición). Además, todas las claves implicadas, ya sea para el Primer Cifrado y el Segundo Cifrado, o los HMAC en los paquetes de funciones, permanecen constantes con respecto a la entrada de los hashes. Estos dos problemas reducen significativamente la posible seguridad proporcionada por el algoritmo, así como el aparente derroche de recursos. A corto plazo, la adopción de las medidas de seguridad que se proponen a continuación podría limitar la capacidad de un atacante para llevar a cabo exploits similares, sin cambios significativos en el diseño.

Cambiar la entrada del algoritmo hash

Algunos bytes intercambiados entre el Portal TIA y un PLC no se utilizan, ni hay un impacto obvio para esos bytes en la comunicación. Considere los siguientes descubrimientos:

• La sesión de servidor y la sesión de PC, etiquetadas en el paso 5, parecen no tener ningún propósito en el protocolo y pueden reutilizarse en sesiones diferentes, lo que anula el propósito de un número de sesión.
• Se ha demostrado que la "matriz de desafío" de 16 bytes en el desafío de 20 bytes enviado por el PLC desempeña un papel importante en el mecanismo anti repetición. Sin embargo, no se ha determinado que los 4 bytes restantes influyan en el mecanismo anti repetición.
• En el paquete de respuesta S7 de TIA-Portal, los bytes etiquetados en el paso 7, se generaron antes del valor de 132 bytes. Sin embargo, permanecen constantes con respecto a los dos valores hash y no se descubre ninguna relación con el mecanismo anti-replay.

En consecuencia, se propone que una opción para limitar la capacidad de un atacante para generar un paquete S7 viable es incluir algunos de los bytes mencionados anteriormente en el mecanismo anti-replay. Por ejemplo, se sugiere incluir la sesión del servidor y los cuatro bytes restantes de la matriz de desafío en el algoritmo hash que genera las claves de cifrado, junto con una breve historia de la matriz de desafío como parte de la entrada para generar los bytes anti-repetición. Esto no remediará la amenaza de un atacante que utilice técnicas de ingeniería inversa en el software para obtener la entrada y el algoritmo utilizado en el mecanismo anti-repetición, pero cualquiera que lo intente necesitará generar los 150 bytes anti-repetición completos, incluyendo la determinación de las claves en cada ataque, y ser capaz de obtener sesiones previas de comunicación del Portal TIA.

Limitar la duración de la sesión

Durante el análisis, se descubrió que una sesión TCP permanecerá viva hasta que el TIA Portal finalice la comunicación, no acuse recibo de los paquetes TCP keep alive o los paquetes S7 enviados por el PLC, o envíe los bytes anti repetición incorrectos. Por ejemplo, si se establece un punto de interrupción en TIA Portal durante la comunicación con el PLC, dejarán de enviarse paquetes S7CommPlus legítimos.

Mientras tanto, el PLC enviará periódicamente paquetes TCP keep alive y no finalizará la comunicación mientras el TIA Portal responda con el paquete TCP keep alive. Esto aumenta el tiempo disponible para cualquier posible atacante para realizar un análisis más profundo en cada etapa de la comunicación.

Además, el paquete S7 -ACK puede ser explotado para realizar un ataque de denegación de servicio, mediante el agotamiento de recursos, ya que la cantidad de recursos dedicados a la comunicación en un PLC es limitada.

Una posible mitigación sería una actualización del firmware del PLC para garantizar que los PLC se desconecten de una sesión S7 inactiva (una sesión que solo contiene paquetes S7 -ACK) o después de no recibir ningún paquete S7 legítimo tras un periodo de tiempo determinado, a menos que el operador configure el PLC de otro modo.

Otras recomendaciones

Las siguientes son algunas recomendaciones para mantener protegido PLC contra amenazas o al menos mitigar los riesgos teniendo en cuenta lo visto en este post y en su primera parte:

• Seguridad en primer lugar: como las industrias consideran la seguridad como un factor principal al diseñar, actualizar o funcionar cualquier PLC, la seguridad debe ser primordial. Esto debe considerar el hardware, software y redes. Las empresas deben elaborar una evaluación de riesgos más detallada, respuestas y estandarizaciones antes de implementar cualquier proyecto PLCs. Un ejemplo podría ser: No considerar una actualización de firmware de un PLC antiguo por no tener planeada una detención de la línea de producción.
• La ciberseguridad es responsabilidad de todos. Todos los empleados deben estar siempre conscientes y preocupados por la seguridad. Los empleados deben informar de inmediato cualquier práctica insegura, dispositivo inseguro o comportamiento sospechoso.
• Roles y autenticación: los privilegios para acceder a la información y dispositivos deben estar adecuadamente restringidos y bien considerados antes de asignarlos a los empleados. Los privilegios deben ser bien validados, controlados, registrados y monitoreados (usar identificaciones únicas o credenciales de acceso). La actividad no autorizada o no monitoreada debe ser prevenida o al menos reducida al mínimo. Los usuarios solo deben tener acceso a su trabajo y tareas diarias relacionadas. La revisión automática del registro y el monitoreo de los usuarios también podrían ayudar.
• Revisión y comparación diaria: como las empresas están tan preocupadas por la seguridad antes y durante el funcionamiento de las líneas de producción, deben preocuparse más por la integridad de los archivos que se ejecutan en los PLC o los HMIs. Esto debe hacerse mediante una herramienta de software que compare la lógica de la escalera con el archivo maestro confiable original antes de iniciar las nuevas líneas de producción. Siempre existe la posibilidad de que alguien sabotee la lógica o cree un malware inactivo dentro del código de la lógica de la escalera que pase desapercibido.
• Acceso remoto e IoT (Internet de las cosas): debe estar restringido a ciertos dispositivos, áreas o, a veces, desactivado. Si es necesario, solo debe estar habilitado por un tiempo limitado y utilizado por personal interno capacitado desde un dispositivo aprobado, monitoreado y controlado; todas las comunicaciones deben filtrarse y verificarse. Los sistemas o dispositivos que no necesitan estar conectados a otras redes, incluida Internet, deben estar adecuadamente segregados y aislados para evitar cualquier amenaza.
• Los puertos USB deben ser desactivados físicamente en los HMIs (interfaces hombre-máquina) y en cualquier otra PC asociada. Solo se deben permitir USB autenticados y aprobados que deben ser utilizados por administradores. Malware como Stuxnet se propaga a través de una red SCADA a través de dispositivos de almacenamiento USB infectados.
• Registro del sistema: debe generarse y mantenerse durante un tiempo razonable en caso de que sean necesarios si algo sale mal.
• Auditoría del sistema periódica y pruebas de penetración periódicas.
• Detección de intrusión del sistema: que también debe incluir protección perimetral "tradicional" (por ejemplo, antivirus, firewalls, etc.). Siempre deben mantenerse actualizados y encendidos.
• PLCs en general deben ser físicamente resistentes y seguros. No se centre solo en asegurar ciertos dispositivos de campo. Asegurar todo el sistema es crítico y obligatorio.

Conclusión

En esta serie de posts, hemos proporcionado una visión general de los PLC: sus lenguajes y hardware, además de una visión general de las redes industriales asociadas a ellos, los HMI y los DTU. Hemos resumido las principales vulnerabilidades de los dispositivos basados en estos dispositivos, también se dieron ejemplos basados en otras investigaciones de cómo aplicar exploits en dichas vulnerabilidades. Utilizado el protocolo S7CommPlus, se ha demostrado que un atacante con acceso a la red puede enviar paquetes a un PLC, leer un challenge, calcular la respuesta y crear comprobaciones de integridad en los paquetes posteriores para mantener una sesión válida. Esto permite a un atacante crear paquetes que serán aceptados por el PLC, por ejemplo para causar que un PLC se detenga, arrancar la lógica de la CPU que ha sido previamente detenida por un usuario legítimo, secuestrar una sesión legítima existente entre un PLC y el Portal TIA (demostrado para causar un DOS), y potencialmente otros problemas como reprogramar la CPU.

Comparado con el trabajo de Cheng “The spear to break the security wall of S7CommPlus”, esta investigación proporciona un análisis más detallado describiendo el mecanismo anti-replay del protocolo S7CommPlus, incluyendo nueva información sobre las dos encriptaciones de clave simétrica involucradas en el bloque de 132 bytes y el HMAC en los paquetes de función.
Por otra parte, se aportan nuevos conocimientos sobre la generación de bytes anti-replay, incluidos los detalles de los algoritmos utilizados y la forma de manipular las claves generadas.

Mientras tanto, los autores de dichos papers han propuesto una serie de nuevos pasos de mitigación que no se habían propuesto anteriormente en investigaciones relacionadas. Estos pasos pueden llevarse a cabo para hacer que tales exploits sean más difíciles de descubrir y ejecutar por un atacante decidido; a saber, adoptar un enfoque de tiempo de espera para mitigar posibles DOS, y cambiar la forma en que se implementa el algoritmo hash para asegurar que la manipulación de las funciones del Portal TIA sea más difícil de lograr para un atacante. Al igual que la investigación en ciberseguridad en otros campos, los autores esperan que la información proporcionada sobre la realización de este análisis de vulnerabilidades, proporcione a la comunidad investigadora una visión más profunda hacia la comprensión de los enfoques de los atacantes y las estrategias de mitigación viables.

Lecturas de Interés:

• https://claroty.com/team82/research/white-papers/evil-plc-attack-weaponizing-plcs
• Peter M. D. Scully Mark J. Neal “Positional: A Collaborative Host-based Architecture for Securing Industrial Networks” Department of Computer Science, Aberystwyth University, Wales, United Kingdom
• Yong Wang, Jinyong Liu, Can Yang, Lin Zhou, Shuangfei Li, Zhaoyan Xu “Access Control Attacks on PLC Vulnerabilities”Department of Information Security, Shanghai University of Electric Power, Shanghai, China & Palo Alto Networks, California, CA, USA
• https://www.youtube.com/watch?v=93lyRgZYxKw
• https://youtu.be/ocOEiNp-8K0