Publicaciones CERTSI e INCIBE sobre Ciberseguridad Industrial, actualizado 11/04/18.

Tanto INCIBE (Instituto Nacional de Ciberseguridad de España) como CERTSI (CERT de Seguridad e Industria) publican a menudo en sus respectivas Webs noticias, guías y artículos sobre distintas temáticas teniendo como telón de fondo la seguridad. Para esta ocasión he ordenado las referentes a Ciberseguriad Industrial, que recopilan un buen número de investigaciones, incidentes, análisis, e informes, sobre distintas temáticas.  Sin duda constituye un conjunto de referencias para el aprendizaje de todo profesional que esté o quiera desempeñarse en securización de estos entornos. Espero que os guste y sobre todo os resulte útil.

Un saludo!

Guías:

  1. Despliegue de un IDS/IPS y gestión centralizada de alertas.
  2. Protocolos y Seguridad en SCI.
  3. Identificación y reporte de incidentes de seguridad para operadores estratégicos: Guía básica de protección de Infraestructuras Críticas.
  4. El Puesto del Operador: Guía básica de protección de Infraestructuras Críticas.
  5. Guía de Seguridad de Protocolos Industriales – Smart Grid

 Artículos:

  1. Automatización de bajo conste.
  2. El valor de los indicadores de compromiso en la industria.
  3. Gestión de parches en Sistemas de Control.
  4. Introducción a los sistemas embebidos.
  5. Seguridad Industrial 2017 en cifras.
  6. Convergencia TI-TO.
  7. Retos y riesgos de ciberseguridad y privacidad en IoT.
  8. Iniciativas y y mejores prácticas de seguridad en IoT.
  9. 46 métricas para mejorar la ciberresiliencia en un servicio esencial.
  10. Diseño y configuración de IPS, IDS y SIEM en Sistemas de Control Industrial.
  11. Cómo evaluar mi nivel de capacidades en Ciberseguridad según C4V.
  12. Los conocimientos del personal de seguridad industrial.
  13. Ciberseguridad en las comunicaciones inalámbricas en Entornos Industriales
  14. SNMP, ¿es tan simple como el nombre indica?
  15. Cortafuegos transparentes, ladrillos de cristal.
  16. PRP y HSR: Protocolos redundantes.
  17. Robots y drones en la Industria 4.0.
  18. Hardware Hacking en Sistemas de Control Industrial.
  19. CrashOverride: El malware para SCI ataca de nuevo.
  20. Analizando la seguridad sin riesgos: laboratorios de pruebas.
  21. Asegurando la virtualización de tus sistema de control.
  22. Gestión de credenciales en sistemas de control.
  23. Prevención de intrusos y gestión de eventos para sistemas de control.
  24. Insider, las dos caras del empleado.
  25. Amenazas emergentes en entornos industriales.
  26. Honeypots Industriales.
  27. Gestionar el riesgo de los proveedores como propio.
  28. Seguridad en protocolos industriales – Smart Grid
  29. Criptografía para reforzar la ciberseguridad en entornos industriales.
  30. Características y seguridad en PROFINET.
  31. Analizadores de red en Sistemas de Control.
  32. Seguridad Industrial 2016 en cifras.
  33. ¿Nuevo ciberataque a la red eléctrica de Ucrania?
  34. Inventario de activos y gestión de la seguridad SCI.
  35. Líneas de actuación del Esquema Nacional de Seguridad Industrial.
  36. Protocolos Industriales: Herramientas de Seguridad.
  37. ¿Tu empresa es segura? Medir es el primer paso para conseguirlo.
  38. Atrapando sombras en la industria.
  39. Cyber Kill Chain en Sistemas de Control Industrial.
  40. DDOS de actualidad: IoT y los DNS de Dyn.
  41. Seguridad en BlueTooth: Fortalezas y debilidades.
  42. ZigBee en el laboratorio.
  43. Thinking in Big (Data) y la seguridad industrial.
  44. Seguridad desde abajo: dispositivos finales a escena.
  45. Familia de malware en la industria.
  46. Protegiéndose de BlackEnergy: Detectando anomalías.
  47. Seguridad en Comunicaciones ZigBee.
  48. BlackEnergy y los Sistemas Críticos.
  49. Desmontando Modbus.
  50. Safety y security: juntos pero no revueltos.
  51. BMS: Edificios inteligentes, ¿y seguros?
  52. Seguridad industrial 2015 en cifras.
  53. Un SCADA en la ciudad.
  54. Aplicando seguridad en WirelessHart.
  55. Sistemas de control de software libre.
  56. Arquitecturas de seguridad en la nube para la industria.
  57. Las aplicaciones de control se hacen mayores.
  58. Mi SCADA en las nubes.
  59. Evolucionando la comunicación en la industria.
  60. La Ciberseguridad en la Industria 4.0.
  61. Divide y vencerás: Segmentación al rescate.
  62. Monitorización de amenazas en SCADA.
  63. Evolucionando la infraestructura de red en SCI.
  64. Bug Bounties en SCI: Vulnerabilidades en busca y captura.
  65. El consumo eléctrico bajo control.
  66. Buenas prácticas de configuración en la red inteligente.
  67. Disciplina militar en Control Industrial: OPSEC.
  68. Auditorias en sistemas de control.
  69. Amenazas en los Sistemas de Control Industrial.
  70. Certificaciones de seguridad en sistemas de control.
  71. La evolución de los dispositivos en los sistemas de control industrial.
  72. Estándares de ciberseguridad en las redes inteligentes.
  73. BYOD en entornos industriales.
  74. IEC 62443: Evolución de la ISA 99.
  75. La seguridad de los coches inteligentes a examen.
  76. La ciberseguridad en las subestaciones y el estándar IEC 61850.
  77. Herramientas TI que evolucionan para TO.
  78. La evolución del software en los sistemas de control industrial.
  79. Diferencias entre TI y TO.
  80. Normativas de seguridad en sistemas de control.
  81. Identificación de sistemas de control industrial.
  82. Problemática de los antivirus en entornos industriales.
  83. Seguridad en Protocolos de Sistemas de Control Industrial.
  84. Del Air Gap a la Segmentación en ICS.
  85. Guía de seguridad de Sistemas de Control Industrial.
  86. La problemática de la ciberseguridad para los profesionales de los sistemas de control industrial.
  87. Protegiendo Infraestructuras Críticas: no es suficiente con medidas IT.
  88. Hacia una evaluación eficaz de la seguridad en ICS.

