Infraestructura
IoT
Industria 4.0

Detectadas decenas de fallos de diseño inseguros en productos de OT

Los fabricantes de tecnología operativa tienen que mejorar la seguridad de sus dispositivos.

industria

Un nuevo proyecto de investigación ha descubierto 56 vulnerabilidades en dispositivos de tecnología operativa (OT) de 10 proveedores diferentes, todas ellas derivadas de funcionalidades diseñadas o implementadas de forma insegura, y no de errores de programación. Esto pone de manifiesto que, a pesar de la mayor atención que este tipo de dispositivos críticos ha recibido en la última década, tanto por parte de los investigadores de seguridad como de los atacantes malintencionados, la industria sigue sin seguir los principios fundamentales de seguridad por diseño.

"Aprovechando estas vulnerabilidades, los atacantes con acceso a la red de un dispositivo objetivo podrían ejecutar código de forma remota, cambiar la lógica, los archivos o el firmware de los dispositivos OT, eludir la autenticación, comprometer las credenciales, causar denegaciones de servicio o tener una variedad de impactos operativos", según explicaron los investigadores de la firma de seguridad Forescout en su nuevo informe.

Los problemas de seguridad identificados, denominados colectivamente OT:ICEFALL, se derivan de protocolos de ingeniería inseguros, implementaciones criptográficas débiles o esquemas de autenticación rotos, mecanismos de actualización de firmware inseguros y funcionalidades nativas incorrectamente protegidas que pueden ser abusadas para la ejecución remota de código. De hecho, el 14% de las vulnerabilidades reveladas pueden dar lugar a la ejecución remota de código y otro 21% puede conducir a la manipulación del firmware.

Otro hallazgo interesante de esta investigación fue que muchos de los dispositivos vulnerables habían sido certificados de acuerdo con diferentes normas aplicables a los entornos OT, como IEC 62443, NERC CIP, NIST SP 800-82, IEC 51408/CC, IEC 62351, DNP3 Security, CIP Security y Modbus Security.

"Aunque estos esfuerzos de endurecimiento impulsados por las normas han contribuido ciertamente a mejoras importantes en las áreas de desarrollo de programas de seguridad, gestión de riesgos y actividades de diseño e integración a nivel de arquitectura, estos esfuerzos han tenido menos éxito en la maduración de los ciclos de vida de desarrollo seguros para sistemas y componentes individuales", concluyen los investigadores.

 

La historia de la inseguridad en el diseño de las OT

Los investigadores de Forescout comparan sus hallazgos con los del Proyecto Basecamp, un proyecto de investigación de hace 10 años que se centró en exponer los problemas de inseguridad por diseño en las unidades terminales remotas (RTU), los controladores lógicos programables (PLC) y otros controladores que componen los sistemas SCADA (Control de Supervisión y Adquisición de Datos) utilizados en las instalaciones industriales.

Entonces, tras el descubrimiento de sofisticadas amenazas como Stuxnet, desarrolladas por naciones-estado para atacar a los PLC, los investigadores que participaron en el Proyecto Basecamp se propusieron cambiar lo que, según ellos, había sido "una década de inacción" por parte de los fabricantes y propietarios de activos de ICS tras el 11-S. Una década después, OT:ICEFALL muestra que muchos de los mismos problemas, como los oscuros protocolos propietarios que carecen de la autenticación y el cifrado adecuados, siguen siendo habituales en los dispositivos que hacen funcionar nuestras infraestructuras críticas.

"Se sabe que los productos afectados por OT:ICEFALL son frecuentes en las industrias que son la columna vertebral de las infraestructuras críticas, como el petróleo y el gas, la industria química, la nuclear, la generación y distribución de energía, la fabricación, el tratamiento y la distribución de agua, la minería y la automatización de edificios", dijeron los investigadores de Forescout en su informe. "Muchos de estos productos se venden como "seguros por diseño" o han sido certificados con normas de seguridad de OT".

Mientras este estado de inseguridad por defecto ha continuado en el mundo OT, el número de ataques no ha hecho más que aumentar y evolucionar. Desde Stuxnet, hemos visto el ataque Industroyer que causó apagones en Ucrania en 2016, el malware TRITON que se utilizó en el intento de sabotaje de las plantas petroquímicas en Arabia Saudita en 2017, el malware Industroyer2 que se utilizó contra la subestación eléctrica en Ucrania este año, y el kit de herramientas INCONTROLLER APT. La empresa de seguridad de ICS Dragos rastrea 19 grupos de amenazas que tienen como objetivo los entornos de ICS, incluidos tres que se descubrieron el año pasado y mostraron la capacidad de acceder a las redes de ICS/OT.

Los fallos OT:ICEFALL afectan a dispositivos de Bently Nevada, Emerson, Honeywell, JTEKT, Motorola, Omron, Phoenix Contact, Siemens y Yokogawa. Incluyen monitores de estado, sistemas de control distribuido (DCS), estaciones de trabajo de ingeniería, RTU, PLC, controladores de edificios, sistemas instrumentados de seguridad (SIS), sistemas SCADA, protocolos e incluso un tiempo de ejecución lógico.

