#51 Quiza cuando haya pasado un tiempo prepare un articulo explicando todos los detalles de esta vulnerabilidad
#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
#48 Gracias por la explicación. Ya veo que en este caso se esta utilizando LDAP y para eso se necesita un servidor en remoto. Veo que hay otros como HTTP, RMI, DNS y BeanFactory, me intriga saber hasta que punto se podria explotar JNDI XBean pero no soy desarrollador y es mas bien curiosidad, asi que me esperare a ver como se va la cosa.
#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 $.
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 que cuando le preguntas por 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:/// y descargar el exploit.
#48 Gracias por la explicación. Ya veo que en este caso se esta utilizando LDAP y para eso se necesita un servidor en remoto. Veo que hay otros como HTTP, RMI, DNS y BeanFactory, me intriga saber hasta que punto se podria explotar JNDI XBean pero no soy desarrollador y es mas bien curiosidad, asi que me esperare a ver como se va la cosa.
#42 sacado de tu enlace:
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.
#32 puedo confirmar que esta mitigación, aunque pueda sonar un poco salvaje, es válida. Eso si, requiere reiniciar el servicio
#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
#40 Claro. https://unit42.paloaltonetworks.com/apache-log4j-vulnerability-cve-2021-44228/
Aqui muestran en el ejemplo, alguna peticion del escaneo masivo. Estas peticiones llevan un User-Agent modificado en el que esta embebido un comando (curl,wget,bash).
Lo que yo entiendo es que esa peticion podria llevar cualquier otro User-Agent con el comando que el atacante quisiera, como el del ejemplo que puse al principio. Se podria pasar una payload a base de peticiones HTTP sin tener que conectarse a un servidor remoto para descargar (a diferencia del ejemplo de Palo Alto).
#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 $.
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 que cuando le preguntas por 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:/// y descargar el exploit.
#48 Gracias por la explicación. Ya veo que en este caso se esta utilizando LDAP y para eso se necesita un servidor en remoto. Veo que hay otros como HTTP, RMI, DNS y BeanFactory, me intriga saber hasta que punto se podria explotar JNDI XBean pero no soy desarrollador y es mas bien curiosidad, asi que me esperare a ver como se va la cosa.
#24 para invocar otros comandos este ataque primero tiene que hacer que la máquina atacada se conecte a un servidor remoto
#40 Claro. https://unit42.paloaltonetworks.com/apache-log4j-vulnerability-cve-2021-44228/
Aqui muestran en el ejemplo, alguna peticion del escaneo masivo. Estas peticiones llevan un User-Agent modificado en el que esta embebido un comando (curl,wget,bash).
Lo que yo entiendo es que esa peticion podria llevar cualquier otro User-Agent con el comando que el atacante quisiera, como el del ejemplo que puse al principio. Se podria pasar una payload a base de peticiones HTTP sin tener que conectarse a un servidor remoto para descargar (a diferencia del ejemplo de Palo Alto).
#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 $.
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 que cuando le preguntas por 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:/// y descargar el exploit.
#48 Gracias por la explicación. Ya veo que en este caso se esta utilizando LDAP y para eso se necesita un servidor en remoto. Veo que hay otros como HTTP, RMI, DNS y BeanFactory, me intriga saber hasta que punto se podria explotar JNDI XBean pero no soy desarrollador y es mas bien curiosidad, asi que me esperare a ver como se va la cosa.
#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
#31 gracias
#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
#24 eso o deshabilitar la la ejecución desde jdni con la variable "log4j2.formatMsgNoLookups=true"
O desactivar jdni directamente
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:
https://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:
https://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+
#54 Que la movida es que te pueden mandar una peticion en la que figure ese texto asi formado, no?
"$"
Para que el jodio log4j se lo coma 
Ejemplo:
POST http://mipagina.com/user
#46 Hola,
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
#25 Correcto. Esta vulnerabilidad debe seguir considerandose critica y requiere una actualizacion de Log4j2.
Para aquellos que utilizaron el hotpatch de AWS Corretto, confirmamos que el parche evita los problemas de RCE y DOS mencionados en el nuevo CVE.
La utilidad:
https://github.com/corretto/hotpatch-for-apache-log4j2