CTF – no exploiting me – Feat DirtyC0w

novembre 2, 2016

Au programme de cet article, l’élévation de privilège sur le CTF ‘no exploiting me’ sorti il y a quelques temps déjà, produit par Brian Wallace AKA « bwall’, AKA « bot_hunter ».

En errant sur Root-me en quête de CTF, je me suis arrêté cette fois sur le CTF « no exploiting me ». Je m’y étais déjà cassé un peu les dents il y a quelques temps, mais avec la découverte de Dirty Cow, j’ai eu l’envie de m’y replonger. Pour ceux désirant récupérer la VM, elle est téléchargeable directement sur vulnhub

J’ai pour habitude d’utiliser VMware workstation pour mes testes/ctf, la VM étant au format VDI j’ai dû tout simplement :

exploitingme

la VM étant lancée, il n’y a plus qu’a s’y mettre.

NMAP m’indique que la cible se situe sur la 192.168.211.137

Le port 80 nous conduit vers une page web d’authentification classique :

noexploitingme-2

Mais NMAP nous indique surtout la présence de MongoDB. MongoDB est un système de base de données classifié de NOSQL. C’est un système orienté « document » contrairement à un système de base de données relationnelles où les informations sont stockées par ligne dans des tables, dans MongoDB, l’information est modélisée sur un document au format JSON (Javascript Object Notation).  Mais plus important encore, MongoDB ne doit pas être exposé sur internet car il ne dispose d’aucun système d’authentification propre, comme celui de Mysql par exemple.

Pour s’y connecter, rien de plus simple. Par exemple via l’outil (multiplateforme) robomongo, aucune authentification n’est requise et il nous listera l’intégralité de la base, compte USERS compris !

robomongo

Nous aurions également pu utiliser l’outil NoSQLMAP

nosqlmap

 

Facilement, nous récupérons les credentials du compte :
{
« _id » : ObjectId(« 5794cdcae0ea4f0ae69a3290 »),
« user » : « badadmin »,
« password » : « yes, this password does get reused »
}

si l’on retourne sur la page web, l’authentification fonctionne mais ne nous apporte rien d’intéressant. Elle nous envoie vers un formulaire nslookup, vulnérable lui aussi, mais sans intérêt pour la suite. Essayons maintenant de nous connecter via SSH.

Reste l’élévation de privilège. J’ai mis un peu de temps pour trouver une solution satisfaisante. J’ai fouillé sur le serveur afin de récupérer quelques informations, je pense notamment au fichier Genhashes.py à la racine,  dont l’utilité m’est encore obscure pour l’élévation de privilège.

Ensuite un : find / -user badadmin -type f 2> /dev/null  m’aura permis de tomber sur un /etc/shadow.backup intéressant.

Là je me dit , chouette une piste ! dégainons HASHCAT et voyons si un bon dico viendrait à bout du SHA512

Malheureusement cela n’a rien donné :/ j’ai tenté avec un brute force classique, sur 7 caractères (39heures qd même sur une gtx 970)  ce n’était pas mieux… déprimant.

Reste à s’orienter vers un exploit kernel. Lorsque je cherche à élever mes privilèges par le biais d’un exploit, je me renseigne un maximum sur la machine cible,  version du noyaux, type d’OS, etc.  Pour automatiser cette tâche j’utilise de temps en temps un script : http://www.securitysift.com/download/linuxprivchecker.py

J’ai tenté les plus prometteurs mais sans succès.. Je commençais à baisser les bras puis je me suis dit, pourquoi ne pas tenter un exploit + récent ? Pourquoi ne pas tenter avec Dirty COW (CVE-2016-5195). La vulnérabilité Dirty Cow tire son nom de l’abréviation des fonctionnalités Copy-On-Write du noyau. Cette fameuse vulnérabilité vielle de 9 années récemment dévoilée au travers de (très) nombreux POCs  exploite un race condition dans les opérations du kernel.

 

pokemon

On compile

et on lance :

l’idée est ici de donner les droits root à notre compte user ‘badadmin’ en écrivant dans /etc/passwd, fichier logiquement ‘read only’.

pokemon2

L’exploit terminé, il n’y a pu qu’à se reconnecter via SSH :

pokemon3

et voila :)