Certains serveurs avec nginx restent vulnérables à la technique Nginx Alias Traversal, qui a été proposée lors de la conférence Blackhat en 2018 et permet d'accéder aux fichiers et répertoires situés en dehors du répertoire racine spécifié dans la directive "alias". Le problème n'apparaît que dans les configurations avec une directive "alias" placée à l'intérieur du bloc "location", dont le paramètre ne se termine pas par un caractère "/", tandis que "alias" se termine par "/".
L'essence du problème est que les fichiers pour les blocs avec la directive alias sont donnés en attachant le chemin demandé, après l'avoir mis en correspondance avec le masque de la directive location et en supprimant la partie du chemin spécifiée dans ce masque. Pour l'exemple de configuration vulnérable ci-dessus, un attaquant peut demander le fichier "/img../test.txt" et cette requête correspondra au masque spécifié à l'emplacement "/img", après quoi la queue restante "../test.txt" sera attachée au chemin de la directive d'alias "/var/images/" et en conséquence le fichier "/var/images/../test.txt" sera demandé. Ainsi, les attaquants peuvent accéder à tous les fichiers du répertoire "/var", et pas seulement aux fichiers de "/var/images/", par exemple, pour télécharger le log nginx, vous pouvez envoyer la requête "/img../log/nginx/access.log".
Dans les configurations où la valeur de la directive alias ne se termine pas par un caractère "/" (par exemple, "alias /var/images;"), l'attaquant ne peut pas passer au répertoire parent, mais peut demander un autre répertoire dans /var dont le nom commence par celui spécifié dans la configuration. Par exemple, en demandant "/img.old/test.txt", vous pouvez accéder au répertoire "var/images.old/test.txt".
Une analyse des référentiels sur GitHub a montré que les erreurs de configuration nginx à l'origine du problème se retrouvent toujours dans les projets réels. Par exemple, la présence d'un problème a été détectée dans le backend du gestionnaire de mots de passe Bitwarden et pouvait être utilisé pour accéder à tous les fichiers du répertoire /etc/bitwarden (les requêtes pour /attachments étaient émises à partir de /etc/bitwarden/attachments/), y compris la base de données qui y est stockée avec les mots de passe "vault.db", un certificat et des journaux, pour lesquels il suffisait d'envoyer des requêtes "/attachments../vault.db", "/attachments../identity.pfx", "/ pièces jointes../logs/api.log" etc.
La méthode fonctionnait également avec Google HPC Toolkit, où les requêtes /static étaient redirigées vers le répertoire "../hpc-toolkit/community/front-end/website/static/". Pour obtenir une base de données avec une clé privée et des informations d'identification, un attaquant pourrait envoyer des requêtes "/static../.secret_key" et "/static../db.sqlite3".
Source: opennet.ru