Otras Guías de interés:

  1. Guía de Pentest: Recolección de información (Information Gathering).
  2. Guía sobre análisis de tráfico con Wireshark.
  3. Guia de Seguridad en servicios DNS
  4. Ciber-Resiliencia: Aproximación a un marco de medición.
  5. Detección de APTs.

 

Seguridad en BACnet para control de edificios

El pasado día seis de enero publicaba un artículo en el que hablaba de la aplicación y fundamentos sobre BACnet para la gestión y control de edificios. Ahora bien,  hoy hablaremos de Seguridad en BACnet que, a diferencia de otros protocolos, sí dispone de medidas nativas aunque su implementación es opcional. Sí, opcional, con lo que todos sabemos lo que puede llegar a suceder… que no se aplica.

El propósito de la arquitectura es proporcionar autenticación entre dispositivos, origen de los datos y operador, además de confidencialidad e integridad de información.

La seguridad es añadida en forma de mensajes en la capa de red. Por definición, no hay una “capa de seguridad” como tal, pero se refieren a ella de una manera separada de tal manera que pueda ser entendida más fácilmente. Por ello, es que todos los menajes referidos a seguridad son tratados de forma separada, aunque en realidad forman parte de los mensajes a nivel de capa de red del propio protocolo.

BACnet delega en el uso de claves compartidas. Para la autenticación de dispositivos y usuarios, se utilizan tanto mensajes firmados como claves para firma; mientas que para la confidencialidad de datos, claves de cifrado y protección de payload. Se definen un total de 6 tipo de claves, como son:

  1. General-Network-Access, empleados para mensajes de broadcast, túneles de cifrado y  dispositivos con interfaces de usuario que no pueden autenticarlos.
  2. User-Authenticated, al contrario que el anterior, empleado por dispositivos cliente que sí pueden validar usuarios.
  3. Application-Specific, empleada para limitar a ciertos dispositivos intercambiar información de una aplicación concreta.
  4. Installation, usadas para dar acceso a dispotivos de la red BACnet de forma temporal para aquellos usuarios que así lo requieran.
  5. Distribution, para la distribución las claves como, General-Network-Acess, User-Authenticated, Application-Specific e Installation.
  6. Device-Master, Empleada únicamente para la distribución de la clave de Distribución. Es única para cada dispositivo.

El uso de claves para introducir distintos niveles de seguridad, lleva aparejado unas tareas de gestión, mantenimiento y recursos que pueden llegar a ser más o menos complejos dependiendo de cómo queramos proteger los dispositivos, la información y las instalaciones. Esto es, si el nivel de seguridad no es muy alto, o contamos con otros equipos que pueden introducirla de manera externa, la asignación de claves puede hacerse en el momento de la instalación de equipo y luego no cambiar. Pero si esto último es necesario, el protocolo dispone de mecanismos para cambiarlas con mayor o menor frecuencia.

Documento Seguridad en BACnet

En ese sentido, las claves pueden ser distribuidas a todos los dispositivos por un servidor de claves denominado “BACnet Key Server”. Las relativas a “General-Network-Access”, “User-Authenticated”, “Application-Specific” e “Installation” son reunidas y enviadas de forma conjunta a los distintos dispositivos junto con lo que se denomina “revisión number” por medio de la “Distribution-Key”. Cada dispositivo BACnet dispone de fábrica (o debería) de una clave maestra de dispositivo llamada “Device-Master” o contar con un proceso de asignación de una. Luego, el servidor de claves empleará ésta para crear la de distribución, “Distribution-Key”, y a partir de ahí hacer llegar el resto. El tratamiento de esta clave es distinto de las otras ya que se considera que cambia con menos frecuencia.

Cuando un dispositivo necesita mandar información de forma segura, se genera un nuevo tipo de mensaje en el que se introduce la información original dentro del payload “seguro”. El nivel más básico que se le da es la firma mediante HMAC (keyed-hash message authentication algorithm) mediante MD5 o SHA-256. Aparte, se indican tanto el origen y destino de las instancias de los dispositivos, identificador de mensaje y una marca horaria.

En otro orden, BACnet define dos tipos de redes red dependiendo de las medidas de seguridad aplicadas. Las define como “Trusted” donde se aplica seguridad física o mediante el uso de firmas o cifrado; o “Non-Trusted” en la que no se aplica ninguna de las anteriores.

