[16/12/2021] Se ha descubierto una segunda vulnerabilidad que afecta a Apache Log4j, mientras la industria de la seguridad se esfuerza por mitigar y solucionar una grave falla de día cero en el registro de la biblioteca Java (CVE-2021-44228), denominado Log4Shell. La nueva vulnerabilidad, CVE 2021-45046, podría permitir a los atacantes elaborar datos de entrada maliciosos utilizando un patrón de búsqueda JNDI, lo que daría lugar a un ataque de denegación de servicio (DoS), según la descripción de la CVE.
Ya se ha publicado un parche para el nuevo exploit, que elimina la compatibilidad con los patrones de búsqueda de mensajes y desactiva la funcionalidad de JNDI por defecto, con la corrección de Log4j 2.15.0 para la falla original "incompleta en ciertas configuraciones no predeterminadas".
La vulnerabilidad de Log4j sigue amenazando a las organizaciones
El descubrimiento de esta segunda vulnerabilidad es indicativo de los continuos riesgos de seguridad que plantea el problema de Log4j, calificado con un 10 sobre 10 en la escala de calificación de vulnerabilidades del CVSS. Los datos de todo el sector han revelado un gran número de actores de amenazas que explotan Log4Shell para atacar a las empresas, y las advertencias sobre la inminente llegada de un gusano autopropagable también causan preocupación pública.
"La primera vulnerabilidad creaba un riesgo de ejecución remota de código y, dado que Log4J se utiliza de forma tan generalizada, afectaba a muchos tipos diferentes de software", explica Matthew Gracey McMinn, jefe de investigación de amenazas de Cetacea. "Como tal, arreglar esto era una prioridad. Sin embargo, parece que el primer parche, aunque evita la ejecución remota de código, puede no tener éxito al 100%, si se tiene una configuración muy personalizada". El peligro de esta nueva y segunda vulnerabilidad es la amenaza de ataques DoS, añade.
Los ciberdelincuentes pueden explotar esta vulnerabilidad muy fácilmente y hacer caer los servidores y aplicaciones contra los que puedan ejecutar el exploit. "Un mensaje especialmente diseñado enviado a un servidor vulnerable es todo lo que se necesita para comprometerlo y explotar esta vulnerabilidad", anota Gracey McMinn.
Priorizar la aplicación de parches y la defensa en profundidad para mitigar el riesgo
Gracey McMinn insta a las organizaciones a instalar el nuevo parche tan pronto como puedan, sin desactivar los servicios críticos de la empresa. "En términos más generales, las empresas deben considerar la necesidad de habilitar cosas como JNDI para servidores específicos. Log4j es necesario para muchas aplicaciones, pero JNDI no es una característica necesaria para muchas empresas", afirma.
En los casos en los que no es posible actualizar o deshabilitar, un modelo de defensa en profundidad puede resultar útil, continúa Gracey McMinn. "Ningún fragmento de código debería suponer una falla crítica para una empresa, y un atacante que consiga explotar Log4j no debería tener acceso y control ilimitados de toda la red. Deben existir capas de defensa posteriores para evitar el ataque en etapas posteriores. De este modo, se puede minimizar el impacto de cualquier ataque".
Basado en el artículo de Michael Hill (CSO) y editado por CIO Perú