Experimenta el impacto de la vulnerabilidad Path Traversal, la culpable de los recientes problemas de Apache
A principios de octubre, Apache publicó la versión 2.4.49 para corregir un Vulnerabilidad de recorrido de ruta y ejecución remota de código y, posteriormente, 2.4.50 para corregir el hecho de que la corrección de 2.4.49 estaba incompleta. Quizás hayas visto en las redes sociales hablar sobre 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, ¿qué pasa? ¿Cuánto riesgo existe aquí?
¿Por qué no lo pruebas tú mismo?
Hemos creado una misión para demostrar los riesgos en un entorno de la vida real y la hemos hecho pública para que todos puedan intentarlo. En esta misión, le explicaremos cómo la vulnerabilidad Path Traversal puede afectar a su infraestructura y aplicaciones. Haga clic a continuación para acceder directamente o continúe leyendo para obtener más información 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. Lamentablemente, no pudo normalizar correctamente las rutas codificadas en URL. Esto hace posible llevar a cabo un ataque transversal si la siguiente configuración no está presente:
.avif)
Y si mod_cgi está habilitada, también se puede aprovechar para crear una vulnerabilidad de ejecución remota de código. Pero primero analicemos la codificación de URL para entender mejor qué es lo que ha fallado.
Codificación de URL
En su forma más básica, la vulnerabilidad se produce debido a la falta de consideración por las URL con codificación de URL. La función de normalización de rutas recientemente introducida no gestionaba completamente los casos en los que los puntos estaban codificados en URL.
Recuerda que para llevar a cabo un ataque que atraviese el camino, tendrás que recorrerlo con la secuencia .. /. La función de normalización, sin embargo, es lo suficientemente inteligente como para eliminar eso. Entonces, ¿qué haces? Puede codificar una URL .(Punto) hasta %2e, y usa una secuencia como .% 2e/. Eso funcionaría en muchos casos contra Apache 2.4.40. Pero también puedes ir un paso más allá y codificarlo dos veces. La versión codificada en URL de .% 2e/ es .% 252e/. Esto pudo evitar aún más el intento de normalización por parte de Apache.
Pero hay una trampa
Si alguien quisiera intentar aprovechar esta vulnerabilidad directamente en su navegador, no tendría éxito. Esto se debe al hecho de que los navegadores también intentan normalizar las URL que se envían a los servidores. Esto significa que incluso nuestra secuencia de doble codificación se eliminará. También significa que no podemos simplemente usar un navegador para demostrar esto.
Puede usar cURL para demostrar esto mediante el --ruta tal cual bandera, que evita que normalice la URL antes de enviarla:
.avif)
Prevención y mitigación
Para evitar por completo este problema, es importante mantenerse al día con los últimos parches de Apache. Concretamente, querrás actualizar a la versión 2.4.51 como mínimo. Sin embargo, es una buena práctica actualizar de forma 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 la configuración de Apache:
.avif)
Y para evitar la ejecución remota de código, desactive mod_cgi si no lo utilizas.
Experimenta el impacto por ti mismo
¿Estás interesado en explorar exactamente lo que pasó y probarlo por ti mismo?
A principios de octubre, Apache publicó la versión 2.4.49 para corregir una vulnerabilidad de recorrido por rutas y ejecución remota de código y, a continuación, la versión 2.4.50 para corregir el hecho de que la corrección estaba incompleta. Hemos creado una misión para demostrar los riesgos en un entorno real. Pruébelo ahora.
Secure Code Warrior là pour aider votre organisation à protéger le code tout au long du cycle de vie du développement logiciel et à créer une culture où la cybersécurité est une priorité. Que vous soyez administrateur AppSec, développeur, CISO ou toute autre personne impliquée dans la sécurité, nous pouvons aider votre organisation à réduire les risques associés à un code non sécurisé.
Veuillez réserver une démonstration.
A principios de octubre, Apache publicó la versión 2.4.49 para corregir un Vulnerabilidad de recorrido de ruta y ejecución remota de código y, posteriormente, 2.4.50 para corregir el hecho de que la corrección de 2.4.49 estaba incompleta. Quizás hayas visto en las redes sociales hablar sobre 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, ¿qué pasa? ¿Cuánto riesgo existe aquí?
¿Por qué no lo pruebas tú mismo?
Hemos creado una misión para demostrar los riesgos en un entorno de la vida real y la hemos hecho pública para que todos puedan intentarlo. En esta misión, le explicaremos cómo la vulnerabilidad Path Traversal puede afectar a su infraestructura y aplicaciones. Haga clic a continuación para acceder directamente o continúe leyendo para obtener más información 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. Lamentablemente, no pudo normalizar correctamente las rutas codificadas en URL. Esto hace posible llevar a cabo un ataque transversal si la siguiente configuración no está presente:
Y si mod_cgi está habilitada, también se puede aprovechar para crear una vulnerabilidad de ejecución remota de código. Pero primero analicemos la codificación de URL para entender mejor qué es lo que ha fallado.
Codificación de URL
En su forma más básica, la vulnerabilidad se produce debido a la falta de consideración por las URL con codificación de URL. La función de normalización de rutas recientemente introducida no gestionaba completamente los casos en los que los puntos estaban codificados en URL.
Recuerda que para llevar a cabo un ataque que atraviese el camino, tendrás que recorrerlo con la secuencia .. /. La función de normalización, sin embargo, es lo suficientemente inteligente como para eliminar eso. Entonces, ¿qué haces? Puede codificar una URL .(Punto) hasta %2e, y usa una secuencia como .% 2e/. Eso funcionaría en muchos casos contra Apache 2.4.40. Pero también puedes ir un paso más allá y codificarlo dos veces. La versión codificada en URL de .% 2e/ es .% 252e/. Esto pudo evitar aún más el intento de normalización por parte de Apache.
Pero hay una trampa
Si alguien quisiera intentar aprovechar esta vulnerabilidad directamente en su navegador, no tendría éxito. Esto se debe al hecho de que los navegadores también intentan normalizar las URL que se envían a los servidores. Esto significa que incluso nuestra secuencia de doble codificación se eliminará. También significa que no podemos simplemente usar un navegador para demostrar esto.
Puede usar cURL para demostrar esto mediante el --ruta tal cual bandera, que evita que normalice la URL antes de enviarla:
Prevención y mitigación
Para evitar por completo este problema, es importante mantenerse al día con los últimos parches de Apache. Concretamente, querrás actualizar a la versión 2.4.51 como mínimo. Sin embargo, es una buena práctica actualizar de forma 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 la configuración de Apache:
Y para evitar la ejecución remota de código, desactive mod_cgi si no lo utilizas.
Experimenta el impacto por ti mismo
¿Estás interesado en explorar exactamente lo que pasó y probarlo por ti mismo?
A principios de octubre, Apache publicó la versión 2.4.49 para corregir un Vulnerabilidad de recorrido de ruta y ejecución remota de código y, posteriormente, 2.4.50 para corregir el hecho de que la corrección de 2.4.49 estaba incompleta. Quizás hayas visto en las redes sociales hablar sobre 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, ¿qué pasa? ¿Cuánto riesgo existe aquí?
¿Por qué no lo pruebas tú mismo?
Hemos creado una misión para demostrar los riesgos en un entorno de la vida real y la hemos hecho pública para que todos puedan intentarlo. En esta misión, le explicaremos cómo la vulnerabilidad Path Traversal puede afectar a su infraestructura y aplicaciones. Haga clic a continuación para acceder directamente o continúe leyendo para obtener más información 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. Lamentablemente, no pudo normalizar correctamente las rutas codificadas en URL. Esto hace posible llevar a cabo un ataque transversal si la siguiente configuración no está presente:
Y si mod_cgi está habilitada, también se puede aprovechar para crear una vulnerabilidad de ejecución remota de código. Pero primero analicemos la codificación de URL para entender mejor qué es lo que ha fallado.
Codificación de URL
En su forma más básica, la vulnerabilidad se produce debido a la falta de consideración por las URL con codificación de URL. La función de normalización de rutas recientemente introducida no gestionaba completamente los casos en los que los puntos estaban codificados en URL.
Recuerda que para llevar a cabo un ataque que atraviese el camino, tendrás que recorrerlo con la secuencia .. /. La función de normalización, sin embargo, es lo suficientemente inteligente como para eliminar eso. Entonces, ¿qué haces? Puede codificar una URL .(Punto) hasta %2e, y usa una secuencia como .% 2e/. Eso funcionaría en muchos casos contra Apache 2.4.40. Pero también puedes ir un paso más allá y codificarlo dos veces. La versión codificada en URL de .% 2e/ es .% 252e/. Esto pudo evitar aún más el intento de normalización por parte de Apache.
Pero hay una trampa
Si alguien quisiera intentar aprovechar esta vulnerabilidad directamente en su navegador, no tendría éxito. Esto se debe al hecho de que los navegadores también intentan normalizar las URL que se envían a los servidores. Esto significa que incluso nuestra secuencia de doble codificación se eliminará. También significa que no podemos simplemente usar un navegador para demostrar esto.
Puede usar cURL para demostrar esto mediante el --ruta tal cual bandera, que evita que normalice la URL antes de enviarla:
Prevención y mitigación
Para evitar por completo este problema, es importante mantenerse al día con los últimos parches de Apache. Concretamente, querrás actualizar a la versión 2.4.51 como mínimo. Sin embargo, es una buena práctica actualizar de forma 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 la configuración de Apache:
Y para evitar la ejecución remota de código, desactive mod_cgi si no lo utilizas.
Experimenta el impacto por ti mismo
¿Estás interesado en explorar exactamente lo que pasó y probarlo por ti mismo?
Veuillez cliquer sur le lien ci-dessous et télécharger le PDF de cette ressource.
Secure Code Warrior là pour aider votre organisation à protéger le code tout au long du cycle de vie du développement logiciel et à créer une culture où la cybersécurité est une priorité. Que vous soyez administrateur AppSec, développeur, CISO ou toute autre personne impliquée dans la sécurité, nous pouvons aider votre organisation à réduire les risques associés à un code non sécurisé.
Veuillez consulter le rapportVeuillez réserver une démonstration.
A principios de octubre, Apache publicó la versión 2.4.49 para corregir un Vulnerabilidad de recorrido de ruta y ejecución remota de código y, posteriormente, 2.4.50 para corregir el hecho de que la corrección de 2.4.49 estaba incompleta. Quizás hayas visto en las redes sociales hablar sobre 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, ¿qué pasa? ¿Cuánto riesgo existe aquí?
¿Por qué no lo pruebas tú mismo?
Hemos creado una misión para demostrar los riesgos en un entorno de la vida real y la hemos hecho pública para que todos puedan intentarlo. En esta misión, le explicaremos cómo la vulnerabilidad Path Traversal puede afectar a su infraestructura y aplicaciones. Haga clic a continuación para acceder directamente o continúe leyendo para obtener más información 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. Lamentablemente, no pudo normalizar correctamente las rutas codificadas en URL. Esto hace posible llevar a cabo un ataque transversal si la siguiente configuración no está presente:
Y si mod_cgi está habilitada, también se puede aprovechar para crear una vulnerabilidad de ejecución remota de código. Pero primero analicemos la codificación de URL para entender mejor qué es lo que ha fallado.
Codificación de URL
En su forma más básica, la vulnerabilidad se produce debido a la falta de consideración por las URL con codificación de URL. La función de normalización de rutas recientemente introducida no gestionaba completamente los casos en los que los puntos estaban codificados en URL.
Recuerda que para llevar a cabo un ataque que atraviese el camino, tendrás que recorrerlo con la secuencia .. /. La función de normalización, sin embargo, es lo suficientemente inteligente como para eliminar eso. Entonces, ¿qué haces? Puede codificar una URL .(Punto) hasta %2e, y usa una secuencia como .% 2e/. Eso funcionaría en muchos casos contra Apache 2.4.40. Pero también puedes ir un paso más allá y codificarlo dos veces. La versión codificada en URL de .% 2e/ es .% 252e/. Esto pudo evitar aún más el intento de normalización por parte de Apache.
Pero hay una trampa
Si alguien quisiera intentar aprovechar esta vulnerabilidad directamente en su navegador, no tendría éxito. Esto se debe al hecho de que los navegadores también intentan normalizar las URL que se envían a los servidores. Esto significa que incluso nuestra secuencia de doble codificación se eliminará. También significa que no podemos simplemente usar un navegador para demostrar esto.
Puede usar cURL para demostrar esto mediante el --ruta tal cual bandera, que evita que normalice la URL antes de enviarla:
Prevención y mitigación
Para evitar por completo este problema, es importante mantenerse al día con los últimos parches de Apache. Concretamente, querrás actualizar a la versión 2.4.51 como mínimo. Sin embargo, es una buena práctica actualizar de forma 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 la configuración de Apache:
Y para evitar la ejecución remota de código, desactive mod_cgi si no lo utilizas.
Experimenta el impacto por ti mismo
¿Estás interesado en explorar exactamente lo que pasó y probarlo por ti mismo?
Table des matières
Secure Code Warrior là pour aider votre organisation à protéger le code tout au long du cycle de vie du développement logiciel et à créer une culture où la cybersécurité est une priorité. Que vous soyez administrateur AppSec, développeur, CISO ou toute autre personne impliquée dans la sécurité, nous pouvons aider votre organisation à réduire les risques associés à un code non sécurisé.
Veuillez réserver une démonstration.TéléchargerRessources pour débuter
Thèmes et contenu de la formation sur le code sécurisé
Notre contenu de pointe évolue constamment afin de s'adapter au paysage changeant du développement logiciel, en tenant compte de votre rôle. Nous proposons des thèmes allant de l'IA à l'injection XQuery pour différents postes, des architectes et ingénieurs aux chefs de produit et responsables de l'assurance qualité. Découvrez un aperçu de ce que notre catalogue de contenu a à offrir par thème et par fonction.
La Chambre de commerce établit la norme en matière de sécurité à grande échelle axée sur les développeurs
La Chambre de commerce néerlandaise explique comment elle a intégré le codage sécurisé dans le développement quotidien grâce à des certifications basées sur les rôles, à l'évaluation comparative du Trust Score et à une culture de responsabilité partagée en matière de sécurité.
%20(1).avif)
.avif)
Modélisation des menaces avec l'IA : transformer chaque développeur en modélisateur de menaces
Vous repartirez mieux équipé pour aider les développeurs à combiner les idées et les techniques de modélisation des menaces avec les outils d'IA qu'ils utilisent déjà pour renforcer la sécurité, améliorer la collaboration et créer des logiciels plus résilients dès le départ.
Ressources pour débuter
Cybermon est de retour : les missions IA de Beat the Boss sont désormais disponibles à la demande.
Cybermon 2025 Beat the Boss est désormais disponible toute l'année chez SCW. Mettez en œuvre des défis de sécurité avancés basés sur l'IA et le LLM afin de renforcer le développement sécurisé de l'IA à grande échelle.
Explication de la loi sur la cyber-résilience : implications pour le développement de logiciels sécurisés dès leur conception
Découvrez les exigences de la loi européenne sur la cyber-résilience (CRA), à qui elle s'applique et comment les équipes d'ingénierie peuvent se préparer grâce à des pratiques de conception sécurisées, à la prévention des vulnérabilités et au développement des compétences des développeurs.
Facilitateur 1 : Critères de réussite définis et mesurables
Le catalyseur n° 1 inaugure notre série en 10 parties intitulée « Les catalyseurs de la réussite », qui montre comment relier la codification sécurisée aux résultats commerciaux, tels que la réduction des risques et la rapidité d'atteinte de la maturité du programme à long terme.
