Einige Server mit nginx bleiben anfällig für die Nginx Alias Traversal-Technik, die auf der Blackhat-Konferenz 2018 vorgestellt wurde. Diese Technik ermöglicht den Zugriff auf Dateien und Verzeichnisse, die außerhalb des Root-Verzeichnisses liegen, das in der „alias“-Direktive festgelegt ist. Das Problem tritt nur in Konfigurationen auf, in denen die „alias“-Direktive innerhalb eines „location“-Blocks platziert ist, dessen Parameter nicht mit dem Symbol „/“ endet, während „alias“ mit „/“ endet.
Das Kernproblem besteht darin, dass Dateien für Blöcke mit der alias-Direktive über die angehängte angeforderte Route zurückgegeben werden, nachdem sie mit dem Maskenmuster aus der location-Direktive abgeglichen und der in diesem Muster definierte Teil der Route entfernt wurde. Für das oben gezeigte Beispiel einer anfälligen Konfiguration könnte ein Angreifer die Datei „/img../test.txt“ anfordern. Dieser Antrag würde unter das in der location-Direktive angegebene Muster „/img“ fallen, wonach der verbleibende Teil „../test.txt“ an den Pfad aus der alias-Direktive „/var/images/“ angehängt wird. Infolgedessen würde die Datei „/var/images/../test.txt“ angefordert. Damit können Angreifer auf beliebige Dateien im Verzeichnis „/var“ zugreifen, nicht nur auf Dateien im „/var/images/“. Beispielsweise könnte eine Anfrage wie „/img../log/nginx/access.log“ gesendet werden, um das Nginx-Log herunterzuladen.
In Konfigurationen, in denen der Wert der Direktive alias nicht mit dem Zeichen „/“ endet (zum Beispiel „alias /var/images;“), kann der Angreifer nicht in das übergeordnete Verzeichnis wechseln, hat jedoch die Möglichkeit, ein anderes Verzeichnis in /var anzufordern, dessen Name mit dem in der Konfiguration angegebenen übereinstimmt. Beispielsweise kann durch die Anforderung von „/img.old/test.txt“ auf das Verzeichnis „var/images.old/test.txt“ zugegriffen werden.
Die Analyse von Repositories auf GitHub hat gezeigt, dass die konfigurationsbezogenen Fehler in nginx, die zu Problemen führen, weiterhin in realen Projekten vorkommen. Beispielsweise wurde ein Problem im Backend des Passwortmanagers Bitwarden festgestellt, das zum Zugriff auf alle Dateien im Verzeichnis /etc/bitwarden verwendet werden konnte (Anfragen an /attachments wurden aus /etc/bitwarden/attachments/ ausgeliefert), einschließlich der dort gespeicherten Datenbank mit Passwörtern „vault.db“, des Zertifikats und der Logs, deren Zugriff nur durch die Anforderung von „/attachments../vault.db“, „/attachments../identity.pfx“, „/attachments../logs/api.log“ usw. erforderlich war.
Die Methode funktionierte auch mit dem Google HPC Toolkit, in dem Anfragen an /static in das Verzeichnis „../hpc-toolkit/community/front-end/website/static/“ umgeleitet wurden. Um auf die Datenbank mit dem privaten Schlüssel und den Zugangsdaten zuzugreifen, konnte der Angreifer Anfragen wie „/static../.secret_key“ und „/static../db.sqlite3“ senden.
Quelle: opennet.ru
