Introduction

Lors d’une récente intervention sur un serveur pour le compte d’un client, j’ai eu l’opportunité de relever un défi passionnant, bien que différent de mes projets habituels. Bien que je préserve l’anonymat du client dans cet article, je tiens à partager cette expérience qui met en évidence l’importance d’une expertise technique et d’une approche méthodique pour résoudre des problèmes complexes.

Suite à un appel de détresse d’un client paniqué, nous avons été sollicités chez SQLI par le patron d’une franchise de garage automobile pour examiner un dysfonctionnement majeur de leur application sur le serveur. Étant donné que nous n’avions jamais travaillé avec ce client auparavant, nous avons décidé de nous rendre sur place pour évaluer la situation et déterminer la faisabilité et la rentabilité de l’intervention, car mobiliser une équipe de dix personnes sur une période prolongée nécessitait des ressources significatives, potentiellement hors de portée du client.

Analyse du problème

Une fois arrivés sur les lieux, nous avons découvert toute l’histoire derrière cette situation critique. À la suite d’un différent entre le patron et l’employé en charge du développement et de la gestion de leur CRM maison interne, ce dernier avait quitté l’entreprise, laissant le CRM soudainement dysfonctionnel. Ce scénario semblait trop inhabituel pour être une simple coïncidence.

L’objectif de l’intervention était clair : se connecter au serveur et réparer le CRM. Cependant, cette tâche s’annonçait plus complexe que prévu, car toutes les informations liées à l’administration du serveur étaient détenues par l’employé parti, et le patron ne disposait d’aucun moyen d’accès, ni d’identifiants SSH ni de mots de passe. Bien que cela semblait décourageant, nous avons accepté de consacrer une journée entière à la recherche d’une solution. Nous étions conscients que nos efforts pourraient ne pas aboutir, mais l’espoir de trouver une solution persistait.

Heureusement, le serveur était hébergé chez Infomaniak, ce qui a permis au client de me créer un compte au sein de son équipe. Cela m’a donné accès à l’adresse IP du serveur, première étape cruciale dans ma quête d’accès. La première tentative a été de contacter le support technique d’Infomaniak en présence du client afin de réinitialiser les identifiants par défaut, mais cette approche n’a pas abouti et nous avons été invités à résoudre le problème de manière autonome.

Face à cette impasse, j’ai envisagé une approche plus brute. Je me suis demandé si des rainbow tables contenant des mots de passe SSH pourraient être utilisées pour révéler le mot de passe adéquat. Sachant que le compte par défaut était “debian”, j’avais déjà le nom d’utilisateur, mais il me manquait toujours le mot de passe. Malheureusement, après quelques essais infructueux de mots de passe courants, il est devenu évident que le serveur n’acceptait que les connexions via une clé SSH. Une nouvelle difficulté à surmonter.

Persévérance et solution

Malgré le caractère apparemment insoluble du problème, j’ai informé le client que j’étais déterminé à poursuivre mes recherches jusqu’à la fin de la journée. Puis, soudain, j’ai découvert une solution à portée de main, qui avait été sous mes yeux depuis le début. L’interface d’administration d’Infomaniak permettait de passer le serveur en mode de récupération. Dans ce mode, un autre serveur presque vide est activé, avec des identifiants fournis par Infomaniak, et le disque dur du serveur de départ est disponible à part pour être monté et chargé dans ce serveur temporaire.

Je suis donc passé en mode de récupération, j’ai utilisé les identifiants fournis par Infomaniak, et bingo ! J’ai pu accéder à un serveur temporaire ! Il ne me restait plus qu’à monter le disque dur du serveur cible et à explorer les fichiers. J’ai rapidement identifié le profil de l’employé concerné et j’ai remplacé sa clé SSH par la mienne. Ensuite, j’ai redémarré le serveur dans son état normal… et ça a fonctionné ! J’ai pu me connecter au serveur en utilisant le compte de l’employé et ma clé SSH !

Résultats

La première action que j’ai entreprise a été d’examiner l’historique des commandes exécutées, afin de recueillir des informations pour mon rapport. Les dernières commandes exécutées consistaient à pousser tout le code du CRM sur le compte GitHub de l’employé, avant de tout supprimer du serveur. Ce comportement expliquait pourquoi le CRM ne répondait plus.

J’ai poursuivi mes investigations sur le serveur, recueilli toutes les informations pertinentes, y compris la découverte d’un site Web à part, qui était une ancienne version très personnalisée de WordPress, avec des identifiants de base de données présents en clair dans environ 50 fichiers personnalisés. Cela me laissait penser que la qualité du code du CRM ne devait pas être optimale. Pour limiter les risques, j’ai modifié les identifiants de la base de données ainsi que dans chaque fichier, empêchant ainsi l’employé de causer davantage de dommages. J’ai ensuite finalisé mon rapport, comprenant toutes les preuves à charge, ainsi que les nouveaux identifiants pour chaque base de données et chaque compte du serveur, que j’ai remis au client. Bien qu’il n’ait pas pu récupérer le code de son CRM, il disposait de tous les éléments nécessaires pour prendre des mesures supplémentaires, si nécessaire.

Conclusion

Quelques jours plus tard, le client a s’est entretenu avec l’employé en question et a pu récupérer le code de son CRM, qui a été réinstallé sur le serveur. Par la suite, il nous a sollicités pour reprendre le développement du CRM à la place de l’employé. Cependant, après avoir effectué un audit approfondi de la qualité et de la maintenabilité du code existant, nous avons exprimé des doutes quant à la faisabilité de cette reprise. Le code du CRM était extrêmement complexe, dépourvu de logique cohérente, et il était surprenant qu’il fonctionne encore partiellement. Nous avons conseillé au client de reconstruire le CRM à partir de zéro, en respectant les normes et les bonnes pratiques, pour garantir une solution stable, maintenable et pérenne. Depuis lors, nous n’avons plus eu de nouvelles du client. J’espère qu’il a pu achever son CRM à temps et qu’il a pris des mesures pour sauvegarder ses données de manière adéquate.

Cette intervention sur le serveur d’un client a été une expérience enrichissante, mettant en évidence l’importance d’une expertise technique approfondie et d’une approche méthodique face aux situations complexes. Elle souligne également l’importance de la sécurité des informations et de la prise de mesures préventives pour prévenir les pertes de données critiques.