El Equipo de Respuesta a Incidentes del Centro Criptológico Nacional, CCN-CERT, informa sobre la publicación de actualizaciones de la vulnerabilidad que afecta a Apache Log4j 2. Como se alertó el pasado viernes, 10 de diciembre, se ha hecho pública una vulnerabilidad que afecta a la librería de registro de Java Apache Log4j 2, herramienta desarrollada por Apache Foundation que ayuda a los desarrolladores de software a escribir mensajes de registro.
![CCN-CERT AL 09/21 Vulnerabilidad en Apache Log4j 2 [Recomendaciones]](https://cdn.mnmstatic.net/cache/36/dd/media_thumb_2x-link-3595568.jpeg?1639471086)
Comentarios
Amazon ha implementado un hotpatch que permite parchear sin necesidad de actualizar ni reiniciar servicios:
https://github.com/corretto/hotpatch-for-apache-log4j2
#4 ¡Muy grande la aportación!
#4 ¿Sirve para todas las versiones de java, incluso JDK 1.7?
#14 a ver, si usas Java, pero por alguna razón no usas log4j da igual. Aquí el problema es usar log4j inferior a 2.15.0. Entonces esas opciones te debería valer.
#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
#16 #26 A eso me refería, si. Parece que este parche solo sirve para versiones superiores a JDK 1.8, nosotros tenemos JDK 1.7 en algunos servidores y log4j 1.15 no es compatible con JDK 1.7
#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
#16 Si usa java y no usa log4j su problema es mucho mayor que este problemilla de seguridad.
#47 como si no hubiera más opciones. Conozco unos cuantos casos con slf4j + logback que están bastante tranquilos.
#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
#14 JDK 8, 11 y 17. No dicen nada de JDK 1.7, habría que probarlo.
#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
Acordaos de Elasticsearch...
#5 Sobre todo esas versiones del año catapún que no actualiza nadie, "¿paque?", si esto lo tenemos en la red interna tras el firewall.
#9 O que no se actualizan porque negocio no quiere dedicar recursos o sacar personal de otros equipos para solucionar algo que "ya funciona correctamente" o que no da dinero, o ninguna ventaja sobre la competencia.
Eso es asi.
#10 La de veces que me dicen yo lo tengo todo actualizado y estoy migrando lo que no...
Luego, le suelto lo de vamos ha hacer inventario y
#18 Wazuh es tu amigo.
#3 No, se refiere a salida.. un servidor web normalmente no tiene por que tener salida sin filtrar a internet este exploit fuerza a que el servidor web se conecte a un host remoto y ejecute el programa allí alojado, si no hay salida a internet no podrá (y un servidor web solo necesita que el cliente llegue a el, no devolver la conexión)
#11 Esto... si tengo un ecommerce tengo q tener la entrada HTTP/HTTPS abierta a cualquiera que quiera comprarme (aunque siempre se puede limitar por país de origen o por reputación de IP para controlar un poco).
Pero mi servidor web no tiene porqué tener salida a Internet por si mismo, más que a aquello que necesite.
#3 Veo que #6 lo ha explicado mejor que yo
#24 Obviamente no hay solución mágica (o dejaríamos de cobrar a final de mes ) pero como 'la moda' es usar sistemas modulares donde una vez tomas control del servidor te descargas los módulos que necesites... con un buen control de tráfico saliente limitarías muchos ataques.
Aunque es más fácil decir que hacer
#35 si tienes toda la razón, pero de ahí a aconsejar que antes que filtrar en la entrada lo hagan en la salida.... Porque vamos que poner una web Shell es facilísimo y no hace falta que el servidor tenga conexión. Es más, al cargar en memoria la clase de Java puedes cargar en memoria la webshell y eso ya es más jodido de pillar.
Los C2 que hagan conexiones inversas muy bien, pero como no soluciones el problema poco vas a hacer
Y nada te lo curras un poco más (o menos) y haces una webshell a mano para saltarte las firmas del AV
#6 ¿como que un servidor web no necesita devolver la conexion?¿Como hace entonces para que la pagina llegue a tu navegador?
Se pueden cerrar los servicios y puertos no necesarios, poner un firewall que filtre el trafico entrante, un firewall a nivel de aplicacion que corte la conexion si la web intenta hacer cosas raras ... pero dejar un servidor web sin salida a internet no tiene sentido.
#36 Tu te conectas a un servidor web y le dices "GET" o "PUT" el servidor web no se conecta a tu equipo, la pagina "te la traes" tu (tu navegador)
#36 lo que se pide bloquear no es "devolver" la conexión. Lo que se pide es no poder iniciar una conexión desde el servidor hacia Internet.
Aplicar listas blancas en la salida de internet en caso de duda de estar usando la librería log4j
Creo que este consejo es el que te puede salvar de más 0-day.
"Da igual" si tu servidor es vulnerable, si no puede descargarse el código malicioso porque simplemente no puede conectarse al exterior.
Sea esta vulnerabilidad o cualquier otra q aparezca mañana
Obviamente... a actualizar lo antes posible, pero controlar el tráfico saliente de los servidores accesibles desde Internet debería estar en las prioridades de los administradores
#2 yo lo entiendo como el trafico entrante no el saliente (pero vamos que el concepto esta claro)
#2 eso eso, tu aplica listas a la salida, y deja la entrada libre.... Ya verás que risas!
#2 Esto es importante de aplicar, pero no todos los ataques se enfocan en descargar codigo desde un servidor remoto.
Este ataque podria invocar otros comandos para crear por ejemplo un binario o un script ejecutable. Por ejemplo, reemplazando una utilidad del sistema ya tendria permisos de ejecucion.
Ejemplo: "echo "xyz" > /usr/bin/nslookup", concatenando lineas hasta que el binario esta completado.
El binario podria tener como funcionalidad capturar credenciales a bases de datos, escaneo de puertos, coleccion de certificados privados etc.
Enviar trafico al exterior en ciertos escenarios es posible yendo encapsulado con DNS u otro trafico, o a traves de otro nodo. Pero siendo un servidor web, podrias recopilar los datos en un archivo o varios en el directorio web y despues descargarlos llamando la URL.
#24 para invocar otros comandos este ataque primero tiene que hacer que la máquina atacada se conecte a un servidor remoto
#34 No. Puedes ver el ejemplo en la web de Palo Alto, donde muestran la peticion al servidor, y el comando incluido en ella. En ese ejemplo enseñan concatenado "curl", "wget", "bash" pero podria haber sido cualquier otro.
#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 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.
#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.
#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.
#51 Quiza cuando haya pasado un tiempo prepare un articulo explicando todos los detalles de esta vulnerabilidad
#2 Hay otras mitigaciones y workarounds, las tiene esta noticia que acabo de publicar ya que esta no las contiene
Análisis de la vulnerabilidad de Log4j 2 - CVE-2021-44228 (ENG)
Análisis de la vulnerabilidad de Log4j 2 - CVE-202...
randori.comPaso a ennumerarlas de nuevo:
For those who cannot upgrade to 2.15.0:
-In releases >=2.10, this vulnerability can be mitigated by setting either the system property log4j2.formatMsgNoLookups or the environment variable LOG4J_FORMAT_MSG_NO_LOOKUPS to true.
-For releases from 2.0-beta9 to 2.10.0, the mitigation is to remove the JndiLookup class from the classpath: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class.
If patching is not possible, it is highly advised organizations apply the temporary mitigation below and monitor impacted applications closely for anomalous behavior.
To mitigate the vulnerability in place of updating Log4 2j, the following parameter should be set to true when starting the Java Virtual Machine:
log4j2.formatMsgNoLookups;
The presence of JAR files belonging to the log4j library can indicate an application is potentially susceptible to CVE-2021-44228. The specific files to search for should match the following following pattern:
log4j-core-*.jar;
Depending on the installation method, the location of the matching JAR file may also give indications as to which application is potentially vulnerable. For example, on Windows, if the file is located in C:Program FilesApplicationNamelog4j-core-version.jar it indicates ApplicationName should be investigated. On Linux, the lsof utility can show which processes currently have the JAR file in use and can be run via the following syntax:
lsof /path/to/log4j-core-version.jar;
Currently, detection guidance in the form of regular expression signatures in the public space appear to be overly broad and bypasses have surfaced to circumvent them.
La de servidores que van a caer con esta vulnerabilidad.....
#1 y los que ya habrían caído sin saberlo años antes...
#54 CloudFlare ya detectó ataques de la vulnerabilidad 9 días antes de hacerse pública.....
Fuente:
Aquí otra mitigación sencilla, básicamente cargarse la clase JndiLookup del jar https://github.com/zhangyoufu/log4j2-without-jndi/blob/master/README_en.md
#32 puedo confirmar que esta mitigación, aunque pueda sonar un poco salvaje, es válida. Eso si, requiere reiniciar el servicio
Es que Java no va a morir nunca... seguirá dando por saco eternamente.
#31 gracias
#27 pero la arranca Apache Tomcat, no? Pensaba que sería algo a modificar en algún fichero de configuración
#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
Asimismo, si por lo que sea no podéis parchear. Estas dos propiedades de Java os deberían salvar el culo:
-Dlog4j2.disable.jmx=true -Dlog4j2.formatMsgNoLookups=true
#8 si por lo que sea no podéis parchear: ir mirando qué problema político/humano hay detrás, puede que lo mejor sea no hacer nada. El responsable de que no se pueda parchear no tardará en caer, pero intenta que quede constancia de quién es el responsable de que no se pueda parchear.
#12 todo por correo/escrito. 2ª ley del DevOps
Y cuando el responsable de que no se pueda parchear es el CTO, poco puedes hacer.
#13 hasta que caiga media empresa, todos los equipos cifrados,... y se vea claramente que fue por no parchear está vulnerabilidad.
A lo mejor se encargan hasta de robarle las cuentas del banco o publicar su sueldo...
#8 #12 para casos como los que mencionáis es para lo que vale la utilidad de parcheo en caliente que se menciona más arriba
#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
#21 cierto, gracias por el aporte.
la solución en #8 es para versiones de log4j entre 2.10 y 2.14.
#8 dónde las configuras?
#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)