Faux site Megaupload

Avant de faire un billet plus approfondi sur le dossier Megaupload, un petit billet d’alerte sur une campagne de manipulation en cours sur les réseaux sociaux. Une adresse IP est diffusée depuis le soir même de la fermeture de Megaupload en promettant le retour du site, avec des messages du genre:

si on remonte quelques heures plus tôt dans la recherche sur Twitter on trouvait d’ailleurs le 18 janvier un autre usage de cet IP: la diffusion d’informations sur la façon de regarder gratuitement sur Internet le match Real Madrid – FC Barcelone:

Dès que cette IP a commencé à circulé j’ai senti qu’il y avait certainement un piège là-derrière, tout simplement parce qu’on ne relance pas un service comme Megaupload derrière une simple adresse IP, étant donnée l’infrastructure complexe qu’il faut pour accepter des millions de visiteurs par jour.

Mon tweet de vendredi matin ...

Cela s’est confirmé un peu plus tard avec différents blogs qui soulignent les incohérences (cf sur le blog reflets.info). Dès hier, PC Inpact a obtenu une confirmation “officielle” (sur cette brève).

Pourquoi une adresse IP ?

En fait ce site est aussi accessible par un nom de domaine trompeur: megavideo.bz (comme on peut le lire sur ce site en langue espagnole), mais il aurait été rapidement filtré par Twitter et d’autres formes de filtres. En effet, lorsque vous postez une URL dans Twitter, elle est automatiquement remplacée par un service de redirection de Twitter (http://t.co/) qui leur permet de repérer et de bloquer les URL dangereuses (j’en parlais au mois de juillet ici-même).

Et il semble donc que, malheureusement, le filtre mis en place par Twitter ne fonctionne pas encore pour les adresses IP.

Conclusion

La version accessible aujourd’hui est tristounette:

Et pour cause, la première version de la page se contentait d’être un copier-coller du site original avec dans le code des liens vers les images et les scripts CSS (qui régissent la présentation) hébergés sur www-static.megaupload.com … qui depuis a été débranché, vraisemblablement dans le cadre de l’enquête en cours. On note au passage les liens Facebook et Twitter qui incitent  rediffuser l’adresse et le message larmoyant qui avertit sur les risque de hameçonnage… (oui à quoi peut servir une telle audience ?).

La bonne résolution du jour que je vous recommande est donc: je ne retwitterai pas l’adresse IP du nouveau site de Megaupload (qui n’en est pas un).

Guidé uniquement par ma curiosité je décide de suivre le lien qui m’amène sur une page http://mspaworldwide.net/twitter/ qui ressemble en tous points à la page d’accueil de Twitter:

Un petit regard au code source finit de me convaincre qu’il s’agit bien d’un phishing:

et … si l’on remplit le petit formulaire de connexion on est finalement redirigé sans encombre sur la vraie page de twitter (qui, si on est déjà connectés, affiche de toutes façons la liste des publications de nos contacts). Rien de très “high-tech” donc.

Je suis déjà surpris que de nombreuses heures après le début de cette campagne de phishing mon navigateur n’affiche pas une alerte (testé sous Chrome, Firefox, Internet Explorer, à cette heure – 12:07 – seul ce dernier affiche une alerte). Au passage toujours, Twitter utilise http://t.co/ pour relayer ce lien (quand on clique dessus en réalité on passe par http://t.co/2acFQb3 avant d’être redirigé vers le lien original en tinyurl) qui est un domaine censé permettre à Twitter de lutter contre ce genre de problèmes:

Apparemment leur système n’a pas encore détecté le problème… Les pages d’aide de Twitter nous indiquent qu’on peut signaler les abus de http://t.co/ en envoyant un message à tcoabuse@twitter.com, ce que je viens de faire évidemment.

Je ne sais pas si mon contact a laissé accès à son compte à une application mal intentionnée ou a succombé à la tentative de phishing elle-même… dans l’un et l’autre cas l’ensemble de ses contacts ont donc pu recevoir un message direct les invitant à visiter cette page. (15:27: La victime me confirme que c’est passé par le site de phishing lui-même, pas d’application en cause).

Si vous-même êtes tombés dans le panneau, pas trop d’inquiétude et suivez les indications du support de Twitter pour changer votre mot de passe. Je vous conseille de supprimer aussi les messages directs qui doivent apparaître dans votre compte à destination de vos amis (même si les courriers électroniques d’alerte sont sûrement déjà partis…).

Je ne suis pas le premier à parler de ça, bien évidemment (comme ici par exemple et @gcluley en parlait au début du mois de juillet dans un de ses articles, ou encore (17:18) @5ct34m il y a quelques jours qui notait qu’on retrouvait la même IP derrière une URL différente).

Epilogue concernant le site de phishing lui-même (14:19): il est hébergé en Chine. En outre, l’adresse IP hébergeant le site Web de Phishing est 220.164.140.252, qui renvoie, à l’heure où j’écris ces lignes (17:25) à des noms de domaine aux noms intéressants comme iltwitter.com, itiwitter.com ou ltwitteri.com entre autres (voir l’image agrandie pour en apercevoir la liste):

Je pense que seul Twitter peut nous en dire plus sur quelles adresses IP se connectent sur les comptes des victimes. Les infractions que l’on pourrait viser pour cette affaire sont essentiellement celles de collecte déloyale de données à caractère personnel, accès frauduleux à un système de traitement automatisé de données et peut-être le détournement de correspondances privées (les scammers envoient des messages, mais en théorie ils peuvent aussi consulter les autres messages).

Mise à jour (14:51): Chrome n’annonçant toujours pas la page comme du phishing, j’essaie de trouver la fonction qui permet de le signaler. Alors:

• Ouvrir le menu en cliquant sur la petite clé à molette ;
• Outils > Signaler un problème… et ensuite on suit le guide !

Sous Internet Explorer, même principe que sous Chrome:

• Affichage du menu 
• Sécurité… Signaler un site Web d’hameçonnage.

Le fonctionnement est similaire et derrière l’URL http://mspaworldwide.net/app1/function.api.stalktrak.htm vous avez donc un formulaire qui vous invite à nouveau à rentrer votre identifiant et votre mot de passe Twitter, avec un aspect graphique qui ressemble à celui de Twitter.

Ceux qui se sont fait avoir se retrouvent apparemment à faire la publicité de l’application. Topsy nous donne une petite idée du trafic autour de ce site depuis quelques jours (cliquer sur l’image pour l’agrandir):

On note ainsi un pic le 29 juillet, avec un début de propagation le 27.

Stalktrak lui-même (ce qui semble confirmer ce que je rappelais un peu plus haut sur l’adresse IP du serveur suite à une indication de @5ct34m), tourne aussi au moins depuis le début du mois de juillet comme on peut le lire sur cet article de blog (avec une petite vidéo dedans) et où l’on retrouve un des noms de domaine évoqués précédemment.

05 août: Apparemment un nouveau domaine est apparu depuis hier qui délivre les mêmes contenus illégaux : 3xloanstoday.com. Évitez de vous y rendre et signalez le comme site de phishing.

Cliquer sur l'image pour aller vers l'article

Beaucoup de spécialistes ont rapidement souligné que cette vulnérabilité ne devrait pas avoir d’application facile dans la vie réelle. Malheureusement il semble qu’il faille effectivement la prendre au sérieux. En effet, Anıl Kurmuş, jeune chercheur en sécurité Suisse, a rendu public une démonstration (il l’annonçait mercredi 11 novembre sur Full Disclosure) de la possibilité d’exploiter cette attaque sur Twitter.

Le principe sous-jacent est assez simple puisqu’il repose sur la fonctionnalité même de Twitter qui vise à laisser l’utilisateur publier n’importe quoi. Il a suffi à Anıl Kurmuş de détourner l’API (interface de programmation) de Twitter pour publier en lieu et place du message une partie du cookie, qui contient systématiquement le mot de passe codé, dans le cas de Twitter:

Démonstration d'Anil Kurnus

Il ne reste plus qu’à décoder l’identification qui est ici transmise en Base 64 (ou à la réutiliser telle qu’elle !). Twitter aurait depuis le 10 novembre corrigé la faille. On peut suivre l’évolution des publications des mises à jour des applications concernées par la faille de re-négociation SSL/TLS sur le site de Phonefactor, pour l’instant une version mise à jour d’OpenSSL 0.9.8l bloque déjà la fonction de re-négociation, en attendant un correctif plus pointu.

(Plus d’informations ici)

Cela confirmerait les inquiétudes sur la résistance de telles plateformes à des attaques de grande ampleur.

Image du blog de Cyxymu

Les vacances sont finies pour moi ou presque, l’actualité n’a pas été particulièrement active. J’ai continué d’alimenter la liste de signets que vous voyez dans la colonne de gauche du présent blog (sous le titre : “Mes derniers bookmarks”).

Un “événement” a fait la une de l’actualité, y compris dans les principaux journaux français (Le Monde par exemple et plus ici), à savoir l’attaque dont Twitter et Facebook ont été victimes. Je suis presque contraint de l’évoquer, tout en soulignant que des attaques en déni de service sont quotidiennes sur Internet, mais ce n’est pas réellement là le sujet.

Une attaque en déni de service distribué (plus d’explications sur Wikipédia), tout d’abord, consiste à empêcher l’accès des usagers légitimes d’un service sur Internet (donc par exemple un site Web tel que Twitter ou Facebook, ou votre blog personnel) en initiant des connexions multiples depuis plusieurs endroits sur Internet (d’où la notion de distribution).

Ce type d’attaque a été rendu célèbre par les événements survenus en Géorgie l’année dernière, où des attaques coordonnées contre les sites Web gouvernementaux ont accompagné les tensions militaires avec la Russie du mois d’août 2008. C’est donc assez logiquement qu’une explication politique a été trouvée à cette attaque contre Twitter et Facebook. En effet, l’hypothèse d’un attaque ciblant Cyxymu, un abonné Géorgien de Twitter et Facebook et s’exprimant pour l’indépendance la défense d’intérêts liés à la situation de l’Abkhazie s’est très rapidement propagée.

Évidemment, l’utilisation croissante de ces sites par des personnalités du monde politique n’est pas pour rien dans cette médiatisation de l’incident. Et la politique est souvent évoquée dans le cas d’attaques rendues publiques au cours des trois dernières années. La torpeur de l’été y est sans doute aussi pour quelque chose et cela montre aussi l’intérêt des médias pour ces nouvelles formes de communication et de diffusion de l’information.

La réalité des attaques en déni de service est qu’elles sont quotidiennes sur Internet. Les botnets, par exemple, que j’ai évoqués à plusieurs reprises ici, permettent ce genre d’attaques. Ces types de services sont même commercialisés par des groupes criminels pour quelques dizaines ou centaines de dollars, vantant la possibilité d’empêcher le fonctionnement du site Web de son concurrent. Certains (comme Max Kelly, directeur de la sécurité chez Facebook, répondant ici à CNet News), ont émis l’hypothèse que cette attaque particulière aurait été rendue possible grâce à la diffusion de spams supposément émis par Cyxymu et conduisant des milliers d’usagers à se connecter en même temps sur son “tweet” (blog de Cyxymu).

L’explication est-elle convaincante ? L’information sur la coïncidence entre le spam visant Cyxymu et les incidences sur Twitter et Facebook est perturbante, parce qu’elle vise encore la Russie ou plutôt des citoyens Russes, mais sa source est intéressante : Max Kelly a certainement accès aux journaux des serveurs Web de sa société (Facebook) et donc à l’origine des clics qui ont conduit à cet incident, où en tous cas d’une partie d’entre eux.

Cette affaire mérite-t-elle un tel intérêt ? Oui, au sens où la défaillance pendant plusieurs heures d’un site Web aussi utilisé (et utile selon les points de vue) que Twitter en tant que telle est un événement. Les protections contre les attaques en déni de service ne sont pas facile à mettre en œuvre et supposent souvent d’installer des infrastructures supplémentaires en amont des serveurs Web pour filtrer les requêtes problématiques. Il semblerait que dans ce cas il s’agissait – au moins partiellement – de connexions légitimes provenant d’internautes réels utilisant leur propre navigateur : il paraît difficile d’imaginer de filtrer de telles connexions (il faudrait filtrer au niveau applicatif, à savoir sur la base du contenu de la requête lui-même – l’adresse de la page demandée – qui est quasiment le même pour tous les clics).

En tous cas, il sera essentiel que des dispositifs plus efficaces soient inventés pour lutter contre les attaques en déni de service, notamment dans le cas de serveurs utilisés par autant d’internautes dans le monde. Le “cloud computing”, c’est-à-dire le développement de technologies qui permettent de stocker toutes ses données dans des serveurs accessibles et exploitables de partout sur Internet n’est pas viable à long terme dans de telles conditions (on voit combien les incidents dont souffrent parfois les plateformes de Google fait douter ses usagers).

PS: Information incidente révélée aujourd’hui par Jose Nazario de chez Arbor Networks (origine ici). Celui-ci a découvert pendant des investigations sur cette affaire d’attaque en déni de service contre Twitter, que des comptes Twitter sont utilisés par des criminels Brésiliens comme outil pour diffuser les commandes à destination d’un botnet, dont la fonction est vraisemblablement la collecte illégale de données personnelles.