Dyrk

Bonjour à tous,

Je vous souhaite une excellente année 2024, et j'espère que vous avez passé de bonnes fêtes !
Pour ma part, l'année commence avec cette attaque …
De quoi vous offrir le premier article de l'année !

Un autre devrait paraitre prochainement sur comment les outils que vous trouvez sur Internet
permettent de "tricher" sur votre "Ratio" lorsque vous faites de "P2P" sur des "Trackers" privé.
Bref, peut-être des mots chinois si vous n'êtes pas familier au téléchargement de torrent.
Mais je vous rassure, je vous expliquerais tout ça ;)

Préquelle de l'actuel site Dyrk

Près de 10 années se sont écoulées depuis le premier article publié !
Il s'agissait historiquement pour moi d'un objectif d'achat / revente de ce nom de domaine …
Mais force est de constater qu'à l'époque, celui-ci n'a pas sût trouver son publique.

J'ai dû donc m'ateler à lui donner un peu de visibilité sur Internet, et pour cela lui fournir
un peu de contenu. Au fil des mois et des années le référencement s'est progressivement, mais surtout
et avant tout, l'écriture d'un blog m'a amené à me challenger sur tout un tas de curiosité IT.

J'ai fait pas mal d'expérimentation directement sur mon serveur, tant sur du développement logiciel, que
sur de la cybersécurité … puis j'ai partagé ces expérimentations, en exposant parfois directement le blog
à des risques de compromission. Mais bon, il faut bien que jeunesse se fasse …

Par exemple, dans les premières années de l'existence de Dyrk, je me suis interessé à l'OCR.
Il s'agit d'une technologie permettant de faire de la reconnaissance de texte depuis une image.
Je me suis donc attelé à tester des solutions OpenSource, et même à produire de façon plus ou moins fonctionnelle ma propre solution.
J'ai partagé un POC dans un article, avec une petite page permettant d'uploader des images … et d'en récupérer le texte.
Bien mal m'en a pris ! Une armée d'IP venant de chine s'est mis à tambouriner cette page, envoyant des centaines d'images à convertir en texte …
Le CPU de mon serveur était totalement occupé !
J'ai dû mener une opération de longue haleine et un travail de fourmi pour reprendre la main dessus …
La connexion SSH au serveur était très … très … très lente, et chaque caractère que je saisissait, prenait plusieurs secondes avant d'être pris en compte.
Il m'a fallu faire des filtres sur les logs … puis créer des règles "ipTable", afin de bloquer toutes ces ip, sans oublier la suppression de cette fameuse démonstration d'OCR en ligne.

Notification CloudFlare

Fin de journée de boulot, avant d'éteindre mon poste, je prends 5 minutes pour contrôler mes mails perso sur mon téléphone …
Rien d'anormal dans ma boite de réception, mais je jette toutefois un coup d'œil à mes indésirables.
C'est là que je vois un mail de CloudFlare (plus précisément une notification de mon hebergeur OVH me relayant une "plainte" de CloudFlare) !
Peut-être du Spam …. mais en y jetant un œil, je me rends compte que c'est un mail officiel de CloudFlare qui m'informe que Dyrk héberge une page de phishing !

Pour ceux qui ne connaissent pas CloudFlare, il s'agit d'une plateforme qui fait le tampon entre les visiteurs de mon site, et mon site lui-même.
Il assure certains aspect pratique au niveau de la sécurité (WAF), mais permet également un accès plus rapide au contenu de mon site par tout un tas d'outils qu'il met à disposition.
Bref, CloudFlare bloque l'accès à ce contenu avec un message de prévention et à notifié à OVH de la présence d'une page de phishing sur mon serveur ... ce qui enfreint bien évidemment les conditions d'utilisation.

Compromission du serveur

Si CloudFlare m'informe qu'une page de phishing est sur mon serveur, c'est qu'il y a quelque part, une porte d'entrée qui permettrait de télécharger sur mon site internet du contenu malveillant.

Sauvegarde du blog & conservation des "preuves"

Pour l'heure, je n'ai pas encore identifié l'origine de l'attaque, mais pour moi, il est important s'il y a compromission, de sauver ce que je peux sauver.
Je lance donc une opération de sauvegarde d'envergure :

• Fichier(s)
• Bases de donnée(s)
• Log(s)

Cette sauvegarde me permettra non seulement de "sauver les meubles", mais aussi et avant tout de mieux comprendre l'origine de l'attaque, car plus longtemps l'attaquant est installé, plus il a le temps d'altérer / supprimer ses traces, et plus dur pour moi sera la tâche de comprendre ce qu'il s'est passé et comment me sécuriser.

