Après mon article pour sécuriser son blog sous Wordpress, je reviens avec une seconde édition cette fois-ci consacrée aux attaques les plus courantes perpétrées sur votre blog sous Wordpress.

Dans le noyau de Wordpress, tout ce qui est questions en matière de sécurité sont prises très au sérieux par l'équipe de développeurs afin de maintenir l'intégrité de l'application. Cependant la même chose n'est pas valable pour les plugins et thèmes.

L'objectif de cet article est de vous fournir toutes les questions/réponses auxquelles les utilisateurs sous Wordpress ont besoin pour se protéger avec :

• Préambule
• Qu'est-ce qui rend votre Wordpress vulnérable ?
• L'évolution des attaques
• Les attaques les plus courantes sur Wordpress
• Conclusion

Au cours des deux dernières années, la virulence des malwares web a augmenté de prés de 140%. Dans le même temps, Wordpress a explosé en popularité en tant que plateforme de blog et CMS, alimentant prés de 17% des sites web aujourd'hui. Mais cette popularité a un prix car il en fait une cible de choix pour les malwares web. Pourquoi? C'est simple : sa portée peut avoir un impact maximum. A l'inverse, sa popularité est aussi une bonne chose car les évolutions/corrections avec le nombre de contributeurs arrivent rapidement.

Les anciennes versions de Wordpress ainsi que les vulnérabilités sur les thèmes et plugins, le tout multiplié par la popularité du CMS avec un administrateur faisant un peu à sa sauce rendent un site tournant sous Wordpress vulnérable. On va faire par étape :

La première cause est bien sûr l'utilisation d'une version obsolète de Wordpress. Chaque fois qu'une nouvelle version de Wordpress est disponible, les utilisateurs ont un message informatif qui s'affiche mais beaucoup l'ignorent. Les vulnérabilités sur le core de Wordpress sont présentes il ne faut pas se le cacher. La preuve en est avec les versions récentes 3.3.3 et 3.4.1. Mais les équipes de développement chez Wordpress réagissent efficacement pour déployer un patch de sécurité assez rapidement. Mais tout le problème vient des utilisateurs qui ignorent ces messages de mise à jour. Cela ne concerne pas seulement des blogs lambda mais des grosses plateformes comme celle de Reuters qui tournait sur un Wordpress 3.1.1 au lieu de la version courante 3.4.1.

Les vulnérabilités sur les plugins et les thèmes sont un autre problème. Le référentiel de Wordpress regroupe prés de 20.000 plugins. Ces plugins sont de qualité variable et certains d'entre eux ont inévitablement des failles de sécurité, tandis que d'autres sont obsolètes. En plus de cela, il faut tenir compte de tous les thèmes et plugins qui ne sont pas dans le référentiel de Wordpress, y compris ceux payants qui sont distribués sur des sites de Warez et intègrent assez souvent des malwares. Avec Google vous pouvez trouver sans difficulté des thèmes Wordpress gratuits.

Ensuite il y a la popularité de Wordpress avec environ 700 millions de sites web utilisant Wordpress en Mai 2012. Cette popularité signifie que cette plateforme devient une cible de choix pour un pirate car s'il peut trouver une faille sur Wordpress alors des millions de sites deviennent potentiellement son terrain de jeu. Ils peuvent aussi simplement chercher des sites web qui utilisent des vieilles versions en les scannant avec des outils présents dans Backtrack par exemple et utiliser des failles/POC reconnues pour pénétrer sur le site.

Enfin et surtout, le plus grand obstacle auquel se heurtent les utilisateurs de Wordpress, c'est eux-mêmes. Par exemple vous n'êtes pas développeur et vous demandez à quelqu'un de construire votre Wordpress de A à Z. Mais une fois que c'est fait (et passé la garantie) tout est entre vos mains et en général à par ajouter des articles, vous ne vous préoccupez pas de la maintenance de votre blog. C'était vrai il y a quelques années mais aujourd'hui c'est en train de changer et les utilisateurs commencent à s'informer.

Comme Internet a beaucoup évolué, la nature des attaques ont elles aussi suivie le pas. A l'époque montrer ses prouesses techniques en terme de piratage avaient en général des objectifs purement politiques. Aujourd'hui le piratage est plus une question d'argent. Le malware récent DNSChanger, aussi appelé "Internet Doomsday", par exemple, ont permis à des pirates de ratisser prés de 14 millions de dollars avant d'être arrêté par le FBI et la police estonienne en Novembre dernier.

