Introduction

Salut tout le monde ! Aujourd'hui, je vais vous partager mon write-up du Cheese CTF sur TryHackMe. Si vous aimez résoudre des défis en cybersécurité, celui-ci est vraiment intéressant pour tester vos compétences. Je vais vous guider étape par étape à travers ce CTF, en vous montrant comment j'ai découvert les failles et obtenu les drapeaux. Rien de trop complexe, juste un bon mix entre apprentissage et fun ! Prêt à plonger dans l'univers de Cheese CTF ? Suivez-moi !

On commence par un simple scan Nmap pour explorer le réseau.

Tous les ports sont ouverts, ça promet ! Je ne cherche pas plus loin. Allons voir s'il y a un site web sur le port 80 pour HTTP ou le port 443 pour HTTPS.

On tombe sur un site où l'on peut commander du fromage. Je ne sais pas vous, mais ça me donne faim !

Cherchons s'il y a d'autres pages sur le site web ! Pour cela, j'utilise Gobuster, et pendant que ça tourne, j'explore le site manuellement.

Nous avons trouvé manuellement seulement la page login.php

Nous ne pouvons pas nous connecter, même après avoir essayé (admin/admin) et (admin/password).
Avant de passer à la recherche d'une faille SQL, explorons un maximum de pages trouvées sur le site web.
Nous arrivons finalement sur la page messages.html.

En cliquant sur le lien messages, on découvre une faille LFI, accompagnée d'un petit message sympa qui nous indique qu'on est sur la bonne piste. C'est comme si une grosse flèche pointait en disant : 'C'est ici, t'inquiète, tu peux y aller !' 😂

Ici, on voit un php://filter/resource qui lui permet d'accéder à un fichier appelé supersecretmessageforadmin. Cela signifie qu'on peut clairement exploiter cette faille pour accéder au fichier /etc/passwd !

Bingo ! Nous avons identifié deux utilisateurs : comte et root. Maintenant, j’aimerais récupérer un mot de passe dans login.php. Étant donné que ce fichier est censé gérer la connexion, il devrait contenir des informations permettant d'accéder à la base de données, que ce soit sous forme de mot de passe en clair ou via l'inclusion d'un autre fichier. Allons-y !

Pour cela, nous allons d’abord encoder le contenu du fichier en base64. En effet, si nous l'affichons tel quel, le code PHP s'exécutera et nous ne pourrons pas voir les informations que nous recherchons. Une fois que nous avons le contenu encodé, nous pourrons le décoder pour y accéder.

Nous avons trouvé notre fameux utilisateur comte et son mot de passe : VeryCheesyPassword. C'est le code d'accès à la base de données. Avec un peu de chance, il a réutilisé ce mot de passe pour se connecter en SSH ou sur le site web.

Malheureusement, ce n'est pas le cas. Que ce soit pour SSH ou sur le site web, le mot de passe ne fonctionne pas.

Question : peut-on obtenir une exécution de code à distance (RCE) à partir d'une injection de fichier local (LFI) ? Je fais quelques recherches et je tombe sur un outil appelé php_filter_chain_generator.py

Cet outil permet de créer une chaîne php://filter pour générer une exécution de code à distance (RCE) sans avoir besoin de télécharger de fichiers, à condition que le paramètre soit passé dans une fonction require ou include en PHP.

Pour en être certain, je récupère le fichier secret-script.php, qui m'a jusqu'à présent permis d'accéder à des fichiers comme /etc/passwd, etc. Comme précédemment, nous allons encoder le fichier en base64 puis le décoder.

Nous constatons qu'il n'y a pas de filtre et que le paramètre passe correctement dans la fonction include de PHP. Nous pouvons donc utiliser le script php_filter_chain_generator.py pour générer un reverse shell.

PS : N'oubliez pas d'encoder en base64 s'il y a des caractères spéciaux, car ils peuvent être mal interprétés dans l'URL.

Nous plaçons un écouteur sur le port approprié, et nous avons un shell !

Je fouille un peu partout, mais je ne trouve rien ! Cependant, j'ai remarqué une chose : j'ai accès au dossier /home/comte/.ssh et j'ai même les droits d'écriture sur le fichier authorized_keys.

Je génère une paire de clés SSH sur ma machine attaquante.

Ensuite, je colle ma clé publique dans le fichier authorized_keys sur la machine victime.

On modifie les permissions de la clé privée, puis on se connecte en SSH avec l'utilisateur comte.

Nous récupérons enfin le flag user.

Sympa, ce petit fromage !

En route vers ROOT

Maintenant, en route vers le flag root !
Premier réflexe sous Linux : vérifier si nous avons des droits sudo.

On voit qu'on peut démarrer quelque chose appelé exploit.timer. Voyons le statut de ce service, peut-être que nous pourrons obtenir plus d'infos

OK, le service ne fonctionne pas. Partons à la recherche d'un fichier appelé exploit.timer.

Super, on trouve un seul fichier. En listant le contenu du dossier /etc/systemd/system/, on voit qu'il y a notre fichier exploit.timer, mais aussi exploit.service. On peut écrire dans exploit.timer, mais pas dans exploit.service. Par contre, on peut voir ce qu'il fait.

En regardant exploit.service, on voit qu'il copie le binaire xxd dans le dossier /opt et le rend SUID. Nous pouvons exploiter cette faille pour élever nos privilèges et obtenir root.

Mais pour l'instant, il faut réparer exploit.timer.

Nous constatons que la variable OnBootSec doit être modifiée. Il suffit d'ajouter 0 pour que cela fonctionne.

On recharge le deamon, puis on active exploit.timer et enfin, on redémarre le service exploit.timer.

Et hop ! Un nouveau Pokémon apparaît : le fameux binaire XXD en SUID !
On se rend sur GTFOBins pour explorer ce que l'on peut faire. On découvre qu'on peut lire ou écrire des fichiers dans des emplacements où seul root a le droit d'agir.

Il existe plusieurs techniques. Je pourrais faire fuité directement le fichier root.txt, mais imaginons que nous ne sachions pas comment le fichier s'appelle. Dans ce cas, il nous faudrait un accès root. Pour cela, je choisis d'ajouter ma clé publique dans authorized_keys de root, puis de me connecter en tant que root.

Et maintenant, nous pouvons nous connecter en tant que root avec la clé privée.

Et ainsi, obtenir le flag root !

Conclusion

Merci d'avoir suivi ce write-up, et j'espère que vous avez pris autant de plaisir à le lire que j'en ai eu à le rédiger. N'hésitez pas à partager vos pensées ou questions, et à bientôt pour de nouvelles aventures dans le monde de la cybersécurité ! 🚀