Récemment le site d’une pote s’est fait hacker, et son hébergeur, OVH, à bloqué son site dans l’attente de la résolution du problème.

Même si la plupart du temps la solution conseillée est de rollback, à savoir rétablir le site dans un ancien état (~il y a 1 jour / 1 semaine) si on ne fait que ça les problèmes peuvent revenir assez vite.

Donc voici l’ensemble des étapes que j’applique afin de corriger le bousin ; ainsi que certaines alternatives si cela ne fonctionne pas.

C’est pas forcément à la portée de tout le monde sans être méchant, donc les prérequis :

• Savoir lire
• Respecter les consignes de votre hébergeur
• Connaitre un minimum le langage de programmation sous lequel tourne votre site / CMS
  • ~ PHP et MySQL pour les principaux CMS comme WordPress
• Connaitre le gestionnaire de l’hébergeur, par exemple OVH Manager
• Savoir se connecter et manipuler les fichiers via un client FTP ~ FileZilla, WinSCP, Bitvise Tunnelier, peut importe
• Savoir viteuf gérer sur phpMyAdmin (pour MySQL / MariaDB)
• Savoir quelques commandes sur le terminal / bash ça ne fait pas de mal non plus.

Au pire si vous comprenez rieng jetez des jetons LoL ou du platinum pour Warframe par terre et attendez 20 minutes. Quand un développeur se pointera jetez une pokéball pour l’attraper et demandez lui de gérer le bousin.

BREF

Avant toutes choses

1. 💾 Faites des sauvegardes en local sur votre PC, avec un antivirus c’mieux
   • Mais bon si c’est du php ça ne tournera A PRIORI pas sans serveur donc osef
   • Des fichiers
   • Export de la base de données
   • Ensuite dupliquez les : on a un espace pour bosser, et un espace de référence auquel on ne touche pas
2. 📝 Notez les anciens identifiants
3. 🔑 Changez les identifiants FTP
4. 🔑 Changez les identifiants SQL
5. 🔒️ Je recommande chaudement de passer par un générateur de mots de passe forts et de maxer (minimum 25 caractères), ou mieux de passer par un gestionnaire de mots de passe, ~ Dashlane.
6. ⬆️ N’oubliez pas de mettre à jour les identifiants dans le fichier de configuration de votre site, et de le renvoyer en ligne !
7. 📧 Vérifier les éventuelles boites mails associées au site
   • Changez les mots de passe
   • Vérifiez qu’il n’y a pas de nouvelles adresses

ℹ️ Trouver des infos

1. 📝 Voir si l’hébergeur à des recommandations
2. 📝 Voir si l’hébergeur à envoyé un mail ou un ticket dans son administration
3. 🔧 Si OVH > hébergement > infos générales > PHP > Modifier > Passer en développement
   • En mode “production” les erreurs sont masquées

Essayer de choper des indications sur la location & le type de fichiers malveillants.

Par exemple ici :

Problème rencontré : Un script malveillant a été détecté sur votre hébergement
Commande apparente : /homez.515/EUL_CLIENT/www/tmp/cache/3/device/hwm -c default.conf
Exécutable utilisé : /legacy/home/EUL_CLIENT/www/tmp/cache/3/device/hwm
Horodatage: 2023-05-19 11:10:08

Et le mieux reste de regarder les logs afin de voir précisément quels fichiers ont étés impactés.

yay ! Mais bon vaut mieux faire un gros check des familles..

📂 Check des fichiers de surface & thème

Commencer par le commencement, à savoir le dossier racine du site.

En général je récupère l’ensemble des fichiers sur mon poste (ou un VM) et je check directement via VSCode.

Prendre la température avec des fichiers classiques, dans notre cas il s’agit du CMS “SPIP”, français et en déduire des caractéristiques communes.

• Commentaires en français
• Gros blocs de commentaires en début de fichiers, une ligne avant les fonctions
• Grosse indentation ~4 caractères

Vérifiez également qu’il n’y a pas de über grande ligne alakon en début/fin de fichier.

Bon dans le cas présent j’ai rapidement identifié deux fichiers vérolés à la racine :

