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) :
(suite…)

Rapport de hack sur plusieurs hébergements chez Web4all

Logo Web4allBonjour, le 30 janvier 2014 un client nous informait via le système de tickets sur le manager que ses sites avaient été la cibles d’actes de piratage. Ceci est assez courant. En effet les applications clients telles que Joomla, WordPress, PhpBB et autres (pour ne citer que les plus connues) sont constamment la cible de délinquants (appelons un chat un chat, ces personnes ne méritent pas d’autre nom…). Une fois une faille identifiée sur une version de WordPress (par exemple) ou l’un de ses modules, ces délinquants prennent un « malin plaisir » à exploiter ces failles sur les sites qu’ils trouvent et se donnent alors à cœur joie, au mieux à défacer le site (remplacer la page d’accueil) au pire à détruire votre travail. Il y a aussi ceux qui ne font rien de visible mais qui vont placer leur script pour effectuer par exemple du mailing (du SPAM ben entendu) ou du phising (souvent lié avec les envois de SPAM).

Des clients victimes de sites piratés nous en avons tous les jours. Il ne se passe pas un jour sans que nos systèmes  -de manière automatique- ou un membre de notre équipe (les outils d’automatisation ne détectent pas tout) doivent effectuer des actions telles que :

  • procéder au blocage de l’envoi des mails pour un compte mails Zimbra : les identifiants du compte mails sont détournés, le hackeur utilise alors le SMTP pour envoyer des dizaines de milliers de mails SPAM
  • procéder au blocage de l’envoi des mails pour un site sur la plate forme web : piratage d’un site dans le but d’envoyer du SPAM. Si aucune action n’est prise, alors plusieurs centaines de milliers de mails partent dans la journée
  • procéder au blocage de la publication du site : il arrive que la seule solution pour limiter les dégâts soit de dé publier le site, cela peut être le cas lors de problème de SPAM comme sus-cité mais également dans le cas de sites permettant par exemple un dépôt de commentaire sans contrôle (commentaires sur blog, livre d’or…). Les robots déposent alors des millions de commentaires ce qui impacte l’ensemble de l’infrastructure et donc l’ensemble de nos clients
  • répondre aux demandes des partenaires et autorités

Bref, revenons en au client qui nous a signalé son problème. Sur le coup on reste peu inquiet car cela ne cible que le client en question, nous le guidons donc sur les démarches à effectuer pour remettre en ligne son site mais également éviter que cela ne se reproduise trop rapidement.

Quelques heures après nous avions plusieurs clients qui se sont manifestés sur les forums et tickets (5 au total). Cela n’est rien sur le nombre de clients mais ce fût suffisant pour que nous remettions en question la partie qui nous incombe et que nous effectuons les recherches nécessaires pour affirmer que tout était en ordre de notre côté.

Benoit GEORGELIN a alors effectué les recherches et il aura eu bien raison puisqu’il aura :

  • découvert une faille de sécurité sur la plate forme Web4all ayant facilité le passage du hackeur d’un hébergement à un autre
  • pu établir une liste d’hébergement compromis

Avant de donner le détail du rapport de M. GEORGELIN, je conclu cette introduction en rappelant…

Quelques principes de bases :

  • vous devez toujours veiller à ce que vos applications soient à jour
  • vous devez toujours veiller à ce que vos modules des applications soient à jour et que seuls les modules ou thèmes strictement nécessaires (que vous utilisez) soient installés. Ne laissez pas des modules ou thèmes installés s’il ne vous servent pas !
  • vous devez vous assurez de la provenance de ce que vous installez. Ne faites pas une confiance aveugle aux développeurs. Assurez vous que les modules que vous ajoutés sur vos CMS soient connu et réputés fiables. Téléchargez les sur les sites officiels
  • vous ne devez jamais fournir vos identifiants à un tiers (pas même à l’équipe de Web4all !)
  • vous devez comprendre ce que vous faites et donc comprendre le fonctionnement des CHMOD ; les hébergements qui ont été impactés sont ceux qui avaient des CHMOD mal définit !
  • un hébergement est étanche vis à vis des autres hébergements. Au sein d’un même hébergement : aucune étanchéité ! Un site piraté sur votre hébergement donne indéniablement accès à TOUT votre hébergement.

