PARTIE III : RESULTATS ET

DISCUSSIONS
CHAPITRE I : RESULTATS DES TESTS
Dans ce chapitre, nous présentons les résultats obtenus à l’issue des tests d’intrusion
effectués.

I. Reconnaissance et Résultats de l’analyse de vulnérabilités

1. Vérification de WAF (Web Application Firewall)
Tout d’abord, nous effectuons une analyse rapide pour voir si l’application est derrière un
pare-feu.

L’image ci-dessous nous montre que l’application n’est pas derrière un WAF :

Figure 1:Detection de firewall avec whatwaf

2. Détection des ports ouverts et les services associés

Pour cette étape, nous exécutons une analyse initiale rapide de Nmap et shodan pour voir quels
ports sont ouverts et quels services sont exécutés sur ces ports. Le scan nous révèle les ports
ouverts, les services associés à ces ports ainsi que la version de ces services.
Figure 2: Le scan de tous les ports avec nmap

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

Figure 4:Recherche d'exploit sur Openssh 7.4 par searchsploit

 La version du serveur DNS, PowerDNS Authoritative Server 4.4.1, qui s’exécute sur le
port 53 n’est associée à aucune vulnérabilité connue. Searchsploit nous montre :
Figure 5: Recherche d'exploit sur PowerDNS par searchsploit

 La version de SMTP, Exim smtpd 4.94.2, qui exécute sur les ports 465 et 587
n’ont pas de vulnérabilités connues. L’image ci-dessous est le résultat des recherches
sur exploit DB à l’aide de la commande searchsploit.

Figure 6:Recherche d'exploit sur smtpd 4.94.2 par searchsploit

On fait des tests automatiques supplémentaires avec nmap qui nous montre que le 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 :

Figure 7: Scan supplémentaire sur smtpd 4.94.2 avec nmap

  Après une recherche sur exploit dB sur le service FTP exécuté sur le port 21, on
remarque:

Figure 8: Recherche d'exploit sur ftp avec searchsploit

C’est un exploit publié par metasploit. Après le test avec metasploit, on constate que
c’est un faux positif :

Figure 9:Test de FTP avec nmap

 Les recherches sur le service POP (Post Office Protocol) exécuté sur le port 110
nous donnent cette image :
Figure 10: Les exploits probables sur POP
Après les tests, nous avons constaté que ces exploits ne concernaient que la version Linux
2.6.16 or l’OS du serveur est Linux 4.4. Ces exploits ne sont plus d’actualité, c’est-à- qu’ils
ont été corrigés.

Figure 11:La version du kernel Linux utilisé

Figure 12: Test du service POP3 avec nmap

 La version du service IMAP exécuté sur le port 143 n’est pas associée à une
vulnérabilité.

3. Découverte des différents répertoires de l’application

Après la découverte des ports 80 et 443, on essaie d’énumérer les différents répertoires et les
fichiers sensibles à l’aide de nmap, dirbuster et nikto. Le but de ce scanne est d’identifier
 un répertoire nous permettant de soumettre un fichier au serveur. L’image ci-dessous présente
les différents répertoires trouvés :

Figure 13: les différents répertoires trouvés

Après le scanne, nous n’avons pas trouvé un répertoire nous permettant de soumettre un
fichier au serveur.

4. Identification des différentes technologies utilisées

On identifie les différentes technologies ainsi que les versions afin de chercher les
vulnérabilités qui leurs sont associées. Pour cela, nous allons utiliser whatweb, wig, nikto et
ZAP. L’image ci-dessous montre les différentes technologies utilisées :

Figure 14:Les différentes technologies utilisées

On remarque que l’application est réalisée en WordPress. 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

Figure 16: Les plugins utilisés et leur version (1)

Figure 17:Les plugins utilisés et leur version 2

On remarque que le plugin js_composer n’est pas à jour.

5. Le scanne web
Tout d’abord, nous allons intercepter et lire les en-têtes des requêtes envoyées au serveur
ainsi que les en-têtes des réponses fournies par le serveur.

Figure 18: scanne manuel de l'en-tête des requêtes/réponses

 Figure 19:Scanne automatique de l'en-tête des requêtes/réponses

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.

Les en-têtes Son Rôle L’impact

X-Frame-Options L'en-tête de réponse HTTP Les pirates peuvent utiliser

X-Frame-Options peut être cet en-tête afin de mener les
utilisé afin d'indiquer si un attaques de clickjacking (ou
navigateur devrait être « détournement de clic »).
autorisé à afficher une page
au sein d'un élément
<frame>, <iframe>,
<embed> ou <object>.

X-XSS-Protection L'en-tête de réponse HTTP Cross-site Scripting (XSS)

 X-XSS-Protection est une
fonctionnalité d'Internet
Explorer, de Chrome et de
Safari qui empêche le
chargement des pages
lorsqu'elles détectent des
attaques de type cross-site
Scripting (XSS).

Strict-Transport-Security L'en-tête de réponse HTTP Si un site Web accepte une

