WordPress est devenu une plateforme très populaire aussi il est régulièrement pris pour cible.
Comme je possède plusieurs sites fonctionnant avec ce moteur, j’ai trouvé amusant de regarder de plus prés les logs pour tenter d’identifier les tentatives d’attaques. Il faut garder à l’esprit qu’à l’exception de rares attaques vous visant directement, la plupart du temps les attaques suivent la loi des grands nombres. En général, des robots se contentent de tenter leur chance dans l’espoir d’exploiter une faille oubliée. Ce sont un peu des Shadocks du web appliquant le principe : »plus ça rate, plus ça a de chance de réussir »
Dans cet article, je ne vais pas spécialement m’attacher à identifier les attaquants. Ce serait un sujet à part entière et pour tout dire un peu limite vis-à-vis de la législation française. L’analyse des logs d’accès est moins risquée pénalement.
1 – les tentatives d’inscription
WordPress permet l’inscription en ligne d’utilisateur. Il est donc assez logique pour un pirate de chercher à s’inscrire légitiment sur le site dans l’espoir de disposer de droits suffisants pour faire ces petites histoires.
La contre mesure est simple et efficace, interdire les inscriptions.
Si vous tenez à tout prix à autoriser les inscriptions, assurez-vous que par défaut le nouvel inscrit aura un niveau « Abonné » (dans les réglages généraux de WP).
Pensez aussi à modérer les commentaires…
2- les tentatives de connexion
C’est le cas le plus évident. Un robot tente selon différentes techniques de se connecter en tant qu’administrateur en « devinant » la combinaison (Identifiant ; mot de passe). Plus qu’une divination, il va le plus souvent faire de multiples tentatives depuis plusieurs adresses IP différentes.
Je me suis aperçu que certaines attaques commençaient par recenser les auteurs des articles. Les attaquants utilisaient ces noms comme identifiants pour leurs tentatives.
Un dernier mode d’attaque est de faire des demandes de réinitialisation du mot de passe. (wp-login.php ?action=lostpassword)
En terme de contre mesure, il faut avoir un identifiant différent du nom affiché publiquement. Et bien entendu avoir un mot de passe FORT (long et complexe).
La question de le changer régulièrement fait débat. Personnellement, je considère qu’un mot de passe suffisamment fort n’a pas besoin d’être le changer sauf en cas de doute.
3- l’appel de scripts
Dans ce cas l’attaquant va tenter d’exécuter un script PHP de WordPress pour exploiter une faille connu. Un exemple est l’exécution XMLRPC.PHP. Fin 2015, une faille a été largement exploitée et on continue à voir des accès à ce fichier.
Plusieurs scripts sont appelés (WP-setting.php, Control.php , sqlibak.php,etc…) parfois des aussi des scripts ASP (là je n’ai pas compris) . Il s’agit d’essayer de lancer des scripts ayant des failles connues ou d’exécuter des fichiers installés précédemment. Les scripts du dossier wp-admin sont des cibles de choix
La contre-mesure élémentaire est de faire les mises à jour le plus tôt possible de WordPress mais aussi de son hôte (serveur web, PHP, SGBD,…)
Personnellement, je vérifie régulièrement les fichiers de mon site. Je contrôle en particulier les dates de modification avec mon client FTP et au besoin je compare avec une sauvegarde.
Autre appel, mais plus étrange : J’ai noté que les moteurs de recherche cherchaient à visiter (sans succès) des pages générées par le script /aloir/glotir.php …
Je n’ai pas encore trouvé d’explication satisfaisante mais visiblement le phénomène est répandu.
4- Les plugins et thèmes
C’est la suite logique du point précédent. Ces éléments sont souvent pris pour cible pour les pirates. Les 2 attaques que j’ai subit en 8 ans ont ciblés des templates.
Les mécanismes sont simples :
- On aime en avoir beaucoup
- On est moins rigoureux estime leur mise à jour
- Les auteurs ne sont pas toujours très réactifs
- Même si la plateforme de téléchargement WordPress retire les extensions à problème, il n’est pas simple de vois si l’une de nos extensions n’est plus recommandée.
Les pirates vont donc cibler les extensions les plus populaires et celles qui peuvent permettre de télécharger des fichiers sur le site.
Parmi les modules attaqués, il y a notamment :
- recent-backups
- revslider
- simple-ads-manager
- wp-ecommerce-shop-styling
- wp-mobile-detector
… que je n’utilise pas mais aussi le fameux jetpack.
En ce qui concerne les thèmes, je n’ai pas eu beaucoup de tentatives récemment à part sur Organizer (que je n’utilise pas non plus)
La première des contre mesure est donc de ne conserver que les plugins et thèmes utilisés. Il faut de plus vérifier régulièrement leur mise à jour. Si un de ces éléments n’a pas eu de mise à jour depuis plus de d’un an, c’est suspect… Au-delà de 18 mois, on peut considérer qu’il n’est plus maintenu et que son utilisation est dangereuse.
C’est particulièrement problématique pour les thèmes et les développements spécifiques. Leurs mises à jour doit être prévu …votre prestataire doit être en capacité de comprendre ce qu’il doit corriger. Ce n’est pas toujours très évidemment !
En plus des failles propre à WordPress, il devra prendre en compte les failles liées à la technologie qu’il a utilisé : PHP , MySQL, CSS, XML,…
