Blog

Akerva

Faites l’expérience de la sécurité active & réactive

WonkaChall 2

WonkaChall 2 – leHACK 2019 – Write up Part 3 – LINUX

WonkaChall 2 | 29/07/2019 Découvrez le write up de la troisième et dernière partie du Wonka Challenge 2 ! A l’issue de la deuxième partie, nous avons obtenu un identifiant et un mot de passe pour nous connecter à une machine présente dans un autre sous-réseau. Avant d’entrer dans une nouvelle phase d’énumération, nous allons tenter de nous y connecter pour voir ce qu’elle nous...

Découvrez le write up de la troisième et dernière partie du Wonka Challenge 2 !

A l’issue de la deuxième partie, nous avons obtenu un identifiant et un mot de passe pour nous connecter à une machine présente dans un autre sous-réseau. Avant d’entrer dans une nouvelle phase d’énumération, nous allons tenter de nous y connecter pour voir ce qu’elle nous réserve.

Notre premier serveur Linux !

Le nouveau sous-réseau « 172.16.69.0/24 » nous est pour l’instant inaccessible. Tentons de l’ajouter à notre table de routage afin de vérifier si nous pouvons y accéder directement depuis notre sous-réseau client.

Nous pouvons utiliser netcat pour vérifier rapidement si le service SSH de la machine est accessible.

Ici, nous avons de la chance, la machine est directement accessible. Cela va nous éviter de faire un pivot pour ouvrir une session.

Cette première connexion nous permet d’obtenir le flag 9.

Enumération du serveur

Nous constatons que deux services sont en écoute : SSH sur le port 22 et un second sur le port 80.

Voyons ce que nous pouvons trouver sur ce second service…

Il s’agit d’une simple page de maintenance statique et son code source ne révèle rien de particulier.
Grâce aux en-têtes des réponses HTTP, nous savons qu’il s’agit d’un serveur « nginx ».

Allons jeter un coup d’œil dans le dossier contenant les « VHOSTS » :

Le dossier ne contient qu’un seul fichier de configuration pour « dev3.challenge.akerva.com » (serait-ce un teaser pour la 3ème édition du Wonka Chall ? 😉)

Ce dernier nous révèle l’emplacement des fichiers correspondants au site en question.

Ce dernier ne contient pas grand-chose, si ce n’est une clé privée SSH, qui n’est en plus pas protégée par une passphrase, …     … intéressant !

Cette clé pourrait nous donner accès à une autre machine, mais laquelle et avec quel identifiant ? Pour pouvoir répondre à ces questions, nous devons continuer notre énumération.

Pour gagner du temps, nous allons utiliser « LinEnum.sh » et voir si le script nous remonte des informations intéressantes.

Il permet de repérer rapidement que le fichier « /etc/crontab » contient une entrée non présente dans une installation standard de Debian.
Parfait ! Ce script contient une commande « scp » qui nous donne l’adresse IP de destination, le nom d’utilisateur ainsi que le chemin vers la clé privée (que nous avions déjà).

Accès au serveur de backup

Nous avons obtenu des informations de connexion pour un serveur de backup. Voyons si nous pouvons nous y connecter…

Hmm… Nous obtenons bien une session mais il s’agit d’un shell restreint !
Une recherche rapide nous permettra d’identifier le type de shell utilisé.

Autre fait marquant, un certain nombre de problèmes de sécurité ont été ouverts, suggérant qu’il est peut-être possible de le contourner et d’obtenir un shell standard.
De nombreux PoC sont proposés mais la plupart d’entre eux ne fonctionnent pas dans notre cas. Avec un peu de persévérance, nous parvenons à en trouver un qui permet de nous échapper.

Nous obtenons ainsi le flag 10 ! \o/

LinEnum.sh FTW

Maintenant que nous avons un véritable shell sur le serveur de backup, nous pouvons utiliser notre script d’énumération favori afin d’obtenir rapidement un maximum d’infos sur cette machine.
Premier fait marquant, un binaire setuid inhabituel est présent.

Problème, nous ne pouvons pas l’exécuter. Une ACL est positionnée sur le fichier et autorise seulement l’utilisateur « georgina » à l’utiliser. Gardons cette information de côté pour plus tard…

LinEnum nous révèle que « georgina » possède un fichier « .bash_history ». Cela signifie donc que nous pouvons lister son « HOME ».

Nous pouvons donc essayer de lister son contenu manuellement.

Nous apercevons d’ores-et-déjà le flag 11 mais nous n’avons pas les privilèges requis pour le lire. En revanche, le dossier « .ssh » possède des permissions nous permettant d’accéder à son contenu.

