Site Hacked By …

hacked_by

Qui ne s’est pas déjà réveillé un matin avec la mauvaise surprise de voir son site internet remplacé par une nouvelle page, avec cette fameuse phrase qui pique les yeux : Hacked By xxxx

Malheureusement, beaucoup trop de personnes vivent cette frustration liée principalement à l’incompréhension totale d’avoir été choisi pour cible !

Cet espèce de sentiment que l’on ne sait décrire mais qui énerve au plus profond de soi et qui fait surgir tout un tas de questions. Pourquoi moi ? Comment est-ce possible ? Ai-je une sauvegarde? Mon site est-il toujours fonctionnel malgré cette page horrible souvent accompagnée d’une musique totalement insolite…  Après ces interrogations, vient généralement la question : Comment gérer cette situation ?

La réponse à cette question est largement dépendante des compétences techniques liées à l’administration d’un site internet. Car, oui, administrer un site internet, c’est aussi être en mesure de gérer ces situations délicates.

Chez Web4all, au support, nous avons régulièrement des tickets liés à un site qui s’est fait pirater. Le piratage d’un site internet se manifeste généralement de trois façons différentes (voir cumulées) :

– Les pages du site internet, et principalement l’accueil, ont été modifiées.
Dans ce cas là , c’est le plus évident, le site a été « défacé ». Une modification non sollicitée de la présentation du site internet a eu lieu.

– Un envoi d’e-mails de SPAM en masse est en cours depuis votre site.
Vous n’êtes pas encore au courant, mais ça ne serait tarder ! Web4all détecte que votre site envoi un nombre d’emails conséquent de type SPAM .
Soit vous avez un formulaire non sécurisé qui est exploité soit une tierce personne s’est introduite dans votre hébergement pour déposer des fichiers (.php) dans le but de réaliser une campagne de SPAM.
Dans 90% des cas, des fichiers sont déposés sur l’hébergement. Web4all va alors vous informer que votre domaine a une activité anormale.

– Un processus système anormal est exécuté depuis votre espace d’hébergement.

Comme pour l’envoi de SPAM, vous n’êtes pas forcément au courant qu’il se passe quelque chose mais Web4all vous informe rapidement qu’un processus anormal est en cours d’exécution sur votre espace d’hébergement. Ce processus peut être un script quelconque (perl, python, etc..) ou un programme exécutable (binaire).
Dans 90% des cas, il s’agit de backdoors (portes dérobées) en Perl qui ne peuvent fonctionner en raison du port spécifique utilisé pour recevoir la communication depuis l’externe.

Point Positif de ces trois méthodes: vous êtes au courant qu’il s’est passé quelque chose 🙂
En effet, il est toujours plus simple de savoir qu’il y a une faille lorsqu’elle est exploitée de cette manière plutôt que de faire les frais d’une tierce personne bien plus déterminée à utiliser le contenu de votre site internet (vol de données, phishing) qu’à faire du SPAM.

Une chose est sûr, votre site internet dispose d’une faille de sécurité majeure.

Cette faille profite à une tierce personne et, suivant le type de faille, si celle-ci est en mesure de déposer des fichiers sur votre hébergement, soyons clair, vous avez perdu le contrôle de celui-ci.

Impacts en détail et explications.

Web4all assure l’isolation entre les packs d’hébergement.
PHP, avec la restriction open_basedir, assure l’isolation entre vos différents domaines et sous-domaines. Cela ne concerne que les processus PHP.
Tout autre processus exécuté depuis votre pack d’hébergement sera en mesure de sortir du domaine ou sous-domaine en question.

En cas de faille sur votre site internet , toutes les données présentes sur votre espace d’hébergement (incluant les autres domaines que vous avez sur le même pack) sont à la disposition du pirate. Libre à lui de les consulter, de les modifier ou de les supprimer…
Ici je parle des fichiers, mais votre identifiant et mot de passe de votre base de données étant eux aussi dans un fichier accessible par le pirate, celui-ci est en mesure de les récupérer et de les utiliser pour réaliser des opérations sur votre base de données. Exporter la base de données, ajouter des comptes admin dans les tables, insérer du code dans vos articles et bien plus encore.

Comme vous pouvez le constater, c’est une très mauvaise nouvelle et c’est pourquoi il est important d’être conscient des risques liés à la présence d’une faille de sécurité sur votre site internet.

Que faire après un hébergement compromis ?

Inspirez, Expirer  et ajoutez cet article dans vos favoris 😉analyse_faille

