Comment se faire hacker son site web


Pirate ! Cela fait 3 fois en moins d’un an que je vois des sites web autour de moi se faire pirater, dont celui-ci. Cela méritait bien un petit post.

1 – La page d’accueil du site remplacée par une page turque

C’était en février dernier. La page d’accueil de ce site était remplacée par une page en turc, très kitsch. J’ai d’abord pensé qu’on m’avait hacké le nom de domaine (la pire des hypothèses !) et je me suis vite connectée chez mon registrar : tout était normal. Je me suis alors connectée en FTP sur mon site, pour me rendre compte qu’une page index.html avait été ajoutée à la racine du site, faisant ainsi office de page par défaut à la place de index.php, qui existait toujours. Une suppression du fichier index.html a tout ramené à la normale.

Voyant que d’autres sites du même hébergeur avait eu le même problème, j’ai loggué un ticket au support du-dit hébergeur, qui m’a conseillé de changé mes mots de passe, en particulier FTP. Néanmoins, l’analyse des connections FTP ne montra pas de connection ayant entraîné le remplacement du fichier. Je penche plutôt pour une faille de sécurité chez l’hébergeur, dans la mesure où plusieurs utilisateurs se sont plaint dans les forums du même problème. Ou alors il s’agit d’une faille de WordPress, le logiciel qui gère ce blog, mais je ne vois pas bien comment elle peut fonctionner, et rien dans les logs http ne montrent d’actions bizarres…

2 – Le site est classé comme malveillant chez google et un gros avertissement apparaît dans Firefox quand on essaye d’y accéder

Site malveillantJe n’ai heureusement pas eu à subir cette attaque, assez subtile. En se connectant par FTP sur le site, on constate que tous les fichiers index.xxx (les fichiers correspondant aux pages affichées par défaut par le navigateur) ont une date très récente. En récupérant les fichiers et en regardant le contenu, on constate qu’ils contiennent du code javascript bizarre à la fin ; code qui n’a rien à faire là, si le on compare avec une version sauvegardé précédemment de ces fichiers.

La solution pour résoudre le problème est de supprimer le morceaux de code des fichiers, ou de les ré-uploader  sur votre site si vous avez une copie de sauvegarde. Mais comment faire pour que le problème ne se reproduise pas ? Echaudés par l’attaque de février, nous avons reloggué un ticket chez l’hébergeur, qui  a encore dit de modifier les mots de passe. Mais cette fois, l’analyse des traces FTP a montré des connections qui n’étaient pas les notres, pile aux heures correspondant à la date de dernière modification des fichiers index  => modification immédiate du mot de passe FTP ! Par contre, pas de traces d’une attaque brute, avec diverses tentatives de login / mot de passe : le système qui s’est connecté connaissait le login et le mot de passe. Mais comment ?

Via un virus, qui cible le logiciel de transfert FTP FileZilla (entre autres). Voir ici, par exemple (le lien est en anglais). FileZilla stocke les mots de passe en clair, ou les crypte d’une façon décryptable facilement. Ce message en anglais (de 2005, cela a-t-il changé ?) explique la politique de FileZilla en terme de cryptage. Le virus cible l’installation Filezilla, et  récupère les logins / mots de passe. Modifier le site est ensuite un jeu d’enfant. On ne sait pas trop comment le virus a été attrapé, mais l’antivirus avait détecté quelque chose quelques jours plus tôt, lors d’un upgrade de Flash demandé par Firefox… Le mieux est donc : soit de ne pas utiliser FileZilla, soit de ne pas y stocker les mots de passe.

3 – De la pub pour le Viagra ou autres pilules miracle sur mon blog WordPress

Là-encore, une attaque qui n’a pas touché ce site directement. Après connection FTP pour regarder les fichiers : pas de problème avec les fichiers index, ou autre fichiers php à la racine du site. Le lien apparaissant sur toutes les pages, je me dis que c’est peut-être le thème WordPress qui est en cause : bingo ! Le fichier header.php a une date de dernière modification anormale, et effectivement, à la fin du fichier, on trouve un bout de code qui n’a rien à faire là. On remet le fichier à jour et tout va bien. Je me dis que c’est le retour du FileZilla hack, et le mot de passe FTP est changé.

