Blog

Découvrez l'impact de la vulnérabilité Path Traversal Vulnerability à l'origine des récents déboires d'Apache.

Charlie Eriksen
Publié le 18 octobre 2021

Au début du mois d'octobre, Apache a publié la version 2.4.49 pour corriger une vulnérabilité de type "Path Traversal and Remote Code Execution", puis la version 2.4.50 pour remédier au fait que la correction de la version 2.4.49 était incomplète. Vous avez peut-être entendu parler sur les médias sociaux de l'importance de mettre à jour la dernière version pour éviter ces risques, étant donné qu'Apache alimente 25 % de l'internet selon certaines estimations. Mais qu'en est-il ? Quel est le niveau de risque ?

Pourquoi ne pas l'essayer vous-même ? 

Nous avons conçu une mission pour démontrer les risques dans un environnement réel et nous l'avons rendue publique pour que tout le monde puisse l'essayer. Dans cette mission, nous vous expliquons comment la vulnérabilité Path Traversal peut avoir un impact sur votre infrastructure et vos applications. Cliquez ci-dessous pour entrer directement dans le vif du sujet, ou continuez à lire pour en savoir plus sur la vulnérabilité en détail.

Bannière qui dit d'essayer la mission Apache CVE-2021-41773
Aller à la mission publique


À propos de la vulnérabilité liée au détournement de chemin 

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 des chemins a été introduite. Malheureusement, elle n'a pas réussi à normaliser correctement les chemins codés en URL. Il est donc possible de mener une attaque par traversée de chemin si la configuration suivante n'est pas présente :

Refuser ou autoriser l'accès au système de fichiers du répertoire


Et si mod_cgi est activé, il peut également être exploité pour créer une vulnérabilité d'exécution de code à distance. Mais penchons-nous d'abord sur l'encodage des URL pour mieux comprendre ce qui a mal tourné.

Codage de l'URL

Dans sa forme la plus élémentaire, la vulnérabilité est due à un manque de prise en compte des URL codées. La fonction de normalisation des chemins nouvellement introduite n'a pas entièrement traité les cas où les points étaient codés en URL. 

Rappelez-vous que pour mener une attaque par traversée de chemin, vous devez traverser avec la séquence ../. La fonction de normalisation est cependant assez intelligente pour supprimer cette séquence. Que faire alors ? Vous pouvez coder un .(Point) en URL jusqu'à %2e, et utiliser une séquence comme .%2e/. Cela fonctionnerait dans de nombreux cas avec Apache 2.4.40. Mais vous pouvez aussi aller plus loin et le coder doublement. La version codée en URL de .%2e/ est .%252e/. Cela a permis de contourner la tentative de normalisation d'Apache.

Mais il y a un hic

Si quelqu'un voulait essayer d'exploiter cette vulnérabilité directement dans son navigateur, il n'y parviendrait pas. En effet, les navigateurs tentent également de normaliser les URL envoyées aux serveurs. Cela signifie que même notre séquence doublement codée sera supprimée. Cela signifie également que nous ne pouvons pas nous contenter d'utiliser un navigateur pour le démontrer.

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

Curl path as is code with link

Prévention et atténuation

Pour éviter complètement ce problème, il est important de rester à jour avec les derniers correctifs d'Apache. En particulier, vous devez mettre à jour vers la version 2.4.51 au minimum. Mais il est conseillé de procéder à des mises à jour régulières pour rester à jour.

Pour éviter ce problème, si vous utilisez la version 2.4.49, assurez-vous d'avoir inclus les éléments suivants dans votre configuration Apache :

Balises de code de répertoire avec les règles "allowoverride none" et "require all denied".

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

Faites l'expérience de l'impact par vous-même

Vous souhaitez savoir exactement ce qui s'est passé et l'essayer vous-même ? 


Voir la ressource
Voir la ressource

Début octobre, Apache a publié la version 2.4.49 pour corriger une vulnérabilité de type "Path Traversal and Remote Code Execution", puis la version 2.4.50 pour remédier au fait que la correction était incomplète. Nous avons créé une mission pour démontrer les risques dans un environnement réel. Essayez-la dès maintenant.

Vous souhaitez en savoir plus ?

