CTF Quaoar : la démonstration de l’utilité des bonnes pratiques de sécurité

Cet article a été publié il y a 6 ans 5 mois 23 jours, il est donc possible qu’il ne soit plus à jour. Les informations proposées sont donc peut-être expirées.

Quand on dit qu’il faut éviter les mots de passe par défaut, de suivre les mises à jour de sécurité d’un système (en l’occurrence ici le moteur de blog), ce ne sont pas des paroles en l’air. Et pour vous prouver ça, j’ai décidé de me pencher sur un exemple de challenge disponible sur le site vulnhub.com, qui propose une machine virtuelle prête à l’emploi à attaquer. Et j’annonce tout de suite, pour les moins techniciens, ne fuyez pas trop vite, je vais essayer d’expliquer au plus simple chaque étape.

En fait, c’est par le biais du Journal du Hacker que j’ai découvert ce challenge, simple au demeurant comme on va le voir. J’ai commencé à regarder la vidéo, et dès que j’ai vu qu’il y avait un WordPress, ça a fait tilt dans ma tête creuse, j’ai arrêté la vidéo et je me suis dit que j’allais m’y attaquer moi aussi. Après tout, WordPress est probablement le moteur de sites web le plus utilisé à l’heure actuelle, il est donc nécessaire de vous rappeler à quoi vous vous exposez en l’exploitant de travers, et moi de m’exercer un peu pour l’année prochaine et la prochaine Nuit du Hack (encore que le niveau est assez bas ici apparemment). Et donc, un petit CTF, c’est à dire un Catch The Flag, à savoir que des « drapeaux » sont cachés sur le système à attaquer qu’il faut découvrir pour marquer des points.

Rappel d’usage : il est strictement interdit par la loi de procéder à ce type de manipulation sur un système qui ne vous appartient pas.

Bon, reprenons depuis le début : on télécharge la VM, on l’importe dans Virtualbox, et on la démarre. Pour ceux qui sont déjà un peu perdus, la machine virtuelle simule un équipement distant sur la même machine physique. Car pour rappel, techniquement un serveur sur lequel se trouve un site web n’est finalement à la base que la même chose que votre PC, juste adapté (pas besoin d’écran, par exemple). Virtualbox vous permet donc de démarrer plusieurs systèmes, et dans le cas présent je vais en avoir deux : la cible, et une instance Kali, une distribution Linux spécialisée justement pour les tests de sécurité.

Tout ce qu’on sait en démarrant la machine cible, c’est son adresse IP : ici, c’est 192.168.1.4. On va donc commencer par faire un scan de ports, pour savoir sous quel angle on peut attaquer la machine. Un port, dans le domaine des communications informatiques, peut être vu comme une porte sur une maison, un point d’entrée pour communiquer avec un service : quand votre navigateur vous affiche un site, il demande la page au serveur via le protocole (langage) HTTP sur le port 80; plusieurs ports sont normalisés de la sorte, je ne vais pas faire un listing complet et en plus, en théorie, pour n’importe quel service on peut techniquement changer le port par défaut.

Ici, plusieurs informations différentes, on voit donc du SSH, pour interagir en ligne de commande à distance avec la machine, du HTTP, pour servir des pages web, du DNS, pour jouer aux pages jaunes, et du mail (IMAP, POP et SMTP). Chacun de ces éléments peut être attaqué pour diverses raisons, ici on cherche à prendre le contrôle de la machine, et donc obtenir un accès avec le plus de privilèges possibles. Le serveur web est probablement le plus simple à exploiter, commençons donc par vérifier ce qu’il nous dit.

On a donc une image, qui nous dit de cliquer sur le lien pour savoir quoi faire, et ça aboutit à une deuxième image tout aussi inspirée. Dans le cadres de challenges comme celui-ci, il se peut qu’un des drapeaux à retrouver se cache au sein de l’image, une technique qu’on appelle la stéganographie, mais je vais laisser ça de côté dans l’immédiat, on y reviendra si besoin d’indice qui seraient cachés. Il n’y a donc que peu d’informations pour le moment. Tentons certaines choses, du style /phpmyadmin, et la page d’erreur « 404 » nous donne un peu plus d’informations :