Strict-Transport-Security connexion via HTTP et
(souvent abrégé en HSTS) redirige vers HTTPS, les
informe les navigateurs que visiteurs peuvent d'abord
le site ne doit être accessible communiquer avec la
qu'en utilisant HTTPS et que version non cryptée du site
toute tentative future d'y avant d'être redirigés.
accéder en utilisant HTTP
doit être automatiquement
convertie en HTTPS.

X-Content-Type-Options L'entête X-Content-Type- Les sniffing de type MIME :

Options est un marqueur Le reniflage MIME était, et
utilisé par le serveur pour est toujours, une technique
indiquer que les types utilisée par certains
MIME annoncés dans les navigateurs Web
en-têtes Content-Type ne (principalement Internet
doivent pas être modifiés ou Explorer) pour examiner le
et suivis. Cela permet de se contenu d'un actif
détacher du sniffing de type particulier. Ceci est fait dans
MIME, ou, en d'autres le but de déterminer le
termes, c'est une façon de format de fichier d'un actif.
dire que les webmasters
 savaient ce qu'ils faisaient.

L’outil Nikto nous a révélé le lien suivant : https://esatic.ci /wp-json/wp/v2/pages/1537.

Une fois sur ce lien, on constate l’exposition du contenu des fichiers JSON.

A partir de ce lien, nous avons trouvé des informations suivantes : les auteurs tels que admin,
KOLOTCHALAMA SORO et Hermine TEHOUA.

Figure 20:Les informations sur l'admin

Figure 21: Les informations sur Hermine

 Figure 22: Les informations sur Soro

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.

II. Exploitation des vulnérabilités

A. Authentification rompue
1. Test des informations d'identification transportées sur un canal chiffré
Le constat que nous avons fait au niveau du scan des ports était que le serveur redirigeait tous
le Traffic web sur le port 443 utilisé par le protocole HTTPS. Nous avons capturé les paquets
transitant entre machine et le serveur lors d’une authentification avec wireshark dans le but
de voir si ce protocole fonctionne correctement. L’image ci-dessous montre que les
informations transitant sont illisibles car elles sont chiffrées.

Figure 23:Interception des identifiants par wireshark

 2. Test d’informations d’identification par défaut
Les informations d’identification requis pour accéder à SIGES sont un numéro matricule et
un mot de passe. Pour les matricules, nous avons testé 17-ESATICXXXXAB avec des mots
de passe par défaut (Ex : admin, Password, 123456, Password123, …).

Cette authentification n’est pas sécurisée car les numéros matricules sont connus de tous.

3. Test du mécanisme de verrouillage faible

Le système ne dispose pas de mécanique de verrouillage car nous avons essayé de nous
connecter avec des faux identifiants plus de trente (30) fois sans remarquer une alerte.

Cela laisse libre cours à une attaque de type brute force pour trouver des identifiants valides.

4. Test de contournement du schéma d’authentification

Nous avons essayé d’accéder directement aux pages de l’application SIGES. Ces tentatives se
sont soldées par un échec car nous avons été redirigés vers la page d’authentification. Il est
donc impossible de contourner le schéma d’authentification de cette façon. Chaque fois que
nous avons essayé fut soldé par un échec total. Tous les essaies nous ramenaient sur la page
d’authentification.

Nous avons procédé à une injection SQL manuellement, mais cette technique a échoué.
L’image suivante présente une capture du test. Toutes les tentatives furent redirigées vers
cette page.

Figure 24:La page d'authentification de SIGES

 5. Test des faiblesses du cache du navigateur
Après s’être déconnecté et ensuite appuyé sur le bouton de retour pour essayer d’accéder aux
données contenues dans l’application SIGES, nous avons été automatiquement redirigés vers
la page d’authentification de l’application.

Nous avons analysé l’en-tête des requêtes/réponses :

Figure 25:La configuration des paramètres de cache

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.

6. Test de la politique de mot de passe faible

Les premiers identifiants sont fournis par l’administrateur de l’application car il n’existe pas
de formulaire d’enregistrement sur l’application. Après avoir accédé à son compte pour la
première fois, l’utilisateur a le choix entre changer son mot de passe ou le conservé. Ce qui
pourrait entre dangereux car le mot de passe par défaut est identique pour tous les étudiants.
Un étudiant lambda peut se connecter au compte de son ami en utilisant son matricule qui
n’est pas confidentiel et le mot de passe par défaut si celui-ci ne l’a pas changé.

Cette technique d’authentification favorise l’usurpation des comptes.

7. Test des fonctionnalités de réinitialisation de mot de passe faibles

Nous allons essayer de réinitialiser notre mot de passe. Une fois sur la page
d’authentification.
Figure 26:Mot de passe oublié

Après avoir cliqué sur <<mot de passe oublié>>, on est redirigé vers cette page :

Figure 27:reinitialisation de de mot de passe

On nous demande simplement de fournir le nom d’utilisateur. Nous allons tester les noms
suivants : 17-ESATIC0035BU et les informations trouvées dans le fichier JSON (kolo,
admin et hermine).

Figure 28: Premier test de réinitialisation de mot de passe

Figure 29: Deuxième test de réinitialisation de mot de passe pour admin

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 facilement changer son mot
de passe.