Secure Code Warrior est là pour vous aider à sécuriser le code tout au long du cycle de vie du développement logiciel et à créer une culture dans laquelle la cybersécurité est une priorité. Que vous soyez responsable AppSec, développeur, CISO ou toute autre personne impliquée dans la sécurité, nous pouvons aider votre organisation à réduire les risques associés à un code non sécurisé.

Réservez une démonstration
Partager sur :
Auteur
Charlie Eriksen
Publié le 18 octobre 2021

Partager sur :

Au début du mois d'octobre, Apache a publié la version 2.4.49 pour corriger une vulnérabilité de type "Path Traversal and Remote Code Execution", puis la version 2.4.50 pour remédier au fait que la correction de la version 2.4.49 était incomplète. Vous avez peut-être entendu parler sur les médias sociaux de l'importance de mettre à jour la dernière version pour éviter ces risques, étant donné qu'Apache alimente 25 % de l'internet selon certaines estimations. Mais qu'en est-il ? Quel est le niveau de risque ?

Pourquoi ne pas l'essayer vous-même ? 

Nous avons conçu une mission pour démontrer les risques dans un environnement réel et nous l'avons rendue publique pour que tout le monde puisse l'essayer. Dans cette mission, nous vous expliquons comment la vulnérabilité Path Traversal peut avoir un impact sur votre infrastructure et vos applications. Cliquez ci-dessous pour entrer directement dans le vif du sujet, ou continuez à lire pour en savoir plus sur la vulnérabilité en détail.

Bannière qui dit d'essayer la mission Apache CVE-2021-41773
Aller à la mission publique


À propos de la vulnérabilité liée au détournement de chemin 

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 des chemins a été introduite. Malheureusement, elle n'a pas réussi à normaliser correctement les chemins codés en URL. Il est donc possible de mener une attaque par traversée de chemin si la configuration suivante n'est pas présente :

Refuser ou autoriser l'accès au système de fichiers du répertoire


Et si mod_cgi est activé, il peut également être exploité pour créer une vulnérabilité d'exécution de code à distance. Mais penchons-nous d'abord sur l'encodage des URL pour mieux comprendre ce qui a mal tourné.

Codage de l'URL

Dans sa forme la plus élémentaire, la vulnérabilité est due à un manque de prise en compte des URL codées. La fonction de normalisation des chemins nouvellement introduite n'a pas entièrement traité les cas où les points étaient codés en URL. 

Rappelez-vous que pour mener une attaque par traversée de chemin, vous devez traverser avec la séquence ../. La fonction de normalisation est cependant assez intelligente pour supprimer cette séquence. Que faire alors ? Vous pouvez coder un .(Point) en URL jusqu'à %2e, et utiliser une séquence comme .%2e/. Cela fonctionnerait dans de nombreux cas avec Apache 2.4.40. Mais vous pouvez aussi aller plus loin et le coder doublement. La version codée en URL de .%2e/ est .%252e/. Cela a permis de contourner la tentative de normalisation d'Apache.

Mais il y a un hic

Si quelqu'un voulait essayer d'exploiter cette vulnérabilité directement dans son navigateur, il n'y parviendrait pas. En effet, les navigateurs tentent également de normaliser les URL envoyées aux serveurs. Cela signifie que même notre séquence doublement codée sera supprimée. Cela signifie également que nous ne pouvons pas nous contenter d'utiliser un navigateur pour le démontrer.

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

Curl path as is code with link

Prévention et atténuation

Pour éviter complètement ce problème, il est important de rester à jour avec les derniers correctifs d'Apache. En particulier, vous devez mettre à jour vers la version 2.4.51 au minimum. Mais il est conseillé de procéder à des mises à jour régulières pour rester à jour.

Pour éviter ce problème, si vous utilisez la version 2.4.49, assurez-vous d'avoir inclus les éléments suivants dans votre configuration Apache :

Balises de code de répertoire avec les règles "allowoverride none" et "require all denied".

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

Faites l'expérience de l'impact par vous-même

Vous souhaitez savoir exactement ce qui s'est passé et l'essayer vous-même ? 


Voir la ressource
Voir la ressource

Remplissez le formulaire ci-dessous pour télécharger le rapport

Nous aimerions que vous nous autorisiez à vous envoyer des informations sur nos produits et/ou sur des sujets liés au codage sécurisé. Nous traiterons toujours vos données personnelles avec le plus grand soin et ne les vendrons jamais à d'autres entreprises à des fins de marketing.

