Blog del CCI

sábado, 19 de abril de 2014

De cuando una debilidad revoluciona los medios: HeartBleed y los ICS (Claudio Caracciolo, 11Paths, CCI)

Introducción

En la historia de la Ciberseguridad siempre existieron debilidades graves que “revolucionaron” el mercado de alguna u otra manera.  Algunas de ellas por la potencialidad de las fallas encontradas, otras por la masividad en el uso del software afectado, otras simplemente porque afectaban a un producto específico que de por sí, ya era llamativo…

Hace un poco más de 10 días aproximadamente, el mundo entero se hizo eco de una debilidad sobre OpenSSL llamada HeartBleed dado que la falla se encuentra en la funcionalidad llamada HeartBeat y que por medio de la misma, un atacante puede lograr que los servidores que tienen SSL/TLS implementado con la versión de OpenSSL vulnerable, respondan a determinadas peticiones revelando datos contenidos en la memoria del propio servidor. Considerando que el funcionamiento de SSL/TLS se centra en la criptografía asimétrica y para lo cual se poseen 2 claves, una pública utilizada para cifrar una comunicación y otra privada para descifrarla, y que la privada se ejecuta en el servidor, la falla de la funcionalidad de HeartBeat permite obtener la clave privada desde el propio servidor y así descifrar todas las comunicaciones que puedan capturarse a pesar de estar bajo HTTPS.

Esta debilidad ha sido considerada tan grave que incluso ha sido difundida a través de medios de comunicación masivos en todo el mundo con el objetivo de alertar a toda la población usuaria de internet, y es así como nos encontramos con algunos de estos medios que por no terminar de entender cuál era el problema y con el apuro de comunicar rápidamente, han mencionado a esta vulnerabilidad  erróneamente como un virus confundiendo el mensaje y finalmente, desinformando.

Cuando en el Centro (CCI-Es.org) se planteó escribir un post sobre esta vulnerabilidad, me parecía que no tenía sentido volver a comentar la misma explicación que tan bien han realizado otros sitios periodísticos, portales técnicos, o incluso el sitio oficial www.heartbleed.com , y en este sentido preferí dejar pasar unos cuantos días antes de terminar de escribirlo para tratar de ir un poco más allá de la debilidad en sí misma y analizar la problemática en el sector industrial.

Análisis y Respuestas Varias

Es cierto, la debilidad es grave.
Es cierto, la debilidad tiene dos grandes frentes por atacar, y deben ser en el siguiente orden sí o sí:

  1. Los administradores de todos los sitios web con OpenSSL deben verificar si la versión que poseen implementada es vulnerable, y en caso positivo, actualizarla.
  2. Los usuarios de dichos sitios deben cambiar las claves una vez actualizados.  Para lo cual, los administradores de dichos sitios, deberían notificarles que estuvieron expuestos y que han actualizados los servidores para que ellos hagan el cambio.

Pero en verdad, en entornos industriales, ¿es lo más importante que nos ocurre respecto a la Ciberseguridad? ¿Deben los administradores de estos entornos salir corriendo a actualizar las versiones de OpenSSL?  

La respuesta natural es sí, sin embargo, debemos repensar un poco mejor nuestro estado del arte:  

Sobre la fecha en que se hizo pública la debilidad, se realizaron búsquedas en el famoso buscador de dispositivos conectados a Internet, Shodan, con el fin de determinar cuantos ICS eran vulnerables a esta nueva debilidad.  El resultado fue sorprendente, aproximadamente 1500 sistemas eran vulnerables, lo cual es un número realmente bajo pero (siempre hay un pero), con darnos una vuelta por la documentación de los ICS, o realizar otro tipo de búsquedas en el mismo Shodan nos daremos cuenta que la gran mayoría de los sistemas de control industrial implementados no utilizan el protocolo SSL/TLS, por lo cual sus comunicaciones ni siquiera están cifradas.  
A su vez, al día de hoy, los ICS conectados a Internet no están controlados por un área que conozca sobre seguridad de la información, y mayormente no están documentados o ni siquiera son conocidos por ellos.  Además esos ICS conectados a Internet corren sobre versiones de sistemas operativos desactualizados tanto en versión (mayormente Windows XP) como en parches de seguridad, y hasta incluso la versión del software del propio ICS no esta actualizada y/o no esta incluía dentro de un ciclo de actualización de seguridad periódica.   Pero aún, muchos de los ICS se encuentran hoy con usuarios y claves por defecto o triviales. 

