Experimente el impacto de la vulnerabilidad Path Traversal, culpable de los recientes problemas de Apache
A principios de octubre, Apache lanzó la versión 2.4.49 para corregir una vulnerabilidad de Path Traversal y Ejecución Remota de Código y posteriormente la 2.4.50 para solucionar el hecho de que la corrección de la 2.4.49 estaba incompleta. Quizás hayas visto en las redes sociales la importancia de actualizar a la última versión para evitar estos riesgos, dado que Apache alimenta el 25% de Internet según algunas estimaciones. Pero, ¿cuál es el problema? ¿Qué riesgo existe en este caso?
¿Por qué no lo pruebas tú mismo?
Hemos creado una misión para demostrar los riesgos en un entorno real y la hemos hecho pública para que todos puedan probarla. En esta misión, le mostraremos cómo la vulnerabilidad Path Traversal puede afectar a su infraestructura y aplicaciones. Haga clic a continuación para entrar directamente, o continúe leyendo para aprender más sobre la vulnerabilidad en detalle.
Acerca de la vulnerabilidad Path Traversal
La vulnerabilidad se introdujo en la versión 2.4.49(debido a un cambio en la función de normalización de URL), donde se introdujo una nueva función de normalización de rutas. Desgraciadamente, no normalizó correctamente las rutas codificadas en la URL. Esto hace que sea posible realizar un ataque de path traversal si la siguiente configuración no está presente:
.avif)
Y si mod_cgi está habilitado, también puede ser aprovechado en una vulnerabilidad de Ejecución Remota de Código. Pero primero vamos a profundizar en la codificación de la URL para entender mejor lo que salió mal.
Codificación de la URL
En su forma más básica, la vulnerabilidad se produce debido a la falta de consideración de las URL con codificación de URL. La función de normalización de rutas introducida recientemente no manejaba completamente los casos en los que los puntos estaban codificados como URL.
Recuerde que para llevar a cabo un ataque de travesía de ruta, necesitará atravesar con la secuencia ../. La función de normalización, sin embargo, es lo suficientemente inteligente como para eliminar eso. Entonces, ¿qué se puede hacer? Puede codificar la URL con un .(punto) hasta %2e, y utilizar una secuencia como .%2e/. Eso funcionaría en muchos casos contra Apache 2.4.40. Pero también puede ir un paso más allá y codificarla doblemente. La versión codificada de la URL de . %2e/ es .%252e/. Esto puede evitar el intento de normalización por parte de Apache.
Pero hay una trampa
Si alguien quisiera intentar explotar esta vulnerabilidad directamente en su navegador, no tendría éxito. Esto se debe a que los navegadores también intentan normalizar las URL que se envían a los servidores. Esto significa que incluso nuestra secuencia doblemente codificada será eliminada. También significa que no podemos usar simplemente un navegador para demostrar esto.
Puede utilizar cURL para demostrarlo utilizando la bandera --path-as-is , que impide que normalice la URL antes de enviarla:
.avif)
Prevención y mitigación
Para evitar completamente el problema, es importante mantenerse al día con los últimos parches de Apache. Específicamente, usted querrá actualizar a 2.4.51 como mínimo. Pero es una buena práctica para actualizar en un horario regular para mantenerse al día.
Para mitigar este problema si está ejecutando la versión 2.4.49, asegúrese de haber incluido lo siguiente en su configuración de Apache:
.avif)
Y para evitar la ejecución remota de código, desactive mod_cgi si no lo utiliza.
Experimente usted mismo el impacto
¿Está interesado en explorar exactamente lo que ocurrió y probarlo usted mismo?
A principios de octubre, Apache lanzó la versión 2.4.49 para corregir una vulnerabilidad de Path Traversal y Ejecución Remota de Código y luego la 2.4.50 para solucionar el hecho de que la corrección era incompleta. Hemos creado una misión para demostrar los riesgos en un entorno real. Pruébalo ahora.
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
A principios de octubre, Apache lanzó la versión 2.4.49 para corregir una vulnerabilidad de Path Traversal y Ejecución Remota de Código y posteriormente la 2.4.50 para solucionar el hecho de que la corrección de la 2.4.49 estaba incompleta. Quizás hayas visto en las redes sociales la importancia de actualizar a la última versión para evitar estos riesgos, dado que Apache alimenta el 25% de Internet según algunas estimaciones. Pero, ¿cuál es el problema? ¿Qué riesgo existe en este caso?
¿Por qué no lo pruebas tú mismo?
Hemos creado una misión para demostrar los riesgos en un entorno real y la hemos hecho pública para que todos puedan probarla. En esta misión, le mostraremos cómo la vulnerabilidad Path Traversal puede afectar a su infraestructura y aplicaciones. Haga clic a continuación para entrar directamente, o continúe leyendo para aprender más sobre la vulnerabilidad en detalle.
Acerca de la vulnerabilidad Path Traversal
La vulnerabilidad se introdujo en la versión 2.4.49(debido a un cambio en la función de normalización de URL), donde se introdujo una nueva función de normalización de rutas. Desgraciadamente, no normalizó correctamente las rutas codificadas en la URL. Esto hace que sea posible realizar un ataque de path traversal si la siguiente configuración no está presente:
Y si mod_cgi está habilitado, también puede ser aprovechado en una vulnerabilidad de Ejecución Remota de Código. Pero primero vamos a profundizar en la codificación de la URL para entender mejor lo que salió mal.
Codificación de la URL
En su forma más básica, la vulnerabilidad se produce debido a la falta de consideración de las URL con codificación de URL. La función de normalización de rutas introducida recientemente no manejaba completamente los casos en los que los puntos estaban codificados como URL.
Recuerde que para llevar a cabo un ataque de travesía de ruta, necesitará atravesar con la secuencia ../. La función de normalización, sin embargo, es lo suficientemente inteligente como para eliminar eso. Entonces, ¿qué se puede hacer? Puede codificar la URL con un .(punto) hasta %2e, y utilizar una secuencia como .%2e/. Eso funcionaría en muchos casos contra Apache 2.4.40. Pero también puede ir un paso más allá y codificarla doblemente. La versión codificada de la URL de . %2e/ es .%252e/. Esto puede evitar el intento de normalización por parte de Apache.
Pero hay una trampa
Si alguien quisiera intentar explotar esta vulnerabilidad directamente en su navegador, no tendría éxito. Esto se debe a que los navegadores también intentan normalizar las URL que se envían a los servidores. Esto significa que incluso nuestra secuencia doblemente codificada será eliminada. También significa que no podemos usar simplemente un navegador para demostrar esto.
Puede utilizar cURL para demostrarlo utilizando la bandera --path-as-is , que impide que normalice la URL antes de enviarla:
Prevención y mitigación
Para evitar completamente el problema, es importante mantenerse al día con los últimos parches de Apache. Específicamente, usted querrá actualizar a 2.4.51 como mínimo. Pero es una buena práctica para actualizar en un horario regular para mantenerse al día.
Para mitigar este problema si está ejecutando la versión 2.4.49, asegúrese de haber incluido lo siguiente en su configuración de Apache:
Y para evitar la ejecución remota de código, desactive mod_cgi si no lo utiliza.
Experimente usted mismo el impacto
¿Está interesado en explorar exactamente lo que ocurrió y probarlo usted mismo?
A principios de octubre, Apache lanzó la versión 2.4.49 para corregir una vulnerabilidad de Path Traversal y Ejecución Remota de Código y posteriormente la 2.4.50 para solucionar el hecho de que la corrección de la 2.4.49 estaba incompleta. Quizás hayas visto en las redes sociales la importancia de actualizar a la última versión para evitar estos riesgos, dado que Apache alimenta el 25% de Internet según algunas estimaciones. Pero, ¿cuál es el problema? ¿Qué riesgo existe en este caso?
¿Por qué no lo pruebas tú mismo?
Hemos creado una misión para demostrar los riesgos en un entorno real y la hemos hecho pública para que todos puedan probarla. En esta misión, le mostraremos cómo la vulnerabilidad Path Traversal puede afectar a su infraestructura y aplicaciones. Haga clic a continuación para entrar directamente, o continúe leyendo para aprender más sobre la vulnerabilidad en detalle.
Acerca de la vulnerabilidad Path Traversal
La vulnerabilidad se introdujo en la versión 2.4.49(debido a un cambio en la función de normalización de URL), donde se introdujo una nueva función de normalización de rutas. Desgraciadamente, no normalizó correctamente las rutas codificadas en la URL. Esto hace que sea posible realizar un ataque de path traversal si la siguiente configuración no está presente:
Y si mod_cgi está habilitado, también puede ser aprovechado en una vulnerabilidad de Ejecución Remota de Código. Pero primero vamos a profundizar en la codificación de la URL para entender mejor lo que salió mal.
Codificación de la URL
En su forma más básica, la vulnerabilidad se produce debido a la falta de consideración de las URL con codificación de URL. La función de normalización de rutas introducida recientemente no manejaba completamente los casos en los que los puntos estaban codificados como URL.
Recuerde que para llevar a cabo un ataque de travesía de ruta, necesitará atravesar con la secuencia ../. La función de normalización, sin embargo, es lo suficientemente inteligente como para eliminar eso. Entonces, ¿qué se puede hacer? Puede codificar la URL con un .(punto) hasta %2e, y utilizar una secuencia como .%2e/. Eso funcionaría en muchos casos contra Apache 2.4.40. Pero también puede ir un paso más allá y codificarla doblemente. La versión codificada de la URL de . %2e/ es .%252e/. Esto puede evitar el intento de normalización por parte de Apache.
Pero hay una trampa
Si alguien quisiera intentar explotar esta vulnerabilidad directamente en su navegador, no tendría éxito. Esto se debe a que los navegadores también intentan normalizar las URL que se envían a los servidores. Esto significa que incluso nuestra secuencia doblemente codificada será eliminada. También significa que no podemos usar simplemente un navegador para demostrar esto.
Puede utilizar cURL para demostrarlo utilizando la bandera --path-as-is , que impide que normalice la URL antes de enviarla:
Prevención y mitigación
Para evitar completamente el problema, es importante mantenerse al día con los últimos parches de Apache. Específicamente, usted querrá actualizar a 2.4.51 como mínimo. Pero es una buena práctica para actualizar en un horario regular para mantenerse al día.
Para mitigar este problema si está ejecutando la versión 2.4.49, asegúrese de haber incluido lo siguiente en su configuración de Apache:
Y para evitar la ejecución remota de código, desactive mod_cgi si no lo utiliza.
Experimente usted mismo el impacto
¿Está interesado en explorar exactamente lo que ocurrió y probarlo usted mismo?
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
A principios de octubre, Apache lanzó la versión 2.4.49 para corregir una vulnerabilidad de Path Traversal y Ejecución Remota de Código y posteriormente la 2.4.50 para solucionar el hecho de que la corrección de la 2.4.49 estaba incompleta. Quizás hayas visto en las redes sociales la importancia de actualizar a la última versión para evitar estos riesgos, dado que Apache alimenta el 25% de Internet según algunas estimaciones. Pero, ¿cuál es el problema? ¿Qué riesgo existe en este caso?
¿Por qué no lo pruebas tú mismo?
Hemos creado una misión para demostrar los riesgos en un entorno real y la hemos hecho pública para que todos puedan probarla. En esta misión, le mostraremos cómo la vulnerabilidad Path Traversal puede afectar a su infraestructura y aplicaciones. Haga clic a continuación para entrar directamente, o continúe leyendo para aprender más sobre la vulnerabilidad en detalle.
Acerca de la vulnerabilidad Path Traversal
La vulnerabilidad se introdujo en la versión 2.4.49(debido a un cambio en la función de normalización de URL), donde se introdujo una nueva función de normalización de rutas. Desgraciadamente, no normalizó correctamente las rutas codificadas en la URL. Esto hace que sea posible realizar un ataque de path traversal si la siguiente configuración no está presente:
Y si mod_cgi está habilitado, también puede ser aprovechado en una vulnerabilidad de Ejecución Remota de Código. Pero primero vamos a profundizar en la codificación de la URL para entender mejor lo que salió mal.
Codificación de la URL
En su forma más básica, la vulnerabilidad se produce debido a la falta de consideración de las URL con codificación de URL. La función de normalización de rutas introducida recientemente no manejaba completamente los casos en los que los puntos estaban codificados como URL.
Recuerde que para llevar a cabo un ataque de travesía de ruta, necesitará atravesar con la secuencia ../. La función de normalización, sin embargo, es lo suficientemente inteligente como para eliminar eso. Entonces, ¿qué se puede hacer? Puede codificar la URL con un .(punto) hasta %2e, y utilizar una secuencia como .%2e/. Eso funcionaría en muchos casos contra Apache 2.4.40. Pero también puede ir un paso más allá y codificarla doblemente. La versión codificada de la URL de . %2e/ es .%252e/. Esto puede evitar el intento de normalización por parte de Apache.
Pero hay una trampa
Si alguien quisiera intentar explotar esta vulnerabilidad directamente en su navegador, no tendría éxito. Esto se debe a que los navegadores también intentan normalizar las URL que se envían a los servidores. Esto significa que incluso nuestra secuencia doblemente codificada será eliminada. También significa que no podemos usar simplemente un navegador para demostrar esto.
Puede utilizar cURL para demostrarlo utilizando la bandera --path-as-is , que impide que normalice la URL antes de enviarla:
Prevención y mitigación
Para evitar completamente el problema, es importante mantenerse al día con los últimos parches de Apache. Específicamente, usted querrá actualizar a 2.4.51 como mínimo. Pero es una buena práctica para actualizar en un horario regular para mantenerse al día.
Para mitigar este problema si está ejecutando la versión 2.4.49, asegúrese de haber incluido lo siguiente en su configuración de Apache:
Y para evitar la ejecución remota de código, desactive mod_cgi si no lo utiliza.
Experimente usted mismo el impacto
¿Está interesado en explorar exactamente lo que ocurrió y probarlo usted mismo?
Í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
Encontrar datos significativos sobre el éxito de las iniciativas Secure-by-Design es notoriamente difícil. Los responsables de la seguridad de la información se enfrentan a menudo al reto de demostrar el rendimiento de la inversión (ROI) y el valor empresarial de las actividades de los programas de seguridad, tanto a nivel de las personas como de la empresa. Por no mencionar que a las empresas les resulta especialmente difícil obtener información sobre cómo se comparan sus organizaciones con los estándares actuales del sector. La Estrategia Nacional de Ciberseguridad del Presidente desafió a las partes interesadas a "adoptar la seguridad y la resiliencia desde el diseño". La clave para que las iniciativas de seguridad por diseño funcionen no es sólo dotar a los desarrolladores de las habilidades necesarias para garantizar un código seguro, sino también garantizar a los reguladores que esas habilidades están en su lugar. En esta presentación, compartimos una miríada de datos cualitativos y cuantitativos, derivados de múltiples fuentes primarias, incluidos puntos de datos internos recogidos de más de 250.000 desarrolladores, opiniones de clientes basadas en datos y estudios públicos. Aprovechando esta agregación de puntos de datos, pretendemos comunicar una visión del estado actual de las iniciativas Secure-by-Design en múltiples verticales. El informe detalla por qué este espacio está actualmente infrautilizado, el impacto significativo que un programa de mejora de las competencias puede tener en la mitigación de los riesgos de ciberseguridad y el potencial para eliminar categorías de vulnerabilidades de un código base.
Servicios profesionales - Acelerar con experiencia
El equipo de servicios de estrategia de programas (PSS) de Secure Code Warriorle ayuda a crear, mejorar y optimizar su programa de codificación segura. Tanto si empieza de cero como si está perfeccionando su enfoque, nuestros expertos le proporcionarán orientación personalizada.
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.
Recursos para empezar
¿Vibe Coding va a convertir tu código en una fiesta de fraternidad?
Vibe Coding es como una fiesta de fraternidad universitaria, y la IA es la pieza central de todos los festejos, el barril. Es muy divertido dar rienda suelta a la creatividad y ver adónde te lleva tu imaginación, pero después de unas cuantas borracheras, beber (o usar IA) con moderación es, sin duda, la solución más segura a largo plazo.
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.
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.