Soumettre
Pour soumettre le formulaire, veuillez activer les cookies "Analytics". N'hésitez pas à les désactiver à nouveau une fois que vous aurez terminé.

Au début du mois d'octobre, Apache a publié la version 2.4.49 pour corriger une vulnérabilité de type "Path Traversal and Remote Code Execution", puis la version 2.4.50 pour remédier au fait que la correction de la version 2.4.49 était incomplète. Vous avez peut-être entendu parler sur les médias sociaux de l'importance de mettre à jour la dernière version pour éviter ces risques, étant donné qu'Apache alimente 25 % de l'internet selon certaines estimations. Mais qu'en est-il ? Quel est le niveau de risque ?

Pourquoi ne pas l'essayer vous-même ? 

Nous avons conçu une mission pour démontrer les risques dans un environnement réel et nous l'avons rendue publique pour que tout le monde puisse l'essayer. Dans cette mission, nous vous expliquons comment la vulnérabilité Path Traversal peut avoir un impact sur votre infrastructure et vos applications. Cliquez ci-dessous pour entrer directement dans le vif du sujet, ou continuez à lire pour en savoir plus sur la vulnérabilité en détail.

Bannière qui dit d'essayer la mission Apache CVE-2021-41773
Aller à la mission publique


À propos de la vulnérabilité liée au détournement de chemin 

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 des chemins a été introduite. Malheureusement, elle n'a pas réussi à normaliser correctement les chemins codés en URL. Il est donc possible de mener une attaque par traversée de chemin si la configuration suivante n'est pas présente :

Refuser ou autoriser l'accès au système de fichiers du répertoire


Et si mod_cgi est activé, il peut également être exploité pour créer une vulnérabilité d'exécution de code à distance. Mais penchons-nous d'abord sur l'encodage des URL pour mieux comprendre ce qui a mal tourné.

Codage de l'URL

Dans sa forme la plus élémentaire, la vulnérabilité est due à un manque de prise en compte des URL codées. La fonction de normalisation des chemins nouvellement introduite n'a pas entièrement traité les cas où les points étaient codés en URL. 

Rappelez-vous que pour mener une attaque par traversée de chemin, vous devez traverser avec la séquence ../. La fonction de normalisation est cependant assez intelligente pour supprimer cette séquence. Que faire alors ? Vous pouvez coder un .(Point) en URL jusqu'à %2e, et utiliser une séquence comme .%2e/. Cela fonctionnerait dans de nombreux cas avec Apache 2.4.40. Mais vous pouvez aussi aller plus loin et le coder doublement. La version codée en URL de .%2e/ est .%252e/. Cela a permis de contourner la tentative de normalisation d'Apache.

Mais il y a un hic

Si quelqu'un voulait essayer d'exploiter cette vulnérabilité directement dans son navigateur, il n'y parviendrait pas. En effet, les navigateurs tentent également de normaliser les URL envoyées aux serveurs. Cela signifie que même notre séquence doublement codée sera supprimée. Cela signifie également que nous ne pouvons pas nous contenter d'utiliser un navigateur pour le démontrer.

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

Curl path as is code with link

Prévention et atténuation

Pour éviter complètement ce problème, il est important de rester à jour avec les derniers correctifs d'Apache. En particulier, vous devez mettre à jour vers la version 2.4.51 au minimum. Mais il est conseillé de procéder à des mises à jour régulières pour rester à jour.

Pour éviter ce problème, si vous utilisez la version 2.4.49, assurez-vous d'avoir inclus les éléments suivants dans votre configuration Apache :

Balises de code de répertoire avec les règles "allowoverride none" et "require all denied".

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

Faites l'expérience de l'impact par vous-même

Vous souhaitez savoir exactement ce qui s'est passé et l'essayer vous-même ? 


Accès aux ressources

Cliquez sur le lien ci-dessous et téléchargez le PDF de cette ressource.

Secure Code Warrior est là pour vous aider à sécuriser le code tout au long du cycle de vie du développement logiciel et à créer une culture dans laquelle la cybersécurité est une priorité. Que vous soyez responsable AppSec, développeur, CISO ou toute autre personne impliquée dans la sécurité, nous pouvons aider votre organisation à réduire les risques associés à un code non sécurisé.

Voir le rapportRéservez une démonstration
Partager sur :
Vous souhaitez en savoir plus ?

