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 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 unvollständig war. Wir haben eine Mission erstellt, um die Risiken in einer realen Umgebung zu demonstrieren. Probieren Sie es jetzt aus.
Secure Code Warrior ist für Ihr Unternehmen da, um Sie dabei zu unterstützen, Ihren Code über den gesamten Lebenszyklus der Softwareentwicklung hinweg zu sichern und eine Kultur zu schaffen, in der Cybersicherheit an erster Stelle steht. Ganz gleich, ob Sie AppSec-Manager, Entwickler, CISO oder ein anderer Sicherheitsverantwortlicher sind, wir können Ihrem Unternehmen helfen, die mit unsicherem Code verbundenen Risiken zu reduzieren.
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 unten stehenden Link und laden Sie die PDF-Datei dieser Ressource herunter.
Secure Code Warrior ist für Ihr Unternehmen da, um Sie dabei zu unterstützen, Ihren Code über den gesamten Lebenszyklus der Softwareentwicklung hinweg zu sichern und eine Kultur zu schaffen, in der Cybersicherheit an erster Stelle steht. Ganz gleich, ob Sie AppSec-Manager, Entwickler, CISO oder ein anderer Sicherheitsverantwortlicher sind, wir können Ihrem Unternehmen helfen, die mit unsicherem Code verbundenen Risiken zu reduzieren.
Bericht ansehenDemo 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?
Inhaltsübersicht
Secure Code Warrior ist für Ihr Unternehmen da, um Sie dabei zu unterstützen, Ihren Code über den gesamten Lebenszyklus der Softwareentwicklung hinweg zu sichern und eine Kultur zu schaffen, in der Cybersicherheit an erster Stelle steht. Ganz gleich, ob Sie AppSec-Manager, Entwickler, CISO oder ein anderer Sicherheitsverantwortlicher sind, wir können Ihrem Unternehmen helfen, die mit unsicherem Code verbundenen Risiken zu reduzieren.
Demo buchenHerunterladenRessourcen für den Einstieg
Überblick über das Risikomanagement für Entwickler
Das Risikomanagement für Entwickler ist ein ganzheitlicher und proaktiver Ansatz für die Anwendungssicherheit, der sich auf die Mitwirkenden am Code konzentriert und nicht auf die Bits und Bytes der Anwendungsschicht selbst.
Sicher durch Design: Definition von Best Practices, Befähigung von Entwicklern und Benchmarking von präventiven Sicherheitsergebnissen
In diesem Forschungspapier werden die Mitbegründer von Secure Code Warrior , Pieter Danhieux und Dr. Matias Madou, Ph.D., zusammen mit den Experten Chris Inglis, ehemaliger US National Cyber Director (jetzt strategischer Berater der Paladin Capital Group), und Devin Lynch, Senior Director, Paladin Global Institute, die wichtigsten Erkenntnisse aus mehr als zwanzig ausführlichen Interviews mit Sicherheitsverantwortlichen in Unternehmen, darunter CISOs, ein VP of Application Security und Software-Sicherheitsexperten, offenlegen.
Benchmarking von Sicherheitskompetenzen: Optimierung von Secure-by-Design im Unternehmen
Aussagekräftige Daten über den Erfolg von Secure-by-Design-Initiativen zu finden, ist bekanntermaßen schwierig. CISOs stehen oft vor der Herausforderung, den Return on Investment (ROI) und den Geschäftswert von Sicherheitsprogrammen sowohl auf Mitarbeiter- als auch auf Unternehmensebene nachzuweisen. Ganz zu schweigen davon, dass es für Unternehmen besonders schwierig ist, Erkenntnisse darüber zu gewinnen, wie ihre Organisation im Vergleich zu aktuellen Branchenstandards abschneidet. Die Nationale Cybersicherheitsstrategie des Präsidenten forderte die Beteiligten auf, "Sicherheit und Widerstandsfähigkeit durch Design" zu erreichen. Der Schlüssel zum Erfolg von Secure-by-Design-Initiativen liegt nicht nur darin, Entwicklern die nötigen Fähigkeiten zu vermitteln, um sicheren Code zu gewährleisten, sondern auch darin, den Aufsichtsbehörden zu versichern, dass diese Fähigkeiten vorhanden sind. In dieser Präsentation stellen wir eine Vielzahl von qualitativen und quantitativen Daten vor, die aus verschiedenen Primärquellen stammen, darunter interne Daten von über 250.000 Entwicklern, datengestützte Kundeneinblicke und öffentliche Studien. Auf der Grundlage dieser gesammelten Daten wollen wir eine Vision des aktuellen Stands von Secure-by-Design-Initiativen in verschiedenen Branchen vermitteln. Der Bericht zeigt auf, warum dieser Bereich derzeit nicht ausreichend genutzt wird, welche erheblichen Auswirkungen ein erfolgreiches Schulungsprogramm auf die Minderung von Cybersecurity-Risiken haben kann und welches Potenzial zur Beseitigung von Schwachstellen in einer Codebasis besteht.
Professionelle Dienstleistungen - Beschleunigen Sie mit Fachwissen
Das PSS-Team (Program Strategy Services) von Secure Code Warriorunterstützt Sie beim Aufbau, der Verbesserung und der Optimierung Ihres Programms für sichere Codierung. Ganz gleich, ob Sie neu anfangen oder Ihren Ansatz verfeinern möchten, unsere Experten bieten Ihnen maßgeschneiderte Beratung.
Ressourcen für den Einstieg
Aufgedeckt: Wie die Cyber-Industrie "Secure by Design" definiert
In unserem neuesten Whitepaper haben sich unsere Mitbegründer Pieter Danhieux und Dr. Matias Madou, Ph.D., mit über zwanzig Sicherheitsverantwortlichen in Unternehmen, darunter CISOs, AppSec-Leiter und Sicherheitsexperten, zusammengesetzt, um die wichtigsten Teile dieses Puzzles herauszufinden und die Realität hinter der Secure by Design-Bewegung aufzudecken. Die Sicherheitsteams haben ein gemeinsames Ziel, aber kein gemeinsames Regelwerk.
Wird Vibe Coding Ihre Codebasis in eine Verbindungsparty verwandeln?
Vibe Coding ist wie eine College-Verbindungsparty, und AI ist das Herzstück aller Festivitäten, das Fass. Es macht eine Menge Spaß, sich auszutoben, kreativ zu werden und zu sehen, wohin die eigene Fantasie einen führen kann, aber nach ein paar Bierfässern ist das Trinken (oder die Verwendung von KI) in Maßen zweifellos die sicherere langfristige Lösung.
Entwicklergesteuerte Kodierung.
Sicher ist sicher.
Setzen Sie sich noch heute mit uns in Verbindung und machen Sie Softwaresicherheit zu einem festen Bestandteil Ihres Entwicklungsprozesses.