Laisser le site ouvert

Couper complétement l'accès au site serait une erreur et pourrait faire paniquer l'attaquant, qui mettrait en pause pour une durée indéterminé son attaque.
Il convient donc d'entretenir chez lui le sentiment qu'il continu à gagner, ou du moins à ne pas perdre.
Je prends donc la décision difficile de laisser ouvert et accessible le site, avec une potentielle vulnérabilité dont j'ignore pour le moment la localisation …
Il me faut comprendre comment le "hacker" s'y prend pour télécharger sur mon serveur ses fichiers malveillants.
Bien entendu je ne compte pas trop lui faciliter la tâche …

Déterminer les fichiers récemment installés sur mon serveur

La chance que j'ai à ce moment là, c'est que je n'ai pas touché au blog depuis plusieurs mois …
Logiquement aucun fichier n'a donc été modifié par moi.
Une modification devrait donc pouvoir assez rapidement être isolé avec ce type de commande :

Affichage des fichiers générés depuis moins d'un jour, par l'utilisateur www-data :

$ find /var/www -group www-data -newermt $(date +%Y-%m-%d -d '1 day ago') -type f -print;

Affichage des fichiers générés depuis moins d'une heure, par l'utilisateur www-data :

$ find /var/www -group www-data -cmin -type f -print;

Ces commandes ne permettent pas forcément de déterminer l'origine, mais en tout cas, elles vont nous permettre de localiser une partie des menaces.
Bref, j'ai désormais des fichiers qui sont autant d'éléments permettant de comprendre qui m'attaque, et ses intentions.

Je ne supprime pas les fichiers, mais je les stocke ailleurs pour une investigation ultérieur.

Des pages de phishing produites par des acteurs malveillants

Je comprends assez rapidement qu'il y a plusieurs pages de phishing, et via les commentaires écrit dans leurs fichiers je retrouve des pseudo & liens Telegram de leurs auteurs …
Il ne s'agit pas là du ou des Hackers sévissant sur le blog … mais simplement de personne qui produisent et commercialisent des pages de phishing, qui sont par la suite distribuées manuellement ou de façon automatisée dans mon cas.

J'ai pu contacter ces personnes, elles n'ont absolument aucune information sur ce qu'il advient de leurs "produits" une fois vend.
Cela ne les empêches aucunement d'être friandes de le voir à l'œuvre … quitte à perdre tout sens de moralité en demandant aux victimes (en l'occurrence moi-même), des Screenshot …

Confronter les fichiers et les logs

Les fichiers créés sont datés, il s'agit là d'un indicateur …
Je constate même qu'il s'agit là de plusieurs date de phishing, dispatché dans toutes l'arborescences du blog …
Le Hacker s'est donc aménagé la garantie d'avoir toujours une page de phishing en ligne, si d'autres venaient à être supprimée.
Autre constat … le hacker s'est installé depuis un certains temps, les pages de phishing ne sont pas daté du même jour ….
Ce qui est une mauvaise nouvelle pour moi …
Plus un attaquant est installé longtemps, plus il peut masquer ses traces …. et donc moins nos informations sont fiables….

2 informations me sont désormais utilisables :

• Le nom des fichiers
• Leurs dates de création

Le hacker n'a pas donné dans l'originalité, il y a de nombreux fichiers / dossiers portant les mêmes noms …
Je peux également m'appuyer sur les logs pour voir si ces noms ne sont pas dans des requêtes, ou isolé les requêtes faites sur mon serveur sur les heures où les fichiers ont été créés / modifiés

Par les logs, je constate également la présence de scan … des centaines d'ip font des requêtes très suspecte afin de trouver des archives, des fichiers sensibles des sous-répertoire portant sur des composants potentiellement vulnérables (un vieux phpmyadmin par exemple ;) )

Logs & Contexte de Phishing

L'analyse de logs doit être méticuleuse, mais ce n'est pas forcément simple dans un contexte de phishing.
En effet, le Hacker a disséminé des pages de phishing à plusieurs endroits, et à envoyé un mail à des centaines de milliers … peut-être même de millions de personnes … représentant à la fois une charge pour le serveur, mais également un alourdissement des logs du serveur avec toutes les requêtes générés.

Rotation des logs & disparition des traces !

Au vu des dates des fichiers malveillants, je me rends compte que ce ou ces hackers se sont probablement installé tranquillement, sur plusieurs jours, semaines ou mois.

La plupart des sites qui reçoivent beaucoup de visiteurs doivent faire ce que l'on appelle de la rotation de log.
Dans les grandes lignes, lorsque vous consulter un site internet, celui-ci va automatiquement renseigner dans un fichier de "log" le ou les ressources que vous consulter.
Mais forcément le fichier va se remplir au fil des jours, semaines, mois et si vous avez vraiment beaucoup de monde qui visite votre site ... ça pourrait saturer tout votre espace disque !!!!

On utilise donc la rotation de log pour dire qu'on fait un roulement de logs sur 7 jours, 2 semaines, 3 mois ... bref la période qui vous arrange.

ça va générer un fichier de log par jour, ou par semaine ou par mois, par exemple (jour.1.log, jour.2.log, jour.3.log, ... bien entendu je vulgarise, je vois d'ici les admins sys' faire de grands yeux !) et à la fin du roulement hop on repart à 0.

Si le Hacker attend suffisamment longtemps après avoir infiltré votre serveur, vous n'aurez peut-être plus de trace de son point d'entrée ...

Je vous recommande donc de réfléchir judicieusement à la façon dont vous pourriez configurer votre rotation de logs ;)

Charge serveur & et effet sur le référencement

Il n'est pas malvenu d'avoir un peu de trafic (visiteurs) supplémentaire sur le blog, mais là il faut absolument dégager tout ce nouveau monde qui perturbe mon investigation.
Je vais donc aller à la hache en bannissant toutes ces ips avec du fail2ban ou même directement avec de l'iptable

$ iptables -A INPUT -s xxx.xxx.xxx.xxx -j DROP

Cela me permet d'isoler davantage les requêtes du Hacker vis à vis des victimes de son phishing.

Contrôler l'intégrité

L'avantage de mon blog, c'est qu'il s'agit d'un WordPress on ne peut plus basique, sans trop de fioriture.
Je n'ai donc aucun scrupule à remplacer les fichiers de celui-ci (potentiellement compromis) par les fichiers d'origine fourni par la dernière version de WordPress.
Cela me permet d'avoir des fichiers sains (non altérés).

Mieux encore, cela me permet d'avoir une date unique pour tous ces fichiers !
Ainsi, en ayant écrasé et au passage assaini les fichiers de mon blog WordPress, tous les fichiers remplacés sont désormais avec une seule et même date de création / modification !
Cela me permet encore une fois de détecter des fichiers qui seraient …. en trop (pas à la même date) !

Point(s) d'entrée(s) & neutralisation du risque

J'ai désormais un aperçu plutôt large des fichiers malveillants récents … où installés depuis un petit moment ….
Je supprime donc tout ça, puis j'attends de voir ce qu'il se passe.

Comme indiqué au début de cet article, j'ai par le passé …. après 10 ans d'existence …. testé beaucoup de chose sur le blog.
Disséminé ici et là des scripts / pages de test … bref les points d'entrée pour ce Hacker sont donc multiple …

• J'ai supprimé tout ce qui me paraissait être à risque …
• Durant l'attaque j'ai constaté la présence de "nouveaux" thèmes & plugins …. j'ai donc tout bonnement dégagé ces contenu issus ou à l'origine de l'attaque, en ne conservant que l'essentiel des plugins vitaux & de confiance pour le blog (antispam, captcha, …).
• J'ai dégagé tous les points d'entrée que s'était aménagé notre vilain Hacker …. car une fois installé, celui-ci s'est aménagé un véritable labyrinthe d'accès au site ... au cas où l'un d'entre eux viendrait à être neutralisé.

Le risque est désormais (pour l'instant)…passé.
Je touche du bois (expression française faisant référence à une action portant chance), mais cela fait désormais une dizaine d'heure au moment ou j'écris ces lignes que je n'ai détecté aucune activité suspecte.

Conclusion

Cet article a été écrit pour vous donner un aperçu de comment il est possible de gérer ce type situation.
Il n'y a pas vraiment une méthode unique : il faut vraiment prendre considération le contexte et le risques (les données) qui est en jeu !
Pour ma part, bien que je tienne très fort à mon blog, et 10 ans d'articles écris à la sueur de mon front, je n'adopterais pas (automatiquement) cette stratégie pour un contexte d'entreprise.

Cependant, quelques soit la technique employée, cela demande de garder son sang froid et de ne surtout pas paniquer.
Sauvez ce que vous pouvez sauver, mais gardez en tête que l'observation en temps réel vous permettra de mieux comprendre la stratégie de votre attaquant et de découvrir de nouvelle manière de faire (qui sait ? peut-être découvrir l'exploitation d'une ZeroDay).

Si vous êtes une entreprise, je vous invite à anticiper ce type d'attaque, et à rédiger un mode opératoire pour ne pas être pris au dépourvu le jour où cela arrivera … car cela arrivera … la question c'est … quand ?

Bonne journée à tous !