8. Test d’authentification plus faible

Les informations utilisées pour s’authentifier sont le numéro matricule et un mot de passe.
On peut lancer une attaque par dictionnaire. On définit une liste des numéros matricules
appelé matricule.txt et on utilise un dictionnaire contenant des mots de passe standards.
Dans notre test, on a utilisé rockyou.txt qui est sous linux. Nous allons lancer Hydra pour
essayer de trouver un mot de passe.

Figure 30:test d'authentification faible avec hydra

On utilise les options suivantes :

 -P : pour indiquer la liste des utilisateurs à utiliser

 -L : pour indiquer la liste des mots de passe à tester
 http-post-form : pour dire qu’il s’agit d’u formulaire de soumission de données
 -o : Pour enregistrer le résultat dans un fichier

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 scanné le service HTTPS. On a constaté qu’il fonctionne parfaitement. Il utilise
la version TLSv1.2 et TLSv1.3.

Figure 31:les versions de TLS utilisées

Figure 32: informations sur le certificat utilisé

Le test d’exposition des informations sensibles nous révèle :

 L’existence de l’ancienne application

Nous avons découvert l’existence de l’ancienne application sur le même serveur à

l’adresse :https://esatic.ci/anciensite/.
Figure 33:L'ancienne application disponible

 Une gallérie non conforme

Nous avons trouvé le répertoire /gallery contenant des images qui ne sont pas de l’ESATIC.

Figure 34: Une gallérie avec des images inconnues

 Une vidéo non conforme

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 :

Figure 36:Les requêtes envoyées par sqlmap

Figure 37: Les réponses fournies par le serveur à sqlmap

Le script a exécuté plus de 1200 requêtes durant 24 heures pour une page testée et pour
chacun des types d’injection SQL à savoir l’injection SQL aveugle basée sur booléen,
injection SQL basée sur des erreurs, injection SQL de requête UNION, injection SQL de
requêtes empilées et l‘injection SQL aveugle basée sur le temps, nous avons obtenu le même
résultat en sortie qui est l’échec. Nous aurions dû avoir en sortie la page testée contenant soit
une erreur SQL, soit le résultat de la requête injectée. Le résultat obtenu le contenu originel
de la page testée. Le script a été exécuté pour chacune des pages de l’application.

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

A la fin du test, aucune commande d’injection n’a pu être exploitée.

D. Mauvaise configuration de la sécurité
1. Les en-têtes incorrects
Les en-têtes incorrects observées dans la partie II, chapitre I, le point 5, plus précisément X-
XSS-Protection nous a permis d’exploiter la faille clickjacking.

Nous avons écrit un 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 :

Figure 42: le résultat du clickjacking

Ce résultat prouve que l’application peut être victime d’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 contient des fichiers
JSON ne doivent pas être accessible de tous.

Url :https://esatic.ci/wp-json/oembed/1.0/embed?url=%2Fembed

Figure 43:traversée de chemin

3. CSRF

Figure 44:Absence d'anti-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).

4. Les cookies non sécurisés

Le test de la performance des cookies nous montre qu’ils ne sont pas sécurisés. Nous avons
remarqué l’absence des propriétés de protection telle que httpOnly. L’image ci-dessous est une
illustration.
Figure 45:Les cookies non sécurisés

E. Composants vulnérables et obsolètes

Cette partie consiste à énumérer les composantes utilisées dans l’application qui ne sont pas à
jour et donne les vulnérabilités qui lui sont associées.

 Le scan du WordPress utilisé nous révèle que le plugin js_composer n’est pas à jour.

Figure 46:Composant js_composer

Il se trouve à l’adresse suivante :

/ext/arscode-ninja-popups/tooltipster/plugins/js_composer/.
Après les recherches sur exploit DB et Google, nous n’avons pas de vulnérabilité associée à
la version 6.5.0 utilisée par l’application.

 La librairie JQuery utilisée est la version 3.1.1

Figure 47:La version de JQuery utilisé

Cette version n’est pas à jour et possède de nombreuses vulnérabilités telles que :

Script intersite (XSS)

Cette vulnérabilité consiste à voler des cookies (source : OWASP HttpOnly) et de détourner
des sessions utilisateur.

Pollution prototype
Cette vulnérabilité consiste à polluer les propriétés sur lesquelles la base de code de
l’application s'appuie pour leur valeur informative, y compris les propriétés de sécurité telles
que les cookies ou les jetons. Et cela provoque le Dénis de service.

F. Échecs d'identification et d'authentification

La phase de reconnaissance nous a permis d’identifier trois (3) comptes administrateurs tels
que : kolo, hermine et admin. Avec ces comptes, nous avons constitué un dictionnaire de
nom d’utilisateur et utiliser rockyou.txt comme liste des mots de passe afin de casser
l’authentification des pages d’administration de wordpress, cpanel et SIGES.
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.

G. Server-side request Forgery (SSRF)

Une application Web peut être vulnérable à une attaque SSRF si elle ne valide pas l'URL de
la ressource distante fournie par l'utilisateur.

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.

Figure 50: Test de SSRF