Partager sur :
Auteur
Charlie Eriksen
Publié le 18 octobre 2021

Partager sur :

Au début du mois d'octobre, Apache a publié la version 2.4.49 pour corriger une vulnérabilité de type "Path Traversal and Remote Code Execution", puis la version 2.4.50 pour remédier au fait que la correction de la version 2.4.49 était incomplète. Vous avez peut-être entendu parler sur les médias sociaux de l'importance de mettre à jour la dernière version pour éviter ces risques, étant donné qu'Apache alimente 25 % de l'internet selon certaines estimations. Mais qu'en est-il ? Quel est le niveau de risque ?

Pourquoi ne pas l'essayer vous-même ? 

Nous avons conçu une mission pour démontrer les risques dans un environnement réel et nous l'avons rendue publique pour que tout le monde puisse l'essayer. Dans cette mission, nous vous expliquons comment la vulnérabilité Path Traversal peut avoir un impact sur votre infrastructure et vos applications. Cliquez ci-dessous pour entrer directement dans le vif du sujet, ou continuez à lire pour en savoir plus sur la vulnérabilité en détail.

Bannière qui dit d'essayer la mission Apache CVE-2021-41773
Aller à la mission publique


À propos de la vulnérabilité liée au détournement de chemin 

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 des chemins a été introduite. Malheureusement, elle n'a pas réussi à normaliser correctement les chemins codés en URL. Il est donc possible de mener une attaque par traversée de chemin si la configuration suivante n'est pas présente :

Refuser ou autoriser l'accès au système de fichiers du répertoire


Et si mod_cgi est activé, il peut également être exploité pour créer une vulnérabilité d'exécution de code à distance. Mais penchons-nous d'abord sur l'encodage des URL pour mieux comprendre ce qui a mal tourné.

Codage de l'URL

Dans sa forme la plus élémentaire, la vulnérabilité est due à un manque de prise en compte des URL codées. La fonction de normalisation des chemins nouvellement introduite n'a pas entièrement traité les cas où les points étaient codés en URL. 

Rappelez-vous que pour mener une attaque par traversée de chemin, vous devez traverser avec la séquence ../. La fonction de normalisation est cependant assez intelligente pour supprimer cette séquence. Que faire alors ? Vous pouvez coder un .(Point) en URL jusqu'à %2e, et utiliser une séquence comme .%2e/. Cela fonctionnerait dans de nombreux cas avec Apache 2.4.40. Mais vous pouvez aussi aller plus loin et le coder doublement. La version codée en URL de .%2e/ est .%252e/. Cela a permis de contourner la tentative de normalisation d'Apache.

Mais il y a un hic

Si quelqu'un voulait essayer d'exploiter cette vulnérabilité directement dans son navigateur, il n'y parviendrait pas. En effet, les navigateurs tentent également de normaliser les URL envoyées aux serveurs. Cela signifie que même notre séquence doublement codée sera supprimée. Cela signifie également que nous ne pouvons pas nous contenter d'utiliser un navigateur pour le démontrer.

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

Curl path as is code with link

Prévention et atténuation

Pour éviter complètement ce problème, il est important de rester à jour avec les derniers correctifs d'Apache. En particulier, vous devez mettre à jour vers la version 2.4.51 au minimum. Mais il est conseillé de procéder à des mises à jour régulières pour rester à jour.

Pour éviter ce problème, si vous utilisez la version 2.4.49, assurez-vous d'avoir inclus les éléments suivants dans votre configuration Apache :

Balises de code de répertoire avec les règles "allowoverride none" et "require all denied".

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

Faites l'expérience de l'impact par vous-même

Vous souhaitez savoir exactement ce qui s'est passé et l'essayer vous-même ? 


Table des matières

Voir la ressource
Vous souhaitez en savoir plus ?

Secure Code Warrior est là pour vous aider à sécuriser le code tout au long du cycle de vie du développement logiciel et à créer une culture dans laquelle la cybersécurité est une priorité. Que vous soyez responsable AppSec, développeur, CISO ou toute autre personne impliquée dans la sécurité, nous pouvons aider votre organisation à réduire les risques associés à un code non sécurisé.

Réservez une démonstrationTélécharger
Partager sur :
Centre de ressources

Ressources pour vous aider à démarrer

Plus d'articles
Centre de ressources

Ressources pour vous aider à démarrer

Plus d'articles