Admin/Dev

25
Nov.
2019

Nettoyer un site Joomla, victime d'un hack

Publié par sky

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 :

  1.  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.
  2. 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).
  3. 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.
  4. 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.
  5. 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 ?

 
 
Commentaires
Commentaire de Lecomte le 23 Mars 2020 à 12:48

Bonjour, merci pour cet article très instructif. Comment faites-vous pour décoder et trouver l'URL du fichier .ico dans votre exemple ?

 
Commentaire de sky le 23 Mars 2020 à 13:16

Bonjour Lecomte,
De souvenir, la lecture de l'url pouvait se faire avec la fonction PHP "rawurldecode". Mais, utiliser find pour trouver "tous" les fichiers est la meilleure méthode .
Bon courage.

 
Commentaire de strider le 5 Avril 2020 à 22:36

Pour décoder, on peut éventuellement utiliser www.unphp.net/

 
Commentaire de Ben le 30 Juin 2020 à 21:48

Bonjour,
Merci pour votre article, bien rédigé et accessible (même pour moi!)
La signature "$GLOBALS[" concerne t-elle les .ico ou bien les .php infectés (ou autre?)
Existe t-il une autre signature que celle là ?
merci

 
Commentaire de sky le 30 Juin 2020 à 22:56

Bonjour Ben,
Merci :-)
Le $GLOBAL est du code PHP qui peut éventuellement se cacher dans le faux fichier .ico.
Mais je ne suis plus très sur, cela commence à faire un moment.
Bon courage.

 
Commentaire de Nguyen le 14 Octobre 2020 à 23:23

Super article. Franchement bien fait à la fois techniquement et avec du style. Ca fait un peu "enquête" à la Sherlock. ;) Sky, comment avez-vous fait pour trouver que la signature était "$GLOBALS"? Quel(s) indice(s) vous a (ont) poussé vers ce résultat?
Trop curieux de savoir car on part quasiment de zéro dans cette recherche. Vous avez regardé fichier par fichier???? :)

 
Commentaire de sky le 15 Octobre 2020 à 16:40

Salut, merci pour ton commentaire, ça fait toujours plaisir.
En effet, il a fallut remonter la piste depuis le fichier index.php, Ensuite, le but était de trouver un pattern qui fonctionnait avec tous les fichiers infectés. C'est pas tant le $GLOBAL mais plus le point virgule devant, collé. Un développeur aurait sauté une ligne après chaque ; et/ou laissé un espace après pour la lisibilité. Aussi il était parfois placé avant les en-têtes des fichiers, ce qui est tout aussi illogique. Bref, mon raisonnement était de trouver tous les petits détails qui semblent pas logiques. A postériori, en effet, cela semble amusant de suivre les pistes à la manière d'un Sherlock, mais sur le moment, j'étais plus en stress afin de rendre le site de mon client à la normale le plus rapidement possible.

 

 

Poster un commentaire
En postant sur skymac.org, je m'engage à être courtois et à ce que mon message soit pertinent avec le sujet de l'article.
En outre, j'accepte, sans condition, que mon message soit refusé et supprimé si ces règles ne sont pas appliquées.
Captcha indisponible
Pour valider le formulaire, vous devez confirmer que vous êtes bien une personne. Actuellement, la fonctionnalité est indisponible. Vous devez activer le service ReCaptcha dans le gestionnaire des cookies, et donc consentir à l'utilisation de ses cookies.
Ouvrir le panneau de gestion des cookies
Fermer le panneau
Ce site utilise des cookies pour assurer son bon fonctionnement. Il utilise aussi des cookies issues de services tiers permettant de proposer des fonctionnalités avancées. À tout moment, vous pouvez choisir quels services vous souhaitez activer ou refuser, afin de retirer votre consentement quant à l'utilisation des cookies.
 
Personnalisation des services
Vous êtes libre de choisir quels services vous souhaitez activer. En autorisant ces services tiers, vous acceptez le dépôt et la lecture de cookies et l'utilisation de technologies de suivi nécessaires à leur bon fonctionnement. En retirant votre consentement pour certains de ces services, certaines fonctionnalités du site peuvent ne plus fonctionner.
Navigation du site  En savoir plus
Le site écrit un cookie de session permettant son bon fonctionnement et aidant à la navigation. Il ne peut être désactivé.
Utilisation : 1 cookie, enregistre l'identifiant de la session.
Durée de vie : Le cookie est présent pendant toute la session sur le site. Il devient obsolète après 24 minutes d'inactivité.
Obligatoire
Popup Média
Afficher des vidéos depuis Yoube ou Dailymotion.
ReCaptcha  En savoir plus
Permet de valider que les visiteurs sont bien des humains lorsqu'ils valident des formulaires.
 
Tout accepter Tout refuser Gérer