juanschallibaum/cve-2024-38473-nuclei-templateModèle Nuclei pour détecter les serveurs Apache vulnérables à CVE-2024-38473
Modèle Nuclei conçu pour détecter les serveurs Apache vulnérables à CVE-2024-38473. Il identifie d'abord les serveurs exécutant Apache < 2.4.60 avec les paramètres par défaut de PHP-FPM. Ensuite, il effectue du fuzzing pour trouver des fichiers PHP potentiellement protégés par des ACL qui pourraient être contournés en raison de cette vulnérabilité.
Pour utiliser ce modèle Nuclei, vous devez cloner le dépôt. Vous pouvez le faire en exécutant la commande suivante :
git clone https://github.com/juanschallibaum/CVE-2024-38473-Nuclei-Template
Accédez au répertoire du dépôt cloné :
cd CVE-2024-38473-Nuclei-Template
Exécuter le modèle Nuclei sur un seul hôte :
nuclei -t CVE-2024-38473.yaml -u http://example.com
Exécuter le modèle Nuclei contre une liste d'hôtes :
nuclei -t CVE-2024-38473.yaml -l hosts.txt
Exécuter le modèle Nuclei sur un seul hôte en spécifiant un fichier .html ou .php valide :
nuclei -t CVE-2024-38473.yaml -u http://example.com/valid.php
Exécuter Nuclei de cette manière peut offrir un taux de détection plus élevé. Vous pouvez également inclure des URL sous ce format dans le fichier hosts pour exécuter le modèle contre cette liste.
Pour tester facilement la vulnérabilité CVE-2024-38473, vous pouvez mettre en place un environnement vulnérable en utilisant Docker. Suivez ces étapes pour vérifier rapidement l'efficacité du modèle Nuclei :
Assurez-vous que le démon Docker est en cours d'exécution : Vérifiez que le démon Docker tourne sur votre système. Vous pouvez le démarrer avec la commande suivante s'il n'est pas déjà en cours d'exécution :
sudo systemctl start docker
Lancez le conteneur Docker : Dans le répertoire du dépôt, utilisez la commande Docker suivante pour démarrer un conteneur avec une configuration Apache et PHP-FPM vulnérable :
docker run -p 8787:80 -v "$(pwd)/test-env-webroot:/app" webdevops/php-apache:7.1
Testez la vulnérabilité :
Manuellement : Ouvrez votre navigateur web et accédez à http://localhost:8787 pour interagir avec le serveur Apache tournant dans le conteneur Docker. Accédez à http://localhost:8787/info.php pour tester la vulnérabilité. Ce fichier est protégé par une ACL, et si le contournement de l'ACL réussit, vous verrez la sortie de phpinfo() :
En utilisant le modèle Nuclei : Exécutez la commande Nuclei suivante pour tester le serveur avec le modèle :
nuclei -t CVE-2024-38473.yaml -u http://localhost:8787
Le 8 août 2024, le chercheur en sécurité Orange Tsai a donné une présentation au Black Hat USA 2024 intitulée : Confusion Attacks : Exploiting Hidden Semantic Ambiguity in Apache HTTP Server!. Dans cette présentation, il a signalé plusieurs vulnérabilités affectant le serveur HTTP Apache. Il a expliqué qu'Apache possède une architecture hautement modulaire, composée de centaines de modules, chacun exécutant sa fonction tout en lisant et écrivant dans une structure partagée appelée request_rec, qui contient près de 100 champs.
La cause profonde des vulnérabilités signalées par le chercheur en sécurité réside dans l'incohérence de la façon dont les différents modules Apache traitent les divers champs de la structure partagée. Par exemple, mod_authz_core traite le champ r->filename comme un fichier, tandis que mod_proxy le traite comme une URL, ce qui conduit à des divergences entraînant un large éventail de vulnérabilités.
Dans sa présentation, Orange Tsai définit un type d'attaque appelé « Filename Confusion ». Bien que cette attaque ait une surface d'attaque variée, CVE-2024-38473, que nous couvrons dans ce modèle, se réfère à la façon dont nous pouvons appliquer l'attaque « Filename Confusion » pour contourner les ACL Apache et accéder à des fichiers restreints.
Le problème survient lorsque le module d'authentification d'Apache, mod_authz_core, traite l'attribut r->filename comme un fichier, tandis que mod_proxy le traite comme une URL. De ce fait, les installations Apache avec PHP-FPM dans leur configuration par défaut sont affectées par cette vulnérabilité. Imaginez qu'un serveur exécutant Apache et PHP-FPM ait une ACL configurée comme suit pour protéger l'accès au fichier admin.php avec des identifiants :
<Files "admin.php">
AuthType Basic
AuthName "Admin Panel"
AuthUserFile "/etc/apache2/.htpasswd"
Require valid-user
</Files>
En raison de la vulnérabilité, il est possible de contourner les ACL comme celle ci-dessus qui impliquent la protection d'un fichier individuel. En fait, cela peut être fait aussi simplement qu'en envoyant la requête suivante : http://server/admin.php%3fooo.php.
Pour comprendre cela en profondeur, il est important de considérer que lorsqu'Apache traite une requête comme celle ci-dessus, le module mod_authz_core lit la valeur admin.php?fooo.php depuis le champ r->filename de la structure partagée. Il traite cette valeur comme le nom du fichier demandé, et lorsqu'il la compare à l'ACL, elle ne correspond pas car admin.php?fooo.php est différent de admin.php.
Ensuite, comme admin.php?fooo.php se termine par .php, la requête est traitée par PHP-FPM. PHP-FPM supprime tout ce qui suit le ? dans le nom de fichier reçu d'Apache avant de le traiter, le considérant comme une URL plutôt qu'un fichier. En conséquence, PHP-FPM traitera directement admin.php. Comme la vérification ACL a été passée plus tôt, l'attaquant peut accéder à admin.php sans authentification.
Le modèle Nuclei actuel vise non seulement à découvrir des fichiers protégés par force brute, mais inclut également une logique pour identifier quand un serveur a une configuration Apache < 2.4.60 vulnérable avec PHP-FPM, même si des cas de fichiers protégés par ACL ne sont pas détectés. Dans le flux de base, il essaie d'abord d'identifier si le serveur a une configuration vulnérable, puis, si positif, il tente d'identifier les fichiers courants qui peuvent être protégés par des ACL.
L'idée derrière la détection des configurations vulnérables avec Apache < 2.4.60 et PHP-FPM repose sur deux prémisses de base :
Dans une configuration vulnérable, si file.php existe sur le serveur, alors la requête vers http://server/file.php%3fooo.php renverrait le même code d'état 200 et la même longueur de corps que la requête vers http://server/file.php (car après que PHP-FPM supprime %3fooo.php, le fichier demandé serait le même).
Dans une configuration vulnérable, si file.html existe sur le serveur, alors la requête vers http://server/file.html%3fooo.php renverrait 403 Accès refusé. Cela est dû au fait que PHP-FPM tenterait de charger un fichier avec une extension .html au lieu de .php, ce qui par défaut n'est pas autorisé.
Le flux du modèle se compose de 7 groupes de requêtes. Ils doivent être exécutés dans l'ordre et doivent satisfaire les conditions de correspondance respectives pour passer au groupe suivant. Cela permet de minimiser le nombre de requêtes envoyées inutilement lorsque les conditions sont déjà connues comme non remplies.