Log4j 2.17.1 ahora disponible, corrige el nuevo error de ejecución de código remoto

Apache ha lanzado otra versión de Log4j, 2.17.1, que aborda una vulnerabilidad de ejecución remota de código (RCE) descubierta recientemente en 2.17.0, rastreada como CVE-2021-44832.

Antes de hoy, 2.17.0 era la versión más reciente de Log4j y se consideraba la versión más segura para actualizar, pero ahora la placa ha evolucionado.

Quinto Log4j CVE en menos de un mes

La explotación masiva de la vulnerabilidad Log4Shell original (CVE-2021-44228) por parte de los actores de amenazas comenzó alrededor del 9 de diciembre, cuando surgió un exploit de PoC en GitHub.

Dado el uso extensivo de Log4j en la mayoría de las aplicaciones Java, Log4Shell se convirtió rápidamente en una pesadilla para empresas y gobiernos de todo el mundo.

Si bien el riesgo crítico representado por el exploit Log4Shell original es fundamental, han surgido variantes más leves de la vulnerabilidad en las versiones de Log4j, incluidas 2.15 y 2.16, que anteriormente se creía que estaban completamente parcheadas.

BleepingComputer informó anteriormente sobre cuatro CVE diferentes que afectan a Log4j y uno descubierto en el marco de 'logback'. Después del descubrimiento de una falla DoS en la versión 2.16, la placa se movió rápidamente hacia la actualización a la versión 2.17.0, considerada la más segura de todas.

Pero ahora una quinta vulnerabilidad: se descubrió una falla de RCE, rastreada como CVE-2021-44832 en 2.17.0, con un parche aplicado a la última versión 2.17.1 que está disponible.

Calificada como "Moderada" en severidad y calificada con 6.6 en la escala CVSS, la vulnerabilidad proviene de la falta de controles de acceso JDNI adicionales en log4j.

"JDBC Appender debería utilizar JndiManager al acceder a JNDI. El acceso a JNDI debería controlarse a través de una propiedad del sistema", afirma la descripción del problema vista por BleepingComputer.

"En relación con CVE-2021-44832, donde un atacante con permiso para modificar el archivo de configuración de registro puede crear una configuración maliciosa utilizando un Appender JDBC con una fuente de datos que hace referencia a un URI JNDI que puede ejecutar código de forma remota".

El investigador de seguridad Checkmarx Yaniv Nizry se atribuyó el mérito de informar la vulnerabilidad a Apache:

Estén atentos a una publicación de blog;) pic.twitter.com/D56WpVsuF3

- Yaniv Nizry (@YNizry) 28 de diciembre de 2021

El tweet de Nizry explotó rápidamente en tráfico, atrayendo comentarios y memes por expertos en seguridad y "víctimas" del constante cansancio de los parches log4j.

"Espero que sea una broma, realmente espero Pensive face # log4j", tuiteó un usuario en respuesta.

"Hemos pasado MUCHO del punto en el que lo único responsable por hacer es colocar un letrero de neón intermitente gigante que diga 'LOG4J NO SE PUEDE RESOLVER, NO LO USE EN ABSOLUTO'". burlado otro.

Experto en seguridad Kevin Beaumont etiquetado la instancia otra "revelación fallida de Log4j sobre la marcha" durante las vacaciones.

¿Revelado demasiado pronto?

En el momento del tweet de Nizry, BleepingComputer no vio una advertencia o recordatorio oficial que indicara la presencia de un error de RCE en log4j 2.17.

El tweet en sí no contenía detalles sobre la vulnerabilidad o cómo podría explotarse, pero, en cuestión de minutos, llevó a un grupo de profesionales de seguridad y usuarios de la red a comenzar a investigar el reclamo.

La divulgación prematura de vulnerabilidades de seguridad puede llevar a los actores de amenazas a realizar actividades de exploración y explotación maliciosas, como se evidencia en la filtración del exploit Log4Shell del 9 de diciembre.

Marc Rogers, vicepresidente de ciberseguridad de Okta, reveló por primera vez el identificador de vulnerabilidad (CVE-2021-44832) y que la explotación del error depende de una configuración de log4j no predeterminada donde la configuración se carga desde un servidor remoto:

Parece que log4j CVE-2021-44832 tiene condiciones previas no predeterminadas: "Está cargando la configuración desde un servidor remoto y / o alguien puede secuestrar / modificar su archivo de configuración log4j
Está utilizando el appender de registro JDBC con una dirección URL dinámica ".

- Marc Rogers (@marcwrogers) 28 de diciembre de 2021

Hasta ahora, las vulnerabilidades log4j han sido explotadas por todo tipo de actores de amenazas, desde piratas informáticos respaldados por el estado hasta bandas de ransomware y otros para inyectar mineros de Monero en sistemas vulnerables.

Se ha detectado a la banda de ransomware Conti observando servidores VMWare vCenter vulnerables. Mientras que los atacantes que piratearon la plataforma de cifrado vietnamita ONUS a través de log4shell exigieron un rescate de $ 5 millones.

Los usuarios de Log4j deben actualizar inmediatamente a la última versión 2.17.1 (para Java 8). También se espera que las versiones de backport 2.12.4 (Java 7) y 2.3.2 (Java 6) que contienen la corrección se publiquen pronto.

BleepingComputer se ha puesto en contacto con Checkmarx para hacer comentarios antes de escribir y estamos esperando su respuesta.