Rapport Audit Sécurité - ensiie7

Ecole Nationale Supérieure d’Informatique pour l’Industrie et l’Entreprise

AUDIT DE LA SECURITE DES SYSTEMES D'INFORMATION Rapport relatif au test d’intrusion de la machine ​“ensiie7”

Encadrant :​ Éric Carter

Younes Fkih Sarye Haddadi Lucas Golse

PREAMBULE Le présent rapport vise à exposer les conclusions de l’audit de la sécurité des systèmes d’information de la machine ​“ensiie7”, qui a été réalisé dans le cadre du projet de l’UE de sécurité avancée. Cet audit avait pour but d’évaluer la sécurité de la machine via l’analyse des résultats de tests de résistance du système (par le biais d’attaques explicitées au sein de ce document) menés sur celle-ci. On parle de ​volet intrusif de l’audit de sécurité.

Il convient néanmoins de rappeler ici que les constats d’audit établis reposent sur l'état moyen stable de l’état de l’art en sécurité des systèmes d’information. En effet, les méthodes de tests, d’analyse comme les outils sont en évolution constante. Par ailleurs, un échantillonnage différent, l’évolution permanente de l’état du système d’information limitent la reproductivité de certains constats.

1

Sommaire

Synthèse Vulnérabilités identifiées par les tests d’intrusion Recommandations issues des tests d’intrusion

3 5 5

Contexte des tests d’intrusion Objectif du test d’intrusion Cadre des tests d’intrusion Méthodologie

7 7 7 7

Tests d’intrusion Reconnaissance réseau Identification du système d’exploitation Identification des services Recherche de vulnérabilités Tentatives d’exploitation

8 8 8 9 12 19

Annexes Annexe 1 : métriques

25 25

2

I. Synthèse Les tests d’intrusion ont été réalisés dans une configuration de type boîte noire (c’est-à-dire sans connaissances préalables du système visé). Ceci permet de modéliser l’attaque du système par une personne externe ne possédant pas d’informations concernant celui-ci. Il est à noter qu’aucune action pouvant altérer les machines n’a été menée.

Il ressort du présent audit que la machine est impactée par plusieurs vulnérabilités critiques.

Le traitement de ces dernières constitue une nécessité. En effet, leur maintien peuvent entraîner, via leur exploitation, une altération, complète ou partielle, des qualités de confidentialité, d’intégrité et de disponibilité de la machine. Le niveau de sécurité du site est considéré comme ​faible au regard du niveau de criticité et de l’impact des vulnérabilités découvertes.

Liste des vulnérabilités notables : V2​ Remote File Inclusion possible sur la page info.php : ● Ce type de vulnérabilité permet d’exécuter ou d’injecter un code malveillant sur le serveur. ● Il est recommandé de mettre en place une liste blanche des fichiers autorisés à la lecture et à l’inclure pour ce type de requête.

V3​ Informations sur le système et le serveur Web dévoilées : ● Une page fait appel à une fonction de php et affiche toute la configuration du serveur. et son environnement. ● Il est recommandé de supprimer cette page. ​V4​ Vulnérabilités liées à une version obsolète de PHP : ● La version utilisée concernant PHP est obsolète et présente de nombreuses vulnérabilités à même d’être employées par un utilisateur malveillant. Parmi celle-ci, la possibilité d’une élévation de privilège constitue un risque avéré. Néanmoins, la configuration du serveur permet de prévenir l’utilisation de la vulnérabilité en question. ● Il est cependant recommandé de mettre à jour la version de PHP afin de prévenir l’utilisation de vulnérabilités qui lui sont inhérentes, par exemple dans le cadre d’une attaque DoS (Denial of Service attack).

V5​ Vulnérabilité du noyau de système d’exploitation : ● Reposant sur le déréférencement d’un pointeur NULL, l’exploitation de cette vulnérabilité permet à un utilisateur soit d'exécuter du code avec une élévation de privilège, soit de mener une attaque DoS. ● Il est recommandé de mettre à jour le système d’exploitation.

3

