Trouvé une vulnérabilité dans le serveur http Apache

Récemment, la nouvelle a annoncé que a trouvé un nouveau vecteur d'attaque contre le serveur http Apache, qui n'a pas été corrigé dans la mise à jour 2.4.50 et permet l'accès aux fichiers à partir de zones situées en dehors du répertoire racine du site.

De plus, les chercheurs ont trouvé un moyen qui, en présence de certaines configurations non standard, non seulement lire les fichiers système, mais aussi exécuter à distance votre code sur le serveur.

CVE-2021-41773 sur Apache HTTP Server 2.4.50 était insuffisant. Un attaquant pourrait utiliser une attaque de traversée de chemin pour mapper des URL vers des fichiers en dehors des répertoires configurés par des directives similaires aux alias. Si les fichiers en dehors de ces répertoires ne sont pas protégés par les paramètres par défaut habituels « exiger tout refusé », ces demandes peuvent aboutir. Si les scripts CGI sont également activés pour ces correctifs d'alias, cela pourrait permettre l'exécution de code à distance. Ce problème affecte uniquement Apache 2.4.49 et Apache 2.4.50 et non les versions antérieures.

En essence, le nouveau problème (déjà répertorié comme CVE-2021-42013) il est complètement similaire à la vulnérabilité d'origine (CVE-2021-41773) au 2.4.49, la seule différence réside dans un codage de caractères différent.

Et c'est en particulier, dans la version 2.4.50 la possibilité d'utiliser la séquence "% 2e" était bloquée pour encoder un point, mais ouie perdu la possibilité de double encodage : en précisant la séquence "%% 32% 65", le serveur décodé en "% 2e", puis en ".", c'est à dire Les caractères "../" pour aller au répertoire précédent peuvent être encodés en ". %% 32% 65 / ».

Les deux CVE sont en fait presque la même vulnérabilité de traversée de chemin (la seconde est le correctif incomplet pour la première). La traversée de chemin ne fonctionne qu'à partir d'un URI mappé (par exemple, via les directives Apache "Alias" ou "ScriptAlias"). DocumentRoot seul ne suffit pas

Concernant l'exploitation d'une vulnérabilité par l'exécution de code, c'est possible si mod_cgi est activé et un chemin de base est utilisé dans lequel les scripts CGI sont autorisés à s'exécuter (par exemple, si la directive ScriptAlias ​​​​est activée ou si l'indicateur ExecCGI est spécifié dans la directive Options).

Il est mentionné qu'une condition préalable à une attaque réussie est également de fournir explicitement dans la configuration d'Apache l'accès aux répertoires contenant des fichiers exécutables, tels que /bin, ou l'accès à la racine FS "/". Comme un tel accès n'est normalement pas fourni, une attaque par exécution de code est de peu d'utilité pour les systèmes réels.

En même temps, l'attaque sur l'obtention du contenu du fichier codes système arbitraires et textes source de scripts Web qui sont disponibles pour la lecture par l'utilisateur sous lequel le serveur http s'exécute est toujours d'actualité. Pour mener une telle attaque, il suffit d'avoir un répertoire sur le site configuré à l'aide des directives "Alias" ou "ScriptAlias" (DocumentRoot ne suffit pas), comme "cgi-bin".

En plus de cela, il mentionne que le problème affecte principalement les distributions mises à jour en permanence (Rolling Releases) telles que Fedora, Arch Linux et Gentoo, ainsi que les ports FreeBSD.

Alors que les distributions Linux basées sur des branches stables de distributions de serveurs telles que Debian, RHEL, Ubuntu et SUSE ne sont pas vulnérables. Le problème n'apparaît pas si l'accès aux répertoires est explicitement refusé à l'aide du paramètre « exiger tous les refus ».

Il convient également de mentionner que Les 6 et 7 octobre, Cloudflare a enregistré plus de 300 XNUMX tentatives d'exploitation de la vulnérabilité CVE-2021-41773 par jour. La plupart du temps, à la suite d'attaques automatisées, ils demandent le contenu de "/cgi-bin/.%2e/.git/config", "/cgi-bin/.%2e/app/etc/local.xml " , "/Cgi-bin/.% 2e/app/etc/env.php" et "/cgi-bin/.%2e/%2e%2e/%2e%2e/etc/passwd".

Le problème ne se manifeste que dans les versions 2.4.49 et 2.4.50, les versions précédentes de la vulnérabilité ne sont pas affectées. Pour corriger la nouvelle variante de la vulnérabilité, la version Apache httpd 2.4.51 a été rapidement formée.

Enfin Si vous souhaitez en savoir plus, vous pouvez vérifier les détails dans le lien suivant.


Le contenu de l'article adhère à nos principes de éthique éditoriale. Pour signaler une erreur, cliquez sur c'est par ici !.

Soyez le premier à commenter

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée.

*

*

  1. Responsable des données: Miguel Ángel Gatón
  2. Finalité des données: Contrôle du SPAM, gestion des commentaires.
  3. Légitimation: votre consentement
  4. Communication des données: Les données ne seront pas communiquées à des tiers sauf obligation légale.
  5. Stockage des données: base de données hébergée par Occentus Networks (EU)
  6. Droits: à tout moment, vous pouvez limiter, récupérer et supprimer vos informations.