Résolution du challenge CTF UnknownDevice64

By | March 16, 2019



Aujourd’hui, nous allons nous intéresser à la résolution du challenge CTF UnknownDevice64.
Ci-dessous le lien de la machine vulnérable sur VulnHub.

UnknownDevice64

Le but de ce CTF est d’accéder au drapeau (flag) situé dans le dossier root (/root/flag.txt).


Après avoir importé la machine virtuelle, lançons Netdiscover pour connaître son adresse IP.

L’adresse IP de la machine virtuelle à travers laquelle nous tenterons de nous introdruire est 192.168.1.16.

Lançons à présent un scan Nmap sur cette machine.

Le scan nous apprend que deux ports sont ouverts sur ce système:
_ Le port 1337, qui est utilisé pour faire tourner un serveur SSH OpenSSH.
_ Le port 31337, qui est utilisé pour faire tourner un serveur Web SimpleHTTPServer.

Ci-dessous le site Web en question:

Un scan avec dirb ne apprend pas grand chose…

Mais un coup d’oeil rapide dans le code source du site nous permet de découvrir un indice, sans doute le nom d’une image: key_is_h1dd3n.jpg.

Cette image est accessible via le site Web.

Téléchargeons cette image pour en savoir plus sur elle.

Hidden Secret, en d’autres termes Secret Caché. Cette image pourrait-elle dissimuler des informations secrètes ? des fichiers ?

Après plusieurs tentatives vaines de déchiffrement avec divers logiciels de stéganographie, je décide de me tourner vers StegHide. Quelques dévinettes, puis je finis par découvrir le mot de passe pour le déchiffrement qui est: h1dd3n.
Le déchiffrement de l’image nous donne un fichier texte qui contient un code BrainFuck.

Le décodeur en ligne copy.sh/brainfuck donne le résultat suivant:

Cette chaîne de caractères ud64:1M!#64@ud, fait penser à une combinaison username:password.
Dans l’image suivante, elle nous permet de nous logguer au serveur SSH.

A l’exécution de quelques commandes de bases de Linux, des erreurs s’affichent.

Ces erreurs s’expliquent par la mise en place d’un Restricted Shell sur le profil de notre utilisateur ud64. Restricted Shell est un type de shell Unix qui permet de limiter certaines fonctionnalités lors d’une session utilisateur interactive.
Il est possible pourtant de s’évader de ce shell restrictif en exécutant Bourne Shell à travers un programme comme Vi. Démontration avec l’image suivante.


NB:
Si vous souhaitez en savoir plus sur les techniques d’évasion du Restricted Shell, je vous invite à voir ce lien.

Encore une fois, nous faisons face à un nouveau type d’erreur.


En fait, ces messages signifient tout simplement ces programmes ne sont pas disponibles dans la variable d’environnement PATH.
Ces programmes restent pour autant accessibles grâce à leur chemin absolu.
Afin d’éviter de modifier le moins possible le système, nous utiliserons que les chemins absolus pour la poursuite de ce challenge.

Ci-dessous le dossier source du Serveur Web SimpleHTTPServer contenu dans le répertoire Home de l’utilisateur ud64.

Grâce à Sudo, nous découvrons que l’utilisateur ud64 possède toutes les permissions possibles sur un fichier binaire dont le chemin absolu est /usr/bin/sysud64.

Essayons d’en savoir plus sur ce fichier binaire.

Ce fichier binaire n’est autre que Strace, un outil utilisé notamment pour le debugging et le troubleshooting des programmes sous Linux.

Pour l’utiliser, c’est simple. Il suffit tout simplement de lancer strace suivi de la commande à débugger. De cette manière, la commande à débugger s’exécutera, et strace permettra de voir sur-le-champs les appels système utilisés par la commande. Voir image ci-dessous.

Pour revenir à notre challenge, il faut comprendre que toutes les commandes qui seront exécutées par l’utilisateur ud64 avec sudo sur le fichier binaire /usr/bin/sysud64 seront exécutées en réalité avec les privilèges du compte du compte root.

L’exécution de Bourne Shell avec sudo nous donne accès au compte root, puis au flag de ce challenge.


Fin du challenge.

J’espère que vous avez appris de nouvelles choses.

A très bientôt, et surtout…

Happy Hacking !

🙂

mdestroy

4 thoughts on “Résolution du challenge CTF UnknownDevice64

  1. Usul

    J’ai appris beaucoup de nouvelles choses!

    Merci beaucoup !

    Usul

    Reply
  2. Simon

    Hello,

    J’ai vu passer ton article dans mes flux RSS et avant de répondre, j’ai tenté de résoudre le challenge de mon coté.
    Jusqu’à l’accès SSH, j’ai procédé de la même façon. Cependant, j’ai récupéré le flag en modifiant `web/server.py` dont le propriétaire est `ud64` mais qui est exécuté avec `root`. J’ai fais exécuter `chsh ud64 –shell /bin/sh` et `chmod -R 777 /root`. Après un reboot, le flag était donc dispo en lecture par `ud64`. C’est moins élégant et ça demandera un poil de travail en plus pour passer root en interactif avec cette méthode.

    À bientôt,

    Reply
    1. Secuinfo

      Yes bien vu !

      Cependant une des “régles” des CTF c’est de na pas reboot la machine manuellement 😉

      Reply
  3. Secuinfo

    Très beau write up je voulais en faire un mais tu m’as devancé !
    Pour le root j’ai juste lancé un reverse shell avec le sysud64.
    Et pour le PATH j’ai étais moins délicat j’ai copié le mien XD

    Reply

Leave a Reply

Your email address will not be published. Required fields are marked *