Urgence 1.
Il y a urgence, oui. Non ce n’est pas la fin du monde. La première urgence en cas de modification de votre site internet est de mettre une page de maintenance de votre site internet et que toutes les pages soit redirigées sur cette page de maintenance.

La première chose que vous souhaitez éviter est que les moteurs de recherches puissent indexer votre site internet avec le fameux Hacked By xxxx
Réagissez vite, les moteurs sont parfois bien plus rapides qu’on ne le pense. ^^

Je ne parlerai pas des méthodes pour réaliser la page de maintenance mais une bonne pratique est de rediriger toutes les requêtes arrivant sur votre site vers une page de maintenance avec une exception pour votre adresse IP afin de pouvoir continuer votre analyse. De cette manière, vous continuez à voir le site normalement pendant que vos visiteurs et les moteurs de recherche tombent sur la page de maintenance. De facto, le pirate ne devrais plus être en mesure d’exploiter la faille .

Urgence 2.
La seconde urgence concerne la modification de tous les mots de passe auxquels le pirate aurait pu avoir accès.

Cela comprend:

  • compte(s) Mysql
  • compte(s) FTP
  • compte d’accès au manager (si présent dans un fichier de configuration sur votre hébergement)
  • boîte(s) e-mail(s) (si présent  dans un fichier de configuration sur votre hébergement)
  • compte(s) administrateurs et/ou utilisateurs de votre CMS ou Forum.

De plus , si vous avez utilisé un mot de passe identique sur d’autres services externes à votre hébergement (compte email professionnel, Paypal, Twitter, Facebook, Google, etc..), allez les changer immédiatement. Le pirate essaiera rapidement les mots de passe volés sur les services en ligne les plus populaires

Maintenant les urgences gérées, il faut se mettre au travail et analyser..

L’analyse est la partie la plus compliquée car elle n’est pas simple et demande du temps.

Pendant cette analyse que je vais aussi appeler analyse corrective, l’objectif est de comprendre ce qu’il s’est passé sur votre hébergement tout en corrigeant les problèmes rencontrés.

D’une manière générale, préférez toujours une restauration TOTALE ( fichiers + base de données) à une date antérieure au problème survenu sur votre hébergement.

La bonne pratique veut que cela soit fait pour l’ensemble des domaines et sous-domaines de votre hébergement. En effet, un simple code injecté dans l’un de vos fichiers .php ou un nouvel enregistrement créé dans une table de votre base de données permettront au pirate de revenir.

Suivant votre pack , vous pouvez utiliser le système de restauration pour rétablir votre site à la date de votre choix.

Si la restauration totale n’est pas envisageable, la première chose à faire est d’identifier les fichiers déposés ou modifiés par le pirate. C’est un travail de fourmi mais nécessaire.

Via FTP ou SSH vous pouvez partir à la recherche des fichiers compromis ou ayant servi à compromettre votre hébergement. Conservez une trace des fichiers modifiés et des fichiers identifiés comme nouveaux. N’oubliez pas d’afficher les fichiers cachés avec votre client FTP.

Si vous utilisez un CMS type Joomla, WordPress , Drupal, etc.., vous pouvez aussi supprimer tous les fichiers concernant la partie moteur du CMS , téléchargez la version que vous utilisiez depuis le site officiel et remplacer tous les fichiers.

Au niveau de la base de donnée, là encore, pas de magie. Vous devez vous assurer qu’aucun nouvel utilisateur de type administrateur n’a été ajouté dans votre base.
Si le pirate a eu accès à la base de données, la modification du mot de passe d’un des comptes utilisateur ou administrateur a pu être réalisée… La bonne pratique serait de TOUS les changer, ou bien de restaurer votre base de données avec une sauvegarde avant piratage.

La recherche d’injection de données en base est généralement titanesque mais, suivant votre base de donnée ou le CMS utilisé, vous devriez pouvoir concentrer vos efforts.
Bien entendu, une injection de code peut avoir été faite dans vos articles de blog (WordPress/Joomla/etc..) et s’afficher discrètement sur toutes les pages de votre blog. Gardez un œil sur le code source de vos pages.

Où se trouve la faille ?

remote_code_execCette question devrait avoir une réponse avant que votre site ne soit de nouveau mis en ligne !