Rapport sur Hack découvert sur un site chez Web4all.fr 

Les informations nominatives, noms d’utilisateurs, téléphones… ont été masqués par nos soins. Le rapport est « brut » : utilisation interne non prévue à être communiqué, il est donc peu explicite sur certaines parties.

Le 30/01/2014 : Un client remonte un hack sur ses 3 sites.

Il se trouve que ce hakeur à hacké plusieurs sites sur l’infrastructure Web4all. Celui-ci a utilisé un site en interne a l’infra pour lui permettre de lire des fichiers situé sur les autres hébergements comme les fichiers config.php pour avoir accès aux bases MySQL.

Trace visible dans les logs, IP utilisée : 197.205.98.166

Le hackeur semble avoir pénétré le premier site en date du 29 janvier 2014.

La première trace de l’utilisation de son script pour visualiser les autres hébergements: [29/Jan/2014:22:02:39]

J’ai trouvé le site cachette du hackeur car celui-ci l’utilisait comme source pour ses fichiers vérolés a déposer sur les autres hébergements via un appel HTTP dessus ou pour naviguer sur les fichiers du site en question :

rencontre-xxMASKxx.fr-combined.log-20140131:197.205.98.166 - - [30/Jan/2014:11:41:13 +0100] "GET / HTTP/1.1" 200 907
"http://cxxMASKxxnne.org/a/Indishell/root/datas/vol2/xxMASKxx/var/www/rencontre-xxMASKxx.fr/" "Mozilla/5.0 (Windows NT 5.1;

Il se trouve que le hackeur s’est caché sur un espace hacké sans le défacer.
Sur l’espace ce trouve des outils simples en Php permettant des fonctions via PHP.

Un fichier « pca.txt » contenant une liste d’email et ce qui semble etre des mots de passe se trouve a la racine de l’hébergement

J’ai testé des login/passe sur gmail , aucun ne fonctionnait.

Le hackeur a pu utiliser une faille, la seule et certainement unique possible ou connue a ce jour sur un CloudLInux : Symlink du à un manque de configuration

Cf : http://docs.cloudlinux.com/index.html?securelinks.html

Par défaut Cloudlinux ne protège pas contre cette attaque il faut que cela soit configuré au niveau des paramètres du kernel.

La configuration pour interdire l’utilisation du symlink à été appliquée sur l’ensembles des serveurs HTTP.

Un dossier /a/root renvoyait vers /   ( /a/root -> / )

Apache2 tournant en dehors de la cage, le hackeur peut naviguer sur le serveur en dehors de la cage.
L’accés dépendra des droits relatifs au serveur, son processus aura comme user w4apache(34)
Le hackeur a pu avoir une visibilité totale sur les domaines hébergés chez Web4all
Le hackeur a pu accéder a n’importe quel fichier disposant des droits > 770

 Il semble que le hackeur a pu hacker plusieurs base de données grâce à ce procédé et un fichier « sql.php » lui permettant exécuter des actions rapide :

  1. Mettre le login, pass, db dans un cookie de son navigateur
  2. Réaliser des actions sur la tables d’une base (listTables,add, édit,delete, logout, et Submit pour la sauvegarde )

Au moins 4 bases de données sont identifiées :

  • 1xxxxx_bo4l2
  • 1xxxxx_familia
    • tablename=wp_users
  • 1xxxxx_champa
    • tablename=zc9bd_users
  • 1xxxxx_9g47ya
    • tablename=sotvm_users

