Vulnix : Solution et explications

I. Présentation

Vulnix est une machine virtuelle volontairement vulnérable qui est diffusée sur le site rebootuser.com . Le principe est d'essayer d'attaquer cette machine virtuelle afin de mieux comprendre l'enjeu de la sécurité et de s'entrainer aux tests d'intrusion afin de mieux cerner certaines failles et procédures de sécurité.

Nous allons ici voir en détail la solution pour venir à bout de cet exercice et également essayer d'expliquer l'ensemble des procédures et failles de sécurité que nous utilisons. Je déconseille fortement aux lecteurs n'ayant pas essayé de venir à bout de cette machine virtuelle de venir lire ce tutoriel. Le but de l'exercice étant avant tout de découvrir les failles de sécurité par soit même.

La machine est à télécharge ici : Télécharger Vulnix

Pour l'installer, il suffit de double cliquer sur le .vmx dans l'archive ZIP en ayant un des produits VMware (Player ou Workstation) installé sur sa machine. Pour ma part, j'utiliserais la distribution KaliLinux virtualisée sous VMware également pour faire ma machine d'attaque, cette distribution est la suite de BackTrack est contient un ensemble d'outils d'attaque et de pentest.

II. Découverte

La première étape de l'attaque consiste simplement à trouver notre machine et à essayer de l'identifier, quels services fournit-elle ? On commence par un simple scan du réseau pour repérer l’IP de notre machine :

nmap –f 192.168.19.1-255

On peut noter certains ports « standard » qui sont généralement des cibles de choix :

• Le port 22 pour le SSH qui permet d’accéder à une session sur le serveur.

• Le port 25 pour le SMTP (envoi de mail) qui permet parfois de faire de l’énumération (lister les utilisateurs).

• Le port 2049 qui semble héberger des partages NFS, on pourra peut-être y récupérer des informations si les droits sur les fichiers et dossiers ne sont pas correctement affectés.

On peut également remarquer des ports inconnus (pour ma part) mais sur lesquels nous pourrions nous attarder afin de voir à quoi ils servent :

•   79 – finger

•   513 – login

•   514 – shell

On peut plus généralement supposer qu’il s’agit d’un serveur hébergeant des services Mail (SMTP, POP3, POP3S, IMAP, IMAPS) et de partage de fichier (NFS) sur lesquels des accès distants sont effectués. Avant d’aller plus loin, nous pouvons faire quelques recherches sur nos « ports inconnus » afin d’en savoir plus sur les rôles de ce serveur, on peut pour cela faire quelques recherches :

Note : Pour vous montrer que l’on peut aborder ce genre d’exercice sans avoir des connaissances complètes et absolues de tous les outils et systèmes qui existent, je vais montrer à chaque niveau les recherches que j’ai effectué (Google) ainsi que les résultats de ces requêtes qui m’ont permis d’avancer dans l’attaque. En plus de vous emmener vers des sites qui vous apporterons de nouvelles connaissances, cela vous donnera une idée de comment obtenir une information lorsque l’on aborde un outil que l’on ne connaît pas forcément mais qu’il faut comprendre pour attaquer.

A. Login /shell

Requête : port 513 login

http://fr.wikipedia.org/wiki/Rlogin

rlogin (Remote login) est donc un service qui permet un accès distant sur une machine. On se doute donc qu’il est lié au service du port suivant (514 – shell/rsh pour Remote Shell), on apprend qu’il comporte des problèmes de sécurité dû à une méthode d’identification non sûre.

Requête : rsh attack

https://services.netscreen.com/restricted/sigupdates/nsm-updates/HTML/RSH:User:USER-ROOT.html

On a ici une description de comment fonctionne le rlogin/rsh. On comprend que l’authentification rsh n’est pas sécurisée car il suffit qu’un utilisateur ait saisi un login et un hôte dans un fichier .rhost dans son home pour qu’une connexion avec ce nom d’utilisateur soit faite sans besoin de mot de passe. Étant donné que les adresses d’hôte peuvent facilement être usurpée, la méthode d’identification et d’authentification n’est pas sécurisée.

Requête : rlogin attack

http://en.wikipedia.org/wiki/Rlogin