Aquellos mensajes que no poseen ninguna medida de seguridad, se definen como “plain”, por tanto, podemos decir que pueden darse cuatro posibles tipos de estrategia o políticas de seguridad dentro de una red BACnet.

  1. Plain-trusted, seguridad física pero no se utiliza ningún protcolo.
  2. Signed-trusted, no se require seguridad física pero ésta se aplica mediante la firma de mensajes.
  3. Encrypted-trusted, no se requiere seguridad física, pero se consigue mediante el cifrado de mensajes.
  4. Plain-non-trusted, ninguna de las anteriores, ni física, ni firma ni cifrado de menajes.

Además de lo anterior, existe la posibilidad de determinar seguridad a nivel de dispositivo. Por ejemplo, aquellos equipos ubicados en redes “Plain-non-trusted” (no seguras). Al hablar de política a nivel de red, todos los dispositivos incluidos en ella deben ser configurados de la misma manera. Todos los dispositivos son configurados con una política de seguridad base que determina el nivel mínimo de seguridad para el envío y recibo de mensajes. Esta política podría ser mayor que la definida para la red BACNet, pero no menor.

También se permite establecer túneles cifrados entre dispotivos capaces de llevar a cabo esta tarea.

Con la integración de sistemas de Control y Automatización en redes tanto Ethernet como IP aparecen múltiples beneficios, pero también ciertas obligaciones. Los equipos comienzan a estar expuestos y por tanto, resulta necesario implementar ciertas medidas de seguridad. Cobra especial importancia cuando este protocolo es utilizado para los usos referidos al principio, esto es, sistemas de refrigeración, antincendios, elevadores, cámaras de circuito cerrado, entre otras. Algo que no es exclusivo de edificios de viviendas, también en fábricas o instalaciones industriales. No hablo sólo de las oficinas en ellas ubicadas sino en la propia planta. Por ejemplo, montacargas para trasladar maquinaria, piezas o cualquier otro elemento; sistemas de climatización para mantener temperaturas constantes; sistemas de ventilación para la extracción de gases; equipos contra incendios; etc.

BACnet aporta ciertas medidas para mitigar o reducir el riego de sufrir un incidente pero, aparte de ser configuradas, revisadas y actualizadas; deben ser implementadas. Pero aún y así pueden no ser efectivas contra ciertos ataques, ya que el tipo de instalaciones donde se emplea este protocolo, es necesario apoyarse en otras como pueden la seguridad física o el acceso remoto por medio de VPNs.

Un saludo a todos, nos vemos en la siguiente y no te olvides que puedes seguirnos también en @enredandoconred .

Un saludo, nos vemos en la próxima.

BACnet, fundamentos de un protocolo para la gestión de edificios

A menudo nos centramos en materia de Ciberseguridad haciendo referencia a aquellos equipos y sistemas que intervienen en los procesos productivos o entornos de control y automatización. Sin embargo, las fábricas no sólo son PLCs, HMIs, Workstations, sensores u actuadores. Dependiendo de la actividad y el tamaño, cuentan con otros elementos que también contribuyen a que se garantice la disponibilidad de la que tanto hemos hablado. Me refiero a sistemas de refrigeración, extinción de fuegos, climatización, montacargas, etc. los cuales pueden ser gestionados por medio del protocolo BACnet.

Habitualmente los vemos referenciados en los denominados “Edificios Inteligentes”, sin embargo, su uso ni es exclusivo de ellos ni es algo relativamente nuevo. La gestión de edificios viene dada por las siglas BMS, Building Management System debiéndose distinguir, entre edificios de viviendas o edificios industriales. En general, los sistemas BMS integran un conjunto de subsistemas encargados de los sistemas de control de iluminación, antincendios, alarmas, elevadores, ventilación, temperatura, etc. Si bien muchos de ellos son comunes a ambos entornos no podemos decir que son similares ya que las aplicaciones y alcance son distintos.

Ahora bien, al igual que PLCs, HMIs, y demás dispositivos, estos sistemas han de comunicarse entre sí para su propio funcionamiento y gestión. En este sentido, uno de los protocolos empleados es BACnet, Buiding Automation Control Network. Desarrollado en 1987, ha sido un ANSI e ISO estándar desde 1995 y 2003, respectivamente. Aunque su mantenimiento es continuo, el propósito de BACnet es proporcionar interoperabilidad entre sistemas y dispositivos en aplicaciones de control y automatización de edificios, mediante un protocolo de comunicaciones estándar.

Al igual que muchos otros, cada dispositivo BACNet es una combinación de hardware y software, encontrándolo como norma general en forma de controlador, pasarela o interfaz de usuario. Cada uno de ellos dispone de un identificador o número de instancia único que lo identifica y diferencia de los existentes en la red aparte de otros con información relativa a las entradas y salidas que  monitoriza y controla.

Dentro de BACnet podemos encontrar 3 conceptos claramente diferenciados, Objetos, Propiedades y Servicios.

Toda la información contenida dentro de un dispositivo BACnet es ordenada como objetos, el cual le convierte en un protocolo orientado justamente a esto mismo, a objetos. Cada Objeto” representa un componente del propio dispositivo o un conjunto de información que puede ser solicitada por otro a través de medios como Ethernet, IP, RS-485, etc.

El protocolo define un total de 54 tipos de objetos para los usos más comunes cubriendo así la mayoría de las necesidades. Sin embargo, da la posibilidad de crear otros nuevos para no interferir sobre aquellos usos más concretos o aplicaciones propietarias.

