Résolution du challenge CTF SP: harrison

By | May 17, 2019

Bonjour à tous,

Aujourd’hui, nous allons nous intéresser à la résolution d’un nouveau challenge Vulnhub: SP:harrison.
Ci-dessous le lien de la machine vulnérable sur Vulnhub.com.
SP:harrison

L’objectif du challenge est d’accéder au fichier /root/flag.txt.



Après avoir importé la machine vulnérable, lançons netdiscover dans notre terminal Kali pour connaître son adresse IP.


Un scan nmap nous donnera une idée des services qui sont en cours d’exécution sur la machine.

Le scan nous retourne deux services.
_ Sur le port 22, un serveur OpenSSH,
_ Sur le port 445, un serveur Samba.


Un autre scan sur le port utilisé par Samba à l’aide de enum4linux nous faire découvrir un partage qui semble être accessible…

…et un utilisateur harrison.


Notre client smb smbclient se connecte avec succès en anonyme et nous confirme que le partage est bien accessible.


A l’aide de mount, montons localement ce partage avec un compte guest.


Et là, nous obtenons le premier drapeau. 🙂

Le partage contient des dossiers et des fichiers.

Le dossier silly_cats ne nous apprend rien sinon un mème portant sur une réplique célèbre du caractère Forrest Gump dans le film éponyme oscarisé en 1994… 🙂

…Par contre, le dossier .ssh contient une paire de clé ssh et un fichier authorized_keys.

L’absence de la ligne ENCRYPTED dans la clé privée id_rsa nous fait comprendre qu’elle n’est pas chiffrée.

Bonne nouvelle. 🙂


Une modification sur la permission du fichier id_rsa, et nous parvenons à nous connecter à la machine vulnérable avec le compte d’utilisteur harrison.


Toutes les commandes que nous exécutons sur la machine nous retournent des messages d’erreur.


Seule la commande ls fonctionne.


Le fichier .lhistory nous fait comprendre que nous avons sans doute à faire avec un lshell ou limited shell, un type de shell codé en python qui permet de restreindre un environnement d’utilisateur à certaines commandes.

Pour s’échaper de ce shell et accéder au shell Bash, c’est simple, il suffit d’exécuter la commande suivante.

 echo && 'bash'

Nous parvenons ainsi à nous échapper de lshell. 🙂


Le compte root nous est accessible en lecture, et là se trouve le second flag.

Le message contenu dans le flag nous fait comprendre que nous ne sommes pas encore sorti de l’auberge. 🙁
Ce message comprend bien évidemment un sous-entendu.
What if, nous etions dans un conteneur docker ?

Une exécution de la commande Disk Free nous apprend que notre machine comprend un point de montage sans doute d’une socket docker.

Nous aurons peut-être une chance d’exécuter des commandes en tant qu’un utilisateur priviligié sur l’hôte à partir du conteneur !
Si vous voulez savoir un peu sur les risques sur l’utilisation de la socket docker, je vous invite à jeter un coup d’oeil à cet article très instructif.. 😉

La commande ci-dessous nous permettra de nous connecter à l’API de docker afin d’obtenir des informations sur l’ensemble des conteneurs en cours d’exécution sur l’hôte.

 curl -XGET --unix-socket /var/run/docker.sock http://localhost/containers/json

Le résultat nous apprend que notre conteneur est le seul en cours d’exécution.
Encadré en rouge son id.

Nous allons de ce pas profiter un peu plus de notre privilège pour créer un nouveau conteneur à partir de l’image Ubuntu déjà présente sur le système. Nous tenterons ainsi d’accéder au dossier /etc de l’hôte avec un montage bind.

Ci-dessous les références que nous utiliserons pour créer ce conteneur.
Le dossier /etc de l’hôte sera monté dans notre conteneur dans un répertoire /host_etc.

echo -e '{"Image":"ubuntu","Cmd":["/bin/sh"],"DetachKeys":"Ctrl-p,Ctrl-q","OpenStdin":true,"Mounts":[{"Type":"bind","Source":"/etc/","Target":"/host_etc"}]}' > container.json
 curl -XPOST -H "Content-Type: application/json" --unix-socket /var/run/docker.sock -d "$(cat container.json)" http://localhost/containers/create


Démarrons le conteneur.

curl -XPOST --unix-socket /var/run/docker.sock http://localhost/containers/4607/start

Nous voyons ici que notre connecteur a bel et bien été créé. Notez le nouvel id encadré en rouge dans l’image suivante.


Nous allons à présent nous connecter au conteneur que nous venons de créer au moyen de Netcat.

nc -U /var/run/docker.sock>/p>

Assurons-nous que nous utiliserons la version HTTP/1.1 pour communiquer à travers Netcat. Pour cela, nous enverrons une requête POST comme suit.

NB: Nous n’insérerons que les 4 premiers caractères de l’id de notre conteneur. Vous pourrez bien sûr insérer l’id complet du conteneur si vous le souhaitez.

POST /containers/4607/attach?stream=1&stdin=1&stdout=1&stderr=1 HTTP/1.1
Host:
Connection: Upgrade
Upgrade: tcp

.
Nous obtenons la réponse suivante qui nous informe qu’un upgrade de la version HTTP a été éffectué avec succès.

Notez la présence du dossier /host_etc dans lequel nous avons pris le soin de monter le dossier /etc/ de l’hôte lors de la création du conteneur.

Un accès en lecture sur le fichier /etc/shadow, pourquoi pas le dossier /root ?

Réutilisons le même procédé pour créer un nouveau conteneur, mais cette fois, montons le dossier /root dans le nouveau conteneur…

…Et bingo !

Nous accédons au drapeau final /root/flag.txt.

Fin du challenge !

J’espère que vous avez appris de nouvelles choses. Pour ma part, ce fut un plaisir comme d’hab. 🙂
Si vous avez utilisé d’autres solutions, n’hésitez pas à partager, je serai ravi de les connaître.

Happy Hacking !

mdestroy

2 thoughts on “Résolution du challenge CTF SP: harrison

  1. Benzo

    Merci , pour le partage . Je trouve ça super intéressant. je découvre enum4linux. Sinon tu fais des CTF online ou IRL de temps en temps?

    Reply
    1. mdestroy Post author

      Hello Benzo !
      Uniquement online jusqu’à présent. 🙂

      Reply

Leave a Reply

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