Vendredi 18 Juillet 2014
Le monde se réveille sans se douter qu’une vague d’attaques a touché des milliers de site utilisant WordPress.
Même à jour dans leur version de leur CMS favori, les attaques sont venues d’ailleurs, ce n’est pas WordPress lui même qui est en cause.
On peut toujours se poser la question “Ne serait-ce pas une faille dans WordPress ?“, et même si ça arrive, je n’ai encore jamais vu une vague de piratage suite une faille non divulguée de WordPress.
Les failles sont découvertes par l’équipe en charge de la sécurité, et aussi par les contributeurs : vous ! Ensuite elles sont corrigées dans une branche mineure et une version sort rapidement afin de garder la faille le moins longtemps connue, sans patch.
Qui a été touché ?
C’est totalement aléatoire, vous trouverez des gens avec un serveur dédié, d’autres avec un mutualisé. Certains ont une thème maison, d’autre un Premium Theme Forest. Certains encore utilisent 2 plugins, d’autres 20. Inutile de chercher un point commun entre ces personnes, la vague tente d’exploiter plusieurs failles d’un coup pour rentabiliser.
Pourquoi attaquer des sites ?
Haaaa la fameuse question ! La réponse la plus brève serait : Vous (votre site) représentez une ressource sur le net, vous êtes une bande passante, vous êtes un lieu de stockage, vous êtes le point de départ d’emails, vous êtes un point de départ pour des backlinks SEO blackhat. Vous servirez à relayer des virus, des spams. Même si vous ne tenez que le blog du poney club avec 2 visites par mois (vous, pour vérifier que ça se passe bien !), même si la cible de votre site sont les retraités, le contenu, le SEO importe peu, vous serez ciblés et exploités si la faille existe chez vous.
Alors, comment c’est arrivé ?
Il y a de fortes chances qu’il s’agisse d’un plugin. Et non, je ne vais pas dire “C’est MailPoet !” comme l’a fait Sucuri sur son blog qui a eu le cas sur ses clients. OUI, MailPoet fait partie de la liste, mais la liste est longue et n’a pas de fin …
Il y a par contre de fortes chances qu’il s’agisse d’une faille dans un plugin, découverte récemment. Voici la liste des plugins touchés entre le 18 juin et 18 juillet (du plus récent au plus vieux) :
- Gallery Objects 0.4 SQL Injection
- WPTouch Authenticated File Upload
- CopySafe PDF Protection 0.6 Shell Upload
- Tidio Gallery 1.1 Shell Upload / XSS
- Download Manager 2.6.8 Shell Upload
- BSK PDF Manager 1.3.2 SQL Injection
- MailPoet wysija-newsletters Unauthenticated File Upload
- NextGEN Gallery 2.0.63 Shell Upload
- blogstand-smart-banner.1.0 Cross Site Scripting
- ml-slider 2.5 Cross Site Scripting
- wp-construction-mode.1.8 Cross Site Scripting
- Simple Share Buttons Adder 4.4 CSRF / XSS
En gras, ceux qui permettent l’upload d’un fichier malicieux. Il y en a 6, c’est énorme en si peu de temps.
NextGen a été téléchargé 10 fois plus que MailPoet, il a potentiellement 10 fois plus de chances de rendre un site vulnérable.
Ha, et alors ?
Le jour même Maxime BJ a créé un article pour parler de l’attaque et certains pensent à MailPoet, d’autres n’en sont pas sûrs. A titre personnel, même si mes clients et moi n’avons pas été touchés, un follower m’a indiqué qu’un de ses sites avait été touché, sans MailPoet.
Idem dans l’article chez Sucuri, certains oui, certains non. Je n’aime pas trop qu’on balance un nom de plugin qui va se prendre toutes les foudres des autres failles.
J’ai même lu un commentaire disant qu’il était pourtant à jour partout et qu’il utilisait un ThemeForest. Comme si le TF était un gage de qualité, désolé de cracher dans la soupe car j’en utilise, mais ils sont TRÈS souvent vulnérables …
Je vois aussi les solutions préventives et effectives de certains, et je vois WordFence dans le tas. Juste pour teaser, mon prochain article ici le concernera suite à des failles trouvées, je n’en dit pas plus, attendons un patch pour ça …
Elle fait quoi l’attaque ?
L’attaque, tout plugin confondu parmi nos 6 incriminés permets d’ajouter, uploader un fichier PHP contenant du code malicieux.
Elle permet d’avoir un accès quasi complet, comme sur un FTP. Libre à votre imagination de ce qu’on peut alors faire du site.
La backdoor est d’abord ajoutée dans un dossier, puis lors de son premier lancement, elle se duplique dans l’entête de tous les fichiers PHP du site. Parfois, elle se duplique un peu partout dans l’installation, parfois elle remplace le contenu des fichiers des plugins, etc
Leur détection n’est pas simple car le contenu change, les variables prennent des noms aléatoires, ce qui rends le pattern de détection instable. Aucun script ne permets de tout trouver exhaustivement.
Il est arrivé sur certaines installation qu’un administrateur soit ajouté, au nom ou ID “1001001“. Là, ce n’est pas en rapport avec une backdoor, certes, on peut le faire, mais je vois plutôt l’exploit d’une faille injection SQL. Relisez la liste des derniers plugins vulnérables … Cette faille d’un admin ajouté en 1001001 existe depuis plus d’un an, ce n’est donc pas MailPoet.
Que faire alors ?
Vous vous direz peut-être “Pas grave, j’ai des backups !“, et là, c’est le drame. Pourquoi ? Car les backups sont là quand vous perdez le site, ou la base de données, suite à une mauvaise manipulation en prod.
Mais JAMAIS vous ne devez utiliser un backup suite à un piratage. La raison est simple. Une fois les fichiers malicieux envoyés, l’exploitation de cette backdoor n’est pas instantanée. Le hacker (ou via ses zombies) va attendre plusieurs jours, semaines, mois avant de s’activer. Le but ? Attendre d’entrer dans vos backups…
Et ça marche, la preuve est qu’un autre commentaire chez Maxime dit qu’il a trouvé un fichier uploadé 1 mois en arrière et un autre plus récent. Pour moi, ça veux dire que le récent a exploité rapidement la faille, l’autre attendais encore avant de bouger.
Ajouter un plugin de sécurité serait le minimum à faire. Ici nous avons installé SecuPress Pro, peut-être en utilisez-vous d’autres comme Wordfence ou iThemes Security ou encore Sucuri Security ? Mais si c’est installé a postériori, alors c’est presque inutile, cela ne va rien régler.
Mes conseils, je vous dirais de fouiller la BDD à la recherche de script JS non désiré, de balises META non désirées, ce genre de chose.
Pour les fichiers, supprimez tout ce qui est core, thème, plugins, et ré-uploadez tout au propre avec les dernières versions.
Pour le dossier upload, vérifiez qu’il ne contient aucun fichier PHP, sinon supprimez les, même les index.php. Si vous souhaitez éviter le listing du contenu de vos dossiers, utilisez la règle .htaccess suivante : Options - Indexes.
Aussi, dans le dossier uploads, interdisez l’exécution de tout fichier PHP, il ne doit JAMAIS y avoir de PHP dans ce dossier, le plugin qui le fait, fait une erreur, j’en ai discuté avec Andrew Nacin si ça peut vous convaincre.
Utilisez ce fichier .htaccess que vous poserez dans /uploads/ :
Avec ça, tous les fichiers PHP se retrouvent interdits d’exécution, leur accès direct renvoie une erreur 403 Forbidden.
Bien sûr et avant tout : tenez vous à jour de vos plugins, faites des backups pour au moins récupérer vos uploads et la base si elle est propre, mais, je me répète, ne les utilisez jamais comme ça, fouillez, nettoyez ou faites intervenir un pro de la sécurité web.
Moralité
Ce n’est pas QUE MailPoet le fautif, même si VOUS avez été touché par sa faute, les attaques de vendredi viennent aussi d’autres plugins ou thèmes.
