Si bien siempre están apareciendo nuevas vulnerabilidades y los distintos proveedores van sacando parches para solucionarlo, hay ocasiones que los nuevos huecos de seguridad causan problemas globales como es el caso de Log4Shell o también conocida como LogJam, que ha sido clasificada como Muy Crítica.
Dicha vulnerabilidad afecta al sistema de logueo de Apache Log4j, que esta basado en Java. Si no se parchea se permite la ejecución de código de manera remota en los dispositivos afectados. El problema se refiere a un caso de ejecución remota de código no autenticado (RCE) en cualquier aplicación que use esta utilidad de código abierto y afecte a las versiones no parcheadas, de Apache Log4j 2.0-beta9 hasta la 2.14.1. Así que las versiones de prácticamente los últimos ocho años son vulnerables.
Si bien la gran mayoría de servicios que utilizamos a diario prácticamente no utilizan Java para el logueo, hay muchos que todavía si, y se siguen utilizando. Se usa para acceder a Minecraft por ejemplo y unas cuantas empresas utilizan estos servicios de web apps y software de servidores como son Apple, Amazon, Cloudflare, Twitter y Steam entre otras.
La vulnerabilidad ha sido descubierta por el equipo de seguridad de Alibaba Cloud, y se la comunicaron a Apache el pasado 24 de noviembre. Dado esto, Apache comunicó el 10 de diciembre el lanzamiento del parche que soluciona la vulnerabilidad quedando resuelto en la versión 2.15.0.
Cabe aclarar que esto también afecta a algunas configuraciones de Apache Struts2, Apache Solr, Apache Druid, Apache Flink y otros.
Y un tema que se esta dando, es que empresas de ciberseguridad como BitDefender o Cisco Talos, han confirmado evidencias de escaneo masivo de aplicaciones afectadas en busca de servidores vulnerables y ataques registrados contra sus redes honeypot utilizando un exploit de prueba de concepto.
Desde la Fundación Apache se recomienda actualizar sistemas a la mayor brevedad con la nueva versión 2.15.0, que soluciona el fallo deshabilitando la capacidad de un atacante que en versiones anteriores podía controlar los mensajes de registro o parámetros del log ejecutando código arbitrario cargado desde servidores LDAP cuando se habilitaba la sustitución del mensaje de búsqueda. Este comportamiento es el que se ha desactivado de manera predeterminado.
