Drop That Shell : Quaoar

Bonjour à toutes et à tous !

Afin d’inaugurer ma nouvelle série d’articles, je vous propose de s’attaquer directement à une machine virtuelle (VM) classique dans le domaine du CTF : Quaoar.

Cette VM, disponible sur vulnhub.com, a été créée spécialement pour le Hackfest 2016 par Viper. Considérée comme étant une machine facile à pwn (devenir root), elle me permettra d’expliquer quelques concepts techniques du pentest sur lesquels je ne reviendrai sûrement pas dans les prochains articles afin d’éviter de me répéter.

Commençons sans plus tarder !

Writeup

Dans n’importe quelle épreuve de CTF, l’étape de la reconnaissance est cruciale. C’est grâce aux informations récoltées durant cette partie qu’une réflexion pourra alors être construite afin d’aller plus loin.

Les ports ouverts et les services présents sur ces ports sont des informations très importantes que nous pouvons retrouver grâce à nmap. Ici, je lance un scan agressif (-A) afin d’avoir un maximum d’informations sans me soucier de me faire repérer sur le réseau ! Attention : Ce genre de scan utilise beaucoup de bande passante et peut déclencher des systèmes de détections d’intrusion dans un véritable contexte.

Nmap nous montre alors que plusieurs services tournent sur la machine

  • Un serveur SSH (classique)
  • Un serveur Web (intéressant)
  • Un serveur SMB (à exploiter si j’ai pas trop la flemme)
  • Un serveur Mail (à voir… Intéressant si c’est une vieille version vulnérable)

La plupart des CTF pour débutants se focalisent sur les services Web pour la phase d’exploitation. Le service SSH est bien moins souvent l’objet d’attaque car moins de failles sont présentes sur ce genre de service. Néanmoins, un petit recherche d’exploit pour la version de SSH rencontrée ne fait jamais de mal.

J’ai l’habitude de souvent commencer par une brève exploration du serveur Web afin de récolter plus d’informations, comme des noms d’utilisateurs par exemple. En accédant au serveur Web, je tombe sur une page contenant une image.

Trop vide pour être vrai, j’inspecte le code source de la page afin de vérifier si des informations n’y sont pas cachées.

Rien d’intéressant… On continue !

Le fichier robots.txt est souvent source d’informations utiles. Les dossiers sensibles y sont souvent mentionnés afin de ne pas être référencés par les moteurs de recherche.

Le fichier robots.txt nous apprend qu’une instance WordPress tourne sur le serveur dans le répertoire /wordpress/ … Un troll y est aussi présent.

Comme je ne me fie pas seulement au robots.txt, je décide de lancer mon outil d’énumeration de répertoires favori: dirb

  • Le répertoire /cgi-bin/ et le server-status me jete en tant que “non-autorisé”
  • La LICENSE ne m’apprend rien
  • Le fichier hacking n’est rien d’autre qu’une image. Même passée au peigne fin, aucune information ou code secret n’est caché à l’intérieur

Les images sont parfois trompeuses et peuvent faire l’objet de sténographie.

Une fois tout exploré, je m’attarde alors sur le répertoire /upload/

Ce répertoire contient un CMS Lepton 2. Après plus de 30min à tester des injections SQL/XSS dans la barre de recherche, je laisse ce répertoire de côté afin de me focaliser sur quelque chose de sûrement plus juteux.

Une bonne chose à faire lorsqu’on se trouve face à une installation WordPress est d’utiliser l’outil wpscan. Ce script va nous permettre d’énumérer des points essentiels comme:

  • La version de WordPress
  • Les plugins installés
    • Leur version
    • Leurs vulnérabilités
  • Les thèmes
    • Leur version
  • Les utilisateurs
  • etc

Je vous conseille de jeter un œil au manuel d’utilisation de ce script très puissant.

Le script me révèle alors que deux utilisateurs sont présents:

  • admin
  • wpuser

L’énumération des utilisateurs est très importante car elle permet sur certains challenges de construire des wordlist personnalisées et de mener des attaques bruteforce efficaces.

