Découvrez l'impact de la vulnérabilité de traversée de chemin responsable des récents problèmes d'Apache

Début octobre, Apache a publié la version 2.4.49 pour corriger une vulnérabilité de type « Path Traversal » et d'exécution de code à distance, puis la version 2.4.50 pour remédier au fait que le correctif de la version 2.4.49 était incomplet. Vous avez peut-être entendu parler sur les réseaux sociaux de l'importance de mettre à jour vers la dernière version pour éviter ces risques, étant donné qu'Apache propulse 25 % d'Internet selon certaines estimations. Mais qu'en est-il vraiment ? Quel est le niveau de risque ici ?

Pourquoi ne pas essayer par vous-même ?

Nous avons créé une mission pour démontrer ces risques dans un environnement réel et l'avons rendue publique pour que tout le monde puisse l'essayer. Dans cette mission, nous vous expliquerons comment la vulnérabilité de type « Path Traversal » peut affecter votre infrastructure et vos applications. Cliquez ci-dessous pour vous lancer immédiatement, ou continuez votre lecture pour en savoir plus sur cette vulnérabilité.

À propos de la vulnérabilité de type « Path Traversal »

La vulnérabilité a été introduite dans la version 2.4.49 (en raison d'une modification de la fonction de normalisation des URL), où une nouvelle fonction de normalisation de chemin a été ajoutée. Malheureusement, celle-ci ne parvenait pas à normaliser correctement les chemins encodés en URL. Cela permet de mener une attaque par traversée de répertoire si la configuration suivante n'est pas présente :

Et si mod_cgi est activé, elle peut également être exploitée pour une exécution de code à distance. Mais commençons par nous pencher sur l'encodage d'URL pour mieux comprendre ce qui a échoué.

Encodage d'URL

Fondamentalement, la vulnérabilité survient en raison d'un manque de prise en compte des URL avec encodage. La nouvelle fonction de normalisation de chemin n'a pas entièrement géré les cas où les points étaient encodés en URL.

N'oubliez pas que pour mener une attaque par traversée de répertoire, vous devez traverser avec la séquence ../. La fonction de normalisation, cependant, est assez intelligente pour supprimer cela. Alors, que faire ? Vous pouvez encoder en URL un .(point) en %2e, et utiliser une séquence comme .%2e/. Cela fonctionnerait dans de nombreux cas contre Apache 2.4.40. Mais vous pouvez aller encore plus loin et utiliser un double encodage. La version encodée en URL de .%2e/ est .%252e/. Cela a permis de contourner la tentative de normalisation par Apache.

Mais il y a un piège

Si quelqu'un voulait essayer d'exploiter cette vulnérabilité directement depuis son navigateur, il n'y parviendrait pas. C'est parce que les navigateurs tentent également de normaliser les URL envoyées aux serveurs. Cela signifie que même notre séquence doublement encodée sera supprimée. Cela signifie aussi que nous ne pouvons pas simplement utiliser un navigateur pour démontrer cela.

Vous pouvez utiliser cURL pour le démontrer en utilisant l'option --path-as-is , qui l'empêche de normaliser l'URL avant de l'envoyer :

Prévention et atténuation

Pour prévenir totalement ce problème, il est important de rester à jour avec les derniers correctifs d'Apache. Plus précisément, vous devrez mettre à niveau vers la version 2.4.51 au minimum. Mais il est recommandé d'effectuer des mises à jour régulières pour rester protégé.

Pour atténuer ce problème si vous utilisez la version 2.4.49, assurez-vous d'avoir inclus ce qui suit dans votre configuration Apache :

Et pour prévenir l'exécution de code à distance, désactivez mod_cgi si vous ne l'utilisez pas.

Découvrez l'impact par vous-même

Vous souhaitez comprendre ce qui s'est passé et tester par vous-même ?

‍