ClickCease Proteger los servidores de HeartBleed. Sí, HeartBleed. - TuxCare

Únase a nuestro popular boletín

Únase a más de 4.500 profesionales de Linux y el código abierto.

2 veces al mes. Sin spam.

Proteger los servidores de HeartBleed. Sí, HeartBleed.

3 de noviembre de 2020 - Equipo de RRPP de TuxCare

Proteger los servidores de HeartBleedHeartBleed... parece una canción de amor de los años setenta. Pero no lo es. HeartBleed es una vulnerabilidad seria (CVE-2014-0160) que afecta a la biblioteca compartida OpenSSL. Existe desde 2014, pero a diferencia de los oldies que escuchas de vez en cuando en la radio, esta ciberdebilidad está muy presente hoy en día. NTT Informe mundial de inteligencia sobre amenazas 2020 revela que HeartBleed contribuye a que OpenSSL sea la segunda tecnología de software más atacada del mundo, con 19% de la actividad hostil a nivel mundial.

HeartBleed es un ataque que se aprovecha de un fallo de gestión de memoria en las versiones 1.0.1 a 1.0.1f de OpenSSL. Con HeartBleed, los atacantes son capaces de decodificar 64 kilobytes de datos cifrados durante cada uno de los "latidos" del software OpenSSL. Pueden aprovechar la "fuga" de datos para montar un ataque de intermediario o acceder a información confidencial como contraseñas e identificadores de usuario.

Contenido:

  1. La solución es parchear. El problema también es parchear
  2. Live Patching como forma de mitigar Heartbleed con reinicios
  3. Conclusión

 

La solución es parchear. El problema también son los parches

La solución es parchear. El problema también son los parches.

La mitigación de HeartBleed y amenazas comparables implica la aplicación de parches a las bibliotecas OpenSSL vulnerables, así como a las de la biblioteca GNU C (glibc). El proceso de actualización de las bibliotecas puede adoptar la forma del marco MITRE Adversarial Tactics, Techniques and Common Knowledge (ATT&CK). ATT&CK recomienda que las organizaciones "escaneen regularmente los sistemas de cara al exterior en busca de vulnerabilidades y establezcan procedimientos para parchear rápidamente los sistemas cuando se descubran vulnerabilidades críticas a través del escaneo y de la divulgación pública".

Después, una vez identificadas las vulnerabilidades críticas, los administradores de sistemas suelen programar un tiempo de inactividad para ejecutar el proceso de parcheado propiamente dicho. Esto siempre ha significado apagar la pila, parchear el sistema operativo y reiniciar la pila. También suele requerir tiempo y atención de muchas personas, como administradores de Linux, administradores de bases de datos (DBA), administradores de middleware y usuarios empresariales. Suponiendo que no haya problemas (no siempre es una suposición fiable), el administrador del sistema valida la pila actualizada y la vuelve a poner en producción.

En este proceso surgen varios problemas:

  • Incertidumbre sobre qué bibliotecas necesitan actualizaciones: los administradores de sistemasno suelen tener una idea clara de cuáles de sus bibliotecas necesitan parches. Como resultado, suelen reiniciar todo el sistema.
    Los ciclos de reinicio provocan degradaciones y/o interrupciones del servicio. Después de reiniciar, el rendimiento del servidor puede tardar un tiempo en estabilizarse. A veces, los servidores no vuelven a funcionar correctamente después de un reinicio. 
  • Ventanas de vulnerabilidad-Debido a la mano de obra necesaria para un reinicio, junto con la interrupción potencial, las empresas suelen programar los reinicios para tiempos de inactividad preestablecidos, como los fines de semana. Este retraso deja sus servidores expuestos a los ataques. Incluso si un administrador de sistemas reinicia cada 30 días para cumplir las normas de seguridad, los servidores pueden ser vulnerables durante dos semanas o más.
  • Parcheado incompleto: cuandolos servidores se parchean manualmente, sin reiniciar, las bibliotecas compartidas pueden seguir conteniendo vulnerabilidades. Por ejemplo, cuando las bibliotecas se actualizan en disco, los archivos antiguos sin parchear pueden persistir en la memoria de un servidor. Además, los analizadores de vulnerabilidades no detectan estos archivos de bibliotecas antiguos sin parches en la memoria. 

 

Uso de UChecker para mitigar HeartBleed y otras vulnerabilidades de bibliotecas compartidas

Uso de UChecker para mitigar HeartBleed y otras vulnerabilidades de bibliotecas compartidas

Cuando los servidores se parchean manualmente, sin reiniciar, las bibliotecas compartidas pueden seguir conteniendo vulnerabilidades. Por ejemplo, cuando las bibliotecas se actualizan en disco, los archivos antiguos sin parchear pueden persistir en la memoria. Y, los escáneres de vulnerabilidades no detectan estos antiguos archivos de bibliotecas sin parchear que residen en la memoria. Ahora es posible identificar si el sistema sigue siendo susceptible a HeartBleed o vulnerabilidades similares analizando las bibliotecas en memoria con Uchecker de KernelCare

 Funciona así:

  • UChecker obtiene los últimos BuildIDs actuales de un recurso de nuestro sitio, por ejemplo https://patches04.kernelcare.com/userspace.json
  • Toma un proceso en ejecución iterando sobre /proc/
  • It then gets a linked shared library from /proc/<pid>/maps
  • En este punto, la herramienta comprueba si la biblioteca compartida ha sido sustituida o eliminada
  • Dependiendo del estado del proceso, la herramienta analiza el formato ejecutable y enlazable (ELF) desde el sistema de archivos o desde la memoria asignada.
  • La herramienta recoge BuildID de .note.gnu.build-id
  • A continuación, la herramienta repite este ciclo para escanear bibliotecas adicionales, según sea necesario.

Funcionamiento de UChecker

Figura 1: Funcionamiento de Uchecker

Visite la página página Github de Uchecker y vea la demostración de cómo funciona.

UChecker ayuda a buscar bibliotecas vulnerables de forma gratuita; sin embargo, para actualizarlas es necesario reiniciar el servidor. Si necesita buscar vulnerabilidades y actualizar bibliotecas sin reiniciar procesos ni reiniciar servidores, pruebe con KernelCare+que comprueba si algún proceso en ejecución está utilizando bibliotecas obsoletas en memoria y, a continuación, actualiza las bibliotecas compartidas vulnerables sin reiniciarlos.

 

Conclusión

Las bibliotecas compartidas siguen siendo una grave fuente de exposición a riesgos de seguridad para las empresas que utilizan software libre y de código abierto (FOSS). Uchecker y KernelCare Live Patching Technology permiten la actualización de las bibliotecas compartidas sin las interrupciones y riesgos extendidos de un reinicio del servidor. Juntos, Uchecker y KernelCare permiten aplicar parches a las bibliotecas compartidas de forma más rápida y eficaz. HeartBleed y otras vulnerabilidades similares ahora pueden abordarse de forma que no ralenticen a toda la organización. Más información en https://lp.kernelcare.com/kernelcare-early-access

¿Desea automatizar la aplicación de parches de vulnerabilidad sin reiniciar el núcleo, dejar el sistema fuera de servicio o programar ventanas de mantenimiento?

Más información sobre Live Patching con TuxCare

Conviértete en escritor invitado de TuxCare

Empezar

Correo

Únete a

4,500

Profesionales de Linux y código abierto

Suscríbase a
nuestro boletín