Mes sites WordPress sont attaqués,
oui mais comment ?
Publié le 19 octobre 2020, par Richard Carlier
Étude personnelle
#dataviz #intrusion #sécurité #wordfence #wordpress
WordPress est un outil populaire, connu pour sa facilité d’emploi.
Mais également pour être la cible des méchants. Mais que cherchent-ils ? Et comment ?
Analyse de 30.500 tentatives d’intrusions sur 9 WordPress, en 1 mois…
A la tête de plusieurs sites WordPress, personnels, pour mes clients ou mes cours, j’installe systématiquement un outil de sécurité appelé Wordfence (dans sa version gratuite). Qui empêche les attaques, et conserve des traces de ces évènements (et envoie un rapport de synthèse…)
Et ne sponsorise aucunement cet article…
Extrait du tableau de bord Wordfence d’un site…
A la suite de la lecture d’un article sur le xmlrpc (un guide complet sur le xmlrpc.php dans WordPress… j’ai eu envie d’étudier dans le détail les attaques subies par mes sites.
Récupérer les données
Comme Wordfence stocke ses données dans des tables mysql spécifiques, il est relativement facile de les extraire. Le plus long est sans doute de fusionner les tables en provenances de 9 wordpress, répartis sur plusieurs hébergements, et donc base de données. Comme je travaillais en parallèle à la réécriture d’un script de sauvegardes multi-bases, cela tombait plutôt bien.
Quelques manipulations combinants Php, Mysql et Python, me voici en possession de deux tables:
wordfence_hits(13.766 lignes) contenant toutes les attaques subieswordfence_logins(16.772 lignes) qui contient les tentatives de connections avec login (hélas, Wordfence ne stocke pas les mots de passes tentés, l’analyse aurait été intéressante)
Soit plus de 30.500 tentatives d’attaques… sur la période du 13 septembre 2020 au 14 octobre 2020.
Une petite anonymisation des données permet de faire une analyse transversale. Les sites seront ainsi tous regroupés et connus comme site-exemple.fr, qui à l’heure où j’écris ces lignes n’existe pas.
Précisons tout de même que les sites étudiés sont modestes, peu connus (hélas), et sans doute peu représentatifs de ce que pourrait être une analyse plus massive (ce que fait sans doute Wordfence à un niveau plus global). N’empêche…
Provenance des attaques
Wordfence conserve les adresses IP des attaques, et y associe le code pays (quand il est connu). En associant les codes ISO fournit à une table comprenant la latitude/longitude moyenne de ces pays, cela nous donne…
Attaques globales
La Turquie arrive en tête (15,4%), suivie du Brésil (14,1%) et des États-Unis (11,6%).
Attaques par tentatives de connections
La France arrive en tête (22,9%), puis la Turquie (22,2%), et le Canada (13,4%).
Bien sûr ne déclarons pas la guerre à ces pays : les attaques ne proviennent que de quelques individus…
Ce que semble confirmer l’analyse des adresses IP:
Si on fait un IP Lookup, on s’aperçoit que le Brésil est sur-représenté car l’adresse ip 189.120.79.74 correspond au Brésil (et donc 1694 tentatives minimum… peut aussi être une adresse d’un réseau, camouflant une dizaine d’ordinateurs de méchants…). Qui plus est, l’adresse est associée à un nom de domaine « virtua.com.br », qui vu le nom, évoque un service de nom de domaine virtuel, et donc potentiellement quelqu’un qui n’est pas au Brésil… Et puis, un simple VPN pourrait aussi camoufler certaines données…
Le 166.48.118.131 étant canadien (avec les mêmes réserves).
Quels identifiants utilisés ?
Voici la liste des identifiants tentés par les méchants (uniquement ceux qui ont 10 tentatives et plus).
Rappel: les sites sont regroupés sous site-exemple.fr il faut donc comprendre que le premier login tenté est en fait le nom de domaine du site. Le site https://datas.fun serait ainsi tenté via un identifiant datas, et info@datas.fun, admin@datas.fun… regroupant alors 6323 tentatives (6068+134+121) et peut être quelques autres.
Le curieux [login] me parait être un mauvais réglage d’un outil de piratage… et vu la quantité, les méchants ne sont pas souvent très bons dans les réglages (mais ce n’est qu’une hypothèse).
Il faut comprendre le code %signataire% comme celui d’un signataire d’article (ou plusieurs signataires). Si les articles du site étaient signés richnou, une page auteur richnou existerait sans doute et donc 1054 tentatives seraient tentées… ce qui est logique, car dans ce cas, l’utilisateur richnou existerait bel et bien.
En étudiant la liste complète, on retrouve des noms informatiques classiques comme test, user, demo, guest, admin, admin1, admin2, superadmin… Parfois quelques versions avec fautes (adminnistrator), quelques prénoms (elena, alberto, francesco, sophie, diana, kevin… sortis du chapeau) et quelques trucs surprenants (rencontre-ronde, plan-cul, ou plan-cul-province ; aucun site étudié ne porte pourtant sur ces thématiques).
Vous savez désormais comment NE PAS NOMMER vos utilisateurs… Précisons que sur les très vieux WordPress, admin était l’identifiant par défaut…
Quelles attaques ?
On entre un peu plus dans la technique, mais voici les attaques les plus populaires.
Ci-dessous la liste des urls tentées par les méchants (du moins les principales, il y en a de 59 sortes).
Classifions un peu.
J’ajoute une colonne catégorie, alimentée par des recherches sur quelques mots clefs des urls ci dessus. Cela donne:
Il n’y a pas photo: l’attaque du xmlrpc est en top. L’article cité en référence vous expliquera tout sur le xmlrpc, et est très orienté sur la problématique pourquoi le désactiver. Les chiffres ci dessus le confirme.
Désactiver le fichier xmlrpc.php peut se faire de plusieurs façons (voir l’article), la plus simple étant d’ajouter au fichier .htaccess ces quelques lignes:
<Files xmlrpc.php> Order Allow,Deny Deny from all </Files>
Arrive ensuite l’attaque du fichier wp-login.php. Je présume (il faudrait relire la doc de Wordfence) pour en vérifier la présence. Et s’il est présent, on entre dans l’autre attaque, celle des identifiants (voir ci avant) avec des mots de passe, en espérant trouver la bonne combinaison. Les méchants passent généralement par des systèmes automatisés qui utilisent des mots de passe classique. Wordfence bloque l’adresse ip au bout de plusieurs tentatives.
Prisés par de nombreux plugins, ajax permettant de communiquer entre le navigateur et le serveur, ce qui ouvre parfois le système. D’ailleurs, de nombreuses attaques concernent certains plugins en particulier, qui doivent avoir des failles (ou avoir eu par le passé).
Les autres attaques concernent quelques fichiers du core de WordPress (peut-être bugués à une époque), des interrogations de la rest-api (remplaçante plus sécurisée du xmlrpc), et quelques thèmes sans doute connus pour être bugués…
A noter que, hors le xmlrpc et les tentatives d’intrusion, presque la moitié concernent un essai de récupérer le fichier wp-config.php, lequel contient des informations précieuses (les mots de passe de la base de données, qui sont souvent les mêmes que pour le FTP, voir les identifiants administrateurs…).
A quel moment ?
Si l’on regarde la répartition selon les dates, on constate qu’il y a une activité permanente, et quelques pics.
Les deux pics (en rouge, les 30 sept. et 8 oct.) doivent correspondre aux jours d’activités de notre turc et de notre canadien. Le week end (gris) aussi, pas de repos pour les méchants…
Au niveau des heures, on constate la même chose: une permanence des attaques, de jour comme de nuit…
Bien sûr, il s’agit ici de l’heure de mes serveurs (localisés à ma connaissance en France), pas des heures locales des attaquants…
Conclusions
Quelques conclusions s’imposent…
- Tous les sites WordPress peuvent être attaqués, même ceux qui dorment. J’ai dans la liste un ou deux éléments qui ne sont même plus des sites (le wordpress tourne, mais en mode maintenance), et ils sont également attaqués…
- La principale attaque est sur le XMLRPC obsolète
- Les tentatives d’identification avec des valeurs par défaut sont légions, il convient donc de les éviter absolument
- Certains plugins (et thèmes) ont des brèches; il vaut donc mieux se tourner vers des plugins fiables
Les parades?
Aussi simples que rabâchées par tout l’écosystème WordPress:
- Maintenir son système à jour (WordPress, les plugins, les thèmes…). Autopromo: si vous avez un réseau de site, mon plugin JSON Dashboard Infos peut vous aider…
- Désactiver le XMLRPC
- Prévoir un mot de passe fort (et un identifiant aussi…), ne pas hésiter à envisager des doubles authentifications
- Installer Wordfence ou équivalent, qui protège des intrusions
Finissons par un conseil.
Faites des sauvegardes.
Aucun rapport direct, mais en cas d’intrusion réussie cela permet de restaurer le système…