Une autre technique de piratage qui a émergé dernièrement est le malNETs. Ce sont des réseaux malveillants distribués qui sont utilisés pour tout, y compris le vol d'identité, les attaques par déni de service, la distribution de spam, le drive-by downloads, les faux Antivirus, etc... Le but étant d'automatiser les attaques pour une exposition maximale.

Mais l'automatisation grâce à l'utilisation des bots n'est pas leur seul mécanisme. Aujourd'hui, vous avez également l'automatisation de malware : l'utilisation d'outils pour générer rapidement un payload (c'est-à-dire le produit infectieux), ce qui permet au pirate de se concentrer strictement sur l'accès à l'environnement. Une fois que le pirate a accès à l'environnement, il a juste à insérer le payload. L'un des outils d'automatisation les plus répandu est le Blackhole exploit kit. Il y en beaucoup d'autres qui peuvent être achetés pour des sommes variables sur les réseaux underground. Ce coût (par forfait le plus souvent) permet ainsi d'avoir un kit à jour avec de nouveaux outils pour les dernières vulnérabilités. Il s'agit là d'une véritable entreprise.

Des milliers de types de malwares sont actifs sur Internet mais ne s'appliquent heureusement pas tous à Wordpress. Pour le reste de cet article, nous allons examiner quatre des attaques les plus courantes sur les plateformes Wordpress avec :

• Backdoors
• Drive-by downloads
• Pharma hacks
• Redirections malveillantes

Une backdoor (porte dérobée) permet à un pirate d'avoir accès à votre environnement via ce que vous considérez être des méthodes anormales (FTP, SFTP, WP-ADMIN, etc...). Les pirates peuvent accéder à votre site web en utilisant la ligne de commande ou même en utilisant une interface graphique web comme celle-ci :

Interface graphique d'une backdoor

Les backdoors sont exceptionnellement dangereuses. Si rien n'est fait, cela peut causer des ravages sur votre serveur. Souvent cela peut engendrer des contaminations croisées (cross-site). Par exemple lorsqu'un site web en infecte un autre sur le même serveur.

L'attaque se produit souvent en raison d'une version non à jour ou d'une faille de sécurité dans le code. Une vulnérabilité bien connue de la communauté Wordpress a été trouvée dans le script TimThumb qui était utilisée pour redimensionner une image. Cette vulnérabilité a permis aux pirates de télécharger un payload qui fonctionne comme une backdoor.

Voici un exemple de scanner à la recherche des versions vulnérables de TimThumb sur les blogs Wordpress (log Apache) :

Comme la plupart des infections, celle-ci peut être codée, chiffrée, etc... Cependant, il n'est pas toujours aussi simple de rechercher du code chiffré. Il y a plusieurs cas dans lesquels le code est "légitime" et peut ressembler à ceci :

Autre exemple :

Voici un cas où le contenu est caché dans la base de données :

Et ici une backdoor très simple qui permet à une requête HTTP d'être exécutée :

Encore un exemple d'une backdoor obfusquée (messy backdoor) cette fois-ci ciblant spécifiquement la vulnérabilité TimThumb :

Autre backdoor qui touche généralement les installations de Wordpress, le Filesman :

Maintenant la question est de savoir si mon site est infecté. Les backdoors peuvent être incrustées sur votre site de différentes manières. Dans certains cas, une backdoor est un fichier qui a été changé/renommé comme cela :

• wtf.php
• wphap.php
• php5.php
• 1.php
• p.php
• w00t.php

Dans d'autres cas, le code est intégré dans un fichier apparemment bénin. Par exemple il peut se trouver dans le fichier index.php d'un thème avec du code légitime :

Les backdoors sont difficiles à détecter car celles-ci évoluent constamment et il n'y a donc pas de façon définitive pour dire ce que vous devriez chercher.

Alors elles sont peut-être difficiles à détecter mais il y a un moyen de s'en prémunir. Pour que le hack soit efficace, votre site a besoin d'un point d'entrée qui soit accessible au pirate. Vous pouvez fermer les portes dérobées en procédant comme suit :

Faites en sorte que votre environnement soit difficile d'accès. Il y a une approche à 3 volets pour verrouiller l'accès à wp-admin :

• Filtre par adresse IP
• Authentification à deux facteurs via le plugin Google Authenticator
• Accès limité par défaut

Pour le filtre par adresse IP, si votre serveur web tourne sous Apache, créez un fichier .htaccess dans le dossier wp-admin et mettez-y ce code :

