Nginx Alias La traversée est toujours un problème critique pour de nombreux projets
Récemment, la nouvelle a annoncé que certains serveurs nginx sont encore vulnérables à La technique "Traversée d'alias Nginx», qui a été proposé 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.
L'essence du problème est que fichiers pour les blocs avec la directive alias sont fournis en joignant le chemin demandé, après l'avoir fait correspondre au masque de la directive d'emplacement et découpé la partie du chemin spécifiée dans ce masque.
Le problème apparaît uniquement dans les configurations avec une directive "alias", comme dans la configuration Nginx, il existe une directive appelée "location" qui peut décrire comment l'accès à une URL particulière doit être géré, et est souvent utilisée pour attribuer des URL à des fichiers sur le serveur.
Dans le modèle qui utilise cet emplacement en combinaison avec l'alias, il est essentiel que les deux conditions "ne pas mettre de barre oblique à la fin de l'URL spécifiée par l'emplacement" et "mettre une barre oblique à la fin du chemin spécifié par l'alias" soient remplies. On dit que la vulnérabilité se produit.
Lors de la conférence BlackHat 2018, Orange Tsai a présenté ses recherches sur la rupture des analyseurs d'URL. Entre autres découvertes impressionnantes, il a démontré une technique découverte dans un défi HCTF CTF 2016, créé par @iaklis.
Pour que la technique soit applicable, les conditions suivantes doivent être remplies :
La directive d'emplacement ne doit pas avoir de barre oblique dans son chemin ;
Une directive d'alias doit être présente dans le contexte d'emplacement et doit se terminer par une barre oblique.
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 le fichier "/var/images/../test.txt" sera demandé en conséquence.
Par conséquent, les attaquants peuvent accéder à n'importe quel fichier dans le répertoire "/var", pas seulement les fichiers dans "/var/images/", par exemple, pour télécharger le journal nginx, vous pouvez envoyer la requête "/img../log/nginx /access.log".
Une analyse à partir de dépôts sur GitHub a montré que les erreurs dans la configuration de nginx à l'origine du problème sont toujours présentes dans de vrais projets.
Par exemple, un problème a été détecté 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 depuis /etc/bitwarden/attachments/), y compris la base de données qui y est stockée avec les mots de passe "vault.db", le certificat et les journaux, pour lesquels il suffisait d'envoyer des requêtes "vault.db", "identity.pfx", "api.log", etc.
Il est mentionné que la sévérité de cette vulnérabilité peut varier significativement selon le projet, d'un impact négligeable à un impact critique. L'étendue de son impact est principalement déterminée par le fait que le répertoire exposé contient des données sensibles susceptibles de faciliter de nouvelles attaques ou d'entraîner la divulgation d'informations privées.
Comme point de départ dans notre recherche de cette vulnérabilité, nous avons choisi d'explorer les référentiels GitHub populaires qui montraient ce problème. L'identification de cette vulnérabilité spécifique dans les environnements ayant accès au code source devient beaucoup plus faisable, principalement en raison de deux facteurs principaux :
Détection - L'utilisation d'outils d'analyse de code simples, tels que les recherches d'expressions régulières, nous permet d'identifier efficacement les fichiers de configuration Nginx potentiellement vulnérables au sein de ces projets.
Exploitation : Connaître le répertoire cible exact auquel un alias a été attribué nous permet de configurer une instance locale, d'examiner les répertoires alias à l'aide d'un shell local et de déterminer les fichiers accessibles via la vulnérabilité.
Il convient de mentionner que la méthode fonctionnait également avec le Google HPC Toolkit, où les requêtes étaient redirigées vers le répertoire d'intérêt pour obtenir une base de données avec une clé privée et des informations d'identification, un attaquant pouvait envoyer des requêtes "secret_key" et "db.sqlite3".
Enfin, si vous souhaitez en savoir plus, vous pouvez consulter les détails dans le lien suivant.