Einige Nginx-Server sind weiterhin anfällig für die Nginx-Alias-Traversal-Technik, die bereits 2018 auf der Blackhat-Konferenz vorgeschlagen wurde und den Zugriff auf Dateien und Verzeichnisse ermöglicht, die sich außerhalb des in der „Alias“-Direktive angegebenen Stammverzeichnisses befinden. Das Problem tritt nur in Konfigurationen mit einer „alias“-Direktive auf, die in einem „location“-Block platziert ist, dessen Parameter nicht mit einem „/“-Zeichen endet, während „alias“ mit einem „/“ endet.
Der Kern des Problems besteht darin, dass Dateien für Blöcke mit der Alias-Direktive bereitgestellt werden, indem der angeforderte Pfad angehängt wird, nachdem dieser mit der Maske aus der Location-Direktive verglichen und der in dieser Maske angegebene Teil des Pfads ausgeschnitten wurde. Für das oben gezeigte Beispiel einer anfälligen Konfiguration kann ein Angreifer die Datei „/img../test.txt“ anfordern und diese Anforderung wird unter die im Speicherort angegebene „/img“-Maske fallen, wonach der verbleibende Schwanz „.. /test.txt“ wird an den Pfad der Alias-Direktive „/var/images/“ angehängt und fordert schließlich die Datei „/var/images/../test.txt“ an. Somit können Angreifer auf alle Dateien im Verzeichnis „/var“ zugreifen und nicht nur auf Dateien in „/var/images/“. Um beispielsweise das Nginx-Protokoll herunterzuladen, können Sie die Anfrage „/img../log/“ senden. nginx/access.log".
In Konfigurationen, in denen der Wert der Alias-Direktive nicht mit einem „/“-Zeichen endet (z. B. „alias /var/images;“), kann der Angreifer nicht in das übergeordnete Verzeichnis wechseln, sondern ein anderes Verzeichnis in /var anfordern dessen Name mit dem in der Konfiguration angegebenen Namen beginnt. Wenn Sie beispielsweise „/img.old/test.txt“ anfordern, können Sie auf das Verzeichnis „var/images.old/test.txt“ zugreifen.
Eine Analyse von Repositories auf GitHub ergab, dass Fehler in der Nginx-Konfiguration, die zu dem Problem führten, in realen Projekten immer noch auftreten. Beispielsweise wurde das Problem im Backend des Bitwarden-Passwortmanagers identifiziert und konnte verwendet werden, um auf alle Dateien im Verzeichnis /etc/bitwarden zuzugreifen (Anforderungen für /attachments wurden von /etc/bitwarden/attachments/ ausgegeben), einschließlich des „Tresors“. . db“, Zertifikat und Protokolle, um diese zu erhalten, reichte es aus, Anfragen „/attachments../vault.db“, „/attachments../identity.pfx“, „/attachments../logs/api.log“ zu senden " usw. .P.
Die Methode funktionierte auch mit Google HPC Toolkit, das /static-Anfragen in das Verzeichnis „../hpc-toolkit/community/front-end/website/static/“ umleitete. Um eine Datenbank mit einem privaten Schlüssel und Anmeldeinformationen zu erhalten, könnte ein Angreifer Anfragen „/static../.secret_key“ und „/static../db.sqlite3“ senden.
Source: opennet.ru