El tiempo de ejecución lógico es el software que interpreta y ejecuta la lógica de escalera, el código escrito por los ingenieros para actuar sobre las entradas y salidas del dispositivo. El tiempo de ejecución ProConOS de Phoenix Contact, por ejemplo, se utiliza en múltiples PLC de diferentes proveedores, lo que hace que los fallos descubiertos en él (la falta de autenticación criptográfica de la lógica cargada) sean un riesgo potencial para la cadena de suministro que conduce a la ejecución de código arbitrario.

"Debido a la falta de listas de materiales de software (SBOM) y a la complejidad de las cadenas de suministro de productos, a menudo no está claro qué tiempo de ejecución utiliza un PLC concreto", señalan los investigadores en su informe. "Los tiempos de ejecución suelen tener distintas versiones con sus correspondientes diferencias de protocolo y están sujetos a las decisiones de integración de los fabricantes. Un fabricante de PLC puede optar por utilizar el tiempo de ejecución pero no los protocolos, prefiriendo utilizar los suyos propios, o puede optar por utilizar el protocolo en un puerto no predeterminado o puede optar por cambiar la marca o modificar el tiempo de ejecución por completo. A falta de esfuerzos proactivos y coordinados por parte de los proveedores, las autoridades de numeración de CVE y los CERT para propagar el conocimiento de las vulnerabilidades de la cadena de suministro a todas las partes afectadas, la comunidad de seguridad se ve obligada a redescubrirlas periódicamente y al azar, lo que da lugar a la duplicación de CVE y complica el análisis de la causa raíz".

Por ejemplo, dos CVE asignados en el pasado a problemas en el tiempo de ejecución de ProConOS -CVE-2014-9195 y CVE-2019-9201, solo se asociaron a los PLC de Phoenix Contact, mientras que también afectaban a otros proveedores. Más tarde se descubrió un problema en los controladores STARDOM de Yokogawa y se le asignó CVE-2016-4860, pero en realidad es el mismo problema que CVE-2014-9195, dijeron los investigadores. El problema se agrava aún más por el hecho de que en el pasado muchos problemas de inseguridad por defecto, como los incluidos en OT:ICEFALL, no recibían ID de CVE en absoluto, ya que no se consideraban vulnerabilidades tradicionales, lo que dificultaba su seguimiento por parte de los clientes.

 

Mitigación de las vulnerabilidades de los dispositivos OT

El equipo de Forescout ha colaborado con la Agencia de Ciberseguridad y Seguridad de las Infraestructuras de Estados Unidos (CISA) durante el proceso de divulgación y la agencia ha publicado sus propios avisos para algunos de los problemas. Los propietarios de activos deben instalar parches y actualizaciones de firmware cuando los fabricantes de dispositivos los pongan a disposición, pero la solución de algunos de los problemas identificados podría implicar importantes esfuerzos y cambios de ingeniería, por lo que los proveedores podrían no abordarlos durante mucho tiempo. Mientras tanto, el equipo de Forescout recomienda las siguientes medidas de mitigación:

  • Descubrir e inventariar los dispositivos vulnerables. Las soluciones de visibilidad de la red permiten descubrir los dispositivos vulnerables en la red y aplicar las acciones de control y mitigación adecuadas.
  • Aplicar controles de segmentación y una higiene de red adecuada para mitigar el riesgo de los dispositivos vulnerables. Restringir las vías de comunicación externas y aislar o contener los dispositivos vulnerables en zonas como control de mitigación si no pueden ser parcheados o hasta que puedan serlo. Revisar las reglas del cortafuegos, especialmente los protocolos OT de la lista blanca, en función de los conocimientos de las PYMES. Algunos proveedores ofrecen cortafuegos y conmutadores dedicados con funciones de seguridad que tienen en cuenta el protocolo.
  • Supervisar los parches progresivos lanzados por los proveedores de dispositivos afectados y diseñar un plan de corrección para su inventario de activos vulnerables, equilibrando el riesgo empresarial y los requisitos de continuidad del negocio.
  • Supervisar todo el tráfico de la red en busca de actividades sospechosas que intenten explotar funcionalidades inseguras por diseño. Utilizar soluciones de supervisión con capacidades de DPI para alertar al personal de seguridad sobre estas actividades, de modo que se puedan tomar las medidas adecuadas.
  • Adquirir activamente productos seguros por diseño y migrar a variantes de productos seguros por diseño cuando estén disponibles y sea posible. Evaluar la postura de seguridad de los dispositivos incluyendo evaluaciones de seguridad en los requisitos de adquisición.
  • Utilizar las capacidades nativas de refuerzo, como los interruptores de modo físico en los controladores, que requieren una interacción física antes de poder realizar operaciones de ingeniería peligrosas. Algunos proveedores ofrecen soluciones plug-and-play para simular estas capacidades a nivel de red para múltiples controladores. Cuando sea posible, activar las alertas de los interruptores de modo operativo en las soluciones de supervisión.
  • Trabajar para reducir las consecuencias siguiendo las metodologías Cyber-PHA y CCE. Esto es importante para abordar no sólo la probabilidad sino también el impacto de los incidentes.


TE PUEDE INTERESAR...

Accede a la cobertura de nuestros encuentros
 
Lee aquí nuestra revista digital de canal

DealerWorld Digital

 

Forma parte de nuestra comunidad
 
¿Interesado en nuestros foros? 

 

Whitepaper