La imagen muestra la arquitectura e interoperabilidad entre los distintos elementos que definen el funcionamiento del protocolo para la gestión y automatización de edificios BACnet.

Arquitectura e inteoperabilidad en BACnet

 

Cada objeto tiene un identificador de 32 bits el cual contiene un código para el tipo de objeto y el número de instancia de dicho objeto.

Con independencia del propósito o función, cada “Objeto” posee un conjunto de “Propiedades”. Cada una de ellas contendrá dos partes, un identificador y un valor. El identificador son números que la definen de forma única en el ámbito del tipo de objeto; y el valor, la magnitud del mismo. Luego, dicha información podrá ser tanto de lectura como de y escritura.

Si unificamos ambos conceptos, podemos decir que cada “Objeto” incluyen “Propiedades” que determinan sus capacidades, operación e información asociada.

Como hemos dicho anteriormente los dispositivos interactúan entre sí para su operación. Cuando un equipo se comunica con otro para llevar a cabo una determinada acción, lo hace a través de los denominados “Servicios”. Los servicios son agrupados en 5 categorías según su funcionalidad:

  1. Object access (lectura, escritura, creación, borrado)
  2. Device management (descubrimiento, sincronización horaria, inicialización, copia de respaldo y restauración)
  3. Alarm and event (alarmas y cambios de estado)
  4. File transfer (Tendencia de datos y cambio de programa)
  5. Virtual terminal (interfaz hombre-máquina por medio de menús o similar)

Cada dispositivo envía las peticiones empleando mensajes convenientemente estructurados tanto en la pregunta como en la respuesta. Los mensajes son codificados en un stream numérico definiendo las funciones que deben llevarse a cabo.

Para que dichos mensajes puedan enviarse y recibirse, se establecen varios medios de transporte, los cuales se citan a continuación:

  1. BACnet/IP
  2. BACnet ISO 802-3 (Ethernet)
  3. BACnet MS/TP (Master-Slave/Token Passing)
  4. BACnet over ARCNET
  5. BACnet Point-to-Point (EIA-232 and Telephone)
  6. BACnet over LonTalk Foreign Frames
  7. BACnet over ZigBee

Cada uno de ellos son una combinación de capas Físicas y Enlace de Datos. Sin embargo, el mensaje BACnet es independiente del medio empleado pudiendo existir a su vez pasarelas referenciadas como “Routers” que puedan combinar cada uno de los medios. No obstante, serán los dos primeros los que reclaman más nuestra atención ya que proporcionan integración con redes tradicionales.

BACnet/IP proporciona conectividad a nivel de capa 3 pudiendo ser los equipos accesibles desde distintas redes IP. Cuando este medio es empleado con múltiples subredes, es necesario el uso de una funcionalidad especial denominada BBMD, Broadcast (Management Devices), equipo empleado para administrar los mensajes broadcast entre subredes. Éste recoge dichos mensajes y los redistribuye a otro BBMD ubicado en otra red mediante mensajes unicast.

Mientras que, BACnet ISO 802.3, similar al anterior, pero limitando las comunicaciones a nivel de capa 2.

Ahora bien, teniendo en cuenta los conceptos acerca de dispositivos, objetos propiedades, servicios y la forma en la que transmitir los mensajes, BACnet proporciona capacidades funcionales las cuales son denominadas como “Interoperability Areas”.  Existen un total de 5:

  1. Data Sharing, intercambio de información entre dispositivos. Lo mensajes pueden ser priorizados en función de su propiedad, además de ser de lectura o lectura/escritura.
  2. Trending, visualización de los valores recogidos y graficados para determinar tendencias.
  3. Scheduling, programación de tareas a ejecutar en momentos o intervalos concretos.
  4. Alarm & Event Management, intercambio de información relativo a alarmas o eventos.
  5. Device & Network Management, permite el descubrimiento de dispositivos, objetos dentro de ellos, establecimiento y reconexión en caso de caída de comunicación, sincronización horaria y reinicio.

Estas áreas están definidas dentro de BACnet como BIBB, “BACnet Interoperability Blocks”.

Puesto que BACnet es un estándar, los distintos fabricantes de equipos deben garantizar que sus productos soportan ciertos requisitos para poder operar unos con otros. Para ello, deben cumplir con lo definido en lo que se denomina “Protocol and Implementation and Conformance Statement”, PICS; una ficha técnica con distinta información y entre ella, los distintos BIBB soportados para que puedan ser comparados y garantizar su funcionamiento.

Es importarte resaltar que los mensajes pueden ser dotados de una “Prioridad” dependiendo el tipo de mensaje y la información que transporta. Se definen un total de 16, siendo las dos primeras relativas a cuestiones de “Safety”, “Manual Life-Safety” y “Automatic Life-Safety”.

Hasta aquí la presentación de los conceptos básicos de BACnet. Un protocolo con unas características específicas para entornos concretos. Como decía, es importante remarcar que su uso puede no estar necesariamente asociado a edificios de viviendas sino también a entornos industriales. Éstos también disponen de sistemas de refrigeración, sensores de humos, montacargas, etc. dependiendo, claro está, del tamaño y la actividad. Podrán almacenar productos químicos que deban ser almacenados bajo unas condiciones de temperatura determinada; entornos donde la calidad del aire deba ser única debiendo accionarse los sistemas de ventilación bajo unas circunstancias concretas; controlar la iluminación de un pabellón en distintas franjas horarias, entre otras muchas. ¿Alguien se imagina los efectos que pudiera tener si algo o alguien, pudiese alterar a las dos de la madrugada la iluminación de parte o toda una nave de producción y los operarios no pudiesen trabajar? Y peor aún, cómo o porqué se genera esa situación si no se puede acotar la causa que lo origina. No estamos hablando de un hecho con unas consecuencias graves, pero sí con impacto sobre la actividad de la propia empresa.

