Archivo de la categoría: Vulnerabilidades

Repositorios sobre Vulnerabilidades en productos industriales

Posted on por
Responder

Para que una acción malintencionada tenga éxito y pueda afectar a los Sistemas de Control, Maquinaria o infraestructuras industriales de una organización, deberá explotar alguna vulnerabilidad que esté presente dentro de ésta.

Generalmente tendemos a fijarnos en aquéllas de carácter técnico, sin embargo existen otras muchas que pueden afectar a aspectos como:

  • Incumplimiento de políticas de seguridad.
  • Procedimientos de acceso componentes y sistemas.
  • Configuraciones.
  • Diseño del propio equipamiento.
  • Accesos físicos a equipos en planta, taller o entornos OT en general.
  • Comunicaciones y demás puntos de interconexión entre redes de distintos ámbito.

Lo cierto es que la gestión de vulnerabilidades, puede ser compleja dependiendo del tipo y tamaño de la organización, y sobre todo, la mitigación de las mismas una vez que éstas han sido anunciadas y que desencadenan todos los procesos,  tanto técnicos como organizativos y también procedimentales.

Como todos sabemos la principal medida es la aplicación de parches y actualizaciones, pero lo cierto es que esto en la teoría está muy bien, pero en la práctica se opta más por la aplicación de medidas compensatorias antes que actuar sobre los equipos finales.

En cualquiera de los casos para ser conscientes que nuestra organización puede estar en riesgo cuando se anuncia una vulnerabilidad que afecta a los equipos finales, sean hardware o software, debemos contar con fuentes de información en donde podamos encontrar información relativa a todas ellas para luego ver si realmente nos aplica o no. Esto es si esa vulnerabilidad que afecta a un equipo o solución de un determinado fabricante no aplica porque lo tenemos en nuestra organización o no.

Uno de los repositorios puede ser la iniciativa “ICS Advisory Project”  creada por Dan Ricci. En él podemos encontrar un muy buen resumen en función de diferentes criterios como son:

  • Gravedad de la vulnerabilidad.
  • Fabricante
  • Producto.
  • Ubicación geográfica.
  • …..

Otro es el apartado de “Advisories” del ICS-CERT . Allí las encontraremos por orden de publicación aunque las podremos ordenar también por fabricante.

En el caso de España, INCIBE-CERT dispone de un apartado de “Avisos” similar al del ICS-CERT y que podemos encontrar aquí. Si lo deseamos podemos suscribirnos y recibirlas directamente en nuestro correo electrónico.

Por supuesto los distintos fabricantes realizan anuncios cuando alguna se aha descubierto y proporcionan recomendaciones sobre cómo remediarlas, si es que se puede… Aquí os dejo algunos enlaces hacia las páginas Web de cada uno de ellos donde encontraréis notificaciones:

Otro sitio donde encontrar información CVE Details  donde podremos buscar por el fabricante, identificador de vulnerabilidad, entre otros parámetros. Aquí podrás encontrar las de fabricante OMRON.

Un saludo nos vemos en la siguiente!

 

Vulnerabilidades, métricas y cálculos en en SCI

Posted on por

Allá por junio de 2015 comentamos las vulnerabilidades relacionadas con Sistemas de Control Industrial y, a día de hoy,  continuamente vemos cómo se notifican cada vez más sea cual sea esta si de índole Software o Hardware. Ningún fabricante está exento, más aún cuando todos ellos no han podido ser diseñados bajo la premisa de ser seguro. Hablo desde el punto de vista de “Security” no “Safety”.

En este sentido uno de los métodos de catalogación es el “Common Vulnerability Scoring System”. Un framework abierto y ampliamente utilizado para estimar el impacto cuantitativo de las vulnerabilidades identificadas. Para ello se establece un conjunto de métricas las cuales se dividen de 3 grandes grupos como son: Base, Temporal y de Entorno, donde cada una de ellas engloba distintas características a considerar, como son el Vector de Ataque, privilegios requeridos, interacción con el usuario, remediación, etc.

Luego una fórmula matemática se encarga de establecer en una franja de 0 a 10, la gravedad de la misma, siendo 10 la más alta.

Actualmente se cuenta con la versión 3.1 la cual introduce algunos cambios con respecto a la versión 3.0.

A continuación, os dejo algunos documentos donde podréis encontrar información detallada con respecto a estas dos últimas versiones.

Documento CVSS 3.0

Documento CVSS 3.1

Calculadora CVSS 3.1

Sin embargo, este estándar se ha hecho con el fin de ser aplicado, principalmente en entornos IT, no para entornos OT. Los cuales, como es sabido, son muy distintos. Las consecuencias e impacto de la explotación de una de ellas podrá tener una repercusión Física. Por tanto, una vez más, debemos de establecer unos criterios acordes a los escenarios a los que nos enfrentamos.

En este sentido nos encontramos con IVSS, Industrial Vulnerability Scoring System. Un método que nos ayudará a establecer un valor teniendo en cuenta aspectos concretos de estos entornos como son impacto en la actividad, daños colaterales, rendimiento y elementos Safety.

Elaborada por Clint Bodungen,  la herramienta está disponible es su sitio Web podéis así como la fórmula empleada que permiten obtener dicho índice.

Hay que tener en cuenta que las vulnerabilidades a la hora de descubrirse se llevan a cabo en entornos controlados de laboratorio, junto con la posible explotación asociada. Por tanto, debemos tener presenta que las consecuencias e impacto dependerá del contexto y actividad donde se lleven a cabo. Un laboratorio nunca nos dará el resultado del entorno real.

Además, por ejemplo, no es lo mismo una fábrica donde produzca bajo estrategias JIT/JIS (Just In Time, Just In Sequence) a otra que lo haga con plazos de entrega de días o semanas donde una parada de 24 horas pueda llegar a ser asumible y no suponga repercusión alguna por disponer de estocaje suficiente. O bien, si de lo que hablamos es afecta a la actividad o la seguridad de los empleados como puede ser dispositivos Safety, robots o PLC de control de proceso.

Descubierta la misma, aun cuando el fabricante libere el parche o la remediación, es muy posible que pase un tiempo “muy considerable” antes de ser aplicada. Todo proceso de cambio debe realizarse forma controlada siguiendo una etapa de test, prueba piloto y finalmente despliegue controlado. No podemos llevar a cabo ninguna acción si no estamos seguros al 110 % de que no existirá incompatibilidad o impacto alguno, que pueda penalizar total o parcialmente los procesos bajo su control. No podemos introducir un riesgo mayor del que pretendemos mitigar con la corrección de una vulnerabilidad.

Esto en el mejor de los casos, ya que no sería la primera vez que se detectan vulnerabilidades sobre componentes o sistemas que no puedan ser actualizados, debiéndose aplicar otras medidas compensatorias como el Virtual Patching o definición de arquitecturas de red con mayor o menor índice de segmentación.

Hasta aquí la entrada de hoy, escueta pero que da lugar a invertir tiempo en lectura y tener contacto con un recurso online que nuevamente, entre otros muchos motivos, nos muestra las diferencia de los entornos IT y OT.

Un saludo!

 

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

Posted on por

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.

¿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.

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.

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.

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.

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