Papa est là !

Autant vous prévenir, si vous ne connaissez pas le fonctionnement de Twitter, vous pouvez éviter de lire ce billet... Ce warning étant écrit, je peux démarrer.

Il y a deux jours a été publié un billet en anglais sur l'excellent blog de Sucuri, qui fait partie des centaines de blogs de sécurité informatique que je lis régulièrement.

Pour résumer très rapidement, le chercheur nous indique qu'il est hébergé chez GoDaddy aux USA (l'un des plus gros ISP là-bas), qu'il n'a qu'un honeypot SSH derrière son port 22, et qu'il utilise un/des autres ports pour accéder à ses serveurs en SSH. Alors qu'il farfouillait en bon paranoïaque dans ses journaux de connexion, il découvre avec stupéfaction et horreur qu'une adresse IP inconnue a accédé à son honeypot en utilisant le véritable mot de passe qu'il utilise pour son vrai serveur SSH. Pire, deux mots de passe sont utilisés : ses deux derniers mots de passe.

Les pensées du chercheur à ce moment précis doivent être à peu près : "Panique à bord, mon dieu mon dieu on m'a rooté je suis foutu, les carottes sont /quit (elle est de moi, je la revendique celle-là!), c'est la fin du monde !" (hello au passage à ericvo)

Après quelques recherches, il se rend compte que l'adresse IP attaquante provient de chez GoDaddy, et reçoit à peu près au même moment un mail de GoDaddy l'informant que son serveur web est peut-être infecté par du malware. Et là, en toute quiétude, l'ISP lui dit que les mots de passe dont il dispose dans ses fichiers n'est plus bon et qu'il a besoin de l'accès root (administrateur) pour vérifier ça, sous peine de suspension de compte.

Plutôt inquiétant de voir que (propos de l'auteur)

  • GoDaddy a essayé d'accéder à son SSH sans lui en parler.
  • GoDaddy voulait son accès root.
  • GoDaddy disposait de ses deux derniers mots de passe en clair.

L'histoire ne se finit pas ici. Le chercheur a eu un contact par téléphone avec le CSO (Chief Security Officer) de GoDaddy, qui lui a expliqué un certain nombre de choses :

  • GoDaddy prend les problèmes de malware très au sérieux et intervient lorsque nécessaire sur les serveurs, en mode 24/7.
  • GoDaddy essaye de régler le problème en se loggant sur le serveur.
  • Les mots de passe sont stockés chez eux sous forme chiffrée. Les process internes GoDaddy font que le mot de passe ne peut être récupéré qu'après ouverture d'un ticket d'incident, motivé et écrit, uniquement par l'équipe sécurité de GoDaddy.
  • Ce mode de fonctionnement est apprécié de la plupart des clients (comprendre ceux qui n'ont pas de notion de sécurité)

Au final, pas de malware, l'activité suspecte était dûe au honeypot du chercheur, et il a pu s'expliquer et régler le problème avec GoDaddy sans avoir à communiquer son accès root. L'ISP s'est excusé, et informera ce user de toute prochaine intervention *avant* de faire quoi que ce soit.

Je n'apporterais que très peu de commentaires à propos de ce "fait divers" de sécu :

  • Il est hors de question de donner son accès root à son fournisseur
  • Il peut être bon de signaler à son hébergeur qu'on fait tourner un honeypot, pour peu de pouvoir remonter cette information aux personnes compétentes (gros doute ici quand même...)

Mais ce n'est pas la fin de l'histoire, et le plus amusant reste à venir. Car ce chercheur n'a pas été mis en contact avec un CSO tout puissant suite à un contact avec le support : il a été contacté directement par le CSO. Pourquoi ? Comment ? La réponse est présente sur Twitter.

Le lendemain, je lisais l'update sur le blog. Il est dit : "it reached the ears of the GoDaddy people".

En fait, GoDaddy, comme beaucoup d'entreprises conscientes de la nécessité de surveiller leur image, exerce une surveillance sur Twitter. Et le post blog de sucuri, qui a été largement retweeté, a été rapidement détecté par GoDaddy, qui ont décidé de contacter l'auteur du blog. Je faisais partie de ces gens qui ont retweeté l'article le jour même, et j'ai eu la surprise le lendemain de découvrir un message sur Twitter qui m'était adressé et qui venait du compte officiel Twitter de GoDaddy, je cite:

-- @cedricpernet Just FYI, the author posted an update to his blog. It clarifies a lot. We hope you'll read that too. http://fwd4.me/GxT --

Je me suis empressé de faire quelques recherches, et me suis rendu compte que l'article initial de sucuri avait été retweeté par 130 autres personnes, et que le même message que j'avais reçu avait été tweeté à ces 130 personnes.

Du beau boulot, en termes de communication. GoDaddy non seulement surveille les tweets qui parlent d'eux, mais en plus ils réagissent lorsqu'un incident d'image les impacte, et de façon plutôt pro et efficace. Les réactions ne se sont pas faites attendre sur Twitter : tout le monde a twitté le lien vers l'update, souvent avec un petit commentaire du genre "bravo GoDaddy pour la transparence" ...

Voilà un bel exemple de contre-attaque d'image basé sur un incident de sécurité informatique, ou comment renverser la vapeur et se faire mousser gratuitement sur une base initialement négative.

Chapeau bas, GoPapa ! :-)

Et enfin, je dédie ce post blog à un ami très GUMOristique, sans qui ma vie professionnelle ne serait pas ce qu'elle est :-p

Comments

1. On 2010-02-26, 14:53 by meik

Lors de l'installation d'un serveur Kimsufi (OVH, je sais pas si c'est pareil dans leurs autres offres), il y a la clé publique SSH d'OVH dans /root/.ssh/authorized_keys pour leur permettre de se logguer :-) (bon, en théorie c'est à la demande du client que ça se passe)

2. On 2010-03-05, 18:16 by neosolo

Merci pour ce post très intéressant Cédric.

3. On 2010-03-27, 09:53 by th0m

Salut, Perso je travaille chez un hébergeur. Normalement nous ne conservons les mots de passe (ou clé ...) que si la machine est infogérée par nos services.

Malheureusement trop de clients ne respectent pas les conditions d'utilisations ou le contrat d'hébergement (oui il y en a !)pour envisager de ne jamais conserver les mots de passe root/admin. Si les contrats étaient appliqués à la lettre nous devrions systématiquement couper le port du switch et fournir un accès console au client afin qu'il corrige avant que le port ne soit remonté. Par courtoisie (oui il faut le voir comme ça) ou par efficacité nous intervenons rapidement sur le serveur afin de corriger le problème sans interrompre le service final (mail/web/etc..).

Je ne suis donc pas surpris que son fournisseur ai utilisé le compte root particulièrement si la machine présentait des une activité anormale (?) ou une vuln particulièrement scannée en ce moment.

Des personnes compétentes peuvent interpréter ces actions comme intrusives mais généralement une fois bien expliqué les gens sont plutôt content que le client final n'ai pas eu de coupure.

A+
Thomas