Un saludo a todos, nos vemos en la siguiente y no te olvides que puedes seguirnos también en @enredandoconred .

Triton/Trisis/Hatman; un malware para SIS.

Hace pocos días atrás saltaba la noticia acerca de la aparición de un nuevo malware para Sistemas de Control Industrial bajo el nombre TRITON, TRISIS o HATMAN. Un malware que a diferencia de otros como Stuxnet, Havex, Blackenergy2, CrashOverride tiene como objetivo sistemas SIS.

Los sistemas SIS (Safety Instrumented Systems) son los encargados de mantener bajo condiciones “seguras” instalaciones, procesos y equipos en caso de producirse alguna anomalía o mal funcionamiento. Así como en inglés podemos diferenciar entre “Security” y “Safety”, en español, empleamos únicamente la palabra “Seguridad” introduciendo cierta confusión. Es por ello es que muchas veces debamos especificar el ámbito al que hacemos referencia. Esto es, “Security”, seguridad de la información y “Safety”, seguridad de personas o instalaciones.

Estos sistemas operan al margen del propio proceso productivo, monitorizándolo y siendo independientes de los equipos que participan en él. No obstante, pueden estar integrados dentro de éstos. Aunque, en general, el equipamiento industrial es robusto y confiable, los SIS lo son aún más incorporando técnicas de corrección de errores, autodiagnóstico, componentes redundantes, aparte de una implementación específica acorde a la instalación o infraestructura de la que van a formar parte. Los requisitos están regulados según el estándar bajo el estándar IEC-61508, habiendo otros como el IEC-61511 que lo complementa en cuanto a uso de los mismos.

Cuando un sistema SIS detecta una condición que supera, o va en contra, de lo programado, actúa llevando el proceso a un estado seguro o deteniendo la actividad. Por ejemplo, son los encargados de parar el brazo de un robot en caso de que la puerta de la jaula donde se ubique, se abra evitando que éste pueda golpear a un técnico o dañar las instalaciones. O bien, parar una cadena de montaje si alguno de los sensores infrarrojos que delimitan su perímetro, detectan la presencia de una persona mientras está en movimiento evitando algún tipo de golpe, lesión o atrapamiento.

Como decía al principio, en esta ocasión, el malware detectado no afecta a sistemas de control tradicionales sino SIS, lo que supone un cambio a lo que podríamos estar acostumbrados y una evolución en los ataques a elementos OT.

TRITON/TRISIS/HATMAN, según sea la fuente en la que nos basemos, permite realizar cambios en los controladores SIS del fabricante Schneider Electric modelo Triconex. Entre sus características destacamos la capacidad para leer programas, lectura y escritura de funciones, consultas del estado del controlador y otras adicionales que pueden ser implementadas por medio de payloads específicos.

Durante el incidente que supuso la posterior investigación y detección de este malware, algunos controladores entraron en un estado de “seguridad” provocado por un supuesto fallo y que automáticamente pararon el proceso.

El malware se compone de dos piezas fundamentales. Por un lado, un componente que reside en un equipo tipo PC que posee el software legítimo para la comunicación de los controladores y por otro, dos binarios que se descargan en el propio controlador para actuar sobre él.

Todo comienza con el compromiso de la estación de trabajo encargada de la comunicación contra estos controladores SIS y que emplea sistema operativo Windows. El malware es nombrado como si fuera la aplicación Triconex Trilog, cuya función es el análisis de logs de las estaciones Triconex y que se encuentra dentro de la suite TriStation. El malware es distribuido dentro de un ejecutable denominado “trilog.exe”. Se trata de un script escrito en Python empleando el compilador “py2exe”, el cual es entregado junto con un fichero “library.zip”. Éste, contiene las librerías necesarias para poder operar así como dos binarios necesarios “inject.bin” (código de función maliciosa) e “imain.bin” (control lógico malicioso) que serán enviadas al controlador para la interacción con él. FireEye lo resume así en la siguiente imagen:

Triton Trisis Hatman

Una vez iniciado “trilog.exe” se crea una instancia que comprueba el estado del controlador mediante al protocolo TriStation empleado por el software legítimo TriStation TS1131 para la configuración de los mismo a través del puerto UDP 1502. Si éste se encuentra operativo, conecta con él y pasa los binarios “inject.bin” e “imain.bin” a las librerías de comunicación para enviarlas y almacenarlas en la memoria del controlador.

Una vez allí, el script realiza comprobaciones periódicas para conocer el estado del controlador. Si éste presenta algún error intenta resetearlo a un estado previo mediante el protocolo TriStation. Si esto fracasa, intenta escribir datos falsos en esa misma memoria para borrar cualquier rastro y obstaculizar cualquier tarea forense para determina la causa que ha provocado el fallo.

Dicho protocolo, que no implementa medidas de autenticación y cifrado aunque pueden configurarse ACLs en los equipos que lo dispongan, no está documentado públicamente,. Por tanto hace entender que el autor debió realizar labores de ingeniería inversa para poder llevar a su implementación. El descubrimiento de controladores SIS puede ser realizado mediante el envío de paquetes broadcast usando UDP 1502.

