Tous les tests présentés dans cet article ont été réalisés sur un environnement de test personnel isolé. Les tests de pénétration non autorisés sont interdits.
Les techniques décrites dans cet article sont destinées exclusivement à l'apprentissage en cybersécurité et à l'auto-évaluation corrective. Toute utilisation illégale est strictement interdite. Toutes les expériences ont été menées dans un environnement isolé configuré par l'auteur.
Introduction : Fondements des vulnérabilités de configuration
Principe
Les systèmes ou applications présentent des erreurs lors de leur déploiement ou configuration, entraînant l'inefficacité du mécanisme de sécurité ou son absence d'activation
Méthodes d'exploitation
1. Accéder à l'interface d'administration via des comptes par défaut ou des mots de passe faibles
2. Utiliser des pages de test ou des exemples de code non supprimés pour obtenir des informations système
3. Pénétrer directement via des ports ou services ouverts (comme un port de base de données exposé)
4. Exploiter des vulnérabilités connues non corrigées (comme l'exécution de code à distance)
5. Contourner les contrôles d'accès mal configurés (comme CORS autorisant des requêtes API depuis n'importe quel domaine)
Correctifs
1. Gestion automatisée de la configuration : Utiliser des outils (comme Ansible, Docker) pour standardiser les configurations et réduire les erreurs humaines.
2. Mises à jour et correctifs opportuns
3. Principe du moindre privilège : Limiter les permissions des comptes, désactiver les services/ports non nécessaires.
4. Renforcement de l'authentification : Désactiver les comptes par défaut, utiliser des mots de passe forts ou une authentification à deux facteurs (2FA).
5. Audit de configuration : Analyser régulièrement les erreurs de configuration (comme avec Nessus, des outils de scan de vulnérabilités).
6. Surveillance et journalisation : Surveiller en temps réel les accès anormaux, analyser les journaux pour détecter d'éventuelles attaques.
Cas d'étude
L'application d'exemple Tomcat n'a pas été supprimée, un attaquant a découvert la page d'administration standard à l'aide d'un outil de scan de ports, a deviné le mot de passe faible, est entré dans l'interface d'administration et a déployé un programme malveillant. Comme illustré ci-dessous
I. Vulnérabilités d'naalyse de fichiers
Introduction
Les conteneurs Web (Apache, Nginx, IIS, etc.) analysent les fichiers non scriptés comme des fichiers de script et les exécutent, créant ainsi une vulnérabilité. Les pirates peuvent exploiter cette vulnérabilité pour exécuter des fichiers illégaux.
Exemple:
Dans une vulnérabilité de téléchargement de fichiers, un fichier image avec l'extension .jpg est un fichier non scripté, mais il est traité comme un fichier php.
Les vulnérabilités d'analyse de fichiers résultent principalement d'une mauvaise gestion par l'administrateur du site ou de vulnérabilités inhérentes aux serveurs Web, entraînant l'exécution de certains fichiers spécifiques par IIS, Apache, Nginx ou d'autres serveurs Web dans certaines conditions
Dans phpstudy, les trois conteneurs Web existent et peuvent être utilisés en mode bascule
Vulnérabilité d'analyse multi-suffixe d'Apache HTTPD
Introduction
Apache HTTPD est un service Web dans la suite Apache
Apache HTTPD prend en charge plusieurs suffixes pour un seul fichier, avec des instructions différentes pour chaque suffixe.
Exemple: fichier cmd.php.jpg
Apache autorise par défaut qu'un fichier ait plusieurs suffixes séparés par des points, et si le suffixe droit n'est pas reconnu (pas dans mime.types), il continue à identifier vers la gauche.
Lorsque nous demandons un tel fichier cmd.php.xxx, le suffixe xxx n'est pas reconnu, donc il continue vers la gauche et trouve le suffixe php, confiant le fichier au traitement PHP. Bien que le fichier soit finalement traité par PHP, ce dernier ne reconnaît pas non plus le suffixe .xxx et ne l'analyse pas.
Lors de la configuration du serveur, le personnel d'exploitation ajoute parfois un handler pour qu'Apache puisse analyser les fichiers PHP :
AddHandler application/x-httpd-php .php
Ce qui signifie :
AddHandler mappe l'extension de fichier au programme de traitement spécifique application/x-httpd-php (similaire au parseur PHP)
Résultat:
Dans le cas de plusieurs suffixes, tout fichier contenant l'extension .php sera reconnu comme fichier PHP, peu importe sa position parmi les suffixes. L'exploitation de cette caractéristique peut contourner la liste blanche de téléchargement et créer une vulnérabilité d'analyse.
Numéro de vulnérabilité CVE-2017-15715
Raison de l'absence de CVE
Le numéro CVE (Common Vulnerabilities and Exposures) est principalement utilisé pour identifier les défauts inhérents au logiciel. La cause de ce problème réside dans les instructions de configuration du serveur (comme AddHandler), qui entraînent des règles d'exécution non conformes aux attentes. Il ne s'agit pas d'un défaut dans le code d'Apache, donc ce type de problème n'obtient généralement pas de numéro CVE.
Pourquoi inclure un CVE?
Nécessaire pour la validation
- Environnement d'essai
Conteneur Docker (considéré comme une machine virtuelle) :
Ouvrez la machine virtuelle Ubuntu, accédez au répertoire de la cible vulhub téléchargé précédemment
Accédez depuis le dossier du bureau
Continuez jusqu'au répertoire :
vulhub/httpd/apache_parsing_vulnerability
Démarrer l'environnement d'essai
Démarrer le conteneur Docker : sudo docker-compose up -d
Voir les conteneurs en cours d'exécution : sudo docker ps
Entrer dans le conteneur, exécuter la commande : sudo docker exec -it 010 /bin/bash
# exec exécute dans le conteneur ; -it l'ID du conteneur (généralement 3 chiffres suffisent, ici 010)
# /bin/bash est la commande à exécuter, similaire à l'interface en ligne de commande ; certains utilisent /bin/sh ...
Ici, on peut aussi utiliser : cat /etc/passwd
Accéder au fichier de configuration dans le conteneur :
cd /etc/apache2/conf-available/
cat docker-php.conf
On peut voir la configuartion handler erronée
Voir l'adresse IP de Ubuntu : ifconfig
Copiez l'adresse ens33 et accédez à la vulnérabilité via cette adresse IP
Accéder via le navigateur local : http://xxx.xxx.xxx.xxx/
Reproduire la vulnérabilité
Sous Windows, téléchargez le fichier cmd.php.jpg (contenant un webshell simple) ;
Dans le répertoire racine de Docker Ubuntu, on peut également voir le fichier téléchargé
Utiliser un outil de gestion de webshell pour se connecter et accéder à l'adresse cible http://xxx.xxx.xxx.xxx/var/www/html/uploadfiles/cmd.php.jpg ; avec succès
Tenter de supprimer la configuration erronée
Supprimer la configuration erronée. Comme Docker n'a pas d'éditeur comme vim, il faut d'abord copier le fichier vers Ubuntu :
# Copier depuis l'ID du conteneur : contenu à copier chemin actuel
sudo docker cp 010:/etc/apache2/conf-available/docker-php.conf .
# Éditer et supprimer la ligne incorrecte
sudo vim docker-php.conf
:1,1d
:wq
# Remplacer le fichier original
sudo docker cp docker-php.conf 010:/etc/apache2/conf-available/
reboot
Vérifier le succès du remplacement avec cat
Quitter : exit
# Note
Pour démarrer l'environnement d'essai, il faut être connecté au réseau
II. Vulnérabilités de parcours de répertoire
Introduction
Permettent à un attaquant de lire des fichiers arbitraires sur le serveur d'application sans autorisation. Cela inclut le code de l'application, les données, les informations d'identification et les fichiers sensibles du système d'exploitation.
Dans certains cas, l'attaquant peut également écrire des fichiers arbitraires sur le serveur, modifier les données de l'application ou même prendre le contrôle complet du serveur.
Le programme n'applique pas un filtrage suffisant des caractères de saut de répertoire (comme ../) dans les entrées utilisateur, permettant à un utilisateur de soumettre malicieusement des commandes de saut de répertoire et de parcourir arbitrairement les fichiers sur le serveur.
# Moins dangereux, mais pratique pour les tests de base ; d'autres vulnérabilités comme la divulgation de numéro de version peuvent être signalées dans un contexte professionnel
Vulnérabilité de parcours de répertoire Apache
Numéro de vulnérabilité CVE-2021-42013
Mise en place de l'environnement
# Modifier le fichier de configuration
Dossier : D:\web\tools\php2018\PHPTutorial\Apache\conf\vhosts.conf
Changer : Options -Indexes +FollowSymLinks +ExecCGI
En : Options +Indexes +FollowSymLinks +ExecCGI
# Explication : Options +Indexes permet d'afficher le contenu du répertoire, similaire à l'option "autoriser la liste des répertoires" dans les paramètres du répertoire racine du site phpstudy
Redémarrer phpstudy
Créer un dossier test pour les tests, placer quelques fichiers dans ce dossier
Accéder au dossier test : http://127.0.0.1/test/
# Supprimer les fichiers index.php et l.php dans le dossier www
Résultat : Le contenu du répertoire est listé
En cliquant sur le fichier sql.txt, on peut l'ouvrir directement et voir son contenu
Corriger la vulnérabilité
Changer : +Indexes en : -Indexes
Redémarrer les services de phpstudy
Réessayer d'accéder, la fonctionnalité est désactivée
Vulnérabilité de traversée de répertoire Nginx
Introduction
Lors de la configuration d'un alias dans Nginx, si le slash (/) est oublié, cela crée une vulnérabilité de traversée de répertoire.
# Configuration incorrecte comme suit
location /files {
alias /home/;
}
L'intention initiale était de permettre aux utilisateurs d'accéder aux fichiers du répertoire /home/)
Mais lorsque nous accédons à /files../ , le répertoire réel atteint est : /home/../
/home/…/Normalement, on accède au dossier home, mais en ajoutant ../ après, on remonte d'un niveau et on atteint le répertoire racine
**…/**La traversée de répertoire peut également être appliquée dans des URL normales ; normalement, on accéderait à http://ip:port/files/../... mais ici, c'est une erreur de configuration Nginx, l'accès à /files…/ permet cette syntaxe
Numéro de vulnérabilité CNVD-2010-0917
Mise en place de l'environnement
# Utiliser la cible vulhub sous Ubuntu
Accéder au répertoire du dossier : /Desktop/file/vulhub-master/nginx/insecure-configuration
Démarrer le conteneur : sudo docker-compose up -d
Accéder à la cible : http://xxx.xxx.xxx.xxx:8081/files/ (adresse IP de la machine virtuelle ; sans espaces)
Entrer dans le conteneur, exécuter la commande : sudo docker exec -it b88 /bin/bash
Accéder : adresse IP de la machine virtuelle:8081/files.. (traversée jusqu'au répertoire racine)
Accéder à : http://xxx.xxx.xxx.xxx:8081/files/ , on constate que bien qu'on accède au contenu du dossier files, on voit en réalité le fichier help.txt du répertoire home (comme illustré ci-dessus)
Lorsqu'on accède à : http://xxx.xxx.xxx.xxx:8081/files../ , on constate que depuis le dossier files, on a effectué une traversée de répertoire jusqu'au répertoire racine
Normalement, lors d'un accès standard : http://xxx.xxx.xxx.xxx:8081/files/../../ , on accède à la page d'accueil
La raison est la configuration incorrecte du fichier : location /files { alias /home/; } Il manque un / après files La configuration correcte devrait être : location /files/ { alias /home/; }
Corriger la vulnérabilité
# Code de correction comme suit
server {
listen 8081;
root /usr/share/nginx/html;
index index.html;
server_name_;
autoindex on;
location /files/ { # /files devient /files/
alias /home/;
}
}
# Accéder au dossier de la cible, modifier le fichier de configuration error2.conf
file/vulhub-master/nginx/insecure-configuration
Après modification, copier le fichier : docker cp error2.conf cr8:/etc/nginx/conf.d/
Enfin, redémarrer : sudo docker restart cr8
On peut voir la configuration incorrecte dans le fichier error2.conf du conteneur Docker
Vulnérabilité de parcours de répertoire de la cible pikachu
Numéro de vulnérabilité : Aucun numéro CVE pour la cible
Reproduction
Accéder à la cible, cliquer sur un élément quelconque, on constate que le paramètre title contrôle le contenu du fichier, donc on peut essayer avec ../
En cliquant sur "Aperçu", on constate que le nom du fichier est dir.php
Accéder à title=…/dir.php permet d'accéder au contenu du répertoire parent
Accéder à title=…/…/…/README.md permet d'accéder au fichier README.md du répertoire racine
1 On peut utiliser l'outil Burpsuite pour marquer le nom du fichier …/…//dir.php et lancer une attèque par force brute sur un dictionnaire de noms de fichiers 2 Ou bien marquer directement toute la séquence, ../../../dir.php, et dans le dictionnaire d'attaque, inclure des séquences comme ../../../ pour la force brute, par exemple comme ceci:
Si dans le répertoire racine du site www (au même niveau) il existe un fichier 123.txt contenant les informations d'identification du compte, alors
Accéder à : ?title=…/…/…/…/…/123.txt permet d'effectuer une traversée de répertoire pour obtenir le contenu du fichier
À suivre, en cours de mise à jour…
Suivez-moi 'Notes de hack de Wudaozi' pour plus d'informations :
- Dernières techniques de cybersécurité partagées
- Codes sources de cibles pratiques et analyses
- Guides d'apprentissage systématisés
- Actualités sectorielles et conseils de carrière
Ceci conclut le contenu du blog d'aujourd'hui La création n'est pas facile, si cela vous aide, pourriez-vous aimer et suivre un peu ? Merci pour votre soutien!