Order Deny, Allow
Deny from All
Allow from [Votre adresse IP]

Il faudra ensuite remplacer [Votre adresse IP] par votre adresse IP. Pour connaître votre adresse IP, allez sur WhatIsMyIPAddress. Vous pouvez ajouter plusieurs adresses IP en les séparant par un espace. Par exemple :

Order Deny, Allow
Deny from All
Allow from 10.0.0.1 10.0.0.2 10.0.0.3

Souvent le maillon faible de toute la chaîne Wordpress est le répertoire /uploads/. Il est le seul répertoire qui doit être accessible en écriture dans votre installation. Vous pouvez le rendre plus sûr en empêchant quiconque d'exécuter du code PHP.

Pour cela, créez un fichier .htaccess dans le répertoire uploads et mettez-y ceci :

Deny from All

Une fois que vous avez trouvé une backdoor, le nettoyage est assez facile. Il suffit de supprimer le fichier ou le code. Cependant, trouver le fichier peut être difficile. Sur son blog, Canton Becker fournit quelques conseils sur la façon de fouiller son serveur pour trouver des backdoors. Il n'y a pas de solution miracle mais une recherche de base dans les fichiers en mettant comme élément de recherche eval ou base64_decode peut vous y aider.

Par contre ça devient plus difficile si ça ressemble à ceci :

Si vous êtes familier avec le terminal, vous pouvez vous connecter à votre site web en utilisant SSH et essayer certaines méthodes. La méthode la plus évidente est de chercher en entrant cette commande :

root@server:~# grep -ri "eval" [chemin_vers_wordpress]

Ou

root@server:~# grep -ri "base64_decode" [chemin_wordpress]

L'option r veille à ce que tous les fichiers soient analysés, tandis que l'option i veille à ce que l'analyse soit insensible à la casse. Ceci est important car vous pourriez trouver des variantes comme Eval, EVAL, ou toute autre permutation. La dernière chose que vous pouvez faire est de scanner des fichiers spécifiques pour aller plus vite :

Chercher les fichiers récemment modifiés :

root@server:~# find -type f -ctime -0 | more

L'option -type cherche les fichiers et l'option -ctime se limite aux fichiers modifiés il y a moins de 24 heures. Vous pouvez spécifier de 24 heures à 48 heures en spécifiant -1 ou -2 respectivement.

Une autre option est la commande diff. Cela vous permet de détecter les différences entre les fichiers et les répertoires. Dans ce cas, vous devez l'utiliser pour les répertoires. Pour qu'elle soit réussie, vous avez besoin d'avoir une copie épurée de votre installation et des thèmes. Cela ne fonctionne donc que si vous avez une sauvegarde complète et propre de votre site. En général les hébergeurs proposent des options de backup.

root@server:~# diff -r /[chemin_wordpress_propre] /[chemin_wordpress_infecté] | sort

L'option -r permet la récursivité pour passer à travers tous les répertoires et la commande sort trie le résultat pour rendre la lecture plus simple. La clé ici est d'identifier rapidement les choses qui ne devraient normalement pas faire parti de votre installation en faisant un test d'intégrité. Le second regard à porter aux résultats de diff est de trouver tous les fichiers sur le site web qui ne sont pas dans celui du backup.

Pour ceux qui sont sous Windows vous pouvez utiliser l'excellent WinMerge qui fait toutes ces opérations.

Un drive-by download est l'équivalent d'un drive-by shooting. Techniquement, il est généralement intégré à votre site web via un certain type d'injection de script, ce qui pourrait être associé à une injection de lien.

Le but d'un drive-by download est souvent de télécharger un payload sur la machine locale de l'utilisateur. L'un des payload le plus courant est d'informer l'utilisateur que le site a été infecté et lui propose à ce moment-là d'installer un antivirus comme ici :

Faux antivirus téléchargé via drive-by download

Il y a trois moyens pour que ce type d'attaque fonctionne :

• Version obsolète
• Authentification compromise (wp-admin, FTP)
• Injection SQL

Voici un certain nombre d'exemples d'injections de liens qui peuvent conduire à des attaques drive-by download :

Ou ceci :

Plus récemment, les drive-by downloads et autres malwares se mettaient en fonction comme des malwares conditionnels. En gros ils sont conçus sur certaines règles qui se déclencheront avant que l'infection se présente par elle-même. Vous pouvez trouver plus d'informations sur le fonctionnement des malwares conditionnels sur l'article "Understanding Conditional Malware – IP Centric Variation".

