Mot-clé - incident

Fil des billets - Fil des commentaires

mardi 11 mars 2014

Incidents de sécurité : qui sont les « responders » ?

Une interview de votre serviteur vient d'être publiée, à propos des "incident handlers" ou "incident responders" ... Ca se passe ici, et merci à Jérôme Saiz :-)

vendredi 26 février 2010

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

lundi 7 septembre 2009

0wn3d...Or not !

Recently I attended the SANS GCIH (GIAC Certified Incident Handler) courses in London. I don't want to make too much advertise for it, it is not the goal of this post but anyway, it's a great course and I had a great time there.

Of course, when you're in a room full of other people learning about compromising computers, you expect strange things to happen on the wireless network.

And something strange happened to me during the second day of the course : my computer couldn't connect anymore to the network. I tried to figure out what was happening but couldn't find any problem.

The machine was an XP SP3, fully patched. I'm not using Windows usually (except at work), but it was better for the course. Anyway, I switched to an Ubuntu and had the same trouble : no connection.

Since it was the end of the day, I got back to my hotel and came back early the next morning, to try to fix the problem. I talked about it with someone from the SANS staff, Tomasz, and he told me he had noticed a strange behaviour from one machine, which was sending a hell of a weird trafic, almost taking all the bandwidth. The machine had quickly been blacklisted on the wireless network, according to its MAC address. And guess what ? The MAC address was my wifi card's one.

Well of course, as an incident handler, I immediately thought : hell, I've been compromised. After telling the SANS dudes I had not been running anything special on my machine and not knowing what was up, we decided to have a look at the trafic sent by my machine. It was sending packets on the network like crazy, but there were only two kind of packets : "BROWSER Election Requests", and "Local Master Announcement" ...

Screenshot.jpg

This was definitely not the behaviour of a malicious attacker or malware. For a moment I thought it was a hardware problem with my network card, but under Ubuntu there was no such behaviour.

Anyway, I ended the GCIH course using my Ubuntu, with an XP under VirtualBox.

I left the course on the saturday afternoon, after the capture the flag event (which was really great btw), but I told Tomasz that I would keep in touch, and would investigate the machine later on.

I didn't touch the machine for some weeks (you know this feeling, when you've always got something else to do and can't fight it...) and then I decided I would look at it quickly : I made a full dd of the Windows partition, and decided not to follow the usual forensics rules and just boot the machine. After all, it was mine, and I had a dd in case I would have time to do real forensics on it.

Together with my friend David Bizeul, who was interested in the case, I had put the machine on a hub with another machine, running a network sniffer. The results were the same than before : the machine started to send these crazy packets again, eating a good 25% of the bandwidth I had (10M).

A quick jump in command line, to see more about the activity, immediately proved something was definitely wrong :

1-1.png

All of my UDP ports (except the 256 first ones) were opened, by a unique process.

Now what was the process exactly ? Look here :

2.png

My machine was not infected by a malware. It was not compromised. You guessed it right, it was just an incompatibility problem between VMware Player and my hardware,which is from an Asus 1000H (eeepc).

The version I was using :

3.png

End of the story... I still wanted to blog about it because it could happen to a lot of other people using the same hardware, and to give a clear answer to my SANS friends about this machine, which had been a curiosity... I'm taking this occasion to say hi to the great people from the SANS : Tomasz Miklas, Terry Neal, Pieter Danhieux... And hi to Ben, and all the nice people I met in London :-)

See ya ! :-)