On a ici également des informations comme quoi les informations transitent en clair sur le réseau quand un échange et une authentification se fait avec le serveur. Nous avons également une information intéressante quant à la combinaison avec des partages NFS. On apprend en effet qu’une pratique courante consistant à monter le home des utilisateurs via NFS expose rlogin à une attaque en modifiant le fichier .rlogin de l’utilisateur pour permettre l’acceptation de n’importe quel login à la vérification d’authentification. Il se trouve que nous avons justement un service NFS sur notre serveur cible.

B. Finger

Requête : linux service finger 79

http://etutorials.org/Networking/network+security+assessment/Chapter+5.+Assessing+Remote+Information+Services/5.4+finger/

On peut avoir sur ce lien un aperçu de ce qu’il est possible de faire avec finger : lister les utilisateurs connectés et/ou existants sur le serveur et visiblement sans authentification préalable. Cela nous ouvre donc une autre possibilité pour l’énumération des utilisateurs sur le serveur.

III. Prise d’information

Maintenant que nous avons une vue d’ensemble de ce qui se trouve sur notre serveur, nous pouvons essayer d’aller plus loin. Dans un premier temps, nous allons essayer d’avoir plus d’information sur les versions des services qui tournent sur notre cible ainsi que son système d’exploitation. Il est important d’avoir ces informations car bien souvent, les services ne sont pas mis à jour et possèdent des versions anciennes sur lesquelles des failles de sécurité ont peut être été trouvées et divulguées. On utilise pour cela à nouveau nmap :

nmap 192.168.1.132 sV -O –PN

• “O” : Permet de forcer la détection de l’OS

• “Pn” : Permet de considérer l’hôte comme actif (pour passer la phase de détection de l’hôte d’nmap)

• “sV” : Joue avec les ports pour déterminer les informations sur les services en question

On voit donc que l’OS de notre cible est un Linux kernel 2.6. On voit également d’autres informations sur les serveurs (pas forcément leurs versions) qui font tourner les services détectés (Ex : Postfix, Dovecot) ainsi que quelques informations de versions (OpenSSH 5.9). On peut ainsi regarder si l’OpenSSH est à jour.

Requête : latest version openssh

