Portes dérobées cachées dans WordPress : comment les trouver avant qu’elles ne vous trouvent

Une porte dérobée est un morceau de code qu’un attaquant laisse derrière lui pour pouvoir revenir plus tard, même après la fermeture du point d’entrée initial. La première compromission, c’est la porte. La porte dérobée, c’est la deuxième clé, cachée quelque part sur votre site, prête à servir. Les portes dérobées de WordPress comptent parmi les artefacts les plus fréquemment découverts lors des audits forensiques, et la plupart des propriétaires n’y ont jamais pensé comme à une catégorie à part.

Cet article explique comment les portes dérobées sont installées, où elles se cachent habituellement et comment les repérer sur votre propre site.

Pourquoi les attaquants installent des portes dérobées

Pénétrer pour la première fois dans un site WordPress demande des efforts : trouver une extension vulnérable, l’exploiter, naviguer dans le site. Une fois à l’intérieur, les attaquants veulent s’assurer de pouvoir revenir sans refaire tout ce travail. Une porte dérobée est une assurance contre la correction de la vulnérabilité d’origine.

C’est pourquoi se contenter de corriger le point d’entrée après une compromission ne suffit pas. L’attaquant est probablement toujours sur le serveur. Tant que vous n’avez pas trouvé et supprimé la porte dérobée, chaque nettoyage reste temporaire.

Les formes classiques de porte dérobée WordPress

Les portes dérobées les plus courantes se résument à un petit nombre de schémas reconnaissables.

• PHP obfusqué. Un petit morceau de code, souvent de quelques lignes seulement, qui utilise eval combiné à base64_decode, gzinflate ou str_rot13 pour exécuter une charge envoyée en paramètre. À première vue, le code ressemble à du charabia, et c’est précisément le but. Les variantes incluent des schémas comme eval, assert avec une entrée contrôlée par l’utilisateur, preg_replace avec le modificateur e désormais supprimé, et des appels directs à shell_exec ou system avec des données issues de $_GET, $_POST, $_REQUEST, $_COOKIE ou $_SERVER.
• Web shells. Un fichier PHP dédié qui offre à l’attaquant un gestionnaire de fichiers ou un exécuteur de commandes via le web. Des noms comme c99shell, r57shell, WSO et FilesMan sont tristement célèbres. Une web shell est un petit panneau d’administration installé sur votre serveur que vous n’y avez pas mis.
• Comptes administrateur frauduleux. Un nouvel utilisateur doté du rôle d’administrateur, créé lors de la compromission initiale, souvent avec un nom d’utilisateur un peu étrange ou une adresse e-mail sur un domaine que vous ne reconnaissez pas. L’attaquant peut revenir à tout moment en se connectant avec ce compte.
• Réinfection via cron. Une tâche planifiée de WordPress qui recrée les fichiers malveillants s’ils sont supprimés. Même si vous nettoyez les mauvais fichiers, le cron les remet discrètement en place lors de sa prochaine exécution.
• Fichiers du cœur, du thème ou d’une extension modifiés. L’attaquant modifie un fichier légitime pour y insérer un petit bloc de code malveillant. Le fichier fonctionne toujours comme prévu, mais il exécute aussi la charge de l’attaquant lorsqu’il est déclenché.

Où elles se cachent

Les portes dérobées préfèrent les recoins les plus poussiéreux d’une installation WordPress. Quelques cachettes courantes méritent d’être connues.

• L’arborescence wp-content/uploads. Le dossier des téléversements ne devrait contenir que des médias. Les fichiers PHP qui s’y trouvent sont presque toujours suspects. Un audit récent sur le site d’une agence de Sydney a explicitement passé ce dossier au crible et n’y a trouvé qu’une poignée de stubs anodins de durcissement de WordPress. Tout le reste mérite une enquête.
• Des fichiers aux noms imitant le cœur. wp-loadx.php, wp-shell.php, wp-cron-extra.php, wp-log.php. Un nom qui correspond presque à un vrai fichier WordPress est un choix de camouflage délibéré.
• Des images contenant du PHP. Un fichier portant l’extension .jpg ou .png qui contient en réalité du code PHP au début du fichier. Si quelque chose sur le serveur inclut ensuite ce fichier en tant que PHP, la charge s’exécute. Rare, mais bien réel.
• À l’intérieur de fichiers légitimes d’extensions ou de thèmes. L’attaquant ajoute un petit bloc au début ou à la fin d’un fichier existant. Le fichier fonctionne toujours, mais il exécute aussi la porte dérobée.
• wp-config.php et ses variantes. Parfois via une directive auto_prepend_file qui inclut une charge malveillante avant chaque requête. Parfois en injectant directement une constante ou une instruction include.

Comment rechercher des portes dérobées

Nul besoin d’être un professionnel de la sécurité pour effectuer des vérifications utiles. Une extension de sécurité réputée comme Wordfence réalise une analyse approfondie et signale toute correspondance avec sa base de signatures. La version gratuite le fait bien. La version payante met à jour ses signatures plus rapidement et ajoute une surveillance des vulnérabilités.

Au-delà des extensions, vous pouvez procéder à un balayage manuel. Examinez chaque fichier .php situé hors de wp-admin, wp-includes et des dossiers d’extensions et de thèmes. Repérez les dates de modification récentes pour détecter des fichiers modifiés ces dernières semaines sans explication. Recherchez dans le code les schémas suspects évoqués plus haut. Tout ce qui correspond mérite un examen plus attentif.

Comparez les fichiers du cœur de WordPress aux versions officielles. Plusieurs outils le font, dont Wordfence et l’outil officiel wp cli. Toute différence dans les fichiers du cœur est un signal d’alerte.

Le nettoyage après la découverte d’une porte dérobée

Trouver une porte dérobée signifie rarement qu’il n’y en a qu’une. Les attaquants en installent souvent plusieurs, à différents endroits et sous différentes formes, afin qu’en trouver une ne les empêche pas de revenir. Après avoir identifié une porte dérobée, élargissez la recherche. Inspectez tous les emplacements similaires, traquez les schémas comparables et examinez chaque fichier modifié à la même période.

Renouvelez toutes les informations d’identification : salts et clés, mots de passe WordPress, mot de passe de la base de données, clés d’API, clés SFTP. Réinitialisez toutes les sessions. Réauditez les utilisateurs. Réauditez les extensions. Restaurez une sauvegarde saine antérieure à la compromission si vous pouvez en identifier la date.

Prévenir les portes dérobées dès le départ

Les portes dérobées constituent la deuxième couche d’une compromission. La prévention consiste surtout à éviter la première couche. Maintenez à jour le cœur, les thèmes et les extensions. Supprimez les gestionnaires de fichiers et les extensions d’accès shell dont vous n’avez pas besoin. Limitez les accès administrateur. Utilisez la 2FA. Faites tourner une extension de sécurité qui surveille l’apparition de nouveaux fichiers à des endroits inattendus.

Si vous appliquez ces mesures avec constance, la probabilité qu’une porte dérobée soit installée sur votre site chute considérablement. Une fois qu’un site est bien défendu, les attaquants se tournent vers des cibles plus faciles.

Besoin d’un coup de main ?

Si vous soupçonnez la présence d’une porte dérobée sur votre site WordPress, ou si vous venez de terminer un nettoyage et souhaitez un second regard pour le vérifier, Defyn peut réaliser une analyse forensique et vous dire exactement ce que nous trouvons. Contactez-nous et nous vous donnerons une réponse claire, dans un sens comme dans l’autre.