V6​ Vulnérabilité liée à la version de Openssh : ● La version utilisée n’arrivant pas à bien détecter les paquets ssh à blocs dupliqués, une attaque de type DoS peut être menée sur la machine, entraînant par là-même une compromission de la disponibilité de la machine. ● Une mise à jour de la version de sshd est nécessaire.

V7​ Vulnérabilité liée à un accès non approprié pour certains répertoires web : ● La configuration actuelle des règles d’accès au serveur permet l'accès et le téléchargement des clés publiques d’identification ssh de certains utilisateurs. ● Cette attaque permet d’avoir un accès shell à la machine avec les privilèges du compte utilisé. Il est à noter que dans ce cas, une élévation de privilèges par l’attaquant est possible. ● La configuration du serveur est à revoir.

V8​ Vulnérabilité liée au management du parc informatique : ● Dans le cas présent, dès qu’un nouvel utilisateur arrive, le système lui envoie un email contenant un couple de données très sensibles : il s’agit de ​son identifiant et mot de passe associé. Il apparaît que ces données sont transmises sans être préalablement chiffrées (elles sont diffusées en clair). Cette caractéristique est véritablement problématique. ● Il est conseillé de ne plus utiliser un tel procédé et de lui préférer l’envoi d’un mail d’accueil. Dans le cas d’oubli du mot de passe, l’utilisation de mots de passe temporaires (à changer dans les plus brefs délais) transmis par l’administrateur via un mail est conseillé.

V9​ Vulnérabilité liée aux droits d’utilisateurs : ● Un utilisateur (au moins) peut exécuter, et ce sans être sudoeur, l’éditeur vi en tant que root. Cet éditeur permet l'exécution d’un shell, et donc l’accès à un shell root pour un utilisateur (au moins) ne disposant de l’autorisation requise. ● Les droits d'exécution en super-utilisateur sont à revoir.

4

A. Vulnérabilités identifiées par les tests d’intrusion Identifian t

Réf. constat

Nature (Org/Tech)

V1

V1

Tech

V2

V2

V3

Description de la vulnérabilité

Facilité d’exploitatio n

Impact

Niveau du risque

L’en-tête X-XSS-Protection n’est pas renseigné

Elevée

Mineur

Mineur

Tech

Possibilité d’une RFI

Facile

Important

Majeur

V3

Tech

Informations de configuration de PHP accessibles

Facile

Majeur

Critique

V4

V4

Tech

Integer overflow via une fonction PHP

Facile

Important

Majeur

V5

V5

Tech

Une fonction du noyau possède une faille

Facile

Critique

Critique

V6

V6

Tech

Déni de service via sshd

Difficile

Critique

Important

V7

V7

Tech

Dossiers privés accessible de l’extérieur

Facile

Critique

Critique

V8

V8

Org

Information critique à protéger

Faible

Majeur

Critique

V9

V9

Tech

Possibilité d’un shell root via l’éditeur vi

Faible

Critique

Critique

V10

V10

Tech

En-tête X-Frame-Options n’est pas renseigné

Faible

Mineur

Mineur

V11

V11

Tech

L’en-tête X-Content-Type n’est pas renseigné

Faible

Mineur

Mineur

B. Recommandations issues des tests d’intrusion Identifian t

Vulnérabilit é couverte

Description de la recommandation

R1

V1

Positionner l’en-tête X-XSS-Protection dans les réponses HTTP

R2

V2

Vérifier les entrées utilisateur d’un fichier php

R3

V3

Supprimer une page web

Difficulté de mise en oeuvre

Priorité de traitement

Faible

Faible

Importante

Moyenne

Faible

Elevée 5

R4

V4

Mettre à jour la version de PHP

Faible

Moyenne

R5

V5

Mettre à jour le noyau Linux.

Moyenne

Elevée

R6

V6

Mettre à jour la version du protocole SSH

Faible

Elevée

R7

V7

Modifier la configuration du serveur

Faible

Elevée

R8

V8

Modification du corp de l’e-mail automatique

Facile

Elevée

R9

V9

Revoir les permissions d’exécution en super-utilisateur

Moyenne

Elevée

R10

V10

Positionner l’en-tête X-Frame-Options dans les réponses HTTP

Faible

Faible

R11

V11

Positionner l’en-tête X-Content-Type dans les réponses HTTP

Faible

Faible

