¿Sigue rondando por sus servidores el error Ghost?

Las vulnerabilidades olvidadas pueden volver a atormentarle. Es demasiado fácil dar por sentado que se han aplicado parches o actualizaciones lo suficientemente a fondo como para que una vulnerabilidad peligrosa y ampliamente difundida deje de serlo.

Pero, en realidad, su equipo de seguridad puede haber pasado por alto un parche crítico, o puede haber adquirido sin saberlo una carga de trabajo sin parchear. Por ejemplo, por la compra de soluciones tecnológicas adicionales o porque su organización adquirió o se fusionó con otra.

Por eso merece la pena volver a comprobar que sus cargas de trabajo están parcheadas a fondo contra las vulnerabilidades más críticas. Una de ellas es el error Ghost, una vulnerabilidad que afecta a la versión 2.2 de GNU C Library. GNU C Library es una biblioteca de código abierto que alimenta innumerables aplicaciones y servicios.

Ghost no es un fallo con el que se pueda correr el riesgo de ser descuidado: Ghost recibió la máxima puntuación CVSS de 10, lo que indica que es extremadamente crítico.

En este artículo, explicamos cómo funciona la vulnerabilidad Ghost, explicamos por qué Ghost todavía puede suponer un peligro para sus operaciones y explicamos qué puede hacer para comprobar si tiene alguna biblioteca GNU C sin parchear en sus sistemas.

Contenido:

1. ¿Qué es el fallo Ghost, también conocido como la vulnerabilidad glibc?
2. Cómo parchear tus servidores contra CVE-2015-0235
3. Comprueba si eres vulnerable a Ghost con uChecker
4. Parchear regularmente es clave - para Ghost, y para futuras vulnerabilidades.

¿Qué es el fallo Ghost, también conocido como la vulnerabilidad glibc?

Esta vulnerabilidad de glibc fue descubierta por investigadores del proveedor de seguridad Qualys en enero de 2015 y en ese momento se le asignó CVE-2015-0235.

Qualys encontró que la función __nss_hostname_digits_dots() de la GNU C Library tenía una vulnerabilidad de desbordamiento de búfer que puede ser activada no sólo por usuarios locales, sino también por usuarios remotos. Los atacantes remotos son capaces de utilizar este defecto de desbordamiento de búfer para ejecutar código arbitrario en su servidor utilizando los permisos del usuario que ejecuta la aplicación que está desplegando glibc.

Los investigadores publicaron un análisis de ejemplo que muestra cómo se puede vulnerar un sistema utilizando la aplicación de correo Exim como ejemplo, pero cualquier aplicación de Linux que utilice la función gethostbyname() o gethostbyname2() es vulnerable, ya que estas proporcionan rutas para explotar la vulnerabilidad __nss_hostname_digits_dots().

Con esta vulnerabilidad, un atacante remoto puede hacerse con el control total de tu sistema sin que ni siquiera te enteres. También vale la pena señalar que Ghost es un exploit fácil de implementar. En otras palabras, los atacantes pueden explotar un sistema vulnerable con relativamente poco esfuerzo, que es una de las razones por las que Ghost obtuvo una puntuación tan alta en el índice CVSS, con el máximo de diez, lo que significa que es una vulnerabilidad crítica.

También está muy extendida, ya que la mayoría de los sistemas Linux están afectados por la vulnerabilidad. Puede encontrar una lista de los productos afectados aquí.

Cómo parchear sus servidores contra CVE-2015-0235

Un punto interesante a tener en cuenta es que Ghost se incluyó en glibc-2.2, que se publicó en 2000. En una versión posterior, glibc-2.18, se corrigió la vulnerabilidad como parte de una actualización de la biblioteca GNU C.

Sin embargo, esta corrección se debió a una actualización rutinaria de las bibliotecas y, por tanto, no se "marcó" como una versión de seguridad. Por ese motivo, los proveedores no publicaron automáticamente una actualización para glibc-2.2 hasta que se descubrió la vulnerabilidad más adelante.

Aunque es posible que entretanto haya actualizado su software y, en consecuencia, se haya actualizado a una versión nueva y no afectada de la Biblioteca C de GNU, también puede darse el caso de que siga confiando en la versión 2.2.

Cualquier sistema que aún dependa de la versión vulnerable de la librería necesita ser parcheado. Dada la gravedad de la vulnerabilidad, los principales proveedores han publicado parches, y solucionar la vulnerabilidad es tan sencillo como parchear la distribución de Linux que se esté utilizando.

