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.

 

aurelien.poncini

Conseil d'Administration

5 réponses à “Rapport de hack sur plusieurs hébergements chez Web4all

  1. Hello,

    Merci beaucoup pour ce rapport de hack complet !
    Autant dire que la communication devient rare de nos jours.

    As-tu des recommendations à faire sur ce genre d’attaque ?

    ++

    1. Bonjour Djerfy !

      Les recommandations que l’on peut faire sont assez simples 🙂

      Je pense que la première chose et de garder à l’esprit que dans chaque système et chaque infrastructure il y a des risques.
      Des risques d’attaque venant de l’extérieur, mais aussi et très souvent des attaques provenant de l’intérieur.

      La seconde chose est de se dire qu’en ce moment, il y a des attaques ou des hacks en cours et qu’il faut simplement les trouver !

      Dans notre cas précis, nous avons fait le chois d’utiliser des système sous @Cloudlinux . Ce n’est pas un produit magique qui fait partir les méchants pirates ^^ Mais les fonctionnalités d’isolation des processus par utilisateur est l’une des choses que nous souhaitions avoir pour éviter les risques d’attaques d’un utilisateur à un autre.

      Si tu as un système qui peut contenir des failles, si tu as des utilisateurs qui veulent trouver et jouer avec ces failles , il faut faire le maximum pour limiter la portée de leurs actions.
      Connaitre ses points faible et porter une grande attention sur ce qui ce passer sur son environnement et certainement la meilleure des stratégies.

      Ensuite, bien entendu il y à beaucoup de choses possibles et imaginables à mettre en place pour être aider dans cette lutte quotidienne 🙂

      Comme toujours en informatique et dans beaucoup d’autres domaines, il manque encore beaucoup de communications informatives à destination des utilisateurs pour prendre conscience des risques liés à la découverte de failles sur une application ou un système. Mais ceci n’est pas simple !

      Je ne sais pas si beaucoup d’hébergeur communiquent sur leur « tracas » quotidien liés aux attaques mais c’est loin d’être une partie de plaisir et c’est un domaine ou il y à beaucoup de gens motivés!

      Ce derniers temps on parle beaucoup d’attaques sur des grosses entreprises (Françaises incluent) mais si nous en entendons parler c’est que l’impact est conséquent..

      Un travail en collaboration entre hébergeur serait intéressant pour minimiser la réussite des attaques.

      ++

  2. Bonjour

    Je suis la personne en charge du site ou le hacker s’était caché … Enfin en charge est un bien grand mot : disons que j’ai hébergé ce site chez vous, que j’ai expliqué aux personnes chargées du site comment se servir de Joomla, et les aident quand ils m’appellent.

    Tout d’abord je vous sais gré d’avoir modifié le screen présenté.

    Le site n’ayant pas été défacé, je n’ai rien vu venir.
    Je me sens responsable de ce qui s’est passé et de la perte de temps qu’ont subi quelques un de vos adhérents :

    ->version de joomla pas à jour
    ->des chmod mal définis
    ->ftp au lieu de ssh
    ->pas de vérification régulière d’éventuel nouveau fichier

    Je pensais que pour un petit site sans réels données confidentielles (sauf les mdp), cela n’avait pas beaucoup d’importance.

    Je serai plus consciencieux à l’avenir, et même « si le temps, c’est de l’argent », j’expliquerai à mes interlocuteurs que mises à jour, définitions des droits, vérification régulière etc … c’est important et ça peut éviter de perdre plus de temps encore par la suite et d’en faire perdre aux autres.

  3. Bonjour,

    Merci PESTAK pour ton implication et à tes actions pour la correction de la faille.

    Même s’il s’agit d’un petit site, cela reste une porte possible pour un hacker qui je pense son but était de s’introduire dans le système et non être limité au site.

    Je recommande effectivement de mettre à jour son CMS ( ici Joomla ) dès qu’une mise à jour est possible. Surtout en ce qui concerne les plugins ( 70% des failles ). Sinon faite un environnement de test pour corriger avant de le mettre en ligne 🙂

    Je déconseille très fortement le FTP et recommande l’utilisation du SFTP ( attention pas le FTPS ) ou le SSH.
    Utilisez des clés SSH si possible.

    @Benoit: l’avantage du PHP-FPM est qu’il est possible de lui définir un user/group sur son pool ( donc un pool par site ). N’y a t-il pas un problème de chmod sur le dossier racine du site ? Pourquoi un autre site peut retourner dans d’autres dossiers ?

    Note: PESTAK, tu n’est pas du sud-ouest ? ( mesure de sécurité je ne détails pas plus )

    Cordialement,
    Djerfy

Laisser un commentaire

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