6

II. Contexte des tests d’intrusion A. Objectif du test d’intrusion L'objectif d'un test d'intrusion est d'évaluer le niveau de sécurité d'une cible face aux vulnérabilités et techniques d'attaque connues. Les menaces identifiées voient alors leur criticité qualifiée. Un score CVSS3 est calculé selon leur impact et leur facilité d'exploitation.

B. Cadre des tests d’intrusion La cible du test d'intrusion est une machine accessible depuis l’IP fixe suivante :

192.168.2.100 La cible du test d’intrusion a été auditée à partir de l’adresse IP suivante :

192.168.2.1 Le test d'intrusion s'est déroulé sous l’angle d'attaque de la ​Boîte noire. En effet, l'auditeur ne disposait que de l’IP de la machine cible. Il se positionne donc dans des conditions réelles d’attaquant externe. La machine nous a cependant été remise avec les indications suivantes : ​Reconnaissance - Metasploit - Élévation de privilèges.

C. Méthodologie Dans le cadre de ce test, la méthodologie suivante a été suivie : ● La machine vulnérable a été initialement placée dans un réseau isolé (192.168.2.0/24). ● Une reconnaissance réseau suivie d’une identification des services disponibles a été effectuée. ● À la suite de cela, des recherches de vulnérabilités ont été menées, à l’aide de scans et de recherches manuelles. Les données ainsi recueillies ont permis la mise en place d’un scénario d’attaque. ● Enfin, des tentatives d’exploitation de ces vulnérabilités ont été menées afin d'essayer soit d’accéder à des données protégées, soit de procéder à une élévation de privilèges.

7

III. Tests d’intrusion A. Reconnaissance réseau La reconnaissance réseau permet d’identifier la présence d’hôte via leur IP. Cette étape importante permet d’obtenir une cartographie du réseau cible. >​ netdiscover -i vboxnet1 -r 192.168.2.0/24

Conclusion : La reconnaissance réseau nous a permis d’identifier la présence d’une seconde IP sur la machine cible différente de celle fournie par le client : ● 192.168.2.100 :​ IP fournit par le client. ● 192.168.2.101 :​ seconde IP de la machine. ● 192.168.2.250 :​ IP du serveur DHCP de notre réseau privé.

L’absence d’information de la part du client en ce qui concerne l’existence de cette adresse nous pousse à nous interroger sur la possibilité d’accès à des informations confidentielles via cette adresse ou sur la présence de failles de sécurité à même d’être exploitées par son biais.

B. Identification du système d’exploitation L’identification du système d’exploitation est une étape clé de la phase de reconnaissance. Elle permet dans un premier temps d’identifier la version du système et ainsi de déterminer les vulnérabilités système pouvant être présentes. De plus, cette information permet d’identifier les technologies pouvant être utilisées.

8

>​ nmap -O -v 192.168.2.100

Conclusion : Le système d’exploitation utilisé a été identifié, il s’agit d’un Linux 2.6.32. ​Le support de cette version a expiré en mai 2013​.​ Une mise à jour du noyau est nécessaire.

V5 - Critique

Déni de service via le noyau Linux

6.9

