Nettoyer un site Joomla, victime d'un hack
Il y a quelques temps, le site, créé avec Joomla, de l'un de mes clients, s'est mis à se comporter bizarrement. En effet, à la première connexion à ce dernier, un fichier vide était téléchargé, sans afficher la page d'accueil. Si l'on relance l'adresse URL une seconde fois, le site s'affichait.
Plus bizarrement, en essayant de charger la page depuis un outil comme curl ou wget, le problème n'apparaissait pas.
1/ Détection du problème
Malgré ma méconnaissance du CMS Joomla, et de la structure du site que je n'ai pas créé, la détection du problème ne prend pas trop de temps. Dès l'examen du fichier index.php, je remarque du code qui ne semble pas être du code original, et ce, quelque soit le CMS utilisé.
Dès les premières lignes, je trouve
/*z8v7e*/
@include "\\057h\157m\145z\057w\167w\057\143o\155_\165s\145r\163/\143o\156t\162o\154l\145r\163/\056k\144f\142a\0710\064.\151c\157";
/*z8v7e*/
Il est tout de même bizarre d'encoder le chemin vers un fichier à inclure, non ?
Certes, cela peut certainement berner une personne sans connaissance en programmation, qui du coup, ne touchera à rien, de peur de casser quelque chose.
En décodant le chemin, j'obtiens le résultat suivant
/homez/www/com_users/controllers/.kdfba904.ico
Ici encore, les indices sont faciles à détecter. D'une part, pourquoi inclure un fichier icône ? Deuxièmement, pourquoi le nom du fichier commencerait il par un point. Sur Linux (et macOS), les fichiers commençant par un point sont invisibles, quel intérêt de masquer un fichier du type image ?
Evidemment, il s'agit ici d'être le plus discret possible afin de rester le plus longtemps actif sur le serveur.
L'ensemble des preuves trouvées ici montre bien qu'il s'agit d'un malware, et que donc le site est infecté.
2/ Examen du hack
Le principe est simple, à chaque fois qu'un visiteur accède à une page du site, le fichier index.php est appelé, et avant d'afficher le contenu des pages généré par Joomla, il exécute son petit merdier présent dans le fichier icône.
A l'ouverture du fichier .ico, on repère tout de suite qu'il ne s'agit pas d'un fichier image mais bien du code PHP executable. Encore une fois, il est caché derrière un ensemble de mécanismes d'encodage en cascade qui permet de masquer le code.
N'ayant pas vraiment le temps, je n'ai pas cherché en profondeur ce que fait réellement ce code, mais il y a fort à parier que le malware tente d'envoyer des e-mails, ou réalise du minage de cryptomonnaie, car ce sont les deux principalement plaies présentes actuellement.
Le malware utilisait donc les ressources du serveur pour ses propres besoins, de manière très silencieuse afin qu'il ne soit pas repéré.
3/ Nettoyage du hack - niveau 1
La première chose à faire est de supprimer le code qui appelle le malware en tant que tel. Il est donc nécessaire de supprimer l'include présent dans l'index.php.
Ensuite, il est logique de supprimer le fichier .ico.
La troisième étape est de mettre à jour Joomla, en espérant que la faille de sécurité soit corrigée, et ne fasse pas partie d'un des modules intégrés.
Par précaution, une petite recherche permet de vérifier s'il existe d'autres fichiers .ico du même style. Dans le dossier du site, il suffit de taper :
find . -name ".*.ico"
Sans surprise, le résultat m'indique deux autres fichiers ayant la même structure, à savoir un fichier .ico qui commence par un point. A l'ouverture dans un éditeur de texte, je confirme rapidement que ce d'autres malwares.
Voici la commande pour la suppression des fichiers
find . -name ".*.ico" -delete
S'il y a d'autres fichiers .ico, c'est peut être qu'il y a d'autres fichiers qui tentent d'appeler le malware ?
Pour vérifier, je lance un petite recherche, toujours depuis la racine du site, sur l'ensemble des fichiers du site, pour voir s'il n'y a pas des includes utilisant un chemin encodé.
egrep -ri '@include "\\057' *
Le résultat est accablant, c'est une vingtaine de fichiers qui sont vérolés. Ici, le ménage est fait manuellement, supprimant l'include de tous les fichiers en les éditant 1 par 1. Je suis sur qu'il y a moyen de supprimer le code malicieux automatiquement, mais je n'ai pas souhaité prendre de risque sur des fichiers dont je ne connais pas le contenu habituel.
Le ménage est fait, enfin, en surface ...
4/ Nettoyage du hack - niveau 2
Comme d'habitude, avec ce genre de hack il est nécessaire d'effectuer une surveillance régulière pour être sur que le problème ne revienne pas.
Et heureusement que nous avons mis cette surveillance en place, car dès le lendemain, l'ensemble des fichiers .ico étaient revenus, et les fichiers php avaient retrouvé leurs includes.
Après un nouveau nettoyage complet, il est nécessaire de trouver comment tout cela a pu revenir.
Le plus simple, pour les hackeurs, est d'appeler une autre page qui aurait échappé à notre surveillance. Et comme on en connait pas la structure, il n'est pas possible d'établir une signature afin de réaliser une recherche directe sur les fichiers.
Dans ce cas, le plus simple, est d'éplucher les logs d'accès au site, avec la patience nécessaire.
Les critères de recherche sont :
- Les fichiers de logs sont, en général, très long, il faut réduire la fenêtre de recherche entre la dernière vérification avec succès, et le retour du malware.
- Trouver des requêtes "singletones". En général, lorsqu'un appel à une page est fait, plusieurs autres la suive, demandant au serveur les fichiers CSS, les scripts ou encore les images. Ici, la requête est bien souvent seule, n'ayant pas besoin des fichiers annexes (et n'essayant pas forcément de maquiller sa connexion).
- La requête dispose souvent d'un user-agent très classique, celui d'un navigateur parmi les plus connus, tel de Firefox ou Chrome dans une version pas forcément très récente. Il est aussi possible que le user-agent soit complètement farfelu avec une version de Internet Explorer ou d'Opera datant du début des années 2000.
- Le user-agent permet aussi de faire le tri des requêtes effectuées par les moteurs de recherche. En cas de doute, il est aussi possible de vérifier l'adresse IP enregistrées pour les requêtes. Bien souvent, les adresses des moteurs de recherche sont connues et peuvent être vérifiées sur des sites internets dédiés.
- Enfin, et c'est certainement le plus important, la page demandée doit être atypique. Une page perdue au milieu de l'arborescence du site, voir une page de code qui n'a pas à être appelée directement.
Dans mon cas, ce sont 2 pages que j'ai pu trouvé, perdues au milieu du site, et dont les accès étaient plus que suspects.
Encore une fois, il suffit d'ouvrir les fichiers avec un éditeur de texte pour vérifier la présence d'un code malicieux. Un code qui n'est pas difficile à trouver puisqu'il se trouve en tête de fichier, avant les en-têtes de Joomla, confirmant un peu plus sa présence indésirable.
Après examen, j'ai pu établir une signature simple, afin de trouver tous les fichiers de la sorte, au cas où, ils n'aient pas tous été appelés via leurs URLs.
egrep -ri ';\$GLOBALS\[';
Il suffit ensuite de supprimer le code malicieux des fichiers trouvés. Il ne faut évidemment pas oublier un fichier, sous peine d'avoir à tout recommencer à chaque nouvelle injection du malware.
Le ménage de niveau 2 est effectué, et il est nécessaire de reprendre la surveillance.
Aujourd'hui, après quelques mois passé, le malware n'est pas revenu. Le site est désormais clean de malware ... mais peut être pas d'un autre ...
5/ Résultat
Heureusement que le site était affecté par ce petit comportement initial très bizarre, sinon le hack n'aurait peut être pas été découvert, ou alors, bien plus tardivement.
N'étant pas revenu avec le malware, il devait s'agir d'un soucis dans le hack lui même. Un effet secondaire indésirable sans lequel le propriétaire du site ne se serait pas inquiété, et, pour lequel, je n'aurais jamais mis le nez dedans et détecter un problème.
C'est la seconde fois que je traite ce genre de mésaventures. La première fois, il s'agissait d'un site Wordpress qui avait été hacké pour envoyer des e-mails indésirables par millier. Là aussi, le malware s'était installé dans une multitude de fichiers afin de pouvoir revenir plus facilement.
A chaque fois, ces problèmes me conforte dans l'idée d'utiliser mes propres outils ou des outils n'ayant pas une forte audience. Même si cela implique de ne pas profiter des avantages de ces systèmes.
Je préfère, pour ma part, avoir la maîtrise totale de l'outil. Ce qui permet de déceler plus facilement les fichiers modifiés. Ce qui permet ensuite de réparer le site dans des délais très courts.
Il faut aussi savoir que bien souvent, ce sont les outils les plus utilisés qui sont victimes de ce genre de hack. Car il est plus intéressant pour les hackers de cibler des milliers de sites plutôt de se limiter à quelques uns. C'est d'autant plus vrai que ces CMS grand public peuvent être installés par n'importe qui, sans nécessiter de grandes connaissances, et du coup, sans être capable de voir les éventuels problèmes.
Du coup, même si les outils moins connus sont Open Source, ils n'attirent pas autant l'attention que les projets leaders du marché.
Ici, le site a été entièrement nettoyé, et après des vérifications successives, mais pour 1 site nettoyé, comment de sites sont actuellement infectés ? Bien souvent, ces sites sont hébergés sur des serveurs mutualisés, quel est l'impact pour les autres sites ? Les ressources étant partagées, est ce que cela n'impacte pas de trop, les performances des autres sites présents sur le même serveur ?