Mais quelques jours plus tard, la pub revient. Analyse des logs FTP : pas de connexion étrange. Le problème ne vient pas du FTP. Analyse des logs http : on voit un accès de modification du fichier header.php :

extrait des logs

D’où changement du mot de passe de tous les comptes Administrateur, et suppression du compte nommé « admin », qui est le compte par défaut. Néanmoins, on ne voit pas de traces d’attaque brute, via diverses tentatives de connexion. Là-encore, le user / mot de passe est connu…

En cherchant sur le web, on voit diverses façons de pirater les blogs sous WordPress. Liste non-exhaustive :

  • utiliser une faille de sécurité d’un plug-in
  • utiliser une faille de sécurité de WordPress
  • utilliser une faille de sécurité de l’hébergeur : le site est piraté via un autre site du même hébergeur qui a été piraté

J’ai regardé plus attentivement. Il y a un truc bizarre dans la liste des utilisateurs Administrateurs : Le comptage dit 6, mais il n’y en a que 4 d’affichés… Petit détour par la base de données :

SELECT * FROM `wp_usermeta`
WHERE meta_key = 'wp_capabilities'
AND meta_value LIKE '%administrator%'

=> retourne 6 lignes. On prend la colonne user_id et nouvelle requête : select * from wp_users where ID in (152, 153) (la liste des user_id de la requete précédente).  2 utilisateurs louches, qui justement n’apparaissent pas dans la page des users Admin.  Je repasse sur la wp_usermeta à la recherche de données bidon : select * from wp_usersmeta where user_id = 152 ; la propriété first_name contient du code : c’est louche. Impossible de supprimer les utilisateurs à la main : ils n’apparaissent pas dans l’interface. Avant de les supprimer en base, je vérifie qu’ils ne sont auteurs d’aucun post (champ post_author de la table wp_posts), et hop, je supprime tout ce qui est lié dans les tables wp_users et wp_usermetadata, tout en notant la date et l’heure de créations de ces utilisateurs (4/09/2009) (pour aller vérifier dans les logs).

Ensuite petit tour dans les fichiers via FTP. Je vais voir dans wp-content/upload, où il pourrait y avoir des fichiers bizarres (genre wp-pass.php, qui n’a rien à faire ici). Rien. Par contre, à la racine, je vois une date étrange sur wp-pass.php et 4 autre fichiers (3/10/2010, alors que tout le reste date de 2008). Je les édite, et bingo :  du code javascript bizarre avec des appels à la fonction base64_decode, ce qui est considéré comme très louche (et un peu caché, car sur la même ligne que <?php, mais après une bonne quantité de blancs). Après récupération du site et comparaison avec une sauvegarde, il y a une dizaine de fichiers dans ce cas. Il y a asussi eu un fichier index.php uploadé (le 30/08/2009) avec du code pourri. Ici, il faudrait upgrader wordpress, mais je n’ai pas trop le temps, je me contente de supprimer wp-admin/ et wp-includes/ (au cas où d’autres fichiers seraient corrompus) et d’uploader la sauvegarde. Je ferai l’upgrade dans quelques jours, en changeant le mode de passe de la base de données. Je n’ai rien vu d’étrange dans wp-content et le thème a l’air normal aussi.

Ici, une faille de wordpress est sans doute à l’orgine. La date de création des utilisateurs semble correspondre à des appels à xmlrpc.php dans les logs php (date des logs en heure local = date de création si celle-ci est stockée en base en GMT). Un upgrade est donc fortement conseillé.

    

Un commentaire sur “Comment se faire hacker son site web”

  1. Bonjour

    Je suis tombé sur votre blog en cherchant des infos sur les poussettes. Je suis moi même professionnel de l’informatique. Une chose me surprend dans ce que vous indiquez : Vous vous connecter en FTP sur votre hébergeur. Le FTP n’est pas crypté, le mot de passe circule en clair. Il est très aisé de récupérer les infos, et donc d’usurper votre identité

    Il faudrait plutot privilégier du ssh / sftp.

    Cordialement

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *