La vulnerabilidad Log4Shell es una vulnerabilidad catalogada como crítica (10) que afecta a la librería de Java Log4J en su versión 2 (luego explicaremos qué es), incluida en Apache, y que permite lo que se conoce como ejecución de código remoto. Al ser muy crítica, se recomienda aplicar el parche que la corrige cuanto antes para protegerse de la vulnerabilidad Log4Shell.
Artículo elaborado por José Arroyo Viana, administrador de sistemas, experto en ciberseguridad de Extra Software y autor de la serie de artículos sobre vulnerabilidades en páginas web.
CONTENIDOS
¿Qué es Log4J?
¿Dónde se encuentra Log4J dentro de nuestro entorno?
¿Qué es Log4Shell?
¿Cómo funciona la vulnerabilidad Log4Shell?
El peligro de la vulnerabilidad Log4Shell
¿Cómo protegerse contra la vulnerabilidad Log4Shell?
Conclusión
¿Qué es Log4J?
Log4J es un sistema de logs muy común utilizado por desarrolladores Web, aplicaciones basadas en Java y también por otros lenguajes de programación, que utilizan este componente para registrar/logar información sobre la aplicación.
¿Dónde se encuentra Log4J dentro de nuestro entorno?
Como veremos, no solo es usada en servidores, también se utiliza en aplicaciones e incluso en aplicaciones para móviles, así como en numerosos servicios en la nube. Por tanto, es una vulnerabilidad que afecta potencialmente a muchos usuarios.
Aunque tengamos los servidores debidamente parcheados, nadie nos puede asegurar que el día de mañana nos descarguemos un PDF y a través de este visor PDF nos puedan inyectar código. Si tenemos una aplicación que utiliza este mecanismo de registro de eventos, es vulnerable. Y puede ser una aplicación tan aparentemente inocente como un visor PDF.
Hay muchos productos y fabricantes afectados por esta vulnerabilidad, como puedes ver AQUÍ.
¿Qué es Log4Shell?
Es el nombre que se le ha dado a la vulnerabilidad que ha surgido a raíz de una publicación de lo que se conoce como un 0-day (zero day). Un 0-day es una vulnerabilidad que no es conocida y que no tiene parche que la solucione. La vulnerabilidad se ha publicado como prueba de concepto, es decir, que al publicarla se ha mostrado cómo funciona el exploit que se aprovecha de ella. Y esto se traduce a que desde el primer minuto cualquiera que haya visto la publicación puede explotarla. Por supuesto, incluyendo a los cibercriminales, que han empezado ya a buscar posibles objetivos o víctimas. (continúa más abajo)
¿Cómo funciona la vulnerabilidad Log4Shell?
Esta vulnerabilidad hace posible que cualquier atacante inserte texto en los mensajes de log que almacena el aplicativo. Hasta aquí no sería un problema, pero sucede que Log4J tiene unas funcionalidades que permiten ejecutar ciertas acciones como búsquedas o cambios. Por tanto, pasando las etiquetas correctas a ese log, el atacante podrá hacer que este componente interactúe.
¿Cómo? El servidor al cuál estamos atacando ejecuta el código llamando al Interfaz de Nombrado y Directorio de Java (JNDI -Java Naming and Directory Interface ), pasándole ciertas etiquetas. Mediante URLs especialmente diseñadas, conseguimos que el JNDI haga esas búsquedas a recursos de red como son LDAP, DNS o RMI (una interfaz remota de Java).
El peligro de la vulnerabilidad Log4Shell
Lo que esta vulnerabilidad produce es una validación incorrecta de llamadas, es decir, se confía en datos que no son confiables. Este componente Log4J está logando la información sin pasar por un saneamiento previo. Por tanto, el atacante puede modificar el mensaje que se va a almacenar en el log para confundir a Log4J y conseguir realizar ciertas acciones maliciosas.
Como indicábamos, hay funcionalidades de Log4J –como JNDI- que ayudan al programador a que los datos de esos Logs sean mucho más claros. Por ejemplo, al guardar en los logs acciones de los usuarios, en vez de almacenar su identificador (“El usuario 2547f52a44d52a ha iniciado sesión”), Log4J realiza una consulta LDAP con ese identificador al servidor y en lugar de indicar el usuario por su identificador lo almacena con su nombre. Por ejemplo, indicaría “El usuario José Arroyo ha iniciado sesión”.
Aquí, Log4J está haciendo una comprobación contra un LDAP local pero si en vez de hacerlo contra un LDAP local, el atacante indica un LDAP remoto y además le pasa al atacado una serie de comandos que tiene que ejecutar. Es entonces cuando se explota la vulnerabilidad y no se puede controlar si quién está iniciando la sesión es un atacante.
Cuando esta funcionalidad está habilitada, y por defecto lo está, permite ejecutar recursos externos. Y como Log4J no sanea las URLs pasadas en estas cadenas, permitirá que el atacante haga la consulta a servidores externos a la red local.
Esta vulnerabilidad ha sido catalogada como CVE-2021-44228.
¿Cómo protegerse contra la vulnerabilidad Log4Shell ?
NOTA: La protección contra esta vulnerabilidad se ha actualizado con fecha 11/01/2022
Es totalmente recomendable actualizar a la última versión de esta librería, que a la hora de escribir este artículo es la 2.17.1. Aparte de esta vulnerabilidad se han descubierto otras dos más que afectan también a Log4J versión 2.15.0. La segunda permite llevar a cabo ataques de denegación de servicio DDoS y la tercera permitiría exfiltrar datos sensibles de las víctimas.
A su vez también se ha encontrado una vulnerabilidad en la versión 2.16.0 que surgió como solución a la vulnerabilidad que se comenta en el artículo. La gravedad de esta vulnerabilidad está clasificada como alta (7.5) y permite realizar un ataque de denegación de servicio y el impacto es un bloqueo total de la aplicación.
Recientemente, Apache ha lanzado otra versión de Log4j, 2.17.1, que corrige una vulnerabilidad de ejecución remota de código (RCE) recién descubierta en 2.17.0, la vulnerabilidad ha sido etiquetada como CVE-2021-44832. Por lo tanto ahora lo más seguro es aplicar la versión más reciente 2.17.1, que ya está disponible.
Además, como ya hemos visto, se pueden utilizar aplicaciones aparentemente inocuas (como un visor PDF) para explotar esta vulnerabilidad
Por tanto, además de los servidores, tenemos que intentar tener actualizadas las aplicaciones que usemos en el equipo. Y, si es posible, localizar información sobre algún comunicado que el fabricante haya sacado indicando si ha detectado esa vulnerabilidad en su producto.
Conclusión
Como hemos visto, la vulnerabilidad Log4shell que afecta a Log4J es muy crítica y se recomienda aplicar el parche que la corrige cuanto antes. Además, se deberían tomar otras medidas como la comprobación de las aplicaciones que tenemos instaladas en nuestros dispositivos y, al menos, utilizar últimas versiones y estar pendiente de las publicaciones al respecto del fabricante.