Es importante señalar que los controladores Triconex disponen de un “switch” físico que permite conmutar entre los distintos estados en los que puede operar el equipo. Las configuraciones y cambios deben realizarse en modo “Program”, posición bajo la que podría actuar TRISIS. Sin embargo, si lo está en modo “Run” o “Remote” las modificaciones no están permitidas, con lo que reduciríamos la probabilidad de que pueda ser comprometido.

Así pues, se presentan, a priori, distintos escenarios con las consecuencias que podrían tener sus efectos. Estos podrían ser:

  1. Parada del proceso. Se provocan distintos cambios no autorizados que hagan que los equipos detengan su funcionamiento en previsión de consecuencias mayores.
  2. Programación errónea de dispositivos SIS. Introducir variables o parámetros que permitiesen la operación de las instalaciones bajo condiciones que entrañen peligro para personas y elementos físicos.
  3. Parada o alteración de planta. Dependiendo del impacto afectar a la actividad de la compañía.
  4. Daños físicos. Sin la capacidad de regularizar o parar la actividad en caso necesario, la maquinaria o sistemas no interrumpirían su funcionamiento y por consiguiente el correspondiente daño.

Al parecer, se tiene constancia de que al menos existe una víctima localizada en la zona de Oriente Medio, no trascendiendo su identidad. Dada la naturaleza, propósito, grado de conocimiento tanto tecnológico como de proceso que se requiere, hace pensar que una nación pudiera estar detrás de la autoría. No se aprecian objetivos ni intereses económicos lo que se podría descartar delincuencia organizada.

Sin bien debemos ser conscientes de este nuevo y preocupante escenario, hemos de contextualizar y valorar todas las pruebas existentes, evitando sensacionalismos y alarmas innecesarias. La Ciberseguridad Industrial es un tema álgido dentro de los profesionales del sector, por lo que debemos analizar las circunstancias, condiciones, requerimientos y tecnologías para que estos ataques tengan efecto. Algunos de ellos podrían ser:

  1. Aplica a equipos concretos de un determinado fabricante, no a todos.
  2. Debe darse la condición de que un conmutador físico debe estar en cierta posición.
  3. Alto conocimiento de esta tecnología.
  4. Conocimiento del proceso que se gestiona para poder actuar de forma dirigida y provocar el mayor daño o impacto posible.
  5. No seguir las principales recomendaciones o estándares en materia de Ciberseguridad Industrial. Dependiendo del tipo de compañía, infraestructura o sector esto pudiera ser más o menos probable. No podemos considerar una empresa del sector petroquímico que una manufacturera del sector automoción.

Por último, mencionar algunas recomendaciones que pueden evitar tanto la infección, como la propagación y posterior ejecución.

  1. Establecer una red físicamente independiente para los sistemas SIS.
  2. Implementar NGFW que filtren el tráfico de gestión hacia ellos.
  3. Aplicar Control de Aplicación, Antivirus e IDS/IPS a nivel de red en NGFW.
  4. Sobre la Workstation para sistemas SIS aplicar soluciones de Control de acceso, usuarios con permisos específicos, integración a posible Directorio Activo; Whitelisting de Aplicación [1], [2]; Control de dispositivos USB [1]
  5. Aplicar controles de acceso físico a dichos sistemas; cabinas, armarios, etc.
  6. Registro de logs o envío de eventos cada vez que se lleve a cabo alguna intervención sobre SIS.
  7. Verificar la posición correcta de conmutadores físicos, en este caso, modo “Run” o “Remote”.

Así pues, por esta y otras, amenazas, vectores de ataque e intereses de distinto tipo, resulta necesario tomar medidas y controles sobre nuestros entornos OT. Obviamente, cada infraestructura, organización o compañía será objeto de unas u otras dependiendo de la importancia estratégica, criticidad o actividad, despertando los intereses de agencias, gobiernos, competencia o delincuencia. No podemos tratar a todos por igual. Hemos de contextualizar y analizar de la manera que merece, con la inteligencia que requiere.

Un saludo, nos vemos en la próxima.

Referencias:

Más información:

LLDP, pros y contras de la difusión de información en redes PROFINET

Aunque existen multitud de protocolos propietarios en redes OT, existen estándares que permiten la conexión entre productos de distintos fabricantes. Uno de ellos es PROFINET, evolución del extendido PROFIBUS. Según sea su implementación encontraremos distintas funciones PROFISAFE, PROFIENERGY, PROFINET-MRP, etc. Sin embargo, este protocolo no viene solo, sino que también hace uso de otros para su funcionamiento, entre ellos LLDP. Si, parece que no, pero sí.

Como hemos dicho en anteriores ocasiones, la evolución de las comunicaciones industriales tiende a basarse sobre tecnología Ethernet en detrimento, en muchos casos no en todos, de las comunicaciones serie. Esto va a traer consigo muchas ventajas, pero también algunos inconvenientes. Por ejemplo, será necesario el despliegue de distintas medidas que reduzcan el riesgo de que algo, o alguien, pueda atentar de manera voluntaria o involuntaria contra la disponibilidad de las instalaciones. Y es que, a mayor interconexión, mayor grado de exposición.

