Erleben Sie die Auswirkungen der Path Traversal Vulnerability, die für die jüngsten Apache-Probleme verantwortlich ist
Anfang Oktober veröffentlichte Apache die Version 2.4.49, um eine Schwachstelle in Bezug auf Path Traversal und Remote Code Execution zu beheben, und anschließend die Version 2.4.50, um die Tatsache zu beheben, dass die Behebung der Schwachstelle in 2.4.49 unvollständig war. Vielleicht haben Sie in den sozialen Medien gelesen, wie wichtig es ist, auf die neueste Version zu aktualisieren, um diese Risiken zu vermeiden, da Apache nach einigen Schätzungen 25 % des Internets betreibt. Aber worum geht es hier eigentlich? Wie groß ist das Risiko hier?
Warum probieren Sie es nicht selbst aus?
Wir haben eine Mission erstellt, um die Risiken in einer realen Umgebung zu demonstrieren, und haben sie für jeden zum Ausprobieren freigegeben. In dieser Mission zeigen wir Ihnen, wie sich die Path Traversal Vulnerability auf Ihre Infrastruktur und Anwendungen auswirken kann. Klicken Sie unten, um direkt einzusteigen, oder lesen Sie weiter, um mehr über die Sicherheitslücke im Detail zu erfahren.
Über die Path Traversal-Schwachstelle
Die Schwachstelle wurde in der Version 2.4.49 eingeführt(aufgrund einer Änderung der URL-Normalisierungsfunktion), wo eine neue Pfadnormalisierungsfunktion eingeführt wurde. Leider konnte sie URL-kodierte Pfade nicht korrekt normalisieren. Dadurch ist es möglich, einen Path-Traversal-Angriff durchzuführen, wenn die folgende Konfiguration nicht vorhanden ist:
.avif)
Und wenn mod_cgi aktiviert ist, kann dies auch zu einer Schwachstelle bei der Remote-Code-Ausführung führen. Aber lassen Sie uns zuerst die URL-Kodierung untersuchen, um besser zu verstehen, was schief gelaufen ist.
URL-Kodierung
Die Schwachstelle ist im Wesentlichen auf die fehlende Berücksichtigung von URLs mit URL-Kodierung zurückzuführen. Die neu eingeführte Pfadnormalisierungsfunktion behandelte Fälle, in denen Punkte URL-kodiert waren, nicht vollständig.
Denken Sie daran, dass Sie, um einen Pfadüberquerungsangriff durchzuführen, mit der Sequenz ../ überqueren müssen. Die Normalisierungsfunktion ist jedoch intelligent genug, um dies zu entfernen. Was können Sie also tun? Sie können die URL mit einem .(Punkt) bis zu %2e kodieren und eine Sequenz wie .%2e/ verwenden. Das würde in vielen Fällen gegen Apache 2.4.40 funktionieren. Sie können aber auch einen Schritt weiter gehen und es doppelt kodieren. Die URL-kodierte Version von .%2e/ ist .%252e/. Damit konnte die versuchte Normalisierung durch Apache umgangen werden.
Aber es gibt einen Haken
Wenn jemand versuchen würde, diese Schwachstelle direkt in seinem Browser auszunutzen, wäre er nicht erfolgreich. Das liegt daran, dass Browser auch versuchen, URLs, die an Server gesendet werden, zu normalisieren. Das bedeutet, dass sogar unsere doppelt kodierte Sequenz entfernt wird. Das bedeutet auch, dass wir nicht einfach einen Browser verwenden können, um dies zu demonstrieren.
Sie können cURL verwenden, um dies zu demonstrieren, indem Sie das Flag --path-as-is verwenden, das verhindert, dass die URL vor dem Senden normalisiert wird:
.avif)
Prävention und Schadensbegrenzung
Um das Problem vollständig zu vermeiden, ist es wichtig, die neuesten Patches von Apache zu verwenden. Insbesondere sollten Sie mindestens ein Upgrade auf 2.4.51 durchführen. Es ist jedoch eine gute Praxis, regelmäßig zu aktualisieren, um auf dem neuesten Stand zu bleiben.
Um dieses Problem abzuschwächen, wenn Sie 2.4.49 verwenden, stellen Sie sicher, dass Sie Folgendes in Ihre Apache-Konfiguration aufgenommen haben:
.avif)
Und um Remote Code Execution zu verhindern, deaktivieren Sie mod_cgi , wenn Sie es nicht verwenden.
Erleben Sie die Auswirkungen selbst
Möchten Sie herausfinden, was genau passiert ist und es selbst ausprobieren?
Anfang Oktober veröffentlichte Apache Version 2.4.49, um eine Sicherheitslücke in Path Traversal und Remote Code Execution zu beheben, und dann 2.4.50, um die Tatsache zu beheben, dass der Fix unvollständig war. Wir haben eine Mission entwickelt, um die Risiken in einer realen Umgebung zu demonstrieren. Probiere es jetzt aus.
Secure Code Warrior für Ihr Unternehmen da, um Ihnen zu helfen, Code während des gesamten Softwareentwicklungszyklus zu sichern und eine Kultur zu schaffen, in der Cybersicherheit an erster Stelle steht. Ganz gleich, ob Sie AppSec-Manager, Entwickler, CISO oder jemand anderes sind, der sich mit Sicherheit befasst, wir können Ihrem Unternehmen helfen, die mit unsicherem Code verbundenen Risiken zu reduzieren.
Eine Demo buchen
Anfang Oktober veröffentlichte Apache die Version 2.4.49, um eine Schwachstelle in Bezug auf Path Traversal und Remote Code Execution zu beheben, und anschließend die Version 2.4.50, um die Tatsache zu beheben, dass die Behebung der Schwachstelle in 2.4.49 unvollständig war. Vielleicht haben Sie in den sozialen Medien gelesen, wie wichtig es ist, auf die neueste Version zu aktualisieren, um diese Risiken zu vermeiden, da Apache nach einigen Schätzungen 25 % des Internets betreibt. Aber worum geht es hier eigentlich? Wie groß ist das Risiko hier?
Warum probieren Sie es nicht selbst aus?
Wir haben eine Mission erstellt, um die Risiken in einer realen Umgebung zu demonstrieren, und haben sie für jeden zum Ausprobieren freigegeben. In dieser Mission zeigen wir Ihnen, wie sich die Path Traversal Vulnerability auf Ihre Infrastruktur und Anwendungen auswirken kann. Klicken Sie unten, um direkt einzusteigen, oder lesen Sie weiter, um mehr über die Sicherheitslücke im Detail zu erfahren.
Über die Path Traversal-Schwachstelle
Die Schwachstelle wurde in der Version 2.4.49 eingeführt(aufgrund einer Änderung der URL-Normalisierungsfunktion), wo eine neue Pfadnormalisierungsfunktion eingeführt wurde. Leider konnte sie URL-kodierte Pfade nicht korrekt normalisieren. Dadurch ist es möglich, einen Path-Traversal-Angriff durchzuführen, wenn die folgende Konfiguration nicht vorhanden ist:
Und wenn mod_cgi aktiviert ist, kann dies auch zu einer Schwachstelle bei der Remote-Code-Ausführung führen. Aber lassen Sie uns zuerst die URL-Kodierung untersuchen, um besser zu verstehen, was schief gelaufen ist.
URL-Kodierung
Die Schwachstelle ist im Wesentlichen auf die fehlende Berücksichtigung von URLs mit URL-Kodierung zurückzuführen. Die neu eingeführte Pfadnormalisierungsfunktion behandelte Fälle, in denen Punkte URL-kodiert waren, nicht vollständig.
Denken Sie daran, dass Sie, um einen Pfadüberquerungsangriff durchzuführen, mit der Sequenz ../ überqueren müssen. Die Normalisierungsfunktion ist jedoch intelligent genug, um dies zu entfernen. Was können Sie also tun? Sie können die URL mit einem .(Punkt) bis zu %2e kodieren und eine Sequenz wie .%2e/ verwenden. Das würde in vielen Fällen gegen Apache 2.4.40 funktionieren. Sie können aber auch einen Schritt weiter gehen und es doppelt kodieren. Die URL-kodierte Version von .%2e/ ist .%252e/. Damit konnte die versuchte Normalisierung durch Apache umgangen werden.
Aber es gibt einen Haken
Wenn jemand versuchen würde, diese Schwachstelle direkt in seinem Browser auszunutzen, wäre er nicht erfolgreich. Das liegt daran, dass Browser auch versuchen, URLs, die an Server gesendet werden, zu normalisieren. Das bedeutet, dass sogar unsere doppelt kodierte Sequenz entfernt wird. Das bedeutet auch, dass wir nicht einfach einen Browser verwenden können, um dies zu demonstrieren.
Sie können cURL verwenden, um dies zu demonstrieren, indem Sie das Flag --path-as-is verwenden, das verhindert, dass die URL vor dem Senden normalisiert wird:
Prävention und Schadensbegrenzung
Um das Problem vollständig zu vermeiden, ist es wichtig, die neuesten Patches von Apache zu verwenden. Insbesondere sollten Sie mindestens ein Upgrade auf 2.4.51 durchführen. Es ist jedoch eine gute Praxis, regelmäßig zu aktualisieren, um auf dem neuesten Stand zu bleiben.
Um dieses Problem abzuschwächen, wenn Sie 2.4.49 verwenden, stellen Sie sicher, dass Sie Folgendes in Ihre Apache-Konfiguration aufgenommen haben:
Und um Remote Code Execution zu verhindern, deaktivieren Sie mod_cgi , wenn Sie es nicht verwenden.
Erleben Sie die Auswirkungen selbst
Möchten Sie herausfinden, was genau passiert ist und es selbst ausprobieren?
Anfang Oktober veröffentlichte Apache die Version 2.4.49, um eine Schwachstelle in Bezug auf Path Traversal und Remote Code Execution zu beheben, und anschließend die Version 2.4.50, um die Tatsache zu beheben, dass die Behebung der Schwachstelle in 2.4.49 unvollständig war. Vielleicht haben Sie in den sozialen Medien gelesen, wie wichtig es ist, auf die neueste Version zu aktualisieren, um diese Risiken zu vermeiden, da Apache nach einigen Schätzungen 25 % des Internets betreibt. Aber worum geht es hier eigentlich? Wie groß ist das Risiko hier?
Warum probieren Sie es nicht selbst aus?
Wir haben eine Mission erstellt, um die Risiken in einer realen Umgebung zu demonstrieren, und haben sie für jeden zum Ausprobieren freigegeben. In dieser Mission zeigen wir Ihnen, wie sich die Path Traversal Vulnerability auf Ihre Infrastruktur und Anwendungen auswirken kann. Klicken Sie unten, um direkt einzusteigen, oder lesen Sie weiter, um mehr über die Sicherheitslücke im Detail zu erfahren.
Über die Path Traversal-Schwachstelle
Die Schwachstelle wurde in der Version 2.4.49 eingeführt(aufgrund einer Änderung der URL-Normalisierungsfunktion), wo eine neue Pfadnormalisierungsfunktion eingeführt wurde. Leider konnte sie URL-kodierte Pfade nicht korrekt normalisieren. Dadurch ist es möglich, einen Path-Traversal-Angriff durchzuführen, wenn die folgende Konfiguration nicht vorhanden ist:
Und wenn mod_cgi aktiviert ist, kann dies auch zu einer Schwachstelle bei der Remote-Code-Ausführung führen. Aber lassen Sie uns zuerst die URL-Kodierung untersuchen, um besser zu verstehen, was schief gelaufen ist.
URL-Kodierung
Die Schwachstelle ist im Wesentlichen auf die fehlende Berücksichtigung von URLs mit URL-Kodierung zurückzuführen. Die neu eingeführte Pfadnormalisierungsfunktion behandelte Fälle, in denen Punkte URL-kodiert waren, nicht vollständig.
Denken Sie daran, dass Sie, um einen Pfadüberquerungsangriff durchzuführen, mit der Sequenz ../ überqueren müssen. Die Normalisierungsfunktion ist jedoch intelligent genug, um dies zu entfernen. Was können Sie also tun? Sie können die URL mit einem .(Punkt) bis zu %2e kodieren und eine Sequenz wie .%2e/ verwenden. Das würde in vielen Fällen gegen Apache 2.4.40 funktionieren. Sie können aber auch einen Schritt weiter gehen und es doppelt kodieren. Die URL-kodierte Version von .%2e/ ist .%252e/. Damit konnte die versuchte Normalisierung durch Apache umgangen werden.
Aber es gibt einen Haken
Wenn jemand versuchen würde, diese Schwachstelle direkt in seinem Browser auszunutzen, wäre er nicht erfolgreich. Das liegt daran, dass Browser auch versuchen, URLs, die an Server gesendet werden, zu normalisieren. Das bedeutet, dass sogar unsere doppelt kodierte Sequenz entfernt wird. Das bedeutet auch, dass wir nicht einfach einen Browser verwenden können, um dies zu demonstrieren.
Sie können cURL verwenden, um dies zu demonstrieren, indem Sie das Flag --path-as-is verwenden, das verhindert, dass die URL vor dem Senden normalisiert wird:
Prävention und Schadensbegrenzung
Um das Problem vollständig zu vermeiden, ist es wichtig, die neuesten Patches von Apache zu verwenden. Insbesondere sollten Sie mindestens ein Upgrade auf 2.4.51 durchführen. Es ist jedoch eine gute Praxis, regelmäßig zu aktualisieren, um auf dem neuesten Stand zu bleiben.
Um dieses Problem abzuschwächen, wenn Sie 2.4.49 verwenden, stellen Sie sicher, dass Sie Folgendes in Ihre Apache-Konfiguration aufgenommen haben:
Und um Remote Code Execution zu verhindern, deaktivieren Sie mod_cgi , wenn Sie es nicht verwenden.
Erleben Sie die Auswirkungen selbst
Möchten Sie herausfinden, was genau passiert ist und es selbst ausprobieren?
Klicken Sie auf den untenstehenden Link und laden Sie das PDF dieser Ressource herunter.
Secure Code Warrior für Ihr Unternehmen da, um Ihnen zu helfen, Code während des gesamten Softwareentwicklungszyklus zu sichern und eine Kultur zu schaffen, in der Cybersicherheit an erster Stelle steht. Ganz gleich, ob Sie AppSec-Manager, Entwickler, CISO oder jemand anderes sind, der sich mit Sicherheit befasst, wir können Ihrem Unternehmen helfen, die mit unsicherem Code verbundenen Risiken zu reduzieren.
Bericht ansehenEine Demo buchen
Anfang Oktober veröffentlichte Apache die Version 2.4.49, um eine Schwachstelle in Bezug auf Path Traversal und Remote Code Execution zu beheben, und anschließend die Version 2.4.50, um die Tatsache zu beheben, dass die Behebung der Schwachstelle in 2.4.49 unvollständig war. Vielleicht haben Sie in den sozialen Medien gelesen, wie wichtig es ist, auf die neueste Version zu aktualisieren, um diese Risiken zu vermeiden, da Apache nach einigen Schätzungen 25 % des Internets betreibt. Aber worum geht es hier eigentlich? Wie groß ist das Risiko hier?
Warum probieren Sie es nicht selbst aus?
Wir haben eine Mission erstellt, um die Risiken in einer realen Umgebung zu demonstrieren, und haben sie für jeden zum Ausprobieren freigegeben. In dieser Mission zeigen wir Ihnen, wie sich die Path Traversal Vulnerability auf Ihre Infrastruktur und Anwendungen auswirken kann. Klicken Sie unten, um direkt einzusteigen, oder lesen Sie weiter, um mehr über die Sicherheitslücke im Detail zu erfahren.
Über die Path Traversal-Schwachstelle
Die Schwachstelle wurde in der Version 2.4.49 eingeführt(aufgrund einer Änderung der URL-Normalisierungsfunktion), wo eine neue Pfadnormalisierungsfunktion eingeführt wurde. Leider konnte sie URL-kodierte Pfade nicht korrekt normalisieren. Dadurch ist es möglich, einen Path-Traversal-Angriff durchzuführen, wenn die folgende Konfiguration nicht vorhanden ist:
Und wenn mod_cgi aktiviert ist, kann dies auch zu einer Schwachstelle bei der Remote-Code-Ausführung führen. Aber lassen Sie uns zuerst die URL-Kodierung untersuchen, um besser zu verstehen, was schief gelaufen ist.
URL-Kodierung
Die Schwachstelle ist im Wesentlichen auf die fehlende Berücksichtigung von URLs mit URL-Kodierung zurückzuführen. Die neu eingeführte Pfadnormalisierungsfunktion behandelte Fälle, in denen Punkte URL-kodiert waren, nicht vollständig.
Denken Sie daran, dass Sie, um einen Pfadüberquerungsangriff durchzuführen, mit der Sequenz ../ überqueren müssen. Die Normalisierungsfunktion ist jedoch intelligent genug, um dies zu entfernen. Was können Sie also tun? Sie können die URL mit einem .(Punkt) bis zu %2e kodieren und eine Sequenz wie .%2e/ verwenden. Das würde in vielen Fällen gegen Apache 2.4.40 funktionieren. Sie können aber auch einen Schritt weiter gehen und es doppelt kodieren. Die URL-kodierte Version von .%2e/ ist .%252e/. Damit konnte die versuchte Normalisierung durch Apache umgangen werden.
Aber es gibt einen Haken
Wenn jemand versuchen würde, diese Schwachstelle direkt in seinem Browser auszunutzen, wäre er nicht erfolgreich. Das liegt daran, dass Browser auch versuchen, URLs, die an Server gesendet werden, zu normalisieren. Das bedeutet, dass sogar unsere doppelt kodierte Sequenz entfernt wird. Das bedeutet auch, dass wir nicht einfach einen Browser verwenden können, um dies zu demonstrieren.
Sie können cURL verwenden, um dies zu demonstrieren, indem Sie das Flag --path-as-is verwenden, das verhindert, dass die URL vor dem Senden normalisiert wird:
Prävention und Schadensbegrenzung
Um das Problem vollständig zu vermeiden, ist es wichtig, die neuesten Patches von Apache zu verwenden. Insbesondere sollten Sie mindestens ein Upgrade auf 2.4.51 durchführen. Es ist jedoch eine gute Praxis, regelmäßig zu aktualisieren, um auf dem neuesten Stand zu bleiben.
Um dieses Problem abzuschwächen, wenn Sie 2.4.49 verwenden, stellen Sie sicher, dass Sie Folgendes in Ihre Apache-Konfiguration aufgenommen haben:
Und um Remote Code Execution zu verhindern, deaktivieren Sie mod_cgi , wenn Sie es nicht verwenden.
Erleben Sie die Auswirkungen selbst
Möchten Sie herausfinden, was genau passiert ist und es selbst ausprobieren?
Inhaltsverzeichnis
Secure Code Warrior für Ihr Unternehmen da, um Ihnen zu helfen, Code während des gesamten Softwareentwicklungszyklus zu sichern und eine Kultur zu schaffen, in der Cybersicherheit an erster Stelle steht. Ganz gleich, ob Sie AppSec-Manager, Entwickler, CISO oder jemand anderes sind, der sich mit Sicherheit befasst, wir können Ihrem Unternehmen helfen, die mit unsicherem Code verbundenen Risiken zu reduzieren.
Eine Demo buchenHerunterladenRessourcen für den Einstieg
Themen und Inhalte der Securecode-Schulung
Unsere branchenführenden Inhalte werden ständig weiterentwickelt, um der sich ständig ändernden Softwareentwicklungslandschaft unter Berücksichtigung Ihrer Rolle gerecht zu werden. Themen, die alles von KI bis XQuery Injection abdecken und für eine Vielzahl von Rollen angeboten werden, von Architekten und Ingenieuren bis hin zu Produktmanagern und QA. Verschaffen Sie sich einen kleinen Einblick in das Angebot unseres Inhaltskatalogs nach Themen und Rollen.
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: Beat the Boss KI-Missionen jetzt auf Abruf verfügbar
Cybermon 2025 Beat the Boss ist jetzt das ganze Jahr über in SCW verfügbar. Setzt fortschrittliche KI/LLM-Sicherheitsanforderungen ein, um die sichere KI-Entwicklung in einem großen Maßstab zu stärken.
Cyber-Resilienz-Gesetz erklärt: Was das für die Entwicklung von Secure by Design-Software bedeutet
Erfahren Sie, was der EU Cyber Resilience Act (CRA) verlangt, für wen er gilt und wie sich Entwicklungsteams mit sicheren Methoden, der Vorbeugung von Sicherheitslücken und dem Aufbau von Fähigkeiten für Entwickler darauf vorbereiten können.
Enabler 1: Definierte und messbare Erfolgskriterien
Enabler 1 eröffnet unsere zehnteilige Reihe „Enabler of Success“ und zeigt, wie sichere Codierung mit Geschäftsergebnissen wie Risikominderung und Geschwindigkeit verbunden werden kann, um eine langfristige Programmreife zu erreichen.