Le système semble être une Ubuntu avec un serveur web Apache 2.2.22, ce qui nous indique une Ubuntu 12.04. Comme d’habitude, je ne sais pas encore si ça va nous servir mais le fait est que plus on obtient d’informations, plus on saura comment s’attaquer au système. En effet, les mises à jour de sécurité ont cessé sur cette version et en cas de besoin, on pourra consulter les vulnérabilités non corrigées. Si PHP est installé via les paquets d’origine, il sera en 5.3, ce qui est particulièrement vieux et donc faillible également. Donc vous le voyez, on a déjà, sans même être allé très loin, obtenu suffisamment d’information pour trouver quantité de vecteurs d’attaques potentiels. Et tout à ça la main.

Un fichier qu’on va souvent trouver sur un serveur web est le fichier robots.txt. Il est utilisé dans le cadre du référencement d’un site lors du passage des robots d’indexation de Google&co, pour indiquer les endroits autorisés et interdits pour le référencement. Et tiens, quelle surprise, apparemment il y a un /wordpress/ :

On remarquera la petite blague sur les hackers 🙂

Bingo ! En tout cas, ça ressemble à un WordPress, le thème par défaut date de 2014, ce qui peut laisser présager une version non maintenue à jour. Je pourrais chercher pas mal de choses à la main, mais je vais me concentrer sur un outil particulièrement pratique qui s’appelle WPscan (que j’avais présenté dans un de mes rares usages de Docker sur Manjaro, que j’ai même arrêté de pratiquer après la dernière réinstallation à la perte du SSD). Cet outil va nous permettre de récupérer quelques informations intéressantes :

• version de WordPress
• plugins utilisés avec leur versions si possible
• thèmes
• utilisateurs (pas nécessairement exhaustif)

Et pour certaines de ces entrées, un recensement des vulnérabilités connues. Et là, c’est champagne : le wordpress est dépassé, les rares plugins présents sont vulnérables, et on voit un utilisateur « admin » qui est l’un des identifiants les plus présents sur ce type de solution, au point qu’on devrait pendre les utilisateurs qui le laissent trainer. Pourquoi ? parce que le mot de passe probablement le plus utilisé pour aller avec, c’est admin. La preuve ?

Voilà, j’ai donc déjà le contrôle quasi complet du WordPress. Pas encore suffisant pour moi, mais déjà, ça permet de lancer à peu près ce qu’on veut avec l’utilisateur qui est associé au PHP qui tourne derrière (www-data si PHP est en module, c’est pratiquement assuré), et modifier à peu près ce qu’on veut sur le site, pour intégrer plein de choses dégueulasses qui permettront soit d’exfiltrer les données du site, et donc potentiellement des visiteurs/utilisateurs, leur faire miner de la monnaie électronique de manière cachée (coucou Pirate Bay), transformer le site en boutique de produits contrefaits… Les possibilités sont tellement nombreuses que je ne préfère pas trop m’étendre sur le sujet, en plus j’oublierais des trucs.

Ici on va commencer par s’ajouter un webshell, c’est à dire s’ajouter un mécanisme de ligne de commandes au travers du site, ce qui nous permettra d’effectuer plus d’opérations que par la base de WordPress. Plusieurs possibilités, aussi bien sur les méthodes d’injection, que sur le shell à utiliser. J’ai opté pour ws0shell, que je colle sur le site en passant par l’éditeur de thème :

Voilà, je peux donc maintenant parcourir tous les fichiers du WordPress, et je vais naturellement me tourner vers le fichier de configuration, qui contient les identifiants à la base de données. Et là, deuxième mauvaise pratique : le compte utilisé pour accéder à la base de données, qui contient donc tous les secrets du WordPress, c’est le compte root, autrement dit l’administrateur de la base de données, qui a donc accès à bien plus que la base du wordpress, à savoir tous les autres sites installés sur la même machine. Eh ben vous savez quoi ? J’ai tenté ce couple login/mot de passe pour me connecter via SSH :

