Certains serveurs utilisant nginx restent vulnérables à la technique Nginx Alias Traversal, proposée lors de la conférence Blackhat en 2018, qui permet d’accéder à des fichiers et des répertoires situés en dehors du répertoire racine défini dans la directive « alias ». Le problème ne se manifeste que dans les configurations où la directive « alias » est placée à l'intérieur d'un bloc « location », et où son paramètre ne se termine pas par le caractère « / », tandis que l'« alias » se termine par « / ».
L'essence du problème est que les fichiers pour les blocs avec la directive alias sont fournis en attachant le chemin demandé, après avoir été mis en correspondance avec le masque de la directive location et en enlevant la partie spécifiée dans ce masque. Pour l'exemple de configuration vulnérable illustré ci-dessus, un attaquant peut demander le fichier « /img../test.txt », et cette demande sera couverte par le masque indiqué dans la location « /img », après quoi la partie restante « ../test.txt » sera attachée au chemin de la directive alias « /var/images/ », et finalement le fichier « /var/images/../test.txt » sera demandé. De cette manière, les attaquants peuvent accéder à n'importe quel fichier dans le répertoire « /var », et pas seulement aux fichiers dans « /var/images/ », par exemple, pour télécharger le journal nginx, une requête « /img../log/nginx/access.log » peut être envoyée.
Dans les configurations où la valeur de la directive alias ne se termine pas par le caractère « / » (par exemple, « alias /var/images; »), l'attaquant ne peut pas revenir au répertoire parent, mais il a la possibilité de 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 », on peut accéder au répertoire « var/images.old/test.txt ».
Une analyse des dépôts sur GitHub a montré que les erreurs de configuration qui mènent à ce problème se rencontrent encore dans des projets réels. Par exemple, un problème a été détecté dans le backend du gestionnaire de mots de passe Bitwarden et a pu être utilisé pour accéder à tous les fichiers dans le répertoire /etc/bitwarden (les requêtes /attachments étaient servies depuis /etc/bitwarden/attachments/), y compris la base de données des mots de passe « vault.db », le certificat et les journaux, ce qui nécessitait simplement d'envoyer les requêtes « /attachments../vault.db », « /attachments../identity.pfx », « /attachments../logs/api.log », etc.
La méthode a également fonctionné 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 la base de données avec la clé secrète et les informations d'identification, l'attaquant pouvait envoyer les requêtes « /static../.secret_key » et « /static../db.sqlite3 ».
Source : opennet.ru