LLDP, Link Layer Discovery Protocol, es un protocolo empleado por dispositivos de red para anunciar información propia a otros equipos y dispositivos. Viene definido por el IEE 802.1AB. Su funcionamiento es muy similar al propietario de Cisco CDP, Cisco Discovery Protocol. Todos los dispositivos PROFINET lo soportan y es empleado para identificar, comprobar y mantener la topología de una red PROFINET, aparte de obtener información de diagnóstico si algo cambia. Otro de los usos es facilitar la puesta en marcha, tanto en un funcionamiento normal como en caso de fallo de algún equipo siendo necesario su sustitución. Las operaciones a este respecto se realizan de forma automática y sin necesidad de herramientas tipo software, lo cual simplifica y agiliza la forma en la que un equipo es reemplazado, minimizando la pérdida de disponibilidad.

Para ello los dispostivos PROFINET envían de forma cíclica esta información. Sin embargo  desde el punto de vista de la seguridad…

Haciendo un uso legítimo,  todo son facilidades. Sin embargo, cara a la realización de una auditoría o pentesting en entornos industriales que empleen PROFINET, LLDP se convierte en una fuente de información muy, muy buena.  Las tramas LLDP son enviadas a la dirección multicast 01:80:c200:00e. Los switches, por defecto, inundarán estas tramas por todos los puertos con lo que si conectamos nuestro Wireshark en alguna boca que encontremos libre… Seremos capaces de obtener toda esta información que se anuncia.

Empecemos por lo sencillo, aquí va una captura de un switch del fabricante HP…

LLDP_01

Como podemos comprobar podemos ver el nombre, boca del switch a la que estoy conectado, versión del Firmware, Hardware, etc. etc.

¿Ahora bien que pasa con equipos industriales? ¿Qué información podemos extraer? Veamos algunos ejemplos.

En la siguiente imagen podemos ver la que anuncia un switch SIEMENS. Allí podemos ver que estamos conectados al puerto 1, modelo X208, funciones MRP, IP de administración, etc.

LLDP_02

En la siguiente captura veremos el tráfico referente a un autómata S7-300 a lque nos hemos conectado a una de sus interfaces disponibles en su CPU.

LLDP_03

Como podemos ver aquí ya la información disponible es algo distinta, aunque se mantienen algunos campos como Chassis Subtype, Time to Live, etc. Sin embargo, algunos de los que no están por ejemplo el referente a MRP, protocolo utilizado en  switches para detectar bucles en topologías en anillo. Aprovecho para dejaros el link a una entrada que escribí hace un tiempo. Pincha aquí.

Como último ejemplo pondremos la trama esta vez de un módulo de comunicaciones CP del mismo PLC S7-300 que citaba anteriormente.

LLDP_04

Sin duda la información que vemo en cuanto a cantidad y calidad es muy importante. Si vemos habla de CP 343, propia de estos PLCs, con lo que ya sabemos el modelo que se trata. Como información extra podríamos ver de qué modelo de Firmware 3.2.23.

A partir de aquí habría que investigar si existe alguna vulnerabilidad conocida. En este caso no afecta, pero si la versión hubiera sido algo inferior, desde luego que sí. Un ejemplo de ellas, las podemos encontrar aquí:

Vulnerabilidad en módulos de comunicaciones SIEMENS.

Múltiples vulnerabilidades en módulos SIMATIC CP 343-1/CP 443-1 y CPU SIMATIC S7-300/S7-400 de Siemens

Como podemos comprobar LLDP puede ser un gran aliado en tareas de mantenimiento, puesta a punto o reducción del tiempo en caso de avería ya que simplifica todas las tareas asociadas para restaurar la operatividad. Sin embargo, surge el problema de qué hacer al publicitarse tanta información que luego, pueda hacerse un mal uso de ella. Se me ocurren varios usos, pero mejor no dar ideas.

Sin duda, desde un punto de auditoría o pentesting, LLDP será un gran recurso para una fase inicial de “Information Gathering”, pero como digo, en malas manos…

El problema aquí es que el propio protocolo PROFINET necesita de LLDP por lo que su uso debe ser permitido ya que se requiere bien para el funcionamiento como para reducir el tiempo de indisponibilidad por fallo. Cisco en alguno de sus recomendaciones deshabilitar CDP o LLDP para los equipos finales. Obviamente éstos no lo necesitar para su funcionamiento, pero en Controladores sí.

Puesto que debemos convivir con él, una de la alternativa es el bloqueo de puertos, bien de forma física como lógica.

Phisical Block Switch Port Siemens

No quiero decir con esto que gracias a LLDP nuestras redes PROFINET van a estar en peligro (que también), sino que existen protocolos que para su uso requieren de la difusión de información que aunque no queramos publicarla, debemos de hacerlo para aprovecharnos de las ventajas que éstos ofrecen en el mantenimiento, operación y garantía de disponibilidad.

¡Un saludo, nos vemos en la siguiente!

Edorta

 

Publicaciones CERTSI e INCIBE sobre Ciberseguridad Industrial, actualizado 29/10/17.

Tanto INCIBE (Instituto Nacional de Ciberseguridad de España) como CERTSI (CERT de Seguridad e Industria) publican a menudo en sus respectivas Webs noticias, guías y artículos sobre distintas temáticas teniendo como telón de fondo la seguridad. Para esta ocasión he ordenado las referentes a Ciberseguriad Industrial, que recopilan un buen número de investigaciones, incidentes, análisis, e informes, sobre distintas temáticas.  Sin duda constituye un conjunto de referencias para el aprendizaje de todo profesional que esté o quiera desempeñarse en securización de estos entornos. Espero que os guste y sobre todo os resulte útil.

