CTF_WRITEUPS-TryHackMe-CVE-2021-41773-

CTF_WRITEUPS/TryHackMe /CVE-2021-41773/

CVE-2021-41773/42013

Une petite explication d'un bug de traversée de chemin dans Apache et d'un correctif incomplet

Tâche 1 : Un peu de contexte...

Un bref historique

Le 5 octobre 2021, un CVE détaillant une attaque par traversée de chemin sur le serveur Apache HTTP v2.4.49 a été publié. Identifié sous le numéro CVE-2021-41773, il a été publié avec la description suivante :

Un défaut a été trouvé dans un changement apporté à la normalisation des chemins dans le serveur Apache HTTP 2.4.49. Un attaquant pourrait utiliser une attaque par traversée de chemin pour mapper des URL vers des fichiers en dehors de la racine de documents prévue. Si les fichiers en dehors de la racine de documents ne sont pas protégés par « require all denied », ces requêtes peuvent aboutir. De plus (sic), ce défaut pourrait divulguer le code source de fichiers interprétés comme les scripts CGI. Ce problème est connu pour être exploité dans la nature. Ce problème n'affecte qu'Apache 2.4.49 et pas les versions antérieures.

Décomposons cela et voyons ce que cela signifie réellement pour nous :

• Dans la première partie, on voit qu'un changement récent a exposé la faille. La normalisation des chemins signifie que l'on transforme un chemin donné en une forme canonique que le logiciel peut comprendre, et ainsi mapper vers le système de fichiers réel. Cela nous amène déjà à soupçonner une attaque par traversée de chemin qui peut potentiellement lire des fichiers non voulus.
• La partie suivante confirme nos soupçons : nous pouvons utiliser une attaque par traversée de chemin pour lire des ressources en dehors du périmètre prévu.
• On voit qu'une configuration très particulière est requise. Les fichiers en dehors de la racine de documents doivent explicitement avoir des autorisations accordées. Ce n'est pas la configuration par défaut et cela devrait donc rendre cet exploit inutile contre une grande partie des hôtes Apache (heureusement).
• La partie suivante parle des scripts CGI, ce qui nous amène à tort à croire que CGI doit peut-être être activé pour que cette attaque fonctionne ou que le chemin implique CGI d'une manière ou d'une autre.
• Même si notre configuration n'est pas directement affectée par ce bug, nous voudrons quand même mettre à jour les versions vulnérables dès que possible.

Beaucoup de correctifs plus tard...

Apache a donc corrigé ce bug et publié la v2.4.50. Fin de l'histoire, non ? Eh bien, pas tout à fait. Deux jours plus tard seulement, le 7 octobre, un nouveau CVE a été publié en référence au précédent. Celui-ci mentionne que le correctif de la précédente attaque par traversée de chemin était incomplet, et que l'on pouvait toujours traverser si le chemin en question utilisait une directive alias pour mapper ses URL vers le système de fichiers. Le CVE a reçu le numéro CVE-2021-42013, avec la description suivante :

Il a été constaté que le correctif de CVE-2021-41773 dans le serveur Apache HTTP 2.4.50 était insuffisant. Un attaquant pourrait utiliser une attaque par traversée de chemin pour mapper des URL vers des fichiers en dehors des répertoires configurés par des directives de type Alias. Si les fichiers en dehors de ces répertoires ne sont pas protégés par la configuration par défaut habituelle « require all denied », ces requêtes peuvent aboutir. Si les scripts CGI sont également activés pour ces « aliased pathes » (sic), cela pourrait permettre une exécution de code à distance. Ce problème n'affecte qu'Apache 2.4.49 et Apache 2.4.50, et pas les versions antérieures.

Comme avant, nous pouvons apprendre quelques choses ici :

• Bien que le premier exploit ait été soi-disant corrigé, il existe une autre entrée qui permet à la traversée de fonctionner (souvenez-vous-en pour plus tard).
• Maintenant, nous sommes limités aux directives de chemins aliasés.
• Les répertoires en dehors des chemins habituels nécessitent toujours des autorisations explicites.
• Si CGI est activé, on peut obtenir une RCE en plus de la simple divulgation 😲

