Aviso de seguridad: Una nueva vulnerabilidad zero-day en la biblioteca Java Log4j ya está siendo explotada (en)

Una vulnerabilidad zero-day recientemente descubierta en la biblioteca de registro de Java Apache Log4j, ampliamente utilizada, es fácil de explotar y permite a los atacantes obtener el control total de los servidores afectados. La vulnerabilidad, clasificada como CVE-2021-44228, es grave y permite la ejecución remota de código sin autenticación cuando el usuario que ejecuta la aplicación utiliza la biblioteca de registro de Java. El CERT de Nueva Zelanda advierte que ya está siendo explotada a lo bestia.

[#16 Desactivado]

Vaya huevos publicar una vulnerabilidad grave un viernes por la tarde. No tenían otro dia de la semana, no...

[#60 Razhan]

#16 Si, el jueves, se publico ayer. Algunos llevamos mas de 24 horas con esto

[#4 insulabarataria]

Bah, no creo que log4j se use mucho.

[#5 keiko_san]

#4 Yo soy mas de system.out

[#36 alpoza]

#5 este no falla

[#6 el-brujo]

#4 Los servicios en la nube como Steam, Apple iCloud y aplicaciones como Minecraft son vulnerables.

[#7 insulabarataria]

#6 estaba siendo irónico...

[#8 el-brujo]

#7 ah jaja perdón, pensaba que el comentario iba en serio.

$(jndi):ldap:// en todas partes
o
$(jndi):rdmi://

[#9 EmuAGR]

#4 Hay un montón de versiones de Minecraft vulnerables.

editado:

Ahora he visto que era irónico...

[#11 ronko]

#9 El launcher me manda este sitio para solucionarlo, la versión actual está parcheada ya: https://www.minecraft.net/es-es/article/important-message--security-vulnerability-java-edition?ref=launcher

[#24 EmuAGR]

#11 Bueno, de ahí a que todo esté parcheado...

[#26 todosube]

#4 Pues diría que es la librería para logging más utilizada en Java

[#57 EmuAGR]

#26 Anda que ejecutar código que le pasan por LDAP... Cuánta chorrada meten en ciertas librerías. Es como si alguna agencia de inteligencia hubiera tenido la idea de contribuir alguna estupidez.

[#29 omegapoint]

#4 yo mismo, no dire donde, pero... mierda!

[#37 snowdenknows]

#4 prácticamente todo lo que usa java, usa log4j, si no es la propia aplicación alguna librería que usan

[#3 el-brujo]

CVE-2021-44228, "es grave " --> es muy grave, Gravedad CVSS 10 sobre 10 . No hay nada más grave.
Mitigaciones:
https://www.lunasec.io/docs/blog/log4j-zero-day/
PoC:
https://github.com/tangxiaofeng7/apache-log4j-poc
Web oficial:
https://logging.apache.org/log4j/2.x/security.html

[#23 analphabet]

#14 en #3 tienes el poc

Y básicamente esta imagen lo resume todo

[#27 omegapoint]

#3 ohhhh mierda mierda mierda!!!!

[#42 raul_lapeira]

#3 hombre... Esta haciendo un jndi a traves de un logging... Wtf xxdd. Hay que mirar el codigo fuente de esto... Muy legendario.

Todo el tema de la inyeccion de clases en tiempo de ejecucion que suena muy hipster no deja de ser una gilipollez en sistemas corporativos tipicos.

Vivimos la era del fashion oriented programming y vaya si se nota.

[#43 raul_lapeira]

#42 Pero tios... tambien tienes que secuestrar un JNDI accesible para la JVM donde corra la app donde inyectas la cadena... esto no es tan noticiable ni de lejos, cosas peores tuvieron mucha menos prensa.

[#62 warheart]

#43 #42 no sé si habéis entendido bien la vulnerabilidad. El problema es que tú puedes tener un servicio REST expuesto (127.0.0.1/servicio/p) que recibe un parámetro p y hace un log.error("El parámetro " + p + " no es válido");

Si en ese parámetro alguien manda la cadena del exploit, explota la vulnerabilidad. En el primer enlace de #3 se ve perfectamente.

[#48 la_gusa]

#42 la inyección de clases en tiempo de ejecución es más viejo que el cagar y funciona de puta madre. Es lo que hizo Spring tan popular

[#64 mre13185]

#3 El caso es que Github hace unas semanas me saltó la alarma en una app, no sé si sería por esto. Como para estas cosas lo manejo con lombok y las llamadas a log las tengo centralizadas con una clase de utilidad no me costó mucho corregir la vulnerabilidad, sólo cambiar la anotación de@Log4j a@Slf4j en dicha clase.

[#69 Razhan]

#64 Slf4j es solo una api de logging, por debajo sigues necesitando tener una implementación. Si la implementación es log4j2, seguirías teniendo problemas

[#78 mre13185]

#69 No, ya la probé en su día y era muy engorroso, así que uso la que viene por defecto, logback.

[#1 tiopio]

Para más info: https://www.randori.com/blog/cve-2021-44228/

[#31 Mschumacher]

#28 pero que servidores? Es una librería de Java

[#33 Mutiko30]

#31 no tengo ni idea.. he leído algo de apache y he asumido que era un tema de servidores

[#63 inovercy]

#33 Es una biblioteca que provee de facilidades al programador para escribir logs de su aplicación, da igual la plataforma, windows, linux, mac o lo que sea. Estés programando lo que estés programando.

Luego hay un problema de concepto sobre qué es un servidor. Cuando hablas de servidor linux/windows (windows también tiene una versión para servidores) estás hablando de un servidor "fisico" que corre un SO. Pero también se llaman servidores a aplicaciones que escuchan peticiones de un cliente. Digamos que tú podrías tener un servidor windows/linux con varias aplicaciones de tipo servidor corriendo dentro de este. Por ejemplo un servidor de base de datos (SQLServer corre en windows, por ejemplo) y muchos de estos servidores son susceptibles de usar log4j, independientemente del SO donde corran.

[#45 raul_lapeira]

#31 ... coño y que llevo haciendo 20 años! . Servidores con Java.

[#67 Mschumacher]

#45 pero digo que no es relevante el sistema operativo, es una librería de Java

[#34 Emosido_engañado]

Una vulnerabilidad zero day, nivel 10/10 y un viernes. El hijoputismo no tiene fronteras. Ya puede arder el mundo que mañana me toco los cojones.

[#76 alvdavi]

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

[#2 dsj]

Dolor mucho dolor ...

[#18 skylon]

#2 no lo sabes tú bien

[#59 Razhan]

#18 No voy a mentar el nivel de dolor

[#72 PussyLover]

Lo fuerte de todo esto es que en 2016, el español Álvaro Muñoz ya expuso esta vulnerabilidad en un Black Hat de 2016.

En este Tweet un pequeño vídeo de su presentación:

Y aquí el PDF con su presentación: https://blackhat.com/docs/us-16/materials/us-16-Munoz-A-Journey-From-JNDI-LDAP-Manipulation-To-RCE.pdf

[#73 EmuAGR]

#72 No es lo mismo, la vulnerabilidad aquí no es exactamente la ejecución por LDAP, sino que el Log ejecuta lo que es logueado.

[#75 Razhan]

#73 No, log4j no ejecuta lo que se ha logeado. Log4j no tiene algo tipo $, esta vulnerabilidad es grave, pero no es tan clara.

[#77 EmuAGR]

#75 Ejecuta una clase que se baja de un servidor LDAP. Los programadores en Java están obsesionados con las RPC en vez de usar APIs. Si total, el rendimiento no es lo mejor de Java...

[#79 alvdavi]

#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

[#74 Razhan]

#72 Esta vulnerabilidad consta de dos partes. Una de ellas es lo que Alvaro presento en 2016, pero por si sola no es suficiente. Su presentacion demostro que una injeccion de jndi se puede escalar hasta una ejecucion de codigo remoto. Pero todavia necesitas alguna forma de hacer que Java se conecte a tu servidor.

Log4j no solo lo hizo posible, sino que puede considerarse que lo hizo trivial

[#55 Desactivado]

#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

[#56 alvdavi]

#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

[#68 frg]

#65 Todavía no veo en tus comentarios nada que no sean castillos en el aire, y nada que sea una alternativa real, por lo que asumiré que te explicas realmente mal.

[#70 Desactivado]

#68 Mejor asumir que me explico realmente mal y dejarlo aquí.

[#47 herlocksholmes]

No entiendo nada de lo que habláis.
Os odio a todos

[#12 urannio]

Solamente

[#14 Desactivado]

No entiendo exactamente...

Hay alguna PoC por ahi?

[#38 el-brujo]

#14 https://isc.sans.edu/diary/28120

[#44 raul_lapeira]

#38 Tienes que tener acceso al JDNI que tiene la clase que quiere hacer pupa... para los usuarios de windows en local sí es un problema, pero en la mayoria de redes corporativas que se me ocurren no seria viable este tipo de ataque segun está hecho en la POC.

[#35 Desactivado]

Pero a ver si lo entiendo:

La vulnerabilidad es cuando logueas, directamente, el resultado de una llamada a un LDAP pq lo deserializa in java's way?

Pero quien loguea eso? Por que?

[#39 drnth]

#35 Imagina que tienes un punto de entrada a tu aplicación (suscripción a una cola, un controlador rest, un socket, etc.) y estás guardando trazas de lo que recibes por ahí para poder diagnosticar posibles problemas... No es tan raro, ¿no?

[#49 Desactivado]

#39 A ver, que creo que estoy perdiendome algo, por que sino no seria tan grave:

Generalmente guardaras la respuesta en algun sitio porque la querras para algo mas que logearla, no se la das directamente a un log, y el problema solo ocurre cuando el deserializado lo hace log4j2, no?

Y cuando la recojas para hacer algo con ella la desearilazas a un objeto (de la clase que sea) y ya no lo tendra que hacer log4j2, no? Le daras ese objeto ya parseado a log4j....

Insisto, creo que lo he entendido mal, pero no se QUE he entendido mal.

[#51 Desactivado]

#49 #39 vale, espera!!!!

Que no que no!!!!!

Que es que el mismo atacante te manda la cadena de texto (pongamos en el username cuando alguien va a loguearse o darse de alta en la applicacion, por ejemplo) "$" y coge el tontopollas del log4j y se pone a llamar a la pagina y a deserializar la respuesta y le enchufan una class que explota la vulnerabilidad mitica del deserializado y puede ejecutar lo que quiera con permisos de quien haya lanzado el servidor....

LOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOL

Como pueden hacer un CAGADON de ese tamaño en una puta libreria que SOLO TIENE QUE LOGUEAR, JODER

[#58 EmuAGR]

#51 Ahora a ver quién ha sido el genio de meter todas esas tontopolladas a log4j.

[#66 Desactivado]

#58 Tal cual. Lo peor es q estara en el repo

[#54 alvdavi]

#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+

[#17 Overmind]

Aunque es grave, es posible que finalmente el ataque no funcione en muchos servidores
Parece que con un JDK algo actualizado ya no funciona (por ejemplo, para Java 8, desde la 191 ya no funcionaría).
Por otra parte muchos servidores tienen las conexiones salientes capadas, por lo que ahí tampoco funcionaría el ataque.

[#19 Desactivado]

#17 es que eso es lo suyo, tener whitelisting en vez de blacklisting, network policies lo más restrictivas posibles y la parte pública ponerla a través de proxies que oculten las llamadas internas.

[#40 frg]

#19 Pon un proxy en lugar de parchear, verás que divertido ...

[#61 Desactivado]

#40 es que no debería haber nada de Java de cara en partes públicas de sistemas distribuidos. Es un lenguaje backend y precisamente tener MVCs y monolitos expone a todo un mundo de vulnerabilidades.

Pero sí, estoy de acuerdo con lo que dices y no hay que dejar ningún frente abierto.

[#25 Polmac]

#17 Con esas versiones, si lo he entendido bien, no funciona uno de los vectores de ataque; pero no es el único…

[#52 alvdavi]

#25 Correcto. Esta vulnerabilidad debe seguir considerandose critica y requiere una actualizacion de Log4j2.

[#32 frg]

#17 ¿Que no funcioni?, ¿versiones actualizadas?

[#50 alvdavi]

#17 El uso de una version mas nueva de OpenJDK (ya sea en referencia a jdk8u121, jdk8u191 o 11.0.1) provee unicamente de una mitigacion parcial del problema. En muchas circunstancias, sigue siendo posible explotar la vulnerabilidad utilizando otras alternativas.

Esta vulnerabilidad debe considerarse critica independientemente de que version de OpenJDK se esta utilizando. La unica opcion para evitar el problema es actualizar Log4j2 a la ultiva version de 2.15 disponible (2.15rc2 en el momento de escribir este mensaje)

[#71 PussyLover]

https://github.com/apache/logging-log4j2/pull/608

[#46 respira]

A ver, que si, que es un 0day y la cosa es grave... Pero esta noticia es bastante alarmista. Si usas una java6 medianamente actualizada no estas afectado por la vulnerabilidad "J A V A 6"... Esto significa que tan solo las personas que usen una versión de antes de 2004 o no hayan actualizado están jodidas. Y obviamente NO es fácil de explotar.

Vamos que log4j tiene un fallo muy grave y sin embargo java lo cubre bastante bien para que explotarla sea bastante más difícil de lo que ya es...

¿Esto es el salvame delux de la programación?

[#53 alvdavi]

#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

[#10 code2011]

Vaya día le ha dado la vulnerabilidad esta

[#15 Mutiko30]

Ok, es que Windows es un sistema malo, malo ,malo... Oh wait!

[#20 borteixo]

#15 manzanas traigo

[#30 Mutiko30]

#20 ventanas, ventanas traigo.. y pingüinos, pinguinitos también traigo.

[#22 zeekren]

#15 log4j se usa un huevo en Windows, no es por nada...

[#28 Mutiko30]

#22 Que a mi me la suda.. pero ni una palabra de los S.O afectados en servidores.. hay lo dejo.

[#13 Desactivado]

Demasiados componentes/librerías/módulos y demasiada complejidad... Toca hacer un cambio de paradigma de programación (Soft+Hard)...

[#41 frg]

#13 ¿Y cual propones?, ¿dejar de usar módulos de terceros y hacerlo todo desde 0?, ¿mini aplicaciones gestionadas por "equipos" de dos personas? Me imagino que el log de lo que haces va a la consola, y con suerte a un fichero, a base de "print" o equivalente en tu código. Super granular, escalable y nada complicado de usar cuando tienes unos cuantos cientos de miles de líneas de código.

[#65 Desactivado]

#41 Bueno, por los comentarios que pones directamente asumes que soy tonto de remate o uno de esos del palillo en la boca que apenas ha conseguido programar algo en basic (uffff.... “print”.... ezo ke eeeeee!?!?). También denoto una cierta respuesta a la defensiva como si mi comentario fuera un ataque a las librerías/módulos/etc y no... por ahi no van los tiros sino que, al contrario, lo que pretendo comunicar (pobremente?...) con mi comentario es que hay que ponerse manos a la obra para crear una nueva solución, fusionando el hardware y software, que quite toda esta complejidad y por ende la mayoría de los vectores de ataque.

Hago este comentario basándome en más de 7 años de I+D en el más bajo nivel en el Kernel de Linux; mi mundo discurre en los uS (microsegundos), en la gestión avanzada de threads en el scheduler, en el control de frecuencias en multinucleo y en la optimización de la estrategia idle de cada núcleo entre otras cosas.
También me dedico al tema ML y soy perfectamente consciente que sin todas esas fantásticas librerías no podría programar de forma simple en los distintos lenguajes como por ejemplo python.

Espero no haber soltado un tostón y buen finde!

[#21 manolito_pajotas]

Y seguro que es culpa de VOX