On se retrouvera alors sur le site web d’openSSH (http://www.openssh.com/) qui nous indique que la dernière version est la 6.4 et qu’elle est sortie le 8 novembre 2013. On voit donc que la version d’OpenSSH n’est pas à jour. On peut alors rapidement essayer de voir si des failles de sécurité ont été détectées depuis cette version 5.9. On se rend pour cela sur le site http://www.exploit-db.com/

Ou http://fr.1337day.com/search

On trouve sur ces sites des bases de données qui répertorient un grand nombre de failles de sécurité divulguées selon le service et sa version. On peut potentiellement y trouver des informations et des techniques qui permettront d’attaquer notre hôte.

IV. Énumération

Nous allons maintenant chercher à énumérer les utilisateurs présents sur notre cible. L’énumération nous permet d’entrer dans une autre étape de l’attaque qui est le début des tentatives que nous allons effectuer afin de gagner un accès au serveur. Les étapes précédentes consistaient en une simple prise d’information (plus ou moins poussée). Nous passons maintenant à l’attaque.

A. Finger

On a vu précédemment que Finger était un programme de visionnage des utilisateurs et de leur information en local comme à distance. Quand il est mal configuré, il peut être interrogé à distance sans authentification ce qui permet de faire une énumération des utilisateurs. Depuis la machine d’attaque on peut donc tester différents noms d’utilisateur pour voir la réaction et la réponse de finger. Pour un utilisateur qui n’existe pas :

finger [email protected]

 

Pour un utilisateur qui existe forcément :

finger [email protected]

On voit donc clairement que l’on peut procéder très simplement à une énumération des utilisateurs de notre cible. Mais plutôt que de tout tester et tenter à la main, on peut simplement faire un petit script bash qui automatisera notre énumération. On va donc créer une liste d’utilisateur dans un fichier texte (user.txt) qui se présentera comme cela :

Note : Libre à vous de mettre tous les utilisateurs qui vous passent par la tête ou alors de récupérer une liste d’utilisateur (un « vrai » dictionnaire) en ligne pour l’utiliser dans notre attaque.

Dans un deuxième temps, voici le contenu du script :

On va donc dans un premier temps pinguer notre cible pour voir si celle-ci est disponible puis afficher un résultat (joignable ou non joignable) et arrêter le script par un kill si la cible n’est pas joignable. Dans un second temps nous allons faire une boucle sur la lecture de notre fichier contenant les noms d’utilisateurs (une boucle par ligne, chaque ligne contenant un login) et tester via la commande finger l’utilisateur sur notre cible. On fera un filtre sur la chaine de caractère « Login » qui n’est présente dans le retour de finger uniquement quand une correspondance a été trouvée (quand l’utilisateur existe bien sur la cible) et on affichera une ligne indiquant que la correspondance a été trouvée à l’écran. On rend ensuite notre script exécutable :

chmod +x fingerscript.sh

Puis on l’exécute en mettant en paramètre l’IP de notre cible :

./fingerscript.sh 192.168.19.132

Voici ce que nous pourrons voir (ce résultat n’est valable que pour la liste d’utilisateurs que j’ai ajouté plus haut, vous trouverez peut être plus de correspondance en mettant plus de nom d'utilisateur à tester) :

On commence déjà à avoir des informations sur les utilisateurs. Plus nous faisons de test, plus nous serons précis mais moins nous seront discret.

B. SMTP

Les accès SMTP sont généralement joignable par telnet, on peut alors interroger le serveur en lui lançant des requêtes qui seront traitées par notre cible, on se connecte donc en telnet sur le port SMTP de notre cible :

telnet 192.168.19.132 25

On peut alors vérifier si une adresse mail existe dans la configuration et les enregistrements du serveur sur lequel on se trouve. La plupart des fournisseurs d’accès désactivent cette commande (principalement pour bloquer des techniques de SPAM) mais elles restent autorisées sur beaucoup de serveurs d’entreprise.

La commande VRFY lance une requête sur le serveur qui nous répondra et nous indiquera si l’adresse mail est présente sur le serveur. Pour voir la réaction du serveur dans un cas correcte et un cas incorrect, nous allons faire un premier test :

On voit donc maintenant la forme qu’aura une réponse pour un utilisateur qui existe (ici root qui existe sur toutes les machines Linux) qui sera un code 252 et une réponse pour un utilisateur qui n’existe pas qui aura donc un code 550. On peut donc à nouveau tester différents logins utilisateur à la main. A nouveau, il peut être long et fastidieux de faire ces tests manuels. On peut à nouveau chercher à automatiser notre tâche. Faisons quelques recherches.

Requêtes : SMTP énumération

On arrive donc sur ce lien http://pentestmonkey.net/tools/user-enumeration/smtp-user-enum

Ce site nous informe donc qu’il existe un script qui permet d’automatiser l’énumération des utilisateurs en SMTP. Pour information, ce script est présent nativement dans KaliLinux :

On va donc essayer d’utiliser ce script en lançant la commande suivante :

smtp-enum-user

On a, après les explications des principales options du script, des exemples de commande que nous pouvons reprendre en l’adaptant à notre contexte :

smtp-user-enum –M VRFY –U user.txt -t 192.168.19.132

Note : On réutilise ici le fichier d’utilisateur que nous avons créé tout à l’heure

On a donc le retour suivant (qui peut varier selon les logins présent dans votre fichier user.txt) :

Nous avons maintenant quelques logins que nous pouvons utiliser pour essayer de gagner un accès au serveur.

C. Partage NFS

On a également vu un peu plus tôt lors de nos premiers scans que le port 2049 de notre cible était ouvert et qu’il semblait héberger des partages NFS. On peut rapidement voir les partages fait par une machine en NFS avec la commande « showmount ». On voit d’ailleurs plus de détail en faisant la commande suivante :

man showmount

 

On voit qu’on peut exporter la liste des partages NFS d’un serveur en utilisant l’option « -e ». On peut donc l’utiliser comme suivant :

showmount –e 192.168.19.132

On a justement vu plus tôt qu’il était dangereux de partager en NFS les home des utilisateurs quand un service rlogin était en place. On peut donc essayer d’y accéder.

V. Accéder à la cible

Maintenant que nous avons réussi à avoir des informations sur les utilisateurs et les services de la machine, nous allons pouvoir passer à l'étape d'accès à la cible afin d'avoir un premier ancrage sur celle-ci.

A. Partage NFS

On va donc essayer d’accéder au montage NFS fait sur /home/vulnix :

mkdir /mnt/vulnix
mount 192.168.19.132:/home/vulnix /mnt/vulnix

Le montage semble s’effectuer correctement, cependant, nous ne pouvons pas avoir accès au serveur :

On remarque des permissions/propriétés inhabituelles au niveau de l’utilisateur et du groupe sur le montage vulnix. On peut aisément imaginer que ce n’est pas l’ID du compte réel de l’utilisateur vulnix sur la cible. Nous avons plus clairement réussi à monter le partage qui s’affiche donc avec les mêmes droits que sur le serveur cible mais les accès ne correspondent pas. Linux, pour vérifier si un utilisateur peut avoir accès à un répertoire ou un fichier, va comparer son ID utilisateur et groupe à ceux fixés sur les droits du dossier ou fichier en question. On voit ici que ces ID semblent fossés. On va donc tenter de les découvrir en faisant un brute force. Concrètement, il nous faut tester l’accès avec plusieurs ID utilisateurs différents pour tenter de simuler l’utilisateur vulnix tel qu’il est sur la machine cible, avec un nom « vulnix » et un ID que nous ne connaissons pas mais que nous pouvons simuler. On va donc faire un script qui modifié l’ID de notre utilisateur vulnix à la volée puis qui tente un accès :

On initialise donc notre première valeur « h » qui sera l’ID actuel de notre vulnix, on incrémente cette valeur sur "i"qui sera la valeur suivante de notre identifiant utilisateur. On va ensuite faire une boucle while (« tant que ») notre ID testé est plus petit que 2010 (on pourrait fixer une limite plus grande ou plus petite). Dans ce boucle on fera un remplacement de l’ID utilisateur « vulnix » dans le fichier "/etc/passwd". On va ensuite réaffecter les droits à « vulnix » sur son home car son ID a changé. Ensuite, nous testerons l’accès via SSH (on pourrait utiliser d’autres méthode mais celle-ci me paraissait la plus rapide) on doit auparavant avoir copié la clé publique de root dans le ".ssh/authorized_keys" de vulnix avec les commande suivantes :

ssh-keygen
ssh-id-copy vulnix@localhost

Au travers cette connexion SSH nous allons tester l’accès au répertoire monté dans "/mnt/vulnix" et regarder le code de sortie de cette commande (avec "$ ?"). Si $? vaut 0 c’est que la commande a réussi et donc que nous avons accès au dossier, sinon c’est que $? vaut 1 et que l’accès nous a été refusé. Avec ce script, auquel cas nous refaisons une boucle pour retenter avec l'ID supérieur. Nous aurons une sortie comme suivant à son exécution :

Il semble donc que notre script nous permette l’accès avec vulnix ayant l’ID 2008. Cela signifie que sur notre serveur cible, l’utilisateur vulnix a également l’ID utilisateur 2008 et que, pour les fichiers contenus dans le montage fait, nous agissons au même titre que l’utilisateur vulnix de la machine cible.  Maintenant que nous avons accès à un des home des utilisateurs et que nous savons que le service SSH est installé sur la cible, nous pouvons facilement ajouter une clé publique sur le compte de l’utilisateur vulnix sur la machine cible qui nous permettra d’accéder en SSH au shell de l’utilisateur vulnix sans avoir à saisir de mot de passe. Il nous suffit pour cela de créer un jeu de clé :

ssh-keygen

On va ensuite la copier temporairement notre clé dans "/tmp" :

cp /root/.ssh/id_rsa.pub /tmp

On va donner les droits à vulnix sur cette clé pour qu’il puisse aller la copier à l’endroit voulu :

chown vulnix:vulnix /tmp/id_rsa.pub

On va ensuite se connecter en tant que vulnix sur notre machine d'attaque :

su vulnix

Créer le dossier qui va contenir le fichier qui autorisera les clés et donc l’accès au compte en SSH :

mkdir /mnt/vulnix/.ssh

Et on va pour finir copier la clé publique de root dans le fichier "authorized_keys" de vulnix :

cat /tmp/id_rsa.pub >> /mnt/vulnix/.ssh/authorized_keys

On va ensuite revenir en tant que root sur notre machine d’attaque et tester l’accès en SSH :

ssh [email protected]

Nous avons maintenant accès à notre machine ! L’accès, même en tant que simple utilisateur sans droits particuliers, va nous permettre de passer à l’étape suivante de l’attaque qui est l’élévation de privilège sur notre machine. Mais avant cela, voyons une autre méthode que nous aurions pu utiliser pour gagner un accès à notre serveur.

B. Brute force SSH

Une seconde méthode que nous aurions pu utiliser est le brute force SSH, nous pouvons tenter un brute force sur les comptes que nous avons validés durant la phase d'énumération. Nous allons pour cela utiliser le logiciel « hydra » qui permet de faire des brutes force SSH. Il est déjà installé sur KaliLinux.

Qu'est ce que le “brute-force” ?

Le fait de brute-forcer signifie qu’hydra va tenter plusieurs centaines voir milliers de combinaisons de caractère afin de chercher une correspondance entre le login et un mot de passe. C’est une technique très peu discrète car chaque tentative, fructueuse ou non, est affichée dans les logs. Si une seule IP apparait plusieurs milliers de fois en très peu de temps dans un fichier de logs, cela est vite suspicieux.

Nous utiliserons ici la méthode par dictionnaire qui est souvent moins longue mais efficace qu'en cas de politique de mot de passe "faible". On va pour cela aller télécharger un dictionnaire de mot de passe qui contient généralement les mots de passe les plus couramment utilisés (Ex : « soleil », « 123456 », « password »). L’utilisation de mots de passe faibles de ce genre est beaucoup plus fréquente qu’on ne l’imagine. Pour ma part, je télécharge la liste de mot de passe sur ce lien : http://wiki.skullsecurity.org/Passwords

Je prends ici le fichier « john.txt.bz2 » que je décompresse avec la commande suivante :

bzip2 –d john.txt.bz2

Nous avons tout à l’heure retrouvé trois noms d’utilisateurs qui sont créés sur notre machine cible (root, user et vulnix) , il nous suffit donc d’en faire une liste dans un fichier avec un login par ligne puis d’utiliser ce fichier et le fichier de dictionnaire des mots de passe dans hydra :

hydra -L /root/user.txt -P /root/john.txt 192.168.19.132 ssh –t 2

 Pour information, on pointe donc notre fichier de liste des utilisateurs avec l’option “L”, le fichier dictionnaire des mots de passe avec l’option “P”, on precise ensuite l’hôte et le port/ service à attaquer et on fixe enfin le nombre de processus qui seront affectés à cette tâche (par défaut 16). On se retrouve alors après quelques minutes d’attente avec ce résultat :

Hydra à donc réussi à établir une connexion avec l’utilisateur « user » pour le mot de passe « letmein ». Testons cet accès :

ssh [email protected]

Nous avons à présent deux accès sur notre serveur ce qui étend les possibilités et les droits que nous avons sur celui-ci. On peut donc espérer avoir plus d’information pour l’élévation de privilège. Nous allons dans un premier temps voir les droits que notre utilisateur possède sur le serveur et sur ces services puis tenter d’avoir plus de droit pour atteindre "root".

VI. Élévation de privilèges

Nous allons maintenant faire un « Privilege Escalation », nous avons à présent un accès SSH vers deux utilisateurs sans privilèges intéressants au premier abord, nous allons donc vouloir maintenant prendre le contrôle du serveur, se loguer en root. On va voir si l’utilisateur « vulnix » a des droits supplémentaires que l’utilisateur « root » lui aurait autorisé :

sudo –l

Réponse :

On voit que l’utilisateur « vulnix » a le droit d’édition du fichier « /etc/exports » qui permet de partager des fichiers depuis Linux. C’est grâce à ce fichier que « /home/vulnix » est actuellement partagé. On va donc voir le contenu de ce fichier :

cat /etc/exports

Réponse :

On voit donc bien la ligne qui permet le partage de « /home/vulnix », on voit que le partage est initialisé en « rw » soit lecture/écriture et on remarque également l’option « root_squash ». On peut se renseigner un peu sur cette option.

Requête : NFS root squash

Le premier lien : http://www.inetdoc.net/guides/tutoriel-secu/tutoriel.securite.attaquesprotocoles.nfs.html

On apprend ici que l’option root_squash permet de différencier un root local d’un root externe aux yeux d’un montage effectué sur une autre machine, ce qui est le cas de /home/vulnix.

Étant donné que nous avons un accès en édition sur ce fichier, nous allons passer l’option en « no_root_squash ».

sudoedit /etc/exports

On passe ensuite le « root_squash » en « no_root_squash » et on redémarre le serveur (à défaut de ne pouvoir redémarrer le service) pour que les nouveaux paramètres soient pris en compte (n’ayant pas de moyen de redémarrer le serveur en « vulnix » une coupure électrique fera l’affaire). Une fois de retour sur le serveur, on va chercher à remonter notre partage /home/vulnix sur la machine attaquante :

mount 192.168.19.132 :/home/vulnix /mnt/vulnix

On va ensuite copier la commande “bash” local vers le partage (en tant que root de notre machine d’attaque puisque nous avons maintenant le droit de nous y rendre en root) le fait que ce soit root qui soit considéré comme le créateur de l’exécutable bash dans ce dossier est très important :

cp /bin/bash /mnt/vulnix

On met les droits bit setuid, le bit setuid est un droit spécifique que nous pouvons mettre pour que l’exécution du fichier se fasse avec les droits de celui qui l’a créé plutôt qu’avec les droits de celui qui l’exécute, dans notre cas, le créateur du /mnt/vulnix/bash (qui correspond sur notre cible à /home/vulnix/bash) est root :

chmod 4777 /mnt/vulnix/bash

On va donc ensuite se rendre en SSH sur notre cible en tant que vulnix puis exécuter le /home/vulnix/bash qui, avec le bit setuid, sera exécuté en tant que root (qui est le créateur du fichier aux yeux du système) :

ssh [email protected]
/home/vulnix/bash -p

Nous serons donc root sur le système de notre cible, nous pourrons le vérifier avec la commande suivante :

id

Ou

cd /root

VII. Les précautions à prendre

• Limiter les services qui peuvent être interrogés anonymement

Nous avons vu qu'il était plutôt simple d"effectuer une énumération des utilisateurs présents sur le système via des outils ou des services de la cible. Il font donc systématiquement vérifier que les outils utilisés sont assez robustes est ne présentent pas de possibilités d'être interrogés sans authentification préalable.

• Vérifier les droits

Le contrôle des droits sur les fichiers, les dossiers et les exécutables est une procédure qui peut s'avérer difficile selon la taille de votre système mais c'est une des principales faiblesses du système UNIX qui, rappelons le, dispose de droits par défaut plutôt permissifs (voir Umask).

• Vérifier les procédures de sécurité des services utilisés

Certains services largement utilisés au début de l'air informatique sont bien souvent les premières cibles d'une attaque car, à l'époque, la sécurité ne prenait pas une place importante dans la mise en place d'un système d'information. On a vu que les processus tel que SMTP, finger ou plus largement FTP ou telnet sont par défaut vulnérable de par leur fonctionnement ou leur configuration et permettent de voler des informations lors des échanges ou des connexions. Il faut donc veiller lorsqu'un outil est choisi pour accomplir une tâche que son fonctionnement est un minimum sécurisé et et maintenu au fil des années.

• Utiliser des mots de passe fort

Les techniques d'attaque par brute force sont certes peut discrètes mais fonctionnent très souvent lorsque l'on s'attaque à des comptes d’utilisateurs "normaux" et non professionnels de l'informatique qui utilisent souvent des mots de passe dit "faible". Il faut donc veiller, à la création d'un compte ou au changement d'un mot de passe, que l'accès soit protégé par une mot de passe suffisamment fort et répondant à des minimas précis de sécurité (nombre de caractère, type de caractère utilisé, non sens du mot de passe, etc.).

• Limiter le plus possible l’élévation de privilège d'un utilisateur

Il est souvent très pratique de donner des droits supplémentaires à des comptes utilisateurs dans la gestion quotidienne de serveurs/services mais ces permissions inhabituelles sont très souvent les cibles de la phase "privilege escalation" qui consiste à élever les privilèges d'un utilisateur "normal". Il faut donc être très prudent et minimiser les droits d'un utilisateur au sein d'un système.