最近の 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?
10月の初めに、Apacheはパストラバーサルとリモートコード実行の脆弱性を修正するバージョン2.4.49をリリースし、修正が不完全だったという事実に対処するバージョン2.4.50をリリースしました。私たちは、現実の環境におけるリスクを実証するという使命を掲げました。今すぐ試してみてください。
Secure Code Warrior le ayuda a proteger el código a lo largo de todo el ciclo de vida del desarrollo de software y a crear una cultura que dé prioridad a la ciberseguridad. Tanto si es gestor de seguridad de aplicaciones, desarrollador, CISO o responsable de seguridad, le ayudamos a reducir los riesgos asociados al 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 para descargar el PDF de este recurso.
Secure Code Warrior le ayuda a proteger el código a lo largo de todo el ciclo de vida del desarrollo de software y a crear una cultura que dé prioridad a la ciberseguridad. Tanto si es gestor de seguridad de aplicaciones, desarrollador, CISO o responsable de seguridad, le ayudamos a reducir los riesgos asociados al código inseguro.
Mostrar 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 le ayuda a proteger el código a lo largo de todo el ciclo de vida del desarrollo de software y a crear una cultura que dé prioridad a la ciberseguridad. Tanto si es gestor de seguridad de aplicaciones, desarrollador, CISO o responsable de seguridad, le ayudamos a reducir los riesgos asociados al código inseguro.
Reservar una demostración[Descargar]Recursos para empezar
Temas y contenidos de la formación en código seguro
Nuestro contenido, líder en el sector, evoluciona constantemente para adaptarse al entorno de desarrollo de software en constante cambio, teniendo siempre en cuenta las funciones de nuestros clientes. Abarca todo tipo de temas, desde la inteligencia artificial hasta la inyección de XQuery, y está diseñado para satisfacer las necesidades de diversos perfiles, desde arquitectos e ingenieros hasta gestores de productos y responsables de control de calidad. Echemos un vistazo al contenido que ofrece nuestro catálogo, clasificado por temas y funciones.
La Cámara de Comercio establece el estándar para la seguridad impulsada por desarrolladores a gran escala
Kamer van Koophandel comparte cómo ha integrado la codificación segura en el desarrollo diario mediante certificaciones basadas en roles, evaluaciones comparativas de Trust Score y una cultura de responsabilidad compartida en materia de seguridad.
%20(1).avif)
.avif)
Modelado de amenazas con IA: convertir a cada desarrollador en un modelador de amenazas
Saldrá mejor equipado para ayudar a los desarrolladores a combinar ideas y técnicas de modelado de amenazas con las herramientas de IA que ya utilizan para reforzar la seguridad, mejorar la colaboración y crear software más resistente desde el principio.
Recursos para empezar
Cybermon ha vuelto: la misión de IA para derrotar al jefe ya está disponible bajo demanda.
Ahora se puede jugar a «Cybermon 2025 Beat the Boss» en SCW durante todo el año. Introduzca retos de seguridad avanzados de IA/LLM y refuerce a gran escala el desarrollo seguro de la IA.
Explicación de la Ley de Resiliencia Cibernética: su significado para el desarrollo de software seguro desde el diseño
Descubra qué exige la Ley de Resiliencia Cibernética (CRA) de la UE, a quién se aplica y cómo puede prepararse el equipo de ingeniería para las prácticas de seguridad desde el diseño, la prevención de vulnerabilidades y el desarrollo de las capacidades de los desarrolladores.
Enable 1: Criterios de éxito predefinidos y medibles
Enabler 1 es la primera parte de la serie Enablers of Success, compuesta por diez partes, y presenta cómo madurar un programa a largo plazo vinculando la codificación segura con resultados empresariales como la reducción de riesgos y la velocidad.
