Sicherheitsanfälligkeit von Nginx-Konfigurationen mit fehlerhaften Alias-Blockeinstellungen

Einige Server mit nginx sind anfällig für die Nginx Alias Traversal-Technik, die 2018 auf der Blackhat-Konferenz vorgestellt wurde und den Zugriff auf Dateien und Verzeichnisse ermöglicht, die außerhalb des in der Direktive „alias“ angegebenen Stammverzeichnisses liegen. Das Problem tritt nur in Konfigurationen auf, in denen die Direktive „alias“ innerhalb des „location“-Blocks platziert ist, deren Parameter nicht mit dem Zeichen „/“ endet, während „alias“ mit „/“ endet.

Das Wesentliche des Problems ist, dass Dateien für Blöcke mit der Direktive alias durch Anfügung des angeforderten Pfades zurückgegeben werden, nachdem sie mit dem Muster aus der Direktive location abgeglichen und der in diesem Muster angegebene Teil des Pfades entfernt wurde. Für das obige Beispiel der anfälligen Konfiguration kann ein Angreifer die Datei „/img.. /test.txt“ anfordern und dieser Request fällt unter das angegebene location-Muster „/img“, nach dem der verbleibende Rest „.. /test.txt“ an den Pfad aus der Direktive alias „/var/images/“ angehängt wird, sodass letztlich die Datei „/var/images/.. /test.txt“ angefordert wird. Damit kann ein Angreifer auf beliebige Dateien im Verzeichnis „/var“ zugreifen, und nicht nur auf Dateien in „/var/images/“, beispielsweise könnte für den Download des nginx-Logs die Anfrage „/img.. /log/nginx/access.log“ gesendet werden.

In Konfigurationen, in denen der Wert der Direktive alias nicht mit dem Zeichen „/“ endet (zum Beispiel „alias /var/images;“), kann ein Angreifer nicht in das übergeordnete Verzeichnis wechseln, hat aber die Möglichkeit, ein anderes Verzeichnis in /var anzufordern, dessen Name mit dem in der Konfiguration angegebenen übereinstimmt. Beispielsweise könnte durch das Anfordern von „/img.old/test.txt“ Zugang zum Verzeichnis „var/images.old/test.txt“ gewährt werden.

Die Analyse von Repositories auf GitHub hat gezeigt, dass die konfigurationsbedingten Fehler in nginx nach wie vor in realen Projekten vorkommen. Zum Beispiel wurde das Problem im Backend des Passwortmanagers Bitwarden identifiziert und könnte verwendet werden, um auf alle Dateien im Verzeichnis /etc/bitwarden zuzugreifen (Anfragen an /attachments wurden aus /etc/bitwarden/attachments/ zurückgegeben), einschließlich der darin gespeicherten Datenbank mit Passwörtern „vault.db“, Zertifikat und Logs, für deren Erhalt es ausreichte, die Anfragen „/attachments.. /vault.db“, „/attachments.. /identity.pfx“, „/attachments.. /logs/api.log“ usw. zu senden.

Die Methode funktionierte auch mit dem Google HPC Toolkit, bei 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 die Anfragen „/static.. /.secret_key“ und „/static.. /db.sqlite3“ senden.

Quelle: opennet.ru