Une faille dans la commande pipe permet de causer une déni de service (crash du système suite au déréférencement d’un pointeur NULL) ou de procéder à une élévation de privilège en essayer d’ouvrir un pipe anonyme via /proc/*/fd/ pathname. L’exploitation de cette vulnérabilité permet une compromission totale des propriétés de confidentialités et de disponibilités de la machine.

Elément concerné : Le fichier fs/pipe.c des versions du noyau Linux antérieures à 2.6.32-rc6 Nature

Facilité d’exploitation

Impact

Technique

Facile

Critique

Recommandation 5

Mettre à jour le noyau Linux

Mettre à jour le noyau Linux dans une version supérieure à 2.6.32.

Priorité de traitement

Difficulté de mise en oeuvre

Elevée

Moyenne

C. Identification des services L’identification des services est une étape critique afin de déterminer l’utilité d’une machine. Il n’est pas rare qu’une cible propose un service non-sécurisé ou obsolète, permettant ainsi de déterminer des scénarios d’attaques envisageables.

Scan de la première IP : >​ nmap -A -sV 192.168.2.100 9

Scan de la seconde IP : >​ nmap -A -sV 192.168.2.101

Conclusion : Plusieurs services ont pu être identifiés sur la première IP : ● Un service FTP sur le port TCP 20/21, dont le port utilisé pour faire transiter les données est fermé. ● Un service SSH sur le port TCP 22 possédant trois empreintes de clé, chiffrées respectivement en RSA1, DSA, RSA. La version du protocole SSH utilisée est v1. ● Un service SMTP sur le port TCP 25. ● Un serveur Apache à la version 2.0.55 sur le port TCP 80 utilisant PHP version 5.1.2. ● Un service pop3 sur le port 110. ● Un service UW imap sur le port 143. ● Un service HTTPS sur le port TCP 443 qui est fermé.

10

Au vu des services disponibles via cette adresse IP, il est probable que derrière celle-ci se trouve un serveur mail.

Aussi, les trois techniques de chiffrement utilisées pour les clés publiques du service SSH offrent des niveaux de sécurité pouvant être considérés comme équivalents.

Seul un service a pu être identifié sur la seconde adresse IP : ● Un service HTTP sur le port TCP 80, utilisant Apache dans sa version 2.0.55 et PHP 5.1.2 Il n’y a qu’un seul service actif sur la seconde adresse IP de la cible. La surface d’attaque est ainsi réduite au maximum et ne laisse que peu d’opportunité à un attaquant, ​ce qui est une bonne pratique de sécurité.

Remarque : Un certain nombre de mise à jour sont nécessaires, en particulier, ​les versions d’Apache et de PHP présentent sur les deux adresses IP sont dépassées d’environ 10 ans​, elles sont datées de 2005/2006 et les dernières versions stables d’Apache et de PHP5 datent de 2016. Il convient de mettre à jour ces modules.

De plus, il existe une version plus récente du protocole SSH offrant un meilleur niveau de sécurité que la version actuelle.

Si les services FTP et HTTPS ne sont pas utilisés, il conviendrait de les supprimer plutôt que de fermer les ports qui leur sont associés, et ce afin de limiter la surface d’attaque comme cela a été fait sur 192.168.2.101.

V4 - Majeur

Integer overflow via une fonction PHP

Score CSSV

Un Integer overflow est possible via la fonction shmop_read dans les versions de PHP antérieures à 5.3.6 permettant ainsi à un attaquant ayant accès à la machine de la faire crasher en écrivant un script PHP et en l'exécutant ce qui rendra les services offerts par ma machine indisponible. A la suite de cela, il pourra éventuellement toucher dans une zone de mémoire non permise et déclencher une attaque.

Elément concerné : Le fichier ext/shmop/shmop.c dans les versions de PHP inférieur à 5.3.6. Plus particulièrement la fonction shmop_read.

Nature

Facilité d’exploitation

Impact

Technique

Facile

Important

11

Recommandation 4

Titre de la recommandation

En mettant à jour PHP dans une version supérieur à 5.3.6 ou en possédant une mémoire de plus de 2GO la vulnérabilité ne sera plus exploitable. Une autre solution serait d’inhiber (en les mettant sous commentaire) les extensions de PHP accédant à la mémoire partagée comme c’est le cas de la fonction présente.

Priorité de traitement

Difficulté de mise en oeuvre

Moyenne

Faible

V6 - Important

Déni de service via sshd

7.8

Avec sshd dans OpenSSH avant la version 4.4, en utilisant la version 1 du protocole SSH, permet à un attaquant externe de causer un déni de service (sur-consommation de CPU) via un paquet SSH ne contenant des bloques en doubles, ce qui n’est pas bien traité par le détecteur d’attaque.

L’impact sur la disponibilité de la machine après exploitation de cette vulnérabilité est complet.

Elément concerné : Le service SSH sur le port TCP 22 disponible sur l’IP 192.168.2.100 Nature

Facilité d’exploitation

Impact

Technique

Difficile

Critique

Recommandation 6

Mettre à jour la version du protocole SSH

Utiliser la version 2 du protocole SSH. Priorité de traitement

Difficulté de mise en oeuvre

Elevée

Faible

D. Recherche de vulnérabilités La recherche de vulnérabilité à été faite via des scans et une recherche manuelle. ●

Utilisation de l’outils Nikto pour scanner le serveur à la recherche de pages et de dossiers connus :

Scan de la première IP : >​ nikto -host http://192.168.2.100

12

Scan de la seconde IP : >​ nikto -host http://192.168.2.101

L’outil Nikto nous ayant dévoilé la possibilité d’utilisation de la méthode POST, nous allons nous en servir pour voir si nous avons la possibilité d’uploader des fichiers sur la machine cible. ●

Utilisation de l’outil cURL, pour essayer d’uploader un fichier sur le serveur :

13

Conclusion : La découverte de ressources a permis de mettre en évidence un certain nombre de pages intéressantes : ● Sur la première adresse IP ○ /info.php : la présence de cette page offre de nombreuses informations sur ​la configuration de PHP ? ou serveur ? ou systeme ? ou php + serveur ? ○ /info.php?file=http://cirt.net/rfiinc.txt? : cette page ouvre la possibilité d’une RFI ● Sur la seconde adresse IP : ○ /~root/ : la présence de ce répertoire indique que le serveur peut être un serveur multi-utilisateur. De plus, ce répertoire est le répertoire root et nous est accessible.

Plusieurs autres vulnérabilités mineurs ont aussi été identifiées.

V3 - Critique

Informations de configuration PHP

Score CSSV

Une page contenant les informations de configuration de PHP est accessible, cette page fournit à un attaquant un grande quantité d’informations pouvant l’aider à mettre en place une attaque.

Elément concerné : La page /info.php accessible depuis l’IP 192.168.2.100.

Nature

Facilité d’exploitation

Impact

Technique

Facile

Majeur

14

Recommandation 3

Supprimer la page /info.php

Supprimer la page /info.php.

Priorité de traitement

Difficulté de mise en oeuvre

Elevée

Faible

V2 - Majeur

Possibilité d’une RFI

Score CSSV

Une RFI pourrait être possible via la page /info.php. Un attaquant pourrait inclure un fichier distant et conduire à l’exécution d’un code sur le serveur web.

Après plusieurs tests, nous n'avons pas pu procéder à une RFI. Elément concerné : La page /info.php accessible depuis l’IP 192.168.2.100 Nature

Facilité d’exploitation

Impact

Technique

Facile

Important

Recommandation 2

Vérifier les entrées utilisateurs

Procéder à une vérification des entrées utilisateur au niveau du fichier info.php, s’il n’a pas été supprimé suite à la recommandation R3. Vérifier de même les autres pages disposant d’un champ input de type ‘?file=’.

Priorité de traitement

Difficulté de mise en oeuvre

Moyenne

Importante

V10 - Mineur

En-tête X-Frame-Options n’est pas renseigné

CSSV - 4,3

L’en-tête X-Frame-Options n’est pas inclus dans les réponses HTTP. Elles ne sont donc pas protégées contre les attaques de « Clickjacking », où les pages du site seraient chargées dans des sites tiers non légitimes.

Elément concerné : Les en têtes HTTP de chaque page web.

Nature

Facilité d’exploitation

Impact 15

Technique

Recommandation 10

Facile

Mineur

Positionner l’en-tête X-Frame-Options dans les réponses HTTP

Positionner l’en-tête X-Frame-Options dans les réponses HTTP avec les valeurs suivantes suivant le cas d’utilisation : ● DENY : La page ne pourra être chargée dans une balise de type frame, quel que soit le site d’origine. ● SAMEORIGIN : La page ne pourra être chargée dans une balise de type frame que si cette même page est à l’origine de la requête. ● ALLOW-FROM uri : La page ne peut être chargée dans une balise de type frame uniquement depuis la page spécifiée (uri) Priorité de traitement

Difficulté de mise en oeuvre

Faible

Faible

V1 - Mineur

L’en-tête X-XSS-Protection n’est pas renseigné

CSSV - 6,5

L’en-tête X-XSS-Protection n’est pas positionné, prévenant par là-même l’activation des mécanismes de sécurité que proposent les navigateurs récents pour mitiger les risques d’attaques de type « Cross-site Scripting » (XSS).

NB : des mécanismes de protection propres aux sites sont en place. Cette option rajoute une couche de sécurité.

Elément concerné : Les en têtes HTTP de chaque page web.

Nature

Facilité d’exploitation

Impact

Technique

Facile

Mineur

Recommandation 1

Positionner l’en-tête X-XSS-Protection dans les réponses HTTP

Positionner l’en-tête X-XSS-Protection dans les réponses HTTP avec la valeur « 1 ».

Priorité de traitement

Difficulté de mise en oeuvre

Faible

Faible

16

V11 - Mineur

L’en-tête X-Content-Type n’est pas renseigné

CSSV - 6,5

L’en-tête X-Content-Type n’est pas inclus dans les réponses HTTP. Elles ne sont donc pas protégées contre le « MIME Sniffing » laissant ainsi l’opportunité à un attaquant de mener des attaques de type « Cross-Site Scripting ».

NB : Seules les vieilles versions de Mozilla Firefox et Internet Explorer permettent l’exploitation de cette vulnérabilité.

Elément concerné : Les en têtes HTTP de chaque page web.

Nature

Facilité d’exploitation

Impact

Technique

Facile

Mineur

Recommandation 11

Positionner l’en-tête X-Content-Type dans les réponses HTTP

Positionner l’en-tête X-Content-Type dans les réponses HTTP avec la valeur « nosniff ».

Priorité de traitement

Difficulté de mise en oeuvre

Faible

Faible

●

Utilisation de l’outil Metasploit pour effectuer un scan des utilisateurs FTP :

La présence du répertoire ​/~root indiquant la possibilité pour le serveur d’être un serveur multi-utilisateur, nous avons essayé de faire une énumération des utilisateurs FTP. Nous détectons des utilisateurs possédant des logins et mots de passe avec une attaque par dictionnaire. Cependant, le serveur met fin à toute connection après authentification.

Cette piste ne nous a par conséquent mené nulle part. ●

Utilisation de l’outil « Metasploit » pour un scan des utilisateurs SMTP :

Après utilisation de plusieurs dictionnaires, nous avons pu trouver une liste d’utilisateurs du serveur.

17

●

Tentatives d’accès direct aux dossiers utilisateurs :

18

Nous avons essayé d’accéder aux ​home respectifs de chaque utilisateur afin de voir si ceux-ci contenaient des informations intéressantes. Cette action n’a néanmoins pas eu d’effets probants. Etant donné que les clés d'authentification SSH sont stockés dans le dossier /.ssh, nous avons essayé d’y accéder, et ce, pour chaque utilisateur. La clé d’identification de l’utilisateur ​pirrip a été trouvée.

Remarque : Une configuration du serveur Apache permet d'empêcher l'accès à ce dossier.

V7 - Critique

Accès à des fichiers privés

Score CSSV

Un attaquant externe n’ayant aucun contrôle sur la machine peut avoir accès en lecture au dossier .ssh de chaque compte utilisateur est accessible. Cet état de fait remet en cause la qualité de confidentialité des clés d’authentification SSH des utilisateurs de machine.

Elément concerné : Le dossier /.ssh situé dans le home de chaque user.

Nature

Facilité d’exploitation

Impact

Technique

Facile

Critique

Recommandation 7

Reconfiguration du fichier serveur

Configurer le fichier d’apache httpd-userdir.conf afin d’interdire tout accès aux dossiers .ssh Priorité de traitement

Difficulté de mise en oeuvre

Elevée

Faible

E. Tentatives d’exploitation Le premier scénario d’attaque que nous avons mis au point fût d’utiliser la vulnérabilité V2 exposée plus haut au sein du présent document (correspondant à la CVE-2009-3547). Un fichier ​pipe.c fut téléchargé de exploitDB. Il s'agira donc d’uploader ce fichier sur la machine cible via le compte de ​pirrip dont nous avons la clé d’authentification SSH puis de le compiler et de l'exécuter sur la cible.

Dans un premier temps, nous avons procédé à une vérification de la version du noyau en nous connectant en SSH sur la machine via le compte de ​pirrip.

19

>​ uname -ra

Cette commande confirme la version du système que nous avions détecté précédemment via l’outil nmap, et que celui-ci est donc vulnérable face à la CVE-2009-3547.

Suite à cette introduction, nous avons uploader le fichier ​pipe.c sur la machine cible via la commande ​scp ​de ssh. Seulement, il se trouve que la machine cible ne possède pas de compilateur C d’installé. ​Il convient de noter que la suppression des utilitaires qui ne sont pas usités sur la machine constitue une bonne pratique. Nous avons alors pensé à compiler ​pipe.c sur notre machine pour ensuite envoyer l'exécutable sur la machine cible. La dépendance en librairies et la différence d’architecture entre la machine d’attaque et la machine cible ont cependant tenu en échec la mise oeuvre de cette CVE. A la suite à cela, nous nous sommes mis à la recherche de nouvelles pistes pour procéder à une élévation de privilège. Nous avons commencé par essayer de trouver le mot de passe de ​pirrip afin d’utiliser la commande ​sudo -s​. La reconnaissance faite initialement nous ayant permis de voir que la machine possède un serveur de mail, nous avons donc utilisé la fonction ​mailx​.

>​ mailx

Le septième message de la boite e-mail est un message informant p ​ irrip de ses identifiants.

20

Remarque : Les utilisateurs lamda ont souvent peu de notions sur les bonnes manières en sécurité informatique. Lorsqu’il leur est communiqué des informations sensibles, une bonne pratique et de les informer de ces bonnes pratiques. Dans le cas présent, il faudrait leur signaler de modifier le mot de passe qui leur a été communiqué dès leur première connection.

V8 - Critique

Informations critique à protéger

Score CSSV

L’e-mail automatique envoyé afin d’informer l’utilisateur de ses identifiants se contente de rappeler lesdites informations. Il est possible que l’utilisateur en question ne supprime pas cet email et ne modifie pas son mot de passe. Un attaquant ayant accès à sa boîte e-mail peut alors avoir accès à ses identifiants en retrouvant l’e-mail envoyé. La qualité de confidentialité des informations contenues sur ce compte utilisateur sera alors compromise. Des conséquences plus graves peuvent survenir si l’utilisateur en question à des droits super-utilisateur.

Elément concerné : L’e-mail automatique de rappel l'identifiant.

Nature

Facilité d’exploitation

Impact

Organisationnelle

Faible

Majeur

Recommandation 8

Informer les utilisateurs modifier leur mot de passe

Ajouter la ligne suivante à l’e-mail communiquant aux utilisateurs leur mot de passe : “Ce mot de passe vous a été attribué automatique, veuillez le modifier dès votre première utilisation.”

Priorité de traitement

Difficulté de mise en oeuvre

Elevée

Faible

Nous disposons maintenant du mot de passe de l’utilisateur ​pirrip. Nous tentons donc d’avoir un accès root sur le shell via la commande : >​ sudo -s

L'exécution de cette commande nous permet de voir que pirrip ne fait pas partie des sudoers​. ​Ceci est un bon point à mentionner, en effet il est probable que les permissions d’accès root au shell soit maintenue par une liste blanche. Il n’est pas rare qu’aucun filtrage ne soit fait sur les permissions utilisateurs à ce niveau.

21

Nous continuons donc notre tentative d’exploitation en listant les commandes que ​pirrip peut exécuter avec des droits super-utilisateur via la commande : >​ sudo -l

L'exécution de cette commande révèle quelque chose d'intéressant, ​pirrip à la permission d'exécuter l’éditeur de texte vi en tant que root​. Cette éditeur de texte en ligne de commande à la faculté de pouvoir exécuter un shell via la commande : >​ :!/bin/sh

La commande ​id​ nous permet de vérifier que nous sommes bien root sur ce nouveau shell.

Remarque : Bien que certains utilisateurs aient besoin d’une permission root pour modifier certains fichiers de configuration, la possession de cette permission sur l’éditeur de texte vi induit une vulnérabilité. En effet, vi peut lancer un shell et donc donner accès à un shell root à un utilisateur non autorisé.

V9 - Critique

Shell root via l’éditeur vi

Score CSSV

L’éditeur de texte vi permet l'exécution de la commande ‘/bin/sh’ donnant accès à un shell. Les utilisateurs ayant comme permission de lancer vi en super-utilisateur tout en n’ayant la la possibilité de passer super-utilisateur pourrait se servir de cette possibilité pour avoir accès à un shell root conduisant à une compromission totale de la machine.

22

Elément concerné : Les utilisateurs pouvant exécuter /usr/bin/vi via la commande sudo.

Nature

Facilité d’exploitation

Impact

Technique

Faible

Critique

Recommandation 9

Supprimer la permission de lancer vi en super utilisateur

Supprimer, pour tous les utilisateurs n’étant sudoers, la permission de lancer vi en super-utilisateur.

Accorder la permission d'exécution en super-utilisateur sur un autre éditeur de texte ne pouvant pas lancer de terminal pour les utilisateurs qui ont besoin de la permission précédente, pour, par exemple éditer des fichiers de configuration.

Priorité de traitement

Difficulté de mise en oeuvre

Elevée

Moyenne

Nous pouvons dès lors accéder au fichier ‘/etc/shadow’, qui n’est lisible que par l’utilisateur root, en exécutant la commande : >​ vi /etc/shadow

La modification de tous les mots de passe (y compris celui du compte root) est possible. Il nous suffit de remplacer le hash de chacun des mots de passe par celui de ​pirrip (situé dans le champ à droite du nom d’utilisateur). Ainsi nous pourrons nous connecter à chacun de ces comptes.

23

Conclusion de la phase d’exploitation : L'accès public aux différents dossiers /.ssh, la mauvaise pratique d’un utilisateur ayant gardé un email contenant son mot de passe ainsi que la gestion des droits super-utilisateurs ont compté parmi les éléments déterminants ayant permis d’avoir un shell root sur la machine cible entraînant une compromission totale de celle-ci.

24

IV. Annexes A. Annexe 1 : métriques Les vulnérabilités, qu’elles soient d’origine technique ou organisationnelle, sont classées en fonction du risque qu’elles font peser sur le système d’information, c'est-à-dire en fonction de l’impact de la vulnérabilité sur le système d’information et de sa difficulté d’exploitation.

Le ​niveau du risque lié à chaque vulnérabilité est apprécié selon l’échelle de valeur suivante : ● Mineur : faible risque sur le système d’information et pouvant nécessiter une correction ● Important : risque modéré sur le système d’information et nécessitant une correction à moyen terme ● Majeur : risque majeur sur le système d’information nécessitant une correction à court terme ● Critique : risque critique sur le système d’information et nécessitant une correction immédiate ou imposant un arrêt immédiat du service.

La ​facilité d’exploitation correspond au niveau d’expertise et aux moyens nécessaires à la réalisation de l’attaque. Elle est appréciée selon l’échelle suivante : ● Facile : exploitation triviale, sans outil particulier, ● Modérée : exploitation nécessitant des techniques simples et des outils disponibles publiquement, ● Elevée : exploitation de vulnérabilités publiques nécessitant des compétences en sécurité des systèmes d’information et le développement d’outils simples, ● Difficile : exploitation de vulnérabilités non publiées nécessitant une expertise en sécurité des systèmes d’information et le développement d’outils spécifiques et ciblés.

L’​impact correspond aux conséquences que l’exploitation de la vulnérabilité peut entraîner sur le système d’information de l’audité. Il est apprécié selon l’échelle suivante : ● Mineur : pas de conséquences directes sur la sécurité du système d’information audité. ● Important : conséquences isolées sur des points précis du système d’information audité, ● Majeur : conséquences restreintes sur une partie du système d’information audité, ● Critique : conséquences généralisées sur l’ensemble du système d'information audité.

25

Le tableau suivant indique le niveau de risque inhérent à chaque vulnérabilité découverte, en fonction de leur difficulté d’exploitation et de leur impact présumé : Facilité d’exploitation

Difficile

Elevée

Modérée

Facile

Mineur

Mineur

Mineur

Important

Majeur

Important

Mineur

Important

Important

Majeur

Majeur

Important

Majeur

Majeur

Critique

Critique

Important

Majeur

Critique

Critique

Impact

Tableau : niveau de risque inhérent à chaque vulnérabilité

26