Este post ha sido leído 2106 veces!

Nos hacemos eco de una noticia muy importante ocurrida esta semana. Se ha descubierto una vulnerabilidad grave en el servicio openssl. Hay multitud de servicios que utilizan openssl para la seguridad y encriptación de la información que se transporta por internet.

Para hacernos una idea, se calcula que el 60%, si no más, de los servidores web, son Nginx y Apache, y tenemos que estos dos servidores se ayudan de OpenSSL para asegurar nuestra información.

Hablamos de bancos, yahoo, google, y muchos más sitios que se han visto comprometidos, y que probablemente, han expuesto información considerada segura, como puedan ser usuarios y contraseñas, certificados privados (que pueden permitir suplantar la identidad del servidor para ‘robarnos’ las claves, . . .)


Lo curioso, es que esta vulnerabilidad está entre nosotros desde el año 2011, pero ha sido ahora, el 7 de abril de 2014, cuando se ha echo pública, y todo el mundo ha ido a proteger sus sistemas.

Hoy en el telediario de las 15, daban la noticia por encima, pero realmente ha sido grave.

¿Por qué está entre nosotros esa vulnerabilidad desde hace tanto tiempo, y ha sido descubierta ahora?

No se, le preguntaremos a la N S A y derivados… que no, no seamos paranói… digo realistas.

Bueno el caso es que podemos protegernos si instalamos las versiones de libssl >= libssl1.0.1g o bien instalamos las versiones parcheadas de las actualmente instaladas.

Resumen:

  • El bug es: cualquier usuario, sin necesidad de autenticarse puede conectarse al servidor y obtener los primeros 64KB de memoria, que contienen o pueden contener la clave privada, contraseñas, usuarios, …
  • Infectados servicios tan importantes como Yahoo (ya arreglado) e incluso google en los días anteriores, además de otros.
  • Se descubre el 7 de abril de 2014, pero lleva con nosotros desde el 2011
  • Pocas huellas en los logs (por no decir nada), aunque parece que hay plugin para snort que lo detecta
  • Si instalas versión >= libssl1.0.1g te proteges, aunque ubuntu12,04, ha día de hoy, parchea su paquete con versión 1.0.1e,
    Corregido en Debian 7, paquete 1.0.1e-2+deb7u6
    En ubuntu a partir de la libssl1.0.1g
    Utiliza openssl version -a   y revisa el built on, ya que si la fecha es posterior al 7 de abril, estará parcheada (solucionado bug)
  • Si no puedes hacer un update puedes recompilar sin un flag
  • Web para comprobar si eres vulnerable (no respondo de la misma, si se guarda tus claves, o . . .):    http://filippo.io/Heartbleed
  • Web dedicada a la vulnerabilidad con info:  http://heartbleed.com    (referencias al final de esa web)
  • Se recomienda renovar los certificados una vez parcheado el openssl, y una cosa tan tonta como reiniciar los servicios implicados o incluso el sistema si es posible.

Para solucionarlo y/o ver la versión instalada (Debian/Ubuntu):

  • Comprobamos versión instalada de OpenSSL

  • Actualizamos repos

  • Aquí un detalle, con el atributo -a  veremos un dato importante, el build on
  • Si es superior o igual a 7 de abril de 2014 estaremos cubiertos (ahora si, prueba en la web comentada anteriormente)
  • Actualizamos la librería

Ahora el ejemplo completo con uno de nuestros servidores:

Fijaros como cambia la fecha de creación del paquete libssl, de manera que no hemos cambiado de versión, pero tenemos la misma ya con el problema corregido  (me temo que para versiones anteriores no tenemos parche)

Algunos links de referencia, los podéis encontrar al pie de la web que lleva el bug:  http://heartbleed.com



 

Bueno, ya estáis avisados, siempre pensamos que internet es inseguro, pero ante vulnerabilidades como esta, tan extendidas, es cuando los que trabajamos en esto nos llevamos las manos a la cabeza, imaginaros lo que no conocemos.

Esto afecta también a nuestros queridos openerp, si los servimos con https, así que a parchear.

Espero sea de utilidad.

TwitterMore...