Le retour du #Mega merdier de Kim

C’est donc pil poil un an après le takedown de Megaupload par une opération du FBI que Kim Dotcom vient de lancer Mega. Accessible sur l’url https://mega.co.nz, le site a comme on s’en doutait, rencontré un afflux massif de connexions provoquant des indisponibilités temporaires et surtout des performances d’upload ridicules dues à un uplink très vite saturé. La presse, qui était conviée à une preview du site avant son lancement officiel n’a pas tari d’éloges, le site a été bien accueilli, Gizmodo a même mis en avant le pseudo blindage du site.  Mais voilà, et c’est une habitude avec Kim, il y a aussi une large part d’esbroufe, notamment en matière de sécurité.

Capture d’écran 2013-01-20 à 11.36.01

Kim Dotcom met en avant un mécanisme de chiffrement contrôlé par l’utilisateur, nous allons voir que ceci n’est que partiellement vrai. Plus gênant, plusieurs vulnérabilités de type XSS, qui couplée à la méthode LocalStorage pouvaient conduire à la compromissions des clés RSA privées des utilisateurs. Ceci a été corrigé dans l’heure par les équipes techniques de Mega.

ssl

Plus gênant maintenant. Le mécanisme de chiffrement des utilisateurs peut être désactivé unilatéralement pour un utilisateur par Mega, sans que l’utilisateur n’en soit notifié. Ceci pose un très sérieux problème de confiance. En clair, si vous comptez utiliser ce service professionnellement, c’est une très, très, très mauvaise idée d’y envoyer des fichiers confidentiels.

Mais ce n’est pas tout, comme mentionné plus haut la presse n’a pas hésité à chanter les louanges d’un mécanisme vieux de 10 ans : l’ajout d’un paramètre collectant des données de mouvements de souris pour ajouter de l’entropie à la séquence de génération des clés. Le fichier javascript décrivant le mécanisme cryptographique est d’ailleurs assez effrayant. Nous avons au final assez peu de paramètres pour une génération aléatoire sérieuse des clés privées RSA, on en déduit que la séquence de prédiction de génération de ces clés est cassable.

Le certificat SSL de Mega pose lui aussi depuis ce matin problème(update : ça vient d’être fixé), et quand on regarde qui en est l’émetteur… surprise ! Il s’agit de COMODO, un tiers de confiance qui s’est fait trouer l’année dernière… ça fait au bas mot un peu cheap :

Capture d’écran 2013-01-20 à 10.28.21

Si ce petit désagrément n’est en soi pas une menace directe sérieuse, il y a quelque chose de bien plus embarrassant. Notre petit fichier javascript décrivant le mécanisme de chiffrement nous indique que le certificat static.mega est en 1024 bits… ce qui apparait comme faible.

La petite visite.

Thx @Kaepora@DrWHax @koolfy.

Twitter Facebook Google Plus email

23 thoughts on “Le retour du #Mega merdier de Kim”

  1. Ce qui m’apparait comme faible, c’est surtout le fait de (à nouveau) confier des données à des boites privées, avec du chiffrement à la va-vite, sans peer-reviewing, avec du code propriétaire …

    La seule bonne manière d’inspirer confiance aujourd’hui reste le code libre, et les infrastructures et méthodes transparentes. Sans cela, aucune confiance possible ;)

  2. « Notre petit fichier javascript décrivant le mécanisme de chiffrement nous indique que le certificat static.mega est en 1024 bits… ce qui apparait comme faible. »

    C’est un choix qui semble volontaire.

    https://mega.co.nz/#developers

    « MEGA HTTPS access uses RC4-MD5 (which minimizes CPU load without sacrificing security) with 2048 bit RSA where security is relevant and 1024 bit RSA where it is not. »

  3. Le chiffrement n’est-il pas contre l’esprit du « Cloud » avec un grand C ?

    Après tout, les services comme HubiC qui proposent un espace « illimité » ne sont viables que si l’ensemble des utilisateurs stockent les mêmes données (divX, mp3, pr0n….). OVH se réserve d’ailleurs le droit de clore tout compte qui ne lui conviendrait pas (celui du petit malin qui uploade 500Go de données aléatoires par exemple).

    Pour optimiser la taille des stockages (via le hash md5+taille du fichier comme du temps de de Megaupload), il est intéressant d’utiliser des clés non aléatoires. Il est tout à fait possible de resservir les fichiers à l’utilisateur avec un chiffrement fantoche.

  4. Il est en effet déplorable de voire autant de failles dans un service cloud, qui a pourtant été annoncé comme « ultra sécurisé ». Mais je penses que l’une des principales raisons à ces pannes, est sans doute le fait que le site à été surement codé à la vas-vite. À noté aussi que le site est encore en béta (ce qui n’excuse pas le xss et autre faille de « débutant »).

  5. Vous passez peut être aussi à coté des sous-titres. Ultra sécurisé contre les ayants droits. Le coté sécurité semble plus là pour leur éviter les poursuites à cause de contrainte technique qu’ils ont eux même mis en place.

    Pour la partie sécurité informatique, comme tout produit tout fraîchement sortie des boites, il faut laisser le temps qu’il se sécurise. Vue la réactivité à boucher les trous de sécurité, on voit qu’ils sont présent, c’est assez rassurant.

    1. Oui, c’est clair que le but est de protégé Kim dotcon et uniquement lui…

      Mais on est face à un beau discours marketing visant à couillonner des milliers de gens en leur faisant croire à une sécurité sans faille…

      Quand à la « réactivité » encore heureux… on est face à des failles de débutant… et ça c’est assez inquiétant…

  6. Merci pour l’article, mais pourquoi toujours cette manie d’utiliser des anglicismes ? Takedown, update, upload, preview, cheap. Tous ces mots ont leur équivalent en français.

    Je sais, ça fait un peu nazi de l’orthographe, mais je trouve cela extrêmement paresseux, voire même snob, de finir par parler un charabia franglisch qui nuit à la lisibilité.

    Ou alors, autant tout écrire en anglais.

  7. >Ceci pose un très sérieux problème de confiance.

    J’espère que c’est un thème pour GTK, parce que sinon, venant de la part d’un utilisateur d’un OS propriétaire, ce genre de réflexion me font doucement sourire…

  8. – « Nous avons au final assez peu de paramètres pour une génération aléatoire sérieuse des clés privées RSA, on en déduit que la séquence de prédiction de génération de ces clés est cassable »

    Je ne comprends pas ce que veut dire une « séquence de prédiction de génération de clé ». Mais je suppose que la phrase signifie que l’algorithme utilisé par Mega génère des clés d’une manière prévisible. Si c’est ça, il s’agit quand même d’une affirmation gratuite, il manque la preuve.

Laisser un commentaire

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