Les mots de passe de ses bases sont donc totalement compromis.

 Site cachette du hakeur : URL retirée du rapport public.

Le screen (modifié car appartient à un client) ne présentait aucune trace de hack :
rapport-de-hack-sur-plusieurs-hebergements-chez-web4all

Boite à outils du hakeur :

rapport-de-hack-sur-plusieurs-hebergements-chez-web4allQui permet ensuite de naviguer dans l’arborescence :

rapport-de-hack-sur-plusieurs-hebergements-chez-web4all

rapport-de-hack-sur-plusieurs-hebergements-chez-web4all

rapport-de-hack-sur-plusieurs-hebergements-chez-web4all

rapport-de-hack-sur-plusieurs-hebergements-chez-web4all

Depuis /data/vol1 ou vol2 des dossiers sont en erreur 403

/datas/vol2/xxMASKxxtgelais.com
/datas/vol2/xxMASKxxnsports.fr/

Mais pas tous , comme eux qui sont accessible :

/datas/vol2/xxMASKxxtariat.com/
/datas/vol2/xxMASKxxenceverte.com/

A voir pourquoi…

Cagefs a totalement empêché la création de l’attaque complète des serveurs

Le hackeur avait une fonction PHP pour parser /etc/passwd et créer des symlink pour hacker les autres clients

lrwxrwxrwx  1 w4axxxxxx w4axxxxxx 41 27 janv. 11:46 w4axxxxxx .. wp-config.php -> /home/w4axxxxxx /public_html/wp-config.php
lrwxrwxrwx  1 w4axxxxxx w4axxxxxx 45 27 janv. 11:46 w4axxxxxx .. configuration.php -> /home/w4axxxxxx /public_html/configuration.php
lrwxrwxrwx  1 w4axxxxxx w4axxxxxx 43 27 janv. 11:46 w4axxxxxx .. conf_global.php -> /home/w4axxxxxx /public_html/conf_global.php
lrwxrwxrwx  1 w4axxxxxx w4axxxxxx 38 27 janv. 11:46 w4axxxxxx .. config.php -> /home/w4axxxxxx /public_html/config.php
lrwxrwxrwx  1 w4axxxxxx w4axxxxxx 40 27 janv. 11:46 w4axxxxxx .. Settings.php -> /home/w4axxxxxx /public_html/Settings.php

En image :

rapport-de-hack-sur-plusieurs-hebergements-chez-web4all

 Le fichier sql.php du hackeur contient un « phpmyadmin fait maison »

rapport-de-hack-sur-plusieurs-hebergements-chez-web4all

EN DATE DU 30-01-2014

Ci-dessous les logs des sites compromis et/ou des fichiers visités par le hackeur (tout confondu, voir plus bas par extensions)

345 lignes retirées du rapport public.

Actions du côté de Web4all

  • Communication ou pas ? -> effectuée le 06.02.2014 sur le blog
  • Prévenir les clients concernés a minima –> effectué le 01 et 02 février 2014 via le système de tickets
  • S’assurer que le hackeur n’a pas pu avoir accès a des fichiers contenant des mots de passe chez nous, car il a exploré de anciens fichier de web4all –> aucun fichiers préoccupant (les sites de l’association étant sur une infrastructure à part, les fichiers présent ici sont ceux générés par défaut par le manager)
  • Vérifier nos droits sur les fichiers -> correction effectué (voir au dessus l’explication de la faille Securelinks)
  • Effectuer un dépôt de plainte ? En cours de discussions, IP hors de France… peu de chance que cela ait une utilité
Whois IP
Status
ALLOCATED
Contact Email
Registrant
DySetif
ALGERIA
Administrative Contact
Security Departement
Alger
Telephone: 21321911224
Fax: 21321911208
Email:
Technical Contact
Security Departement
Alger
Telephone: 21321911224
Fax: 21321911208
Email:
197.205.98.166 is the IP address you have a ran a report for on January, 31, 2014.