Bonsoir mes amis,
Ce que je craignais depuis quelques mois est arrivé ! (vous avez dû le constater !)
Jusqu' à présent, les attaques étaient "mineures" et sont passées quasiment inaperçues, car elles ont été traitées en quelques minutes/heures (Le temps d'être averti !).
Cette fois-ci, le problème a été plus sérieux, puisque ce n' est pas le site nouadhibou qui a été visé directement, mais le serveur de notre hébergeur, qui gère des centaines de sites. Le résultat, c' est le piratage de tous les sites hébergés par notre serveur !
Je pressentais un gros problème ... et c' est arrivé ! J' ai passé beaucoup de temps à peaufiner la sécurité du site, mais, comme en 14, c' est de l' intérieur (du serveur lui-même) que l' attaque est arrivée.
Voici le détail de mon dernier mail à l' hébergeur :
=== Début du mail ===
Bonjour,
Je vous copie le mail qui sera envoyé à tout le monde sous peu. Cela devrait répondre à vos questions. Si vous sécurisez votre site web c’est très bien et nous vous en remercions. Malheureusement ce n’est pas tout le monde qui prend la peine de le faire et cela ouvre la porte aux pirates.
Bonjour,
Nous avons décidé de transférer tout le monde sur un nouveau serveur car l’ancien a été la cible de plusieurs piratages et nous croyons que cela risque de se reproduire car il y a des sites qui listent les serveurs hackés et les pirates peuvent consulter ces sites pour « tenter leur chance ».
Le piratage en question est un « mass deface ». Cela consiste à modifier les index.php index.htm et index.html de tous les comptes pour afficher à la place la page du pirate. Ils dévisagent le site si on veut.
Mich : incomplet voire inexact Messieurs !
Dans le cas présent et d'après mes constats, dans ce "mass defacement" les fichiers de type main*.* , ceux de type home*.*, et enfin ceux de type default*.* ont été altérés ! Je peux le prouver !
Cela veut dire que si les clients disposant de blogs, chats et forums réinstallent uniquement les fichiers de type index, leur problème ne sera pas résolu loin de là !
Je conseille fortement à vos clients de réaliser un script php de surveillance pour détecter les fichiers modifiés à une date donnée ou depuis un certain nombre de jours ... (c' est mon cas).
Ce genre d' attaque affecte aussi beaucoup d' autres types de fichiers puisqu' en fait le script de piratage peut altérer tous les types de fichiers une fois qu'il s'est inséré dans un serveur !
Il est très, très difficile de prévenir ce genre de piratage sans l’aide de tous. Nous avons mis en place toute les sécurités sur le serveur afin de protéger celui-ci contre les attaques mais pour protéger le serveur des mass deface il est très, très important que tout le monde y mette du sien et fasse les mises à jour pour leurs scripts. Spécialement les CMS comme Joomla, Wordpress etc. Ce sont les scripts les plus souvent visés par les pirates car beaucoup de gens les utilisent et il est profitable pour eux de découvrir des failles dans ces logiciels.
Nous avons retrouvé le site utilisé par le pirate pour injecter son code sur le serveur, le site a été supprimé du serveur.
Mich : Niet ! Je n'en crois pas un mot !
Certain auront l’impression qu’on se répète car c’est la 3e fois et à chaque fois le même constat, la faille provient d’un site qui n’était pas maintenu à jour. C’est malheureusement la simple et unique explication. 3 sites différents ont été visés par les pirates sur ce serveur. Malchance certes mais cela arrive régulièrement que des sites présentes des failles. Parfois les pirates mettent en place des sites de phishing, envoie du SPAM ou d’autres font des mass deface. Nous rencontrons des sites mal sécurisé régulièrement.
Nous ne tentons pas de mettre la faute sur les dos des clients, toutefois beaucoup de gens nous demandent comment sécuriser leur site etc. Faire les mises à jour est une des meilleures choses à faire et c’est très important. Utilisez des scripts reconnus, des mots de passe complexes sont d’autre bonnes habitudes.
Mich : Vous rigolez j' espère !
Vous avez supprimé le site du pauvre gars, tout fier de son oeuvre, dont le seul crime est de penser qu' il a le droit d' exister sur la toile ! Vous savez pertinemment que les scripts de "mass defacement" sont entièrement paramétrables et qu' il suffit au pirate de renseigner le champ "adresse du site" pour le défigurer et tout le reste est automatisé ...
Vous l' avez fusillé pour l' exemple ou pour masquer votre responsabilité ?
Personnellement, en dehors de 2 blogs Wordpress, d' un phpchat et d'un PhpBB, je code sans CMS, j' imagine donc qu'il y a des failles possibles (c'est même sûr !), c' est pourquoi j' ai blindé les htaccess. Mais les htaccess ne peuvent rien contre une attaque de l' intérieur (du serveur lui-même !) et, à mon avis, il s' agit bien de ce cas de figure : c'est votre serveur qui a saboté les sites de tous vos clients par l' intermédiaire du fichier système dont je vous ai parlé dès le premier jour de l' attaque à savoir : http://nouadhibou.info/cgi-sys/defaultwebpage.cgi
Moi- même je n' ai pas accès au répertoire nouadhibou/cgi-sys. VOUS en êtes l'unique propriétaire . Je pense que vous savez (et ne le dites pas) que ce fichier est responsable des misères de tous vos clients qui se sont tous retrouvés avec un "defaultwebpage.cgi" sur la racine de leur site ! Ce fichier n' a pu être répandu sur les racines de sites que par l' utilisateur Unix "root", c' est à dire votre serveur !
De notre côté nous allons rechercher des outils pour repérer les scripts à risque sur le serveur. Les pirates utilisent ce genre de script pour trouver les failles, il est donc possible d’utiliser leurs propres armes pour se protéger d’eux.
Mich : Pas encore fait ? Tous les script PERL de "mass defacement" sont sur le net depuis des années ... Vous connaissez Gogol ? Rien ne lui échappe ! essayez "mass defacement" sur Google, si, si, vous verrez !
Concernant le nouveau serveur, vous avez été transféré sur le serveur maven2-14.com. C’est une machine pratiquement identique à l’ancien serveur au niveau hardware. Les différences seront au niveau des version du kernel, de CentOs etc mais cela aura peu ou pas d’impact sur vos sites.
Pour accéder au cPanel, vous pouvez utiliser le lien www.xxxx(censuré)/ afin d’être sûr de travailler sur le bon serveur. Hôte FTP : xxxx(censuré)xxxx
L’IP du serveur est : xx(censuré)xx
Pour ceux qui gèrent leur propre DNS :
DNS1.xx(censuré)xx
DNS2.xx(censuré)xx
***IMPORTANT***
Afin de rétablir votre site, vous devez remplacer tous les fichiers index.html index.htm index.php par une sauvegarde. Malheureusement notre partition de sauvegarde a été affectée par le pirate cette fois-ci donc nous ne pouvons pas remettre les fichiers en place pour vous. Ceci est exceptionnel car nous n’avons jamais vu nos sauvegardes affectées par un mass deface. La technique utilisée par le pirate est présentement sous analyse afin de comprendre comment la partition autre que /home a été affectée.
Mich : Sans blague ! (Voir plus haut) Je connais un peu Unix, c'est quelle partition ? etc ? bin ? Un fichier cgi incontrôlé? bizarre autant qu' étrange ! Cela revient à admettre votre responsabilité dans le vérolage des sites que vous hébergez ! Vous parlez trop !
De plus, pas plus tard qu' hier, vous m' avez affirmé disposer de backups ! Heureusement que je dispose des miens !
Nous sommes désolés pour l’inconvénient pour ceux qui n’aurait pas de sauvegarde des fichiers index. Il est important de garder une sauvegarde locale même si nous en avons sur le serveur au cas où ce genre de chose se produise.
Mich : Faux. Vérolés !
Nous avons en sauvegardes tous les autres fichiers/base de données au besoin, seuls les fichiers index ont été touchés.
Mich : Faux. Vérolés !
Les sauvegardes sont présentement désactivées sur le nouveau afin de laisser le temps à tout le monde de remettre les bons fichiers index en place. Ensuite nous allons activer les sauvegardes aux 2 jours comme en temps normal.
Mich : Je vous ai déjà informé par mail du 17/11 que vos sauvegardes (backups) sont "verolées" ! Lisez vos mails de temps en temps !
Si vous avez des questions concernant le présent courriel ou la situation n’hésitez pas à contacter notre support technique au support@mavenhosting.com
Mich : Inutile, j' ai tout compris.
Nous vous remercions pour votre patience pour les temps d’attente en ce moment car nos techniciens sont débordés.
Mich : Moi ca va bien, j'ai éradiqué le salopard sans votre aide. Il ne me reste plus qu' à remettre en forme mes blogs puisque je ne peux toujours pas télécharger mes sauvegardes ! ! !
C' est quel niveau les techniciens ? Bac - 10 ?
Conclusion :
Faudrait peut-être repenser la sécurité de vos serveurs et cesser d' incriminer ceux qui vous font bouffer !
En espérant un retour à la normale le plus rapidement possible. »
Mich : La seule phrase que je partage ... sans y croire !
Merci
Mich : De rien !
____________________________________________
Administrateur Senior ?????? - Support aux clients.??????
Notre devise est votre satisfaction à 100%.??????
Cordialement, Simon
http://www.mavenhosting.com/
Suite du feuilleton, cette réponse à l' hébergeur le lendemain :
Bonsoir,
Je vous l' ai déjà signalé hier, et vous oubliez les fichiers de type home*.* ainsi que les fichiers default*.*
Cela peut aider les autres ...
Mich Cosquer
From: Mavenhosting
Sent: Saturday, November 20, 2010 7:36 PM
To: michelcosquer@aol.com
Subject: Transfert de serveur - Mise à jour 2
Bonjour,
Suite au retour de certains clients, il a été confirmé que le pirate a également ciblé les fichiers de type main*.* (ex: mainfile.php et mainfile.dist.php)
Si votre site utilise ce genre de fichiers il est important de les remplacer par les bonnes versions.
Si d'autres constats sont fait concernant des fichiers touchés par le pirate nous vous contacterons immédiatement avec l'information.
Merci
Cerise sur le gateau, ce message reçu le 22/11 (soit 6 jours après l' attaque !) auquel je n' ai pas pris la peine de répondre tant il m' énerve ...
Bonjour,
Suite au retour de certains clients, il a été confirmé que le pirate a également ciblé les fichiers de type home*.* et les fichiers de type default*.*
Si votre site utilise ce genre de fichiers il est important de les remplacer par les bonnes versions.
Si d'autres constats sont fait concernant des fichiers touchés par le pirate nous vous contacterons immédiatement avec l'information.
Merci
Suite du feuilleton le 26/11/2010 :
From: Support Mavenhosting
Sent: Thursday, November 25, 2010 2:39 PM
To: 'Mich'
Subject: RE: restauration de sauvegarde impossible ...
Bonjour,
Il est parfaitement réalisable de faire un backup par FTP de temps en temps (les fichiers d’un site ne sont pas modifiés chaque jour à moins que celui-ci soit en construction)
Mich : Pas prévu dans le contrat souscrit ! Ce dernier prévoit sauvegardes/remontages à volonté ...
Si je n'avais pas prévu les sauvegardes FTP, je n'aurais jamais pu remettre mon site en route car vos sauvegardes étaient vérolées ainsi que tout le serveur. Ce simple fait signifie à coup sûr que votre serveur est une passoire !
En fait par DOUBLE SECURITE, tout webmaster DOIT avoir une copie FTP de son site ET ses sauvegardes, AINSI que le droit de les REMONTER ! ...
Suivons votre raisonnement : par FTP, mes sauvegardes vont écraser les précédentes et le résultat sera catastrophique en cas de hacking ... (Une vingtaine de Go, c'est pas rien ! Je ne vais pas stocker 40 Go, soit 2 descentes ftp, pour être sûr d' avoir au moins une sauvegarde valide !)
Tout cela est ridicule ...
Ensuite il suffit de faire un mysqldump via le cron pour la base de données qui elle risque d’être modifié constamment.
Mich : Pour sauvegarder automatiquement des injections sql ?
L ' hébergement n'est pas assez sécurisé ...
Le cron est à double tranchant dans ce cas précis !
Je fais mes sauvegardes sql quand je suis sûr du résultat.
Pour les reste comment les courriels etc nous avons des backups sur le serveur pour cela.
Cette politique est en place depuis plusieurs mois.
Mich : Sans avertir vos clients ...
Si vous avez un vieux backup en .tar.gz vous pouvez le déposer sur le FTP et on le remontera pour vous.
Mich : OK. Il se trouve sur /public_html/backup/backup.tar.gz et vous pouvez lancer la restauration.
Conclusion :
En dépit de votre incompétence, j' ai réussi à remettre sur pieds mes 2 blogs et le reste, même s'il subsiste quelques détails à régler.
Cependant, sachez que votre hébergement ne correspond plus à mes attentes ...
Salutations,
Mich Cosquer.
Merci
____________________________________________
Administrateur Senior - Support aux clients.
Notre devise est votre satisfaction à 100%.
Cordialement, Simon
http://www.mavenhosting.com/
De : Mich [mailto:michelcosquer@aol.com]
Envoyé : 25 novembre 2010 08:36
À : Support Mavenhosting
Objet : Re: restauration de sauvegarde impossible ...
Bonjour,
Le problème devient insoluble. Avant je faisais mes sauvegardes régulièrement, et restaurais en cas de pépin.
Dans le cas présent, sans possibilité de restauration, un de mes blogs est absolument irrécupérable.
Pourquoi autorisez-vous les sauvegardes, si vous n' autorisez pas les restaurations ? Ca ne tient pas debout !
La moindre des choses aurait été de prévenir vos clients avant de prendre des décisions arbitraires.
Enfin je vous rappelle vos propres termes dans un mail du 20/11/2010 dont je vous livre un extrait :
Nous sommes désolés pour l’inconvénient pour ceux qui n’aurait pas de sauvegarde des fichiers index. Il est important de garder une sauvegarde locale même si nous en avons sur le serveur au cas où ce genre de chose se produise.
Nous avons en sauvegardes tous les autres fichiers/base de données au besoin, seuls les fichiers index ont été touchés.
Les sauvegardes sont présentement désactivées sur le nouveau serveur afin de laisser le temps à tout le monde de remettre les bons fichiers index en place. Ensuite nous allons activer les sauvegardes aux 2 jours comme en temps normal.
Dans l'immédiat, j' ai ABSOLUMENT besoin de cette possibilité, ne serait-ce qu'une journée, pour remettre mon site à jour.
Et par la suite, je me vois mal faire des ftp tous les jours (ce qui affecterait tout autant les performances cpu) ...
Si vous maintenez votre position je me verrai contraint de chercher un hébergement plus compétent ...
Mich Cosquer.
Auteur : Mich.