También puede actualizar manualmente la biblioteca glibc utilizando la línea de comandos en su sistema operativo - las últimas bibliotecas están aquí, pero por supuesto, recuerde siempre reiniciar su servidor después de haber instalado la actualización.

Por supuesto, si actualmente utiliza KernelCare Enterprise de TuxCare y despliega su complemento LibraryCare, no tiene nada de qué preocuparse. El error Ghost y muchas otras vulnerabilidades ya están parcheadas en sus sistemas.

Sin embargo, si descubre que uno más de sus sistemas necesita un parche, puede registrarlo fácilmente en el ePortal de TuxCare para que lo parchee, y puede estar seguro de que se parcheará en la memoria sin necesidad de reiniciar.

Comprueba si eres vulnerable a Ghost con UChecker

Cuando una vulnerabilidad es tan peligrosa como Ghost, merece la pena volver a comprobar que la carga de trabajo está completamente parcheada contra esa vulnerabilidad, incluso si se trata de una vulnerabilidad de hace unos años.

Aunque un equipo de seguridad cualificado siempre parcheará las vulnerabilidades peligrosas con prontitud, el error humano puede colarse, y a veces las cargas de trabajo sin parchear pueden colarse debido a adquisiciones corporativas o porque usted introdujo una nueva solución tecnológica que resulta que contiene una biblioteca sin parchear.

Afortunadamente, existe una forma sencilla de comprobar si necesita parches para proteger sus servidores contra Ghost.

En TuxCare hemos desarrollado una herramienta de uso gratuito bajo licencia GNU GPL 2. Se llama uChecker y analiza automáticamente tu sistema en busca de bibliotecas sin parches, incluida glibc. La instalación de uChecker es sencilla. Sólo tienes que ejecutar este comando:

curl -s -L https://kernelcare.com/uchecker | python

Cuando ejecute uChecker obtendrá un informe completo de todas las bibliotecas que requieren parches. Esto incluye las bibliotecas almacenadas en disco, así como las bibliotecas actualmente cargadas en memoria.

Como cuestión de seguridad, deberías comprobar a fondo el código que descargas de Internet antes de ejecutarlo en tus sistemas. El comando anterior puede, y debe, dividirse en dos: uno para descargar el código que desea comprobar y otro para ejecutarlo. Lo anterior es sólo una forma conveniente de ejecutar uChecker, no la mejor práctica de seguridad.

Los parches periódicos son fundamentales, tanto para Ghost como para futuras vulnerabilidades.

El bug Ghost sigue ahí fuera y existe la posibilidad de que esté rondando sus sistemas y creando una puerta trasera para los atacantes. Si utiliza un servicio de parcheo de bibliotecas automatizado y sin reinicios, no tendrá nada de qué preocuparse, ya que sus bibliotecas GNU C estarán totalmente actualizadas.

¿No está seguro de haber aplicado todos los parches que debería? Prueba uChecker: es gratuito y te avisará rápidamente si sigues siendo vulnerable al peligroso error Ghost.

La conclusión es que la aplicación periódica de parches mantendrá sus sistemas seguros año tras año, incluso frente a las vulnerabilidades más peligrosas. Siempre se publican nuevas CVE, por lo que es crucial estar atento a ellas y comprobar si sus sistemas están en peligro.

Sólo glibc, por ejemplo, registró cinco vulnerabilidades hasta mediados de julio de 2021, cuando se escribió este artículo. Eso es una nueva vulnerabilidad cada mes, solo en glibc.

Por supuesto, Ghost ha sido y sigue siendo (para aquellos que aún no han parcheado) una de las vulnerabilidades de biblioteca más peligrosas. Pero, ¿quién dice que no habrá otra vulnerabilidad tan peligrosa como la antigua "Ghost"?

¿Cuál crees que sería una buena forma de gestionar una nueva y peligrosa vulnerabilidad? ¿Crees que tu equipo está preparado para un reto tan grande como CVE-2015-0235? ¿Seréis tú y tu equipo capaces de descubrir sistemas vulnerables y parchearlos inmediatamente si ocurre lo peor?

Estos son algunos puntos en los que debería pensar, porque de lo que podemos estar seguros es de que el descubrimiento de otra vulnerabilidad peligrosa está a la vuelta de la esquina.