Drupal : récupérer un accès administrateur sans connaître le mot de passe

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

De par mon utilisation personnelle et le cadre professionnel, je côtoie assez rarement Drupal, et c’est souvent un problème en plus. Malgré tout, et ce via un outil très pratique, j’ai pu accéder et pouvoir dépanner un client sans avoir à mettre à mal la sécurité de ses comptes administrateurs sur le CMS.

Le contexte

Ici, la demande était simple en apparence, moins dans la pratique : une agence potentielle candidate à la tierce maintenance applicative du site d’un client demandait un accès en lecture seule au panel d’administration du site pour disposer de suffisamment d’information et établir une proposition financière. Pas facile, les informations demandées étant avant tout accessibles au rôle d’administrateur, et il n’est évidemment pas question de fournir cet accès à n’importe qui, d’ailleurs nous ne les avons pas nous-mêmes en tant qu’hébergeur (c’est tout à fait habituel, et la plupart du temps inutile). Pas de bol, le client ne sait pas non plus comment accéder au compte administrateur, en temps normal c’est l’agence de développement qui l’exploite pour les routines de maintenance. Vous l’aurez compris, pas facile de demander l’accès au compte à une agence qui va se faire botter le cul pour le boulot qu’elle ne fait apparemment pas assez bien pour le client.

La trousse à outils : Drush

Oui c’est pas de bol, il n’est pas question de piratage, enfin presque mais comme toute manipulation, c’est l’usage qui définit la légalité. Dans tous les cas, il faut un accès physique à la machine pour pouvoir exploiter l’outil en question. En effet, il s’agit de Drush, contraction de Drupal Shell, qui permet donc de manipuler pas mal d’aspects de votre Drupal directement en ligne de commande. Certains de mes clients l’utilisent notamment pour gérer le déclenchement de leurs tâches planifiées.

Donc me voilà tout seul face à un CMS que je connais peu, pour lequel je dois obtenir des informations accessibles via un compte adapté dont je ne connais pas le mot de passe. Au moins je sais obtenir quelques informations, via la base de données. Une pratique peu courante et surtout pas facile à détecter car peu documentée, les URLs pour la connexion de l’utilisateur et le panneau d’administration ont été modifiées (sur WordPress on peut faire ça avec WP Login Door qui va bientôt faire partie de mes plugins). Il aura fallu fouiller dans les logs Apache pour déterminer les URLs, pour commencer. J’ai alors tenté d’ajouter un compte administrateur à la main, comme j’ai déjà pu le faire sur un WordPress (et déjà vu faire aussi par un attaquant ayant pris le contrôle d’un site pour faire du blackSEO), directement via la base de données, sans succès, toutes mes tentatives se sont vues échouer sur la page de login.

Et puis à force de chercher une solution, je tombe sur un article anglophone proposant l’utilisation de Drush pour générer un lien de réinitialisation de mot de passe, à usage unique, et qui permet, si on ne touche pas au mot de passe, d’accéder malgré tout à l’administration du site, en fonction du rôle du compte sélectionné. Ni une ni deux, j’ai tenté le coup :

Et paf, ça a fait des Chocapic. J’ai eu droit à un lien affreux, qu’il a fallu corriger (il n’avait pas inclus le domaine du site dedans), mais grâce auquel j’ai pu accéder aux pages demandées et fournir des captures d’écran des résultats.

Pour la culture, je suis également tombé sur cet article qui propose quantité de méthodes différentes (via drush ou autre) pour modifier un mot de passe sur un compte existant.

Un équivalent pour WordPress

Étant donné la différence d’âge, je ne m’attend pas à ce que l’étendue des possibilités soit équivalent à Drush, mais en effet, il existe maintenant l’outil WP-CLI que j’ai pu tester récemment, notamment pour éviter de faire à la main une modification de nom de domaine suite au passage en production d’un nouveau site. C’est aussi simple que :

Et il va vous expliquer via quelle méthode il va remplacer les occurrences trouvées. Relancez sans le –dry-run, laissez cuire deux minutes, servez. Plus simple que les fameuses requêtes SQL présentées par Korben il y a quelques années, que j’avais notamment utilisées lors du passage en HTTPS du blog, et surtout plus complètes, au cas où certaines occurrences seraient sérialisées ce qui est toujours problématique.

Si vous utilisez déjà l’un de ces deux outils pour votre projet (ou celui d’un de vos clients), n’hésitez pas à partager dans les commentaires 🙂