Boum. Me voilà administrateur de la machine, et j’en ai donc le contrôle total, à pouvoir installer de quoi y rester même si le propriétaire s’en rend compte et colmate ses brèches, et pouvoir faire mes affaires à son insu. Et tout ça, sans être un expert en sécurité ou en « piratage ». Une fois que j’avais terminé moi-même, j’ai lu quelques articles sur ce challenge : parmi les plugins installés, il y en a un qui permet d’inclure n’importe quel fichier du système et donc de l’afficher (ce qui ne devrait pas être permis), et on peut tenter de passer par le shell injecté pour lancer un exploit d’élévation de privilèges, à cause du manque de mises à jour de la machine. Comme quoi, il y avait la voie facile et au moins une autre possibilité pour détourner cette machine de son usage premier.

Donc, récapitulons un peu, pour comprendre quels sont les erreurs qu’il ne faut pas reproduire :

• WordPress pas à jour : bien qu’on aie pas eu à exploiter des failles pointues, il est quand même possible de méchamment péter le site à cause de ça
• compte admin par défaut, avec un mot de passe faible : le login ‘admin’ doit être banni de tous les systèmes d’authentification, et si vous être contraint de conserver ce compte, si possible lui adosser un mot de passe fort, voir même de l’authentification à plusieurs facteurs (comme le 3DSecure sur votre carte bleue qui vous envoie un code par SMS). C’est valable pas uniquement pour le WordPress, mais pour tous les sites.
• identifiant root pour la base de données : si votre site se fait défoncer, tous les sites installés sur la machine peuvent se faire dérober leurs données, ce qui veut également dire des comptes utilisateurs et des mots de passe qui peuvent être exploités ailleurs. C’est sale, très sale, et d’ailleurs, le compte administrateur d’une base de données ne devrait pouvoir être exploité qu’en ligne de commande en local sur la machine. Mieux, on peut le renommer.
• le même mot de passe root pour la base de données et le système en dessous : si les identifiants peuvent être identiques, même si ce n’est pas recommandable, chaque mot de passe doit être à usage unique, et donc doivent être différents. Et la remarque sur la qualité du mot de passe est évidemment toujours valable.
• La possibilité d’utiliser root via SSH directement : idéalement, surtout sur des machines connectées sans filtrage, la connexion SSH devrait être réservée à des comptes utilisateurs standards, et les connexions surveillées par un outil tel que Fail2ban qui va s’occuper de foutre à la porte ceux qui sont trop insistants.

Bien, maintenant pourquoi je rabâche encore sur le sujet de la sécurité ? Pour les personnes les moins aguerries et qui ont eu du mal à suivre jusqu’ici, il est facile de se retrouver face à un service à l’apparence propre qui est plus que discutable si on regarde l’envers du décor. Il est donc impératif de ne pas être trop confiant et le meilleur moyen si on veut tout de même utiliser ce service, c’est de disposer d’un mot de passe unique qui évitera que plusieurs de vos services se fassent trouer et donc vos données avec.

Pour parler un peu plus de technique, le monde merveilleux voudrait qu’on soit tous bons et que toutes les mises à jour soit appliquées en permanence dès que c’est disponible, la réalité est que souvent, et c’est une grosse erreur, un site web même basé sur WordPress est livré en mode « one-shot », sans suivi de sécurité, à la façon d’une affiche de publicité statique. Pire, quand de lourds développements ont été effectués, ils le sont généralement par rapport à une version de PHP bien précise, une version de WordPress bien précise, et occasionnellement, la mise à jour d’un de ces deux acteurs casse des choses, et réparer coûte de l’argent, de l’argent que certains ne sont pas prêts à payer, jusqu’à ce que ce prix soit payé par les clients, via les comptes utilisateurs volés ainsi que les données qui sont associées.

Et si la démonstration que j’ai faite là a pris à peine 20 minutes à la main, les sites web sur la planète entière sont en permanence scannés par des robots et d’autres sites infectés pour tenter d’intégrer les machines à des réseaux de zombies qui seront ensuite exploitées à la demande par des réseaux criminels, pour pas mal de choses comme du déni de service, du bruteforce, et autres joyeusetés. Alors prenez le temps de mettre en place quelques bonnes pratiques (du style celles de cet article, à propos de WordPress), ça vous coûtera beaucoup moins cher plus tard.