Entonces, ¿estamos realmente convencidos que debemos correr por la vulnerabilidad de HeartBleed?

Se me ocurre que ante este estado de situación, el sector industrial debe primero pulir otras cuestiones más importantes que están relacionadas con la identificación de todos los sistemas, la ejecución de un análisis de riesgo, la estandarización de los sistemas, y la evaluación periódica de su seguridad.  Resolviendo esto, también resolverán situaciones como la de HeartBleed sin esfuerzos extras, sino dentro de un proceso natural de revisión y actualización.    ¿Cuál es el sentido de cerrar con llave las puertas de nuestro carro, si dejamos las ventanillas bajas? ¿Cuál es el sentido de mitigar una vulnerabilidad si no lo hago con otras que son mucho más graves y que podrían dar acceso a un atacante a nuestra infraestructura?

Para el caso de un banco, de las redes sociales más conocidas, de las VPN empresariales, etc. HeartBleed es realmente una debilidad  por la cual uno deba correr debido a que existe un trabajo previo de aseguramiento de fondo que se rompe con esta debilidad, sin embargo en las redes industriales, falta mucho más esfuerzo por trabajar para solucionar cuestiones de fondo.    Incluso no solamente en la propia gestión de la redes, sino también en los organismos oficiales, ya que mirando lo que sucedió con los CERT hispano-hablantes en cuanto a lo orientado a infraestructuras críticas, salvo excepciones, podemos darnos cuenta que la Ciberseguridad Industrial aún no es un tema de relevancia real.  Muchos de los CERT se focalizaron en lanzar alertas para que los bancos regularicen la situación, para que los usuarios finales estén atentos, pero muy pocas empresas con infraestructuras críticas recibieron notificaciones específicas para que actualicen sus sistemas. Algunas de ellas, recibieron las alertas normales, las mismas que recibe cualquier usuario suscripto a una lista de correo de un CERT.

Conclusión

Entonces, si administro una red industrial, ¿no debería preocuparme por esta debilidad?

Espero que esta idea no se les haya cruzado por la cabeza en ningún momento mientras leían este articulo, siempre que exista una debilidad debemos hacer algo para mitigarla en nuestros sistemas, es parte fundamental de nuestro trabajo.   Sin embargo, no hay que quedarse en resolver sólo las que salgan en los medios masivos, sino que debemos velar por cerrar todos nuestros agujeros de seguridad.    Nuestro trabajo es cerrar todas las puertas y ventanas para que un atacante no ingrese, además de atender el día a día de nuestro trabajo.  Como siempre decimos, el atacante tiene el tiempo necesario, la paciencia y la determinación para buscar hasta encontrar solo una puerta o ventana abierta, mientras que nosotros debemos cerrar todas, y él, con esa sola, nos deja fuera de juego.

Hoy debemos estar más atentos que nunca.  Si con el correr del tiempo, seguimos encontrando con simples búsquedas en Shodan cientos de sistemas industriales con claves por default, con direccionamiento por DHCP o con software muy desactualizado, es que estamos fallando con algo.   En el Centro trabajamos a diario para minimizar esta brecha.


Claudio B. Caracciolo
CSA en 11Paths
Coordinador del CCI en Argentina
(@holesec)

No hay comentarios :

Publicar un comentario en la entrada