Erleben Sie die Auswirkungen der Path-Traversal-Schwachstelle, die für die jüngsten Apache-Probleme verantwortlich ist.

Anfang Oktober veröffentlichte Apache die Version 2.4.49, um eine Path-Traversal- und Remote-Code-Execution-Schwachstelle zu beheben, gefolgt von Version 2.4.50, da der Fix in 2.4.49 unvollständig war. Vielleicht haben Sie in den sozialen Medien bereits Diskussionen darüber verfolgt, 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 was hat es damit auf sich? Wie groß ist das Risiko wirklich?

Warum probieren Sie es nicht selbst aus?

Wir haben eine Mission erstellt, um die Risiken in einer realen Umgebung zu demonstrieren, und diese für alle öffentlich zugänglich gemacht. In dieser Mission zeigen wir Ihnen, wie sich die Path-Traversal-Schwachstelle auf Ihre Infrastruktur und Anwendungen auswirken kann. Klicken Sie unten, um direkt loszulegen, oder lesen Sie weiter, um mehr über die Schwachstelle im Detail zu erfahren.

Über die Path-Traversal-Schwachstelle

Die Schwachstelle wurde mit der Version 2.4.49 eingeführt (aufgrund einer Änderung der URL-Normalisierungsfunktion), bei der eine neue Pfad-Normalisierungsfunktion implementiert wurde. Leider konnte diese URL-kodierte Pfade nicht korrekt normalisieren. Dies ermöglicht einen Path-Traversal-Angriff, sofern die folgende Konfiguration nicht vorhanden ist:

Und wenn mod_cgi aktiviert ist, kann dies sogar zu einer Remote-Code-Execution-Schwachstelle führen. Doch lassen Sie uns zunächst einen Blick auf die URL-Kodierung werfen, um besser zu verstehen, was schiefgelaufen ist.

URL-Kodierung

Im Grunde genommen entsteht die Schwachstelle dadurch, dass URLs mit URL-Kodierung nicht ausreichend berücksichtigt wurden. Die neu eingeführte Pfad-Normalisierungsfunktion konnte Fälle, in denen Punkte URL-kodiert waren, nicht vollständig verarbeiten.

Denken Sie daran, dass Sie für einen Path-Traversal-Angriff die Sequenz ../ verwenden müssen. Die Normalisierungsfunktion ist jedoch intelligent genug, um diese zu entfernen. Was tun Sie also? Sie können einen . (Punkt) zu %2e URL-kodieren und eine Sequenz wie .%2e/ verwenden. Das würde in vielen Fällen gegen Apache 2.4.40 funktionieren. Sie können aber noch einen Schritt weiter gehen und eine doppelte Kodierung verwenden. Die URL-kodierte Version von .%2e/ ist .%252e/. Dies konnte die von Apache versuchte Normalisierung weiter umgehen.

Aber es gibt einen Haken

Wenn jemand versuchen würde, diese Schwachstelle direkt über den Browser auszunutzen, wäre er nicht erfolgreich. Das liegt daran, dass Browser ebenfalls versuchen, URLs zu normalisieren, bevor sie an Server gesendet werden. Das bedeutet, dass selbst unsere doppelt kodierte Sequenz entfernt wird. Es 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 nutzen, das verhindert, dass die URL vor dem Senden normalisiert wird:

Prävention und Schadensbegrenzung

Um das Problem vollständig zu verhindern, ist es wichtig, die neuesten Patches von Apache zu installieren. Insbesondere sollten Sie mindestens auf Version 2.4.51 aktualisieren. Es ist jedoch generell eine bewährte Praxis, regelmäßige Updates durchzuführen, um auf dem neuesten Stand zu bleiben.

Um dieses Problem zu entschärfen, falls Sie Version 2.4.49 verwenden, stellen Sie sicher, dass Sie Folgendes in Ihre Apache-Konfiguration aufgenommen haben:

Um Remote Code Execution zu verhindern, deaktivieren Sie mod_cgi , falls Sie es nicht benötigen.

Erleben Sie die Auswirkungen selbst

Möchten Sie genau erfahren, was passiert ist, und es selbst ausprobieren? 

‍