Pour savoir si vous êtes infecté, vous pouvez utiliser un scanner comme SiteCheck ou Site Inspector. Les scanners sont généralement bons pour trouver des injections par lien. Une autre recommandation est de vous inscrire sur le Google Webmaster Tools et de vérifier votre site web. Dans le cas où Google est sur le point de blacklister votre site web, il vous envoie avant un e-mail pour vous informer du problème et vous donne une chance de le réparer.

En dehors de l'aide d'un scanner, la difficulté d'identifier une injection dépendra de sa complexité. Quand vous regarderez sur le serveur, il ressemblera à quelque chose comme ceci :

La bonne nouvelle est que ce genre d'infection doit être quelque part où une page est affichée. Les fichiers suivants sous Wordpress sont des lieux communs où vous trouverez des injections de lien :

• wp_blog_header.php (fichier core)
• index.php (fichier core et thème)
• function.php (fichier thème)
• header.php (fichier thème)
• footer.php (fichier thème)

Environ 6 fois sur 10 l'infection sera das un des ces fichiers. De plus, votre logiciel antivirus peut détecter un payload lorsque vous tombez sur votre site web.

Ce genre d'infection peut également se trouver incorporé à des messages, des widgets, etc... Dans un tel cas, il va falloir fouiller dans votre base de données et s'assurer qu'aucun compte n'a été compromis.

Passons maintenant au nettoyage de ce genre d'infection. Ça peut être un défi et cela dépendra de votre habileté technique. Vous pouvez utiliser le terminal pour trouver le problème.

Si vous avez accès à votre serveur via SSH, vous avez de la chance. Si ça ne vous dit rien, vous pouvez télécharger votre Wordpress localement. Voici les commandes qui seront utiles sur le terminal :

• curl : permet de transférer des données.
• find : recherche par nom de fichier ou de répertoire
• grep : recherche dans le contenu des fichiers

Par exemple; pour rechercher tous les fichiers dans une section particulière de l'injection, essayez quelque chose comme ceci :

root@server:~# grep -r "http://objectcash.in" .

Vous pouvez aussi affiner votre recherche par type de fichier :

root@server:~# grep --include ".php" -r "http://objectcash.in" .

Pharma hack est l'une des infections les plus répandues. Il ne faut pas les confondre avec des malwares car il est effectivement classé comme SPAM. Si votre site est reconnu comme serveur de SPAM, vous courez le risque d'être marqué par Google avec l'alerte : This site may be compromised.

Cela ressemblera à ceci dans la page des résultat de Google (SERP) :

L'injection de SPAM Pharma utilise des malwares conditionnels qui applique des règles à ce que l'utilisateur voit. Ainsi, vous pouvez ne pas voir la page ci-dessus. Ceci est contrôlé par l'intermédiaire du code sur le serveur tel que celui-ci :

Certaines injections sont assez intelligentes pour créer leur propre nid au sein d'un serveur. L'infection se sert de $_SERVER["HTTP_REFERER"] qui redirige l'utilisateur vers une boutique en ligne qui est contrôlée par le pirate. Voici un exemple d'attaque monétisée :

Comme la plupart des infections de type SPAM, le pharma hack joue en grande partie sur le contrôle du trafic pour gagner de l'argent. Cela peut être fait par nombre de clics ou bien par le trafic. Il est très rare de constater sur un pharma hack une redirection vers un site malveillant pour une tentative de drive-by download par exemple.

Aujourd'hui, le pharma hack a évolué ce qui a rendu sa détection difficile. Dans le passé, les injections de SPAM apparaissaient sur vos pages où il était facile de les trouver et de les retirer.

Maintenant c'est tout à fait différent. Il utilise une série de backdoors avec beaucoup d'intelligence pour détecter d'où provient le trafic et ensuite il dit à l'infection comment répondre. Encore une fois, il peut se comporter comme un malware conditionnel. De plus en plus les pharma hacks bidouillent leur payload pour les robots de Google, l'objectif étant d'apparaître sur les SERPs de Google. Cela permet une exposition maximale et un plus grand rendement monétaire pour les pirates.

Voici une image d'un vieux SPAM pharma hack injecté sur un blog :

Une autre version d'un pharma hack a été d'infecter des liens bénins comme la page d'accueil, d'à propos ou de contact en redirigeant l'utilisateur vers une page complètement différente comme ceci :