Pendant que nous assimilons cette folie, nous examinerons la configuration requise dans la tâche suivante.

Répondez aux questions ci-dessous

1. Quelle version d'Apache httpd était initialement vulnérable à ce CVE ?

• 2.4.49

2. Cette vulnérabilité nécessite une mauvaise configuration inhabituelle pour être exploitable (Oui/Non)

• Oui

---

Tâche 2 Qu'est-ce que la traversée de chemin, de toute façon ?

Un soupçon de théorie

Un exploit de traversée de chemin est une attaque qui vise à accéder à des ressources normalement inaccessibles en abusant des failles dans la résolution et/ou la normalisation des chemins. On exploite généralement ce type d'attaque en remontant (ou en traversant) en arrière au-delà de la racine supposée à l'aide de la syntaxe ...

Normalisation ? C'est quoi ?

Normalement, pour qu'un code trouve un fichier, un chemin absolu est nécessaire. Appelons cela le chemin canonique. Lorsqu'un chemin relatif est donné à la place, il doit être normalisé en une forme canonique afin que les bibliothèques du système d'exploitation qui utilisent ce chemin puissent trouver la ressource en question. C'est une simplification excessive, bien sûr, mais l'essentiel reste le même.

En général, il existe des bibliothèques de plateforme pour faire cette normalisation à notre place, mais en C/C++, on doit généralement tout faire nous-mêmes. Cela peut offrir une certaine flexibilité, mais cela peut aussi facilement introduire des failles si notre implémentation n'est pas parfaite.

Normaliser les URL

Un serveur HTTP doit traduire une URL en chemin canonique sur le système de fichiers afin de trouver le bon fichier à servir. Bien qu'il existe certainement des filtres pour éviter de pouvoir traverser au-delà de la racine de documents, certains cas d'usage peuvent facilement être oubliés. Dans ce cas, l'exploitation tire parti non seulement de l'encodage URL (nous y reviendrons dans un instant) mais aussi d'une faille dans la normalisation des chemins du module Alias (soi-disant).

Un aparté sur l'encodage URL

Défini dans la RFC 3986, section 2, l'encodage URL est un schéma utilisé pour encoder les caractères spéciaux ou réservés dans une URL. Par exemple, les espaces dans une URL sont encodées sous la forme d'un caractère + (notamment dans les paramètres de requête). Si nous voulons encoder un vrai plus, nous devons l'encoder en utilisant ce que l'on appelle un « encodage en pourcentage ». Cela consiste simplement à préfixer le code hexadécimal US-ASCII du caractère avec un signe %. Dans notre exemple, le symbole + peut être encodé en %2B.

N'importe quel caractère peut être encodé en URL, et les URL entièrement encodées sont fonctionnellement équivalentes à leur version non encodée. D'après la RFC : Si deux URI ne diffèrent que par la casse des chiffres hexadécimaux utilisés dans les octets encodés en pourcentage, elles sont équivalentes.

Alors, que s'est-il passé avec Apache ?

Un changement récent dans le module de normalisation des chemins du serveur Apache a ensuite permis à une URL spécialement conçue de contourner les filtres et de traverser au-delà de la racine de documents, permettant une lecture arbitraire de fichiers sur le système si la configuration le permettait. En outre, si le module CGI était activé, l'exécution arbitraire de fichiers était également possible !

Répondez aux questions ci-dessous

1. Un exploit de traversée de chemin va (choisissez la meilleure réponse) :

A) Inclure des fichiers distants arbitraires à traiter sur le serveur. B) Inclure des fichiers locaux arbitraires à traiter sur le serveur. C) Permettre que des fichiers arbitraires soient exposés par le serveur. D) Aucune des réponses ci-dessus.

• C

2. Encodez en URL le symbole .

• %2E