Si vous ne savez pas, il faut prendre toutes les précautions nécessaires. Avoir fait tout le travail précédent d’analyse, de correction et de nettoyage est totalement inutile si la faille n’est pas corrigée. Pour corriger une faille, il faut la trouver.  Généralement, la réponse se trouve dans les logs brut du serveur web utilisé. Chez Web4all, Apache2 génère un log de toutes les visites faites sur vos domaines et sous-domaines.  Ce log est consultable en temps réel depuis le manager 🙂 Vous avez aussi la possibilité d’activer la copie de log journalier dans votre espace d’hébergement. Chaque nuit, les logs de la journée précédente seront copiés dans votre espace d’hébergement vous donnant ainsi la possibilité de faire votre analyse.

Les requêtes de type GET sont à exclure pour aller droit au but mais elle sont parfois le prémice de la recherche d’une faille. Les requêtes de type POST sont bien plus révélatrices du fonctionnement et des interactions réalisées entre une tierce personne (visiteur, pirate, curieux) et votre site internet.

Dans la plupart des cas, la faille se trouve dans un plugin du CMS utilisé.
Un autre cas fréquent de faille se trouve être au niveau des thèmes utilisés par le CMS. Que ce soit un thème gratuit ou payant, ceux-ci sont sans cesse mis à rude épreuve pour trouver des failles de sécurité.
Bien sur, les failles peuvent être aussi des erreurs de code dans votre développement, une mauvaise gestion d’un formulaire et tout un tas d’autres failles existent.

Ce que l’on remarque aussi trop souvent est l’utilisation de comptes FTP dérobés. L’utilisation d’un couple nom d’utilisateur/mot de passe avec un client FTP par le pirate, lui permettant de faire ce qu’il souhaite sur votre pack d’hébergement dans l’arborescence limitée par la configuration que vous avez appliquée pour cet utilisateur dans le manager.
L’utilisation du protocole FTP non sécurisé pour les échanges de fichiers n’est pas recommandé . Web4all propose l’utilisation du FTP Sécurisé . Cette méthode devrait être votre méthode de prédilection pour tout échange de fichier avec un serveur FTP.

Comment corriger la faille ?

wpupdateDans le cadre d’un CMS, la solution est assez simple si c’est une faille connue. S’il s’agit d’une faille connue sur l’un de vos plugin , thème ou tout simplement du CMS lui même, une mise à jour devrait tout corriger.
C’est le premier réflexe que vous devez avoir, mettre à jour tous les composant de votre CMS.

Si vous utilisez un forum, c’est la même chose. Mettez à jour rapidement.
D’une manière générale, les mise à jour de plugin, thèmes et CMS doivent se faire régulièrement. Si vous n’êtes pas une personne souhaitant faire des mise à jour trop régulièrement, dans ce cas là vous devrez suivre les évolutions à la recherche de patch de sécurité . Si patch de sécurité, alors vous pourrez réaliser une mise à jour.

Vous n’utilisez pas de CMS ou de forum ?
La solution est beaucoup moins évidente, vous devrez passer votre temps à trouver le point d’entrée via les log . Si les log ne sont pas parlant, votre seul ami sera votre éditeur de texte préféré et beaucoup de café 😉

Pour conclure 🙂

Web4all_Safety_first La sécurité d’un site internet avec ou sans utilisation d’un CMS passe avant tout par une maîtrise des éléments utilisés sur un pack d’hébergement.

La facilité d’installation permet à beaucoup de réaliser leur site internet, de mettre en ligne du contenu rapidement mais parfois oublient les  vrais  risques liés à une faille de sécurité. On sous-estime bien trop souvent cet aspect là de la gestion d’un site internet.  Certaines règles de base peuvent éviter bien des problèmes mais il faut avant tout en avoir conscience. En mettant vos sites internet à jour, vos plugins, vos thèmes et votre code, vous  limiterez grandement ces failles exploitées bien souvent de manière automatique, basées sur la version de votre CMS ou d’un plugin.

Web4all s’efforce de proposer un environnement et une plateforme sécurisés , 2014 aura été une année mouvementée en faille de sécurité importantes.
Le dernier maillon de la chaîne est votre site internet, le mettre à jour régulièrement c’est comme fermer la porte de chez vous chaque soir en rentrant 🙂

J’espère que cet article vous aura apporté des informations intéressantes sur comment mieux appréhender la découverte de l’utilisation d’une faille sur votre espace d’hébergement. J’aurai le plaisir de réaliser d’autres articles sur le même thème. Si vous avez des demande particulières, n’hésitez pas à les partager sur les commentaires.

Si vous désirez aller plus loin, nous vous invitons à lire les documents réalisés par l’ANSSI :

A noter que concernant les attaques de type DDoS, Web4all vous protège grâce à une solution Arbor Networks.

benoit.georgelin

Conseil d'Administration

Laisser un commentaire

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