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 hier, um Ihrem Unternehmen dabei zu helfen, den Code während des gesamten Lebenszyklus der Softwareentwicklung zu schützen und eine Kultur zu schaffen, in der Cybersicherheit oberste Priorität hat. Ganz gleich, ob Sie AppSec-Administrator, Entwickler, CISO oder in einem anderen Bereich der Sicherheit tätig sind – wir können Ihrem Unternehmen dabei helfen, die mit unsicherem Code verbundenen Risiken zu reduzieren.
Eine Vorführung buchen
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?
Klicken Sie auf den untenstehenden Link und laden Sie die PDF-Datei dieser Ressource herunter.
Secure Code Warrior hier, um Ihrem Unternehmen dabei zu helfen, den Code während des gesamten Lebenszyklus der Softwareentwicklung zu schützen und eine Kultur zu schaffen, in der Cybersicherheit oberste Priorität hat. Ganz gleich, ob Sie AppSec-Administrator, Entwickler, CISO oder in einem anderen Bereich der Sicherheit tätig sind – wir können Ihrem Unternehmen dabei helfen, die mit unsicherem Code verbundenen Risiken zu reduzieren.
Bericht anzeigenEine Vorführung buchen
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?
Inhaltsverzeichnis
Secure Code Warrior hier, um Ihrem Unternehmen dabei zu helfen, den Code während des gesamten Lebenszyklus der Softwareentwicklung zu schützen und eine Kultur zu schaffen, in der Cybersicherheit oberste Priorität hat. Ganz gleich, ob Sie AppSec-Administrator, Entwickler, CISO oder in einem anderen Bereich der Sicherheit tätig sind – wir können Ihrem Unternehmen dabei helfen, die mit unsicherem Code verbundenen Risiken zu reduzieren.
Eine Vorführung buchenHerunterladenRessourcen für den Einstieg
Themen und Inhalte der Schulung zum Thema sicherer Code
Unsere branchenführenden Inhalte werden ständig weiterentwickelt, um sich an die sich wandelnde Landschaft der Softwareentwicklung anzupassen und dabei Ihre Rolle zu berücksichtigen. Es werden Themen angeboten, die von KI bis hin zu XQuery-Injektion reichen und sich an verschiedene Positionen richten, von Architekten und Ingenieuren bis hin zu Produktmanagern und Qualitätskontrolleuren. Verschaffen Sie sich einen Überblick über unser Angebot an Inhalten nach Thema und Funktion.
Die Kamer van Koophandel setzt Maßstäbe für entwicklergesteuerte Sicherheit in großem Maßstab
Die Kamer van Koophandel berichtet, wie sie sicheres Codieren durch rollenbasierte Zertifizierungen, Trust Score-Benchmarking und eine Kultur der gemeinsamen Verantwortung für Sicherheit in die tägliche Entwicklungsarbeit integriert hat.
%20(1).avif)
.avif)
Bedrohungsmodellierung mit KI: So wird jeder Entwickler zum Bedrohungsmodellierer
Sie werden besser gerüstet sein, um Entwicklern dabei zu helfen, Ideen und Techniken zur Bedrohungsmodellierung mit den KI-Tools zu kombinieren, die sie bereits verwenden, um die Sicherheit zu erhöhen, die Zusammenarbeit zu verbessern und von Anfang an widerstandsfähigere Software zu entwickeln.
Ressourcen für den Einstieg
Cybermon ist zurück: Die KI-Missionen von Beat the Boss sind jetzt auf Abruf verfügbar.
Cybermon 2025 Beat the Boss ist jetzt das ganze Jahr über bei SCW verfügbar. Implementieren Sie fortschrittliche KI- und LLM-Sicherheitsherausforderungen, um die sichere Entwicklung von KI in großem Maßstab zu stärken.
Erläuterung des Gesetzes zur Cyberresilienz: Was bedeutet es für die Entwicklung sicherer Software?
Entdecken Sie, was das EU-Gesetz zur Cyberresilienz (CRA) verlangt, für wen es gilt und wie sich Ingenieurteams mit sicheren Designpraktiken, der Vermeidung von Schwachstellen und der Entwicklung von Fähigkeiten für Entwickler darauf vorbereiten können.
SCW feiert sein 11-jähriges Bestehen: eine Lektion in Echtzeit über Anpassungsfähigkeit und kontinuierliche Verbesserung
2025 war ein großartiges Jahr für KI, Cybersicherheit und SCW. Ich gehe mit ruhiger Zuversicht und dem Optimismus, den nur harte und lohnende Arbeit mit sich bringen kann, auf das Jahr 2026 zu.