On a beau ne pas être fan du bonhomme, il faut quand même lui accorder qu’il a le sens du suspens et du rebondissement. Depuis la fermeture de Megaupload, Kim Dot Com n’avait de cesse d’expliquer qu’il reviendrait avec mieux, plus gros, plus fort. C’est donc aujourd’hui que Mega, son nouveau site devrait ouvrir ses portes. J’ai donc voulu aller jeter un oeil à la plomberie du nouveau site de l’ami Kim.
A ma première tentative de connexion au frontal http://mega.co.nz/, il semble que le DNS en mange déjà plein la tête, et une redirection me téléporte sur kim.com/mega avec un joli message m’expliquant l’embouteillage :
Peu importe, nous y accèderons par l’IP : http://94.242.253.38/
Première surprise, l’hébergeur est un illustre inconnu : as5577 et voici ses informations de peering.
Le frontal semble être un apache et petite subtilité… il est en debug !
Et voici ce que nous raconte le Nmap :
Un apache en debug, un MySQL… c’est quand même un peu étrange pour un site qui est sensé encaisser des millions de requêtes dans quelques minutes… mais bon, pourquoi pas après tout ? Alors bluff ou pas bluff ton Mega, Kim ?
Update : le host et le dig sont assez intéressants également :
Update 2, cette fois nous y sommes Mega est ouvert, et la véritable infrastructure se dévoile, on est niveau AName sur une architecture similaire à celle de Megaupload :
Update 3 : Le lancement semble être un succès, les premiers chiffres devraient le confirmer rapidement. En parcourant un peu le code source on tombe sur le CDN qui sert les fichiers statics, ces derniers semble être servis par Cogent. Gageons que ceci va faire super plaisir à Orange et que la guerre du transit qui a opposé les deux entreprises va surement s’étendre à d’autres fournisseurs d’accès Internet français.
A la racine du static files server, circulez, il n’y a rien à voir :
Mes premiers tests d’upload… merdiques, je n’ai jamais réussi à finir l’upload d’un binaire d’openoffice, l’upload s’est tout simplement bloqué, et la crête d’upload a du avoisiner les… 6,4ko (Mega a peut-être été victime de son succès, mais c’est franchement pas top) :
J’ai tenté ensuite une inscription comme ça pour le fun après avoir lu un article de Gizmodo qui nous explique que Méga fait dans la Méga sécurité… mouais bof, utiliser les mouvements de souris pour ajouter de l’entropie lors d’une génération de clé, ça n’a rien d’une nouveauté, c’est comme ça que procèdent déjà de nombreux logiciels « sérieux ».
En tout cas, Kim l’a bien vendu en appelant ça de la crypto contrôlée par l’utilisateur. Je n’y vois personnellement pas de procédé révolutionnaire mais la presse devrait se laisser embobiner assez facilement, les 3 mots ensemble claquent pas mal.
Update 4 : La crypto coté user c’est un concept plutôt sympa, mais voilà quand on sert la secu de son paquet de javascript avec une clé 1024 bits, on parait tout de suite un peu moins blindé, c’est ce que relève @DrWHax (thx @koolfy).
On commence à voir fleurir une multitude d’âneries sur le supposé blindage de Mega, une analyse un peu plus fine de l’infra et des petites horreurs en Javascript qui traitent un peu trop de logique pour que ce soit si blindé que ça, devraient vite révéler les faiblesses de Mega. Si vous comptez utiliser Mega « professionnellement », pour le moment, réfléchissez y à deux fois.
Un XSS a même déjà été trouvé.
Le XSS peut conduire à un vol de la clé RSA privée puisque cette dernière utilise LocalStorage, ce qui est bien… mais franchement pas top.
De multiples grossières erreurs peuvent avoir un impact important sur la sécurité globale des utilisateurs de Mega et pour le moment, le « blindage » du site reste à démontrer, mais une chose est sûre… peut mieux faire.
Update 5 : Bon ça commence à être la fête du slip, un nouveau scan met en évidence d’autres ports ouverts sur le front en 166 (errata le 7070 et le 554 sont probablement de faux positifs):
Update 6 : Niveau accessibilité c’est pas non plus trop ça, en fait c’est même à se demander qui y accède :
Update 7 : il y aurait bien un souci concernant le mécanisme de génération des clés de chiffrement, assuré par un fichier javascript. En fait Mega semble utiliser assez peu de différents paramètres pour générer ses clés. Il en découle une entropie non satisfaisante et on peut donc supposer que la séquence de prédiction des clés est faillible. @Kaepora signale aussi fort justement que Mega peut très bien désactiver le chiffrement serveur side pour un utilisateur donné sans que ce dernier en soit notifié. La crypto coté user ok mais le contrôle reste à Mega… Bref si vous avez des fichiers confidentiels, oubliez tout de suite de les coller sur Mega, ils ne sont pas en sureté.
Update 8 : les bizarreries au niveau du certificat SSL commencent. Voir le paste de l’analyse SSLyze de @fo0_ .Ce qui était valide hier ne l’est plus aujourd’hui :
Wget le met en évidence, l’émetteur est maintenant rapporté comme étant inconnu (thx @ali0une)… et c’est vrai que le choix de Comodo peut paraitre un peu curieux :
A ce jour, les discussions de l’Assemblée Nationale ont essentiellement porté sur le Peer to Peer, il est assez amusant de constater que les téléchargements directs ne pourront, eux être surveillés. C’est donc avec un outil de « hacker chinois pirate pédo zombie nazi communiste », à savoir Google, que nous allons vous démontrer, une première fois que l’HADOPI est morte comme le disco.