Académique Documents
Professionnel Documents
Culture Documents
Partie III
Partie III
DISCUSSIONS
CHAPITRE I : RESULTATS DES TESTS
Dans ce chapitre, nous présentons les résultats obtenus à l’issue des tests d’intrusion effectué.
L’image ci-dessous nous montre que l’application n’est pas derrière un WAF :
Ensuite, nous avons analyser les ports ouverts et obtenu les résultats suivants :
La version Openssh qui s'exécute sur le port 22 n'est associée à aucune vulnérabilité
critique,
il est donc peu probable que nous obtenions un accès initial via ce port, sauf si nous
trouvons des informations d'identification.
On effectue une recherche des exploits sur OpenSSH 7.4 avec searchsploit. L’image
ci-dessous nous montre les exploits trouvés :
Figure 3:Test de ssh avec namp
La version du serveur DNS, PowerDNS Authoritative Server 4.4.1, n’est associé à aucune
vulnérabilité connue. Searchsploit nous montre :
On fait des tests automatiques supplémentaires avec nmap qui nous montre que service n’est
pas associé à une vulnérabilité connue et qu’on ne peut pas se connecter avec les identifiants
par défauts ni énumérer les utilisateurs :
C’est un exploit publié par metasploit. Après le test avec metasploit, on constate que
c’est faux positif :
Figure 9:Test de FTP avec nmap
Après le scanne, nous n’avons pas trouver un répertoire nous permettant de soumettre un
fichier au serveur.
On remarque que l’application est réalisée en WordPress version. Nous allons lancer un
scanne à l’aide de wpscan, qui est un outil de scanne pour les applications faites en
WordPress, pour connaitre les différents plugins utilisés et leur version et d’autres
informations. On obtient :
Figure 15:Lancement de wpscan
5. Le scanne web
Tout d’abord, nous allons intercepter et lire l’en-tête des requetés envoyé au serveur ainsi que
l’en-tête des réponses fournies par le serveur.
Le tableau ci-dessous contient Les en-têtes manquants ainsi que l’impact que cela pourrait
engendrer si un pirate profite de cette mauvaise configuration du serveur.
A partir de ce lien, nous avons trouvé des informations suivantes : les auteurs tels que admin,
KOLOTCHALAMA SORO et Hermine TEHOUA.
Pour le scanne approfondi, nous allons utiliser les outils suivants : Zed Attack Proxy (ZAP)
d’OWASP et Nessus. Ils sont open Source, gratuits et effectuent tous les tests de
vulnérabilité web de façon automatique. Ces outils ont confirmé les vulnérabilités que nous
avons découvertes manuellement.
Cette authentification n’est pas sécurisée car les numéros matricules sont connus de tous.
Cela laisse libre cours à une attaque de type brute force pour trouver des identifiants valides.
Nous avons procédé à une injection SQL manuellement, mais cela un échec. L’image
suivante présente une capture du test. Toutes les tentatives furent redirigées vers cette page.
Cette directive indique que le serveur de l’application ne stocke aucune donnée dans le cache
du navigateur.
Ces tests révèlent que le cache du navigateur ne stocke pas de données sensibles.
Après avoir cliqué sur <<mot de passe oublié>>, on est redirigé vers cette page :
Le message de confirmation nous révèle l’adresse email associé au nom d’utilisateur saisi. On
constate que l’email de l’administrateur est drigos1er@yahoo.fr.
Si un pirate prend le contrôle du mail de l’administrateur, il peut faciliment changer son mot
de passe.
Nous avons faire environ 03 heures de test sans que l’application ne rejette les requêtes
d’authentification automatique d’Hydra. Cela prouve que l’application n’a pas de système qui
lui permet de rejeter les requêtes à partir d’un certain nombre d’essai.
Après 06 heures de test, nous avons épuisé le dictionnaire des mots de passe sans succès.
B. Échecs cryptographiques
Nous avons scanner le service HTTPS. On a constaté qu’il fonctionne parfaitement. Il utilise
la version TLSv1.2 et TLSv1.3.
Nous avons trouvé le répertoire /gallery contenant des images qui ne sont pas de l’ESATIC.
Nous avons un répertoire /vidéo contenant une vidéo qui n’est pas de l’ESATIC.
Figure 35: Une vidéo non conforme
C. Injections
Le script automatisé que nous avons exécuté a permis de tester la sensibilité de l’application à
une attaque de type injection SQL. Le résultat en sortie est un fichier texte comportant les
requêtes exécutées et les réponses du serveur. Ces réponses sont du format suivant :
Nous avons aussi essayé une injection SQL standard au niveau de la page d’authentification
et de la page de réinitialisation de mot. Une restriction sur le type d’entrée attendu qui « text
» et aucun filtre de caractère interdisant la validation des caractères <<“’,’’, ;,=,<,>,/?q=1,/?
q=1',/?q=1' or '1'='1,/?q=1 or 1=1>>.
Figure 38: Test d'injection SQL sur la page d'authentification de SIGES
Figure 39:Test d'injection SQL sur la gage d'authentification de cpanel
Figure 40: Test d'injection SQL sur la page de réinitialisation de mot de passe
Nous avons écrit script HTML et CSS qui charge l’application dans une balise iframe.
Figure 41: le script d'exploitation de clickjacking
On a le résultat suivant :
Ce résultat prouve que l’application peut être utiliser dans une attaque de phishing dans
l’optique de tromper la vigilance de la cible.
2. Traversée de chemin
Nous pouvons accéder au répertoire /wp-json/oembed/. Ce répertoire contenant des fichiers
JSON ne doivent pas être accessible de tous.
Url :https://esatic.ci/wp-json/oembed/1.0/embed?url=%2Fembed
3. CSRF
L’image ci-dessous nous montre qu’il est possible de rejouer une session si elle n’est pas
expirée car l’application n’utilise pas les jetons de session (Token).
Le scan du WordPress utilisé nous révèle que le plugin js_composer n’est pas à jour.
La librairie JQuery utilisée est la version 3.1.1 cette version possède de nombreuses
vulnérabilités telles que :
Figure 48:Test d'attaque par dictionnaire formé avec les informations trouvées
Figure 49:la fin du test d'attaque par dictionnaire
Après 1 heure de test, nous avons parcouru toute la liste de mot de passe sans succès.
Mais toutefois, il demeure vulnérable d’avoir des informations des administrateurs sur
l’application.
Lors des différents tests, nous avons pu accéder au fichier JSON à l’adresse
suivante :https://esatic.ci/wp-json/oembed/1.0/embed?url=https://esatic.ci/. A partir de ce
fichier, nous avons collecté des informations sensibles.
A. Authentification rompue
Eviter l’utilisation des noms d’utilisateur populaire pour s’authentifier ;
Avoir un nombre défini de tentative d’authentification ;
Mettre en place un système d’alerte de l’administrateur lors d’une attaque par brute
force ;
Mettre en place une politique de mot de passe et la communiquer aux utilisateurs ;
Renforcer le système de réinitialisation de mot de passe ;
Mettre en place un mécanisme de verrouillage de compte après nombre de tentation
d’authentification échouée.
B. Échecs cryptographiques
Supprimer les répertoires inutiles
Supprimer les fichiers inutiles
Être le professionnel le plus possible lors du développement d’une application
Mettre en place un système d’alerte pour le renouvellement du certificat.
Empêcher l’utilisation du protocole HTTP