Je vois ici que 38 vulnérabilités ont été détectées en se basant sur la version de WordPress. Évidemment, mon but ici n’est clairement pas de toute les tester. Mais une faille de type LFI attire alors toute mon attention.

J’ai donc directement essayé d’exploiter les multiples injections SQL montrées par wpscan. Malheureusement, je n’ai jamais réussi à en tirer quelques chose.

La faille LFI quand à elle s’est avérée d’actualité. En effet, en accédant à la page “http://192.168.0.192/wordpress/wp-content/plugins/mail-masta/inc/campaign/count_of_send.php?pl=/etc/passwd”, le contenu du fichier /etc/passwd s’affiche ! Une première possibilité d’exploitation.

Je remarque alors que dans ce fichier se trouve un utilisateur que je n’avais pas encore énuméré, “wpadmin”.

N’étant pas très expérimenté avec les failles de type LFI, je décide de me pencher sérieusement sur des recherches afin de tourner cette LFI en RCE (Remote Code Execution).

En contrôlant le contenu d’un fichier sur le serveur, nous pouvons exécuter du code arbitraire en le faisant afficher grâce à notre LFI. Ainsi, si notre LFI permet d’afficher le contenu des logs d’accès Apache par exemple (ou les logs d’erreur), nous pouvons injecter du code PHP dans nos requêtes GET apache afin de les faire apparaître dans le fichier de logs et de le faire exécuter par le serveur en les affichant par la LFI. Complexe vu comme ça, mais brillant une fois compris.

Après une bonne heure à tester tous les fichiers de logs possibles, je me rend compte qu’aucun d’entre eux n’est lisible via la LFI et que mes efforts pour la transformer en RCE sont vains.

Par la suite, je repense à l’utilisateur “wpadmin” et me demande si je pourrait lire le contenu de son répertoire personnel via la lfi…

Premier drapeau obtenu !

Après ce petit succès, je retourne alors sur wordpress.

L’utilisateur admin içi n’est pas très commun et plutôt intéressant. Je me dis que tenter de me loger avec son compte ne coûte rien et tente le fameux “admin:admin”.

Et voilà, je me retrouve admin de l’installation wordpress !

Tout fébrile, je cherche alors un moyen d’avoir un reverse shell grâce à mon tout nouvel accès. Me vient alors une idée très tordue, mais qui fonctionna parfaitement. Je décide de modifier la page 404 du thème installé afin d’y insérer mon reverse shell. (Pourquoi faire simple quand on peut faire compliqué ?)

Metasploit intègre le module exploit/unix/webapp/wp_admin_shell_upload qui permet de se procurer un meterpreter grâce à des logins wordpress valides. Au moment où je fait le CTF, je n’en ai aucune idée.

Ainsi, après avoir déclenché une erreur 404 sur le site, je me vit octroyé un shell avec l’utilisateur www-data.

Le reverse shell de pentest-monkey, écrit en php, est un script extrêmement utile à avoir sur soi. Après un peu de modification ce script sera votre meilleur ami !

Une fois un shell ouvert, j’ai une petite habitude bien personnelle qui est de me lancer un VRAI shell, pas juste un interpréteur très limité. Pour cela, une ligne de python fait l’affaire :

Une fois bien installé, j’inspecte le fichier de configuration utilisé par wordpress afin d’y chercher des informations juteuses.

Ce mot de passe ressemble bien à un mot de passe root… Je test, on sait jamais !

PWNED !

 

C’est déjà la fin de ce premier writeup ! J’espère qu’il vous a plu. Il y a sûrement plusieurs autres manières d’arriver au compte root de cette machine. N’hésitez pas à me donner des suggestions dans les commentaires si vous êtes du genre créatif !

Durant mes prochains articles je pense garder la même trame d’écriture afin de vous expliquer mes raisonnements, mes echecs et mes découvertes subsidiaires concernant ces machines.

Cette VM était d’un niveau assez faible mais permet de se mettre dans le bain lorqu’on se lance dans les CTF.

Je vous donne rendez-vous très bientôt pour de nouveaux articles ! 🙂

Laisser un commentaire