Un saludo!

Guías:

  1. Despliegue de un IDS/IPS y gestión centralizada de alertas.
  2. Protocolos y Seguridad en SCI.
  3. Identificación y reporte de incidentes de seguridad para operadores estratégicos: Guía básica de protección de Infraestructuras Críticas.
  4. El Puesto del Operador: Guía básica de protección de Infraestructuras Críticas.
  5. Guía de Seguridad de Protocolos Industriales – Smart Grid

 Artículos:

  1. Los conocimientos del personal de seguridad industrial.
  2. Ciberseguridad en las comunicaciones inalámbricas en Entornos Industriales
  3. SNMP, ¿es tan simple como el nombre indica?
  4. Cortafuegos transparentes, ladrillos de cristal.
  5. PRP y HSR: Protocolos redundantes.
  6. Robots y drones en la Industria 4.0.
  7. Hardware Hacking en Sistemas de Control Industrial.
  8. CrashOverride: El malware para SCI ataca de nuevo.
  9. Analizando la seguridad sin riesgos: laboratorios de pruebas.
  10. Asegurando la virtualización de tus sistema de control.
  11. Gestión de credenciales en sistemas de control.
  12. Prevención de intrusos y gestión de eventos para sistemas de control.
  13. Insider, las dos caras del empleado.
  14. Amenazas emergentes en entornos industriales.
  15. Honeypots Industriales.
  16. Gestionar el riesgo de los proveedores como propio.
  17. Seguridad en protocolos industriales – Smart Grid
  18. Criptografía para reforzar la ciberseguridad en entornos industriales.
  19. Características y seguridad en PROFINET.
  20. Analizadores de red en Sistemas de Control.
  21. Seguridad Industrial 2016 en cifras.
  22. ¿Nuevo ciberataque a la red eléctrica de Ucrania?
  23. Inventario de activos y gestión de la seguridad SCI.
  24. Líneas de actuación del Esquema Nacional de Seguridad Industrial.
  25. Protocolos Industriales: Herramientas de Seguridad.
  26. ¿Tu empresa es segura? Medir es el primer paso para conseguirlo.
  27. Atrapando sombras en la industria.
  28. Cyber Kill Chain en Sistemas de Control Industrial.
  29. DDOS de actualidad: IoT y los DNS de Dyn.
  30. Seguridad en BlueTooth: Fortalezas y debilidades.
  31. ZigBee en el laboratorio.
  32. Thinking in Big (Data) y la seguridad industrial.
  33. Seguridad desde abajo: dispositivos finales a escena.
  34. Familia de malware en la industria.
  35. Protegiéndose de BlackEnergy: Detectando anomalías.
  36. Seguridad en Comunicaciones ZigBee.
  37. BlackEnergy y los Sistemas Críticos.
  38. Desmontando Modbus.
  39. Safety y security: juntos pero no revueltos.
  40. BMS: Edificios inteligentes, ¿y seguros?
  41. Seguridad industrial 2015 en cifras.
  42. Un SCADA en la ciudad.
  43. Aplicando seguridad en WirelessHart.
  44. Sistemas de control de software libre.
  45. Arquitecturas de seguridad en la nube para la industria.
  46. Las aplicaciones de control se hacen mayores.
  47. Mi SCADA en las nubes.
  48. Evolucionando la comunicación en la industria.
  49. La Ciberseguridad en la Industria 4.0.
  50. Divide y vencerás: Segmentación al rescate.
  51. Monitorización de amenazas en SCADA.
  52. Evolucionando la infraestructura de red en SCI.
  53. Bug Bounties en SCI: Vulnerabilidades en busca y captura.
  54. El consumo eléctrico bajo control.
  55. Buenas prácticas de configuración en la red inteligente.
  56. Disciplina militar en Control Industrial: OPSEC.
  57. Auditorias en sistemas de control.
  58. Amenazas en los Sistemas de Control Industrial.
  59. Certificaciones de seguridad en sistemas de control.
  60. La evolución de los dispositivos en los sistemas de control industrial.
  61. Estándares de ciberseguridad en las redes inteligentes.
  62. BYOD en entornos industriales.
  63. IEC 62443: Evolución de la ISA 99.
  64. La seguridad de los coches inteligentes a examen.
  65. La ciberseguridad en las subestaciones y el estándar IEC 61850.
  66. Herramientas TI que evolucionan para TO.
  67. La evolución del software en los sistemas de control industrial.
  68. Diferencias entre TI y TO.
  69. Normativas de seguridad en sistemas de control.
  70. Identificación de sistemas de control industrial.
  71. Problemática de los antivirus en entornos industriales.
  72. Seguridad en Protocolos de Sistemas de Control Industrial.
  73. Del Air Gap a la Segmentación en ICS.
  74. Guía de seguridad de Sistemas de Control Industrial.
  75. La problemática de la ciberseguridad para los profesionales de los sistemas de control industrial.
  76. Protegiendo Infraestructuras Críticas: no es suficiente con medidas IT.
  77. Hacia una evaluación eficaz de la seguridad en ICS.

Otras Guías de interés:

  1. Guía de Pentest: Recolección de información (Information Gathering).
  2. Guía sobre análisis de tráfico con Wireshark.
  3. Guia de Seguridad en servicios DNS
  4. Ciber-Resiliencia: Aproximación a un marco de medición.
  5. Detección de APTs.