Bonjour à tous et bienvenue si vous êtes nouveau sur ce site internet.
Aujourd’hui, nous allons examiner ensemble l’un des casse-têtes les plus difficiles auxquels j’ai été confronté lors de mes débuts en investigation post-incident après une cyberattaque. Nous aborderons également le nettoyage des logiciels malveillants afin de restaurer le système à son état normal.
Tout a commencé un vendredi matin, lorsque j’ai été contacté par un client pour qui j’avais conçu un site internet. Ce dernier avait décidé qu’après la conception du site, la maintenance et les mises à jour seraient effectuées par son équipe interne.
Le client m’explique que son site internet semble être devenu plus lent et que certains utilisateurs se plaignent d’être redirigés vers des sites de casinos et de publicités trompeuses. Cependant, lorsqu’il est connecté au site, il ne remarque pas les problèmes signalés par ses clients.
Après avoir discuté des modalités et des conditions du mandat, j’ai commencé par mettre en place un environnement contrôlé (sandbox) pour analyser le site infecté sans risquer de compromettre l’intégrité de mes propres fichiers. Pour ce faire, j’utilise des images VMware avec des outils préinstallés. Chaque fois que je dois travailler sur un incident de ce type, je crée une nouvelle VM et je l’isole de toute communication avec mon poste principal.
IOCs (Indicateurs de compromission)
Tout au long de cet article, j’utiliserais le terme IOC « Indicator of Compromise » qui veut dire indicateur de compromission est une preuve que quelqu’un a pu s’introduire dans le réseau ou le point de terminaison d’une organisation.
Une fois que mon environnement configuré, je me rends sur le site et je remarque effectivement le premier indicateur de compromission mentionné plus haut qu’on va appeler (IOC1) qui est la redirection vers des sites malicieux externes (capture ci-dessous).
Un autre aspect surprenant de cette redirection est qu’elle n’est pas visible pour les utilisateurs connectés au site internet. Cela explique probablement pourquoi les administrateurs du site n’ont pas remarqué la redirection, car il fallait consulter le site en tant que visiteur lambda pour être redirigé, comme le montre la capture IOC1.
Déjà juste en observant l’IOC1 on peut déjà supposer qu’on assiste à une redirection javascript CAD du code malicieux javascript a été insérer dans l’une des pages du site web afin de rediriger les visiteurs vers des sites externes.
J’ai mis le site en pause à cette étape et je suis allé effectuer une recherche sur Google pour vérifier s’il existait des cas de compromission de sites WordPress impliquant des redirections par JavaScript.
Effectivement, des cas similaires avaient déjà été documentés. Je me suis inspiré de certains de ces articles pour faciliter la résolution de mon problème.
Note : J’ai toujours pensé que les compétences en recherche devraient représenter plus de 50 % du profil d’un informaticien, quel que soit son domaine de spécialisation. Savoir trouver la bonne information sur Google est crucial et peut faire gagner énormément de temps.
Je suis allé plus loin pour déceler d’autres traces potentielles de compromission. En me connectant au site avec les accès fournis par le client, je suis allé dans la section des utilisateurs et j’ai remarqué que des utilisateurs non autorisés avaient été ajoutés. Nous appellerons cela IOC#2
Note : Le site web dans ce contexte est un site WordPress. Par conséquent, les techniques de nettoyage que je vais utiliser sont spécifiques à WordPress. Cependant, la méthodologie et la démarche d’investigation peuvent être adaptées et appliquées à d’autres types de sites internet.
Vérification de la version des extensions et du thème
J’ai ensuite procédé à une vérification du code source des fichiers de base de WordPress, tels que wp-blog-header.php et wp-config.php, pour déterminer s’ils avaient été modifiés. Le fichier par défaut wp-blog-header.php ressemble à l’image ci-dessous :
Voici la version qu’on avait sur le site compromis ci-dessous;
Nous avons un méchant ajout de code obfusqué en base64.
En terme simple l’obfuscation de code est le fait de rendre un code illisible. Dans la plupart des cas comme celui-ci, c’est souvent à des fins malveillantes afin de rendre le travail d’investigation plus compliqué.
On appellera ceci IOC #3
Analyse des journaux d’accès
À ce stade, cela a été un véritable combat avec l’entreprise d’hébergement pour obtenir les journaux d’accès du site. Cependant, nous avons réussi à les obtenir grâce à une sauvegarde accessible via le cPanel du client.
Le journal d’accès en format brute ressemble à ce qu’on a sur l’image ci-dessous;
Il contient plusieurs éléments utiles pour l’investigation, tels que l’adresse IP des visiteurs, les pages visitées, le type de requête (GET, POST, TRACE, etc.), la durée des requêtes, le user agent, le code de réponse, etc.
Pour cette étape, j’ai utilisé un outil libre appelé XL Parser afin d’organiser les journaux dans un format lisible et facilement compréhensible.
À cette étape, j’essaie de créer une base de données avec les détails provenant du fichier journal afin de pouvoir y naviguer plus facilement avec des requêtes SQL. Un article dédié sera consacré à l’apprentissage de l’utilisation de XL Parser pour effectuer des analyses post-incidents.
À cette étape, nous procédons à la conversion des entrées du journal en format SQL, comme mentionné précédemment. Cela peut prendre beaucoup de temps en fonction de la taille des journaux. Dans notre cas, nous avons 333 673 lignes à convertir, avec un temps estimé d’environ 11 minutes.
Ce qui va nous donner une base de données d’environ 100MB.
Je me rends maintenant dans la section « query database » afin d’exporter des données spécifiques grâce à des commandes SQL. Dans la capture plus haut je demande à exporter toutes les entrées en format Excel.
On fini par obtenir un beau rapport comme dans l’image ci-dessous
La prochaine étape consiste à filtrer ce rapport pour isoler ou retrouver toute requête pouvant être associée à une action malveillante.
Avant de commencer, je tiens à préciser que le client est dans le secteur de la restauration et que le site est en français. Un restaurant a généralement une clientèle locale, car, il est évident que si vous souhaitez manger un croissant, vous ne pensez pas à le commander en ligne ou à prendre l’avion pour le déguster, sauf si vous êtes Cristiano Ronaldo.
De ce fait, la présence d’un nombre élevé d’adresses IP provenant de l’extérieur pourrait déjà constituer un indice de compromission.
Accès privilégiés
Un site WordPress dispose généralement d’une interface de gestion accessible via le chemin ../wp-admin. En isolant le type de requête visant ce répertoire, nous pouvons identifier les différentes adresses IP qui ont tenté de se connecter au panneau d’administration. En filtrant le fichier Excel généré précédemment, nous obtenons la liste complète des adresses IP ayant tenté un accès privilégié.
J’ai pris une des adresses IP qui ne correspondait pas aux adresses IP de gestion habituelles et j’ai effectué une recherche sur https://www.whatismyip.com/ip-address-lookup/.
Il s’avère que cette adresse IP appartient à un fournisseur d’accès Internet réputé pour avoir des adresses IP associées à des fraudes sur internet. Pour rendre cet article aussi concis que possible, je vais me limiter à l’analyse de cette seule adresse.
Nous appellerons cela IOC #4.
Accès aux répertoires privilégies
Méthodes http
Les deux méthodes les plus couramment utilisées sont « GET » et « POST ». La méthode « GET » est employée pour télécharger une ressource ou une URL depuis le serveur web, tandis que « POST » est utilisée pour envoyer des informations au serveur web. La méthode « POST » est souvent utilisée pour transmettre des données sensibles au serveur, et l’extraction des requêtes « POST » est fréquemment un moyen rapide de découvrir des indices de compromission.
Dans XL Parser, nous allons utiliser la requête suivante :
SELECT * FROM LOG WHERE http_method = ‘POST’
On obtient un fichier Excel avec le résultat suivant;
On va analyser une des adresses surtout celle essayant d’interagir avec le plugin lightspeed.
On retrouvait dans les journaux une coupe d’adresses de ce genre qui essayait d’accéder au site à travers les répertoires privilégiés.
J’en suis venu à la conclusion que le site avait été piraté, et que les utilisateurs fantômes étaient probablement vendus sur le dark web. Cela expliquerait pourquoi nous observions des adresses IP provenant de divers horizons tentant de se connecter à la plateforme.
Phase 2 : Nettoyage
J’ai jugé qu’il était nécessaire de procéder à un nettoyage complet avant que la situation ne s’aggrave. Si j’avais opté pour un nettoyage manuel, j’aurais supprimé et désinstallé toutes les extensions ainsi que le thème utilisé par WordPress, puis je les aurais réinstallés via des sites légitimes tels que ThemeForest.
La force d’un CMS comme WordPress réside dans sa vaste communauté d’utilisateurs qui développe des outils pour en faciliter l’utilisation. Wordfence est l’un de ces outils qui a grandement facilité mon travail en me permettant de :
- Comparer les extensions installées sur le site avec leurs versions originales
- Analyser le code malveillant
- Mettre en place des mesures de contrôle après le nettoyage, telles que le firewalling, la double authentification, et la journalisation des événements
L’interface du logiciel ressemble à ceci
Wordfence est capable de corriger les disparités entre les versions de fichiers et de détecter si un fichier a été modifié ou altéré. J’ai procédé à un nettoyage complet en supprimant également les utilisateurs malveillants qui avaient été ajoutés.
Bloquage d’adresses IP.
J’ai également filtré les addresses IP provenant des sources malveillantes grâce à une modification du fichier .htaccess
Avec ça je pensais que tout était terminé et que le client pouvait dormir paisiblement mais non. Le mal était bien plus profond que ça.
Recompromission du site
Une semaine plus tard, le client m’a rappelé, et le même scénario s’est reproduit. Les pirates avaient méticuleusement inséré une tâche cron via le cPanel du client, qui réinjectait le code malveillant à une fréquence spécifique. Ainsi, peu importe le nettoyage effectué sur le site web, la tâche planifiée (cron) existant sur le serveur était capable de recompromettre à nouveau le site internet (voir l’image ci-dessous).
On l’appellera IOC #5
Je m’excuse si l’image n’est pas claire. Ci-dessus, vous pouvez voir plusieurs tâches cron contenant du code obfusqué en base64. C’est la technique que les attaquants ont utilisée pour maintenir l’accès au système. Cela ressemble fortement à ceci :
De ce fait, il fallait tout refaire et additionnellement supprimer les tâches planifiées.
Tout est bien qui fini bien. Je n’ai pas eu de nouvelles depuis et je me charge maintenant du suivi et de la maintenance de ce site web.
Conclusion
La cybersécurité, n’étant pas toujours perçue comme un domaine générant un retour direct sur investissement pour l’entreprise, rencontre généralement une certaine réticence en ce qui concerne l’investissement. La plupart des entreprises décident d’investir en cybersécurité uniquement après avoir été victimes d’un incident, comme dans le scénario actuel.
La perte monétaire liée à la compromission du site dépasse largement le budget qu’il aurait fallu pour protéger cet actif, qui générait pratiquement plus de 50 % de son chiffre d’affaires.
De plus, les effets à long terme de ce genre d’incident incluent une baisse de visibilité sur les moteurs de recherche et, dans certains cas, le risque que le site soit blacklisté.
Vous pouvez également consulter cet autre article qui traite de la sécurité des sites WordPress.
https://solutiontechcan.com/ameliorer-la-securite-de-votre-site-wordpress/
Chez Solution Tech nous accompagnons les entreprises et particuliers vers une transition numérique sécuritaire.
Vous pouvez nous contacter via contact@solutiontechcan.com pour toute consultation reliée à la sécurisation de vos actifs informationnels et de transition numérique.