Des permissions pour le moins douteuses semblent en effet avoir été configurées sur ce répertoire. Cela nous permet de récupérer une nouvelle clé privée ! 😊

Ne crions pas victoire trop rapidement, vérifions que cette clé nous permet bien de nous connecter en tant que « georgina ».

C’est tout bon ! Et nous obtenons le flag 11 !

Pwn !

Résumons la situation. Nous nous sommes connectés sur le serveur de backup en tant que « violet » puis nous nous sommes échappés d’un shell restreint. Ensuite, une phase d’énumération locale a révélé la présence d’un binaire setuid inhabituel, exécutable seulement par « georgina ». Finalement, nous avons réussi à nous authentifier en tant que « georgina ».

Aucun vecteur d’élévation de privilèges évident n’a été trouvé, essayons donc de voir s’il y a un moyen de détourner ce binaire.

Il nous demande de fournir un mot de passe pour créer une archive ZIP chiffrée.

Un fuzzing basique nous permet de provoquer rapidement une erreur de segmentation. Cela est certainement dû à un « buffer overflow ».

Récupérons le fichier sur notre machine afin de poursuivre l’analyse.

En rejouant ce test dans GDB, on remarque que l’erreur survient au niveau d’une instruction « ret ». Effectivement, la première valeur disponible sur la pile est 0x4141414141414141, qui n’est pas une adresse de retour valide. Comme nous contrôlons cette valeur, nous pouvons rediriger le flux d’exécution.

A ce stade, nous pouvons déjà constater que la pile n’est pas protégée. Cela est confirmé par la commande « checksec ». En revanche, les protections NX et ASLR sont bien actives, ce qui suggère que nous devrons certainement utiliser la technique « Return Oriented Programming ».

La recherche de motif avec GDB révèle que la valeur de RBP est située à l’offset 288. Il suffit donc d’ajouter 8 octets à ce dernier pour contrôler l’adresse de retour.

Par ailleurs, la section PLT contient une entrée pour la fonction « system » de la « libc » (cette fonction est en effet utilisée pour exécuter la commande « zip »). Cela facilitera notre travail d’exploitation.

En spécifiant cette adresse, on peut d’ores-et-déjà constater que nous sommes en mesure d’appeler cette fonction.

Ici, nous avons de la chance puisque l’argument de « system » pointe vers le début de notre buffer. En modifiant légèrement notre « payload », nous devrions donc pouvoir obtenir un « shell ». Bien entendu, on n’oublie pas l’astuce de la commande « cat » pour conserver « stdin » et « stdout » et empêcher le programme de terminer prématurément.

Et voilà ! Nous obtenons un shell en tant que « root » ! \o/
En accédant à son répertoire, nous pouvons récupérer sa clé privée.

Nous obtenons alors un véritable shell ainsi que le flag 12 !

Qui se cache derrière l’organisation Willy Wonka ?

Nous disposons désormais d’un accès « root » sur le serveur de backup. Nous avons donc a priori tout ce qu’il faut pour recueillir les éléments qui nous permettrons d’identifier le ou la responsable de l’organisation Willy Wonka.

Avant toute chose, revenons un peu en arrière et arrêtons-nous un instant sur l’outil « exportVIP ». Le fichier ZIP de sortie est déposé dans « /mnt/backup/ », cela semble indiquer qu’il s’agit d’un point de montage.

Le fichier « /etc/fstab » confirme cette hypothèse. Il nous indique en plus qu’il s’agit d’un point de montage vers un partage NFS accessible depuis une troisième machine.

Plutôt que de monter le sous-dossier « backup », essayons de monter la racine du partage.

Le dossier « VIP » semble être une cible de choix. Il contient en particulier un DOCX et un PDF.

Récupérons par exemple le fichier « INVOICE.pdf ». Les métadonnées constituent une bonne source d’information.

Le champ « Author » révèle finalement le nom de l’auteur du document. Son hash SHA256 nous donnera le dernier flag ! \o/

Vous avez désormais toutes les cartes en main pour résoudre le Wonka Challenge 2. Le challenge reste accessible jusqu’au mercredi 31 juillet 2019, à vous de jouer !
Merci à tous les participants et bravo aux gagnants.

RDV l’année prochaine pour la seconde édition de @leHACK ! 😉

Actualités & blog

Restez informé des dernières actualités d'Akerva

RESTEZ INFORMÉ DES ACTUALITÉS AKERVA

ABONNEZ-VOUS À NOTRE NEWSLETTER