
Outil d'exploitation pour Apache 2.4.49-2.4.50, contournement de chemin et RCE (CVE-2021-41773, CVE-2021-42013). Analyse des listes d'URL, fonctionne avec et sans CGI, et automatise l'exploitation.
Attaque de traversée de chemin et RCE dans Apache/2.4.49-2.4.50
-> Prend une liste d'URLs
-> Fonctionne pour CGI et non-CGI
-> Fonctionne pour Apache/2.4.49 - 2.4.50
$ git clone https://github.com/CalfCrusher/Path-traversal-RCE-Apache-2.4.49-2.4.50-Exploit
$ cd Path-traversal-RCE-Apache-2.4.49-2.4.50-Exploit && pip3 install -r requirements.txt
$ python3 main.py urls.txt
Le 5 octobre 2021, un CVE détaillant une attaque de traversée de chemin sur Apache HTTP Server v2.4.49 a été publié. Identifié sous le numéro CVE-2021-41773, il a été publié avec la description suivante :
Une faille a été trouvée dans une modification apportée à la normalisation des chemins dans Apache HTTP Server 2.4.49.
Un attaquant pourrait utiliser une attaque de traversée de chemin pour mapper des URLs 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 réussir.
De plus (sic), cette faille pourrait divulguer la 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 que Apache 2.4.49 et non les versions antérieures.
Décomposons cela et voyons ce que cela signifie réellement pour nous :
D'après la première partie, nous voyons qu'un changement récent a exposé la faille. La normalisation des chemins signifie que nous transformons un chemin donné en une forme canonique que le logiciel peut comprendre, et ainsi le mapper au système de fichiers réel. Cela nous amène déjà à suspecter une attaque de traversée de chemin qui pourrait potentiellement lire des fichiers non prévus.
La partie suivante confirme nos soupçons, et nous sommes capables d'utiliser une attaque de traversée de chemin pour lire des ressources en dehors du périmètre prévu.
Nous voyons qu'une configuration très particulière est requise. Les fichiers en dehors de la racine de documents doivent explicitement se voir accorder des permissions. Ce n'est pas la configuration par défaut et cela devrait donc rendre cet exploit inutile contre un grand pourcentage 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.
Pour résumer, afin d'exploiter cette vulnérabilité, nous aurons besoin d'une configuration très inhabituelle sur notre serveur cible, et d'attaquer via un chemin spécifique. 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. Seulement 2 jours plus tard, le 7 octobre, un nouveau CVE a été publié citant le précédent. Celui-ci mentionne que le correctif pour l'attaque de traversée de chemin antérieure était incomplet, et que nous pouvions toujours traverser si le chemin en question utilisait une directive alias pour mapper ses URLs au système de fichiers. Le CVE a été identifié sous le numéro CVE-2021-42013, avec la description suivante :
Il a été constaté que le correctif pour CVE-2021-41773 dans Apache HTTP Server 2.4.50 était insuffisant.
Un attaquant pourrait utiliser une attaque de traversée de chemin pour mapper des URLs 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 réussir.
Si les scripts CGI sont également activés pour ces chemins aliasés (sic), cela pourrait permettre une exécution de code à distance. Ce problème n'affecte que Apache 2.4.49 et Apache 2.4.50 et non les versions antérieures.
Comme précédemment, nous pouvons apprendre quelques choses ici :
Bien que le premier exploit ait été soi-disant corrigé, il existe une autre entrée pour permettre à 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 permissions explicites.
Si CGI est activé, alors nous pouvons obtenir une RCE en plus d'une simple divulgation.
Veuillez noter que je ne suis pas responsable des dommages et des utilisations illégales. Ne soyez pas un imbécile !