Identifier une infection de ce type peut être très difficile. Dans ses débuts, l'identification de ce type d'infection était aussi facile que la navigation sur votre site. Aujourd'hui, il existe des versions plus avancées qui sont plus difficiles à trouver.

La bonne nouvelle est que si vous êtes un webmaster assidu en permettant un certain type de contrôle ou de surveillance de vos fichiers sur votre site Wordpress, vous serez en mesure de voir si de nouveau fichiers ont été ajoutés ou modifiés. C'est de loin l'une des méthodes les plus efficaces de détection.

Vous pouvez essayer d'utiliser des scanners gratuits comme ceux que j'ai proposé dans la partie Backdoors. Mais malheureusement, bon nombre de scanners HTTP ne remonteront pas les infections car celles-ci ne sont pas techniquement malveillantes.

Pour identifier et retirer ce genre d'infections, vous pouvez utiliser les commandes dont j'ai parlé plus haut comma par exemple :

root@server:~# egrep -wr 'viagra|pharmacy' .

En utilisant la commande egrep, vous êtes en mesure de chercher plusieurs mots en même temps séparés par un pipe. Ou bien essayez quelque chose comme ceci :

root@server:~# grep -r "http://canadapharmacy.com" .

Cela fonctionne seulement si l'infection n'est pas codée, chiffrée ou concaténée.

Une autre méthode efficace consiste à accéder à votre site avec des user-agents et une adresse IP différente. Pour cela essayez Bots vs Browsers pour vérifier votre site à travers un certain nombre de navigateurs.

Pour ceux qui utilisent le terminal, vous pouvez essayer en utilisant la commande curl :

root@server:~# curl -A "Mozilla/4.0 (compatible; MSIE 5.01; Windows NT 5.0)" http://somesite.com

Prévenir un pharma hack peut être délicat. Ce genre de hack exploite en général des versions obsolètes de logiciel. Cependant, une version obsolète de Wordpress n'est pas nécessairement le problème. Même si vous êtes à jour, une autre installation à jour sur le même serveur pourrait être vulnérable. Si le payload réel réside sur votre serveur et non pas dans un répertoire de votre site web, il peut être extrêmement difficile de le trouver.

Voici un exemple de ce que vous devriez peut-être chercher si vous ne trouvez pas l'infection dans votre installation :

Une redirection malveillante renvoie un utilisateur vers un site web malveillant. En 2010, 42.926 nouveaux domaines malveillants ont été détectés. En 2011, ce nombre est passé à 55.294. Et cela inclut seulement les domaines principaux et non pas l'ensemble de leurs sous-domaines.

Quand un visiteur est redirigé vers un site autre que le principal, le site web peut contenir ou non un payload. Supposons que vous ayez un site web mysite.com. Quand quelqu'un le visite, le site web pourrait emmener le visiteur vers par exemple badsite.com/foo.php où foo.php est un payload ou bien cela pourrait être un simple site avec des annonces publicitaires.

Comme pour de nombreuses attaques de malwares, il s'agit encore une fois de l'accès à votre serveur. Le pirate pourrait balayer votre site à la recherche d'une vulnérabilité comme celle de TimThumb ou d'une vieille version de votre Wordpress et qu'il la trouve, télécharge le payload qui fonctionnera alors comme une backdoor.

Détecter une redirection n'est pas aussi complexe que la détection de certaines autres infections. On le trouve souvent dans votre fichier .htaccess et ressemble à ceci :

Il peut y avoir des cas où une redirection est codée en PHP. Si c'est le cas, il se trouvera généralement dans un de ces fichiers :

• header.php
• footer.php
• index.php

Il pourrait ressembler à ceci :

Pour empêcher cela, une méthode rapide et facile est de changer le propriétaire du fichier et ou de réduire les autorisations du fichier de sorte que seul le propriétaire soit autorisé à le modifier. Toutefois, si votre compte root est compromis, ça ne changera pas grand chose...

Le fichier le plus important est le .htaccess. Regardez le tutoriel "Protect Your WordPress Site with .htaccess" et gardez à jour les règles énoncées en vous rendant sur le site PerishablePress. La dernière version sur son site à ce jour étant la 6G Beta.

Voilà vous connaissez maintenant les types d'infections qui peuvent ravager votre installation de Wordpress. Avec ce peu de connaissance vous devriez vous en sortir. Et rappelez-vous d'une chose importante, gardez votre Wordpress et ses plugins à jour et vérifiez la maintenabilité de ces derniers.