InfraFenceInfraFence

Live Security Operations

Commencer

CVE-2021-41773 : path traversal Apache 2.4.49, vérifier et corriger

Dernière mise à jour:

Apache HTTP Server 2.4.49 a modifié la façon dont il normalise les chemins, et ce changement laissait passer un point encodé (%2e). Une requête avec des segments .%2e/ dans son chemin pouvait alors atteindre des fichiers hors des dossiers que la configuration expose. Avec CGI activé sur un tel dossier, la même astuce exécute des programmes sur le serveur.

Seule la version 2.4.49 est concernée. Son correctif, 2.4.50, était lui-même incomplet (CVE-2021-42013) : la version à utiliser est donc 2.4.51 ou ultérieure.

En bref

CVE
CVE-2021-41773
Logiciel
Apache HTTP Server
Versions concernées
2.4.49 uniquement
Corrigé dans
2.4.50 (incomplet, voir CVE-2021-42013) ; passez à 2.4.51 ou ultérieur
Score CVSS
9.8 Critique (NVD, CVSS 3.1) · CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
CISA Known Exploited Vulnerabilities
Oui, ajoutée le 3 novembre 2021
Publiée par le NVD
5 octobre 2021
Correctif virtuel InfraFence
vp-cve-2021-41773 (ModSecurity id 9920001)

Ce qui est concerné

Apache 2.4.49 a été la version courante pendant environ trois semaines, en septembre et octobre 2021. On la trouve aujourd'hui surtout sur des serveurs compilés depuis les sources, dans des images de conteneurs de cette période, ou sur des systèmes qui n'ont pas été mis à jour depuis. La divulgation de fichiers ne fonctionne que là où les fichiers hors des dossiers exposés ne sont pas protégés par le Require all denied par défaut sur <Directory /> ; l'exécution de code nécessite en plus CGI (mod_cgi ou mod_cgid) sur un dossier avec alias.

Vérifier si un serveur est vulnérable

Vérifiez d'abord la version :

Debian / Ubuntu
apache2 -v
Famille RHEL
httpd -v
Compilé depuis les sources (préfixe par défaut)
/usr/local/apache2/bin/httpd -v

Tout ce qui n'est pas Apache/2.4.49 ou Apache/2.4.50 n'est pas concerné par cette faille. Sur ces deux versions, vérifiez la configuration de la racine du système de fichiers, qui doit refuser l'accès, et si un module CGI est chargé :

Toute distribution
sudo grep -rn -A3 '<Directory />' /etc/apache2/ /etc/httpd/ /usr/local/apache2/conf/ 2>/dev/null
Toute distribution
sudo apachectl -M 2>/dev/null | grep -i cgi

Les tentatives laissent des points encodés dans les journaux d'accès :

Journaux d'accès Apache
sudo grep -rhiE '\.%2e/|%2e\./|%2e%2e/|%%32%65|\.%%32' --include='*access*' --exclude='*.gz' /var/log/apache2 /var/log/httpd 2>/dev/null | tail -20

Corriger

Passez à 2.4.51 ou ultérieur. Avec le paquet de votre distribution (la mise à jour redémarre Apache : choisissez un moment calme) :

Debian / Ubuntu
sudo apt-get update
sudo apt-get install --only-upgrade apache2
apache2 -v
Famille RHEL
sudo dnf upgrade httpd
httpd -v

Un serveur compilé depuis les sources nécessite une nouvelle compilation à partir de la version 2.4 actuelle ; un conteneur nécessite une nouvelle image. Assurez-vous ensuite que la racine du système de fichiers refuse l'accès, comme dans la configuration par défaut, et rechargez :

httpd.conf / apache2.conf
<Directory />
    AllowOverride None
    Require all denied
</Directory>
Toute distribution
sudo apachectl configtest && sudo apachectl graceful

Attention: Si les journaux montrent des requêtes réussies (statut 200) avec des points encodés, considérez le serveur comme compromis : des fichiers comme /etc/passwd ou une configuration contenant des mots de passe ont pu être lus, et avec CGI un programme a pu s'exécuter.

Comment InfraFence la bloque pendant que vous mettez à jour

Le correctif virtuel pour CVE-2021-41773 est une règle ModSecurity sur le chemin brut de la requête, avant qu'Apache ne le décode : il bloque un chemin contenant un point encodé à côté d'un point (.%2e, %2e., %2e%2e) suivi d'une barre oblique, en clair ou encodée. Les URL normales ne contiennent jamais cette séquence.

Comment le correctif est appliqué

  1. L'agent note quels ports SSH et quels sites répondent.
  2. Il écrit la règle (identifiant ModSecurity 9920001) entre ses propres marqueurs dans son fichier ModSecurity, lance apachectl configtest et recharge Apache en douceur. Un test en échec remet le fichier précédent en place.
  3. Il vérifie que SSH et les sites répondent toujours, et retire le correctif sinon.
  4. Il vérifie que ModSecurity bloque réellement avec la règle, au moyen d'une requête de sonde locale inoffensive. Un ModSecurity en DetectionOnly se contente de journaliser : le correctif est alors retiré et signalé comme inefficace, jamais comme appliqué.

Chaque requête bloquée par le correctif est signalée avec CVE-2021-41773 (agent 1.0.37 ou ultérieur) : vous voyez les tentatives dans l'activité du serveur et sur la page Exploitation du tableau de bord, et vous savez ainsi que la vulnérabilité est tentée contre vous.

Attention: Un correctif virtuel bloque la forme connue de l'attaque sur les requêtes qui passent par Apache sur ce serveur. Il ne remplace pas la mise à jour : installez la version corrigée, puis retirez le correctif depuis Activité avec Annuler si vous n'en avez plus besoin.

Les correctifs virtuels nécessitent Apache avec ModSecurity, le réglage Autoriser les modifications de la configuration du serveur web, et aucun panneau d'hébergement ni outil de gestion de configuration aux commandes du serveur web ; ils font partie du plan Pro et d'AutoMode. Une personne les applique depuis l'analyse IA, ou AutoMode le fait. Voir Correctifs virtuels.

Sources

Les faits de cette page viennent de ces sources ; consultez-les pour les mises à jour.

Essayez gratuitement sur 1 serveur

Starter est gratuit pour un serveur, avec la protection complète et le blocage automatique. Sans carte bancaire.

Installez l'agent en root, avec votre jeton à la place de <TOKEN> :

curl -fsSL https://github.com/infrafence/infrafence-agent/releases/latest/download/install.sh | sudo bash -s -- --token <TOKEN>

Le jeton se crée dans le tableau de bord, dans Serveurs › Ajouter un serveur.