Je me fait une petite liste des fichiers sur lesquels je suis passé, avec des emojis en rafale :

- ✅ `/www/spip.php` > à l'air classique, en FR et donc merdique.
  - Pas de code caché sur une seule grande ligne alakon
- ⏳🦠 `/www/BsQjxTFX.php` > Yeah rien que le nom pue du fion. Code PHP über compréssé avec des clés/payloads/etc. > Proba un bruteforce de mot de passe.
  - En attente pour investigation
- ✅ `/www/index.php` > A priori non modifié
- ✅🔥 `/www/phpinfo.php` > à la racine > yeah non je vire, faille de sécurité, ptet ajouté par le hack
- ⏳🦠 `/www/response.php` > +- même bail que BsQ..

Pas si pire pour la racine du projet. Je check vite fait les sous répertoires afin de voir si des choses sautent aux yeux.

⚡️ Astuce : Dans l’arborescence de VSCode on peut naviguer dans les fichiers dossiers avec les flèches haut/bas, et forcer l’ouverture du fichier avec espace. On peut donc ‘scanner’ un grand nombre de fichiers très vite, pour voir si des fichiers contiennent une seule ligne de code ou autre facteur discriminant. Spam flèche gauche pour refermer l’arborescence ouverte.

Je détecte 2 autres fichiers dans des sous répertoires > on va donc devoir fouiller en profondeur.

- ⏳🦠 `/www/ecrire/local.php` > eval() et base 64 > virus
- ⏳🦠 `/www/local/config.php` > eval() et base 64 > virus

🔎💩 Essayer de trouver plus de merdes code facécieux hihihihuhuhouhou malicieux

Rechercher dans l’ensemble du dossier avec des mots clés de hackeurh (en gros pas fouiller comme un poulet sans tête) ; le mieux reste de piocher dans les fichiers précédemment trouvés et de réutiliser les noms de fonctions.

Cela permet de virer les éventuelles répliques de fichiers mise en place pour que le virus reparte si certains fichiers sont virés.

Voici une liste des mots clés qui sont rarement présents dans des codes legit

