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

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

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

 

ICSSPLOIT, paro de PLCs S7-300 y S7-400

Hola de nuevo. Siguiendo en la línea de herramientas orientadas a redes industriales, hoy le toca turno a ICSSPLOIT.

ICSSPLOIT es un framework dirigido a sistemas y protocolos de control industrial que puede sernos de utilidad en tareas como auditorías y labores de pentesting. Escrito en Python, presenta un aspecto similar al Metasploit, conservando la interfaz y la forma de interacción. Se trata de un software Open Source pudiéndolo descargar desde su sitio en Github. Allí podremos ver el conjunto de scanners, exploits, protocolos y clientes que soporta, y que esperemos vaya creciendo con el tiempo. Veamos un resumen.

La herramienta viene preparada para Kali Linux incluyendo lo necesario para su funcionamiento. Sin embargo, si algo nos faltase, podríamos mirar su fichero “requirements” y llevar a cabo la instalación de los paquetes mediante:

pip install -r requirements

Así pues qué mejor manera que verla en acción con un ejemplo. En otras entradas he trabajado con simuladores pero en esta ocasión lo haré con un PLC Siemens S7-300 real. Por supuesto, en un entorno de laboratorio. Por si fuera poco, además lo haré en formato vídeo. Una novedad que he querido introducir gracias al creciente número de visitas que ha ido teniendo el blog. Así pues, a continuación, veremos cómo llevar a “STOP” tanto la CPU como el una tarjeta CP del autómata para luego revertir el proceso. Todo de forma remota. Ahí va!

Como decía, también es válido para los S7-400. A continuación muestro la captura con Wireshark sobre los paquetes enviados y recibidos. Comentar que el PLC tiene IP 192.168.0.1 y el PC 192.168.0.100 .

Y su arranque:

Hasta aquí la entrada de hoy. Corta, pero que con el vídeo espero haya sido ilustrativa y hayamos descubierto esta nueva herramienta que sin duda va a ser de mucha utilidad para los profesionales de la seguridad. En sucesivas entradas iremos descubriendo nuevas funcionalidad, poco a poco.

¡Un saludo, nos vemos en la siguiente!

Edorta