Log4Shell se trata de una vulnerabilidad que afecta a la popular librería de registro de Java Log4j, desarrollada por Apache. Es muy utilizada en todo tipo de servicios y software. Por ejemplo en juegos como Minecraft, además de servicios en la nube. Sirve para que las aplicaciones almacenen un registro o log durante su funcionamiento. Podéis visitar nuestro tutorial sobre qué es el archivo htaccess en Apache.
Podemos decir que este problema afecta a millones de servidores en todo el mundo. Todos ellos son vulnerables y pueden sufrir ataques remotos. Al aprovechar el fallo Log4Shell, un atacante podría colar malware y tomar el control total de ese servidor. Básicamente tendría vía libre para hacer lo que quisiera.
Log4j es una librería de registro de logs basada en Java que es ampliamente utilizada por muchos productos, servicios y componentes de Java. No es de extrañar que el fallo, que obtuvo un puntaje 10 sobre 10 en la escala de severidad CVSS y que pone en riesgo a innumerables servidores de que cibercriminales tomen control total de los mismos, haya tenido mucha repercusión más allá de la industria de la seguridad.
De hecho, con la publicación del código del exploit como prueba de concepto que ya está disponible online, ahora somos testigos de una carrera masiva entre actores maliciosos que están escaneando Internet y explotando sistemas vulnerables, y aquellos que se dedican a la defensa, que están actualizando los sistemas e implementando las mitigaciones correspondientes, así como los desarrolladores, que están auditando aplicaciones y librerías de código para cualquier dependencia que pueda incluir versiones vulnerables de la librería log4j.
Se calcula que Java está presente en unos 3.000 millones de dispositivos en todo el mundo. La gran mayoría de programadores utilizan Log4j, por lo que son muchos los que pueden ser vulnerables a este problema. ¿Es posible saber si un sistema es vulnerable a Log4Shell? Hay varias formas de hacerlo y una de las más sencillas es conocer la versión de Log4j que tiene instalada. Las vulnerables van desde la 2.0-beta9 hasta la 2.14.1.
Podemos decir que la forma más sencilla de detectar si un punto final remoto es vulnerable es activar una consulta de DNS. Lo que hace el exploit es que el hipotético servidor vulnerable intente obtener código remoto. Si usamos la dirección de una herramienta gratuita de registro de DNS en la cadena de explotación, podremos detectar cuándo se activa la vulnerabilidad.