- eval(
- @run(
- encode
  - ⏳🦠 `ecrire\auto.php`
  - 👥 `local\config.php`
- ob_get_contents
  - 👥 `\response.php`
  - 👥 `ecrire\auto.php`
  - ⏳🦠 `local\define.php`
- ob_end_clean
- base64_encode
- base64_decode
  - 👥 `local\config.php`
  - 👥 `local\define.php`
- md5(
- strpos(
- substr(md5
- // Propres à ce hack
- payload
  - Un truc ajouté en toute fin de `<footer>` mais dans `/tmp/cache` donc sera benné
- $data
- $pass
- 'k'
- 'c'

🧠 Pour la culture, une grosse parenthèse :

// Les chaînes générées seront toujours les mêmes, à partir des mêmes mots de base
$uneChaineAlakon = base64_encode('poil'); // hAYmFzZTY0X2RltoY29kZSgkaykpPT09J2U3NF
$uneAutreChaineAlakon = md5('peni'); // ykpomJigoJHM9QGJhc2U2NF9kZWNvZGUoJGMpKStarU

// On assemble les différents morceaux
$promisTuVaVoirCaVaEtreHilarant = '' .
   substr($uneAutreChaineAlakon, 39, 3) . // tar
   substr($uneChaineAlakon     , 14, 2) . // to
   substr($uneAutreChaineAlakon, 2, 3);   // à partir du 2eme caractère, on en récupère 3 // pom

// On lance la fonction au nez & a la barbe de la municipalité
eval($promisTuVaVoirCaVaEtreHilarant);

BREF. Côté fichiers a priori on est pas trop mal.

🗃️ Allez plus loin sur les fichiers

Après cette technique reste relativement hasardeuse et n’est pas fiable à 100%.

En vrai je recommande plutôt de repartir d’une base du logiciel propre ; par exemple re-télécharger un WordPress sain et y rajouter votre thème (re-téléchargé également) / et vos données.

Dans la vraie vie on va pas se mentir on l’utilise quand même pas mal, principalement pour 2 raisons

1. Le site est trop vieux, et même si la base est disponible dans les archives ça reste une purge à remettre en place, surtout si ça tourne sur une vieille version de PHP ou Apache ou autre
2. Le site et/ou le thème ont étés personnalisés à l’arrache ~sans thèmes enfants, et on perdrait du contenu / voir on ferait tout sauter en remettant les versions de base.

⚡️ Astuce : Si vous ne pouvez pas éclater la base par une saine, vous pouvez également comparer votre base actuelle avec une base saine (soit via VSCode, soit via Git) afin de mettre en évidence les modifications/virus. Cela permet ensuite de corriger au cas par cas, sans se fader l’intégralité des fichiers du projet.

💾 Vérifier la base de données

Parce que parfois, en plus des fichiers, du code est injecté directement en base de données.

Comme ça même avec les fichiers assainis, du virus peut polluer / ressortir / ressusciter lors de la relance du site.

Si vous n’avez pas les accès à la BDD, le mot de passe client tombe facilement si vous avez l’identifiant / nom de table > recherchez dans les fichiers.

De même Il y a souvent un fichier de config / constantes, comme wp-config.php pour WordPress.

🏗️ Vérifier si il y a des modifications structurelles

Bases & || Tables et ou champs en plus

Genre par exemple : spip_auteurs cay cool. QEGmjh5fsd rouler la tête sur le clavier moins.

Voir sur le résumé de la base si il y a des anomalies (encodages différents, ou très grand nombre de lignes).

Ici toutes les tables font ~[1ko – 40ko] mais la table “messages” fait 134ko.

Ptet du spam qui a été envoyé yay > voir surtout si il y a eu des envois de mails vers l’exterieur.
✅ A priori c’est okay

💬 Vérifier les contenus

Pour les CMS > Voir dans les tables ~options, utilisateurs, pages, posts, metas ; bref partout ou cela peut ressortir sur l’administration ou le front.

Et rechercher large avec les mêmes mots clés alakon avec LIKE % … % afin de voir si ça n’a pas été ajouté n’importe où dans une chaîne.

• ✅ `articles` > RAS
• ✅ `auteurs` > Pas mal d’entrées, principalement pour les commentaires. Check si accès admin (~login pass) différents
• ✅ `meta` > recheche dans “text” pour `%eval%` > OK
• ✅ `plugins` > recherche sur quelques champs textes > ~tout ce qui est suceptible de ressortir en front ou dans l’admin
• ✅ `rubriques` > texte, qui contient du html
• ✅ `urls`

A priori pas de sushis 🍣

🧹 Nettoyage effectif > Kwakonvire en fichiers 🔥

Bah on reprend notre petite liste, on vire les fichiers à la fois en local, et surtout en ligne.

Virer les dossiers de cache ne fait pas de mal également ~ /cache & /tmp.

Le mieux reste de faire tourner une copie du site corrigé en local / sur une VM afin de s’assurer (via les logs) qu’il n’y a rien de bizarre au niveau des fichiers / mails.

Au pire tester sur un autre nom de domaine afin de ne pas pourrir le référencement naturel en cas de soucis.

✅ Terminer

Remettre le site en ligne en suivant les recommandations de l’hébergeur.

📌 Vider le cache de son navigateur, puis tester.

Sur le FTP > Vérifier & ajuster si besoin les droits des fichiers, notamment le fichier .htaccess et les fichiers de configuration ~ wp-config.php.

1. Sur l’ensemble du site gros 644 des familles
2. Eventuellement moins pour les fichiers de configuration
3. Eventuellement plus sur les dossiers d’uploads, de cache

Si sur OVH Manager > rétablir / activer le firewall dans PHP ET les Multisite.

Après le mieux reste d’effectuer une maintenance à minima une fois par mois, et de maintenir les versions serveurs, PHP, CMS, thèmes, plugins à jour. Si il n’y a pas de mise à jour de version majeure cela se fait généralement très rapidement.

Des plugins de sécurité ne font pas de mal également, WordPress > WordFence & WP-Optimize.

Au pire 💸

Vous pouvez me contacter pour une petite prestation :3

Le bon courage, et la bonneuh journay.