Gravatar couramment utilisé Blog perso de Paul Da Silva

Pourquoi je ne crois pas au vol des mots de passe de Skyrock

Posted on | mai 25, 2010 | 17 Comments

Ou pourquoi sont-ils complètement incompétents ?

Vous n’avez pas pu passer à côté de ce fait d’actualité : Skyrock, par le biais de la plateforme Waka mise en place en partenariat avec le gouvernement pour en apprendre un peu sur les jeunes kikoulol qui peuplent le site, a subit une attaque informatique qui aurait résulté en un vol de données confidentielles parmi lesquelles les informations de connexion de 32 millions de comptes – mots de passe non chiffrés…

Outre le fait que stocker des mots de passe en clair soit une ineptie j’ai envie de soulever un autre point qui m’a un peu chatouillé quand j’ai entendu parler de l’affaire : la quantité des données volées.

En effet on parle là de 32 millions d’enregistrements dans une base de données… Ce qui représente, malgré le fait qu’il ne s’agisse que de texte, un fichier d’une taille assez raisonnable !

Je me suis donc livré à une série de petits calculs en me basant sur le formulaire d’inscription de skyrock pour estimer la taille du fichier que le pirate aurait réussi à sortir au nez et la barbe de la deuxième plateforme communautaire francophone (la première étant facebook).

En se basant sur le formulaire d’inscription du site on peut estimer la taille minimale d’un enregistrement. Pour ce faire je suis en considérant les choses suivantes : bases encodées en ANSI et tous les champs remplis par leur valeur la plus courte possible.

En assumant que le pirate n’ai récupéré que les données sensibles que sont le login, le mot de passe et l’adresse email (utile pour revendre ou pour se connecter à des sites sur lesquels l’email fait office de mot de passe) on part sur une base composée par une entrée de ce type :

012,012345,[email protected],

Soit, avec le retour à la ligne final un total de 21 octets en ANSI. Ce qui fait, si l’on multiplie par les 32 millions de comptes un dump total de 640Mo…

Mais poussons le vice un peu plus loin : considérons des enregistrements de taille plus raisonnables : un login de 5 caractères, un mot de passe de 8 et un email d’une taille un peu plus répandue :

01234,0123457,[email protected],

Soit, encore une fois avec un retour à la ligne final un total de 32 octets toujours en ANSI. En multipliant par les 32 millions de comptes on arrive cette fois à un fichier de près d’un gigaoctet.

Toujours plus fort, supposons que le pirate n’ai pas pris la peine de trier les informations et qu’il ai carrément dumpé la table des utilisateurs. En se basant sur le formulaire d’inscription on arrive à un schéma de données qui doit ressembler à ceci :

pseudo : varchar(3, 24),
email : text(7, ?),
mdp : varchar(6, 16),
langue:varchar(5),
sexe:tinyint(1),
prenom:varchar(0, 100),
nom:varchar(0,100),
date_naissance:date,
pays:varchar(2),
code_postal:varchar(1, 16),
tel_mobile:text(0, ?),
pub_mail:tinyint(1),
pub_tel:tinyint(1),
allow_search:tinyint(1)

Ce qui veut dire, qu’à minima, en considérant que tous les champs de tous les enregistrements sont remplis à leur minimum par chacun des 32 millions d’utilisateurs (oui moi non plus j’y crois pas hein, c’est pour l’exemple) on arrive à un enregistrement qui comporte 38 caractères et 14 virgules ainsi qu’un retour à la ligne… Soit 53 caractères… On reste en ANSI et on obtient un total de 54 octets (l’arobase du mail est codée sur deux octets). Soit, pour nos 32 millions de piégés : 1.6Go !

Et parce que je n’ai pas envie de vous achever ce soir, on va finir avec une base qui me parait raisonnable en utilisant les valeurs suivantes :

pseudo : varchar(5),
email : text(15),
mdp : varchar(8),
langue:varchar(5),
sexe:tinyint(1),
prenom:varchar(5),
nom:varchar(7),
date_naissance:date,
pays:varchar(2),
code_postal:varchar(5),
tel_mobile:text(7),
pub_mail:tinyint(1),
pub_tel:tinyint(1),
allow_search:tinyint(1)

Il s’agit là d’estimations à la louche qui ressemblent aux données que j’ai pu voir sur les diverses applications sur lesquelles j’ai été amené à travailler… Je pense encore être en dessous de la vérité et il y a des chances pour que certains champs soient cachés (IP, statut, date_creation, …).

Bref avec ma petite estimation que je sors de nulle part (un peu comme les chiffres sur le piratage annoncés par les maisons de disques) on arrive à un joli total de 73 caractères, toujours pour 14 virgules et un retour à la ligne. Soit 89 octets par enregistrements et un total de tout pile 2Go.

En fonction de ce que le pirate a pu sortir de la base de données il aurait donc du générer et télécharger entre 640Mo et 2Go de données, pour des estimations qui sont de toutes façons très en dessous de la taille réelle de la table en question (qui doit être en utf-8, comporter des caractères spéciaux dans les noms et prénoms, des mails, pseudos et mots de passe bien plus longs que ceux envisagés ici et des champs que nous n’avons pas considérés ici).

Aussi ma question est la suivante : sur une architecture prévue pour héberger des blogs dont le contenu fait au maximum quelques Mo, comment les admins ont-il pu ne pas remarquer une connexion persistante téléchargeant plusieurs Go de données ?

Commentaires

17 Responses to “Pourquoi je ne crois pas au vol des mots de passe de Skyrock”

  1. Stéphane
    mai 25th, 2010 @ 21 h 24 min

    Quand on fait le choix de laisser en clair 32 millions de password alors qu’on est la cible d’attaque récurrente depuis plusieurs années et qu’on se vante d’être le leader européen en matière de CMS……. Ne pas repérer un DL de 600 a 1Go (20 minutes à tout casser ?) sur un des serveurs web, c’est pas ça qui devrait nous sembler louche.

    Ton article pose une vraie question, mais je crois pas qu’il y ai de vraies réponses. Ces mecs sont des brêles, c’est à peu prêt la réponse la plus cohérente qu’on pourrai t’apporter.

  2. 6pri1
    mai 25th, 2010 @ 21 h 38 min

    Ta théorie se tient (j’ai tendance à faire confiance pour les calculs ^^), mais elle me chiffonne :

    Pourquoi Skyrock aurait fait croire que sa base de données a été piratée ?

  3. Kenshin
    mai 25th, 2010 @ 21 h 52 min

    Belle analyse !
    (Une suppression de ces 32 millions de « blogs » aurait fait du bien :))

    L’autre détail amusant, c’est qu’avec ces 32 millions de logins/mdp/adresses mail, il a (très probablement) bien 75% de comptes mails à son entière disposition. (les kikoolol utilisant très souvent le même mot de passe, souvent bidon, partout)

  4. Foxspown
    mai 25th, 2010 @ 21 h 54 min

    Pour cacher la revente d’infos?

  5. Kenshin
    mai 25th, 2010 @ 21 h 54 min

    J’ai oublié d’ajouter :

    Si bien sûr, Skytruc s’est bien fait volé ses mots de passe…(coup de pub gratuit pour relancer la machine qui souffre beaucoup de la concurrence de Facebook ? C’est bien possible. Mais avouer s’être fait piraté, c’est pas vraiment un coup de pub positif selon moi.)

  6. Paul
    mai 25th, 2010 @ 21 h 57 min

    Ils ont confirmé l’intrusion, sur le vol en lui même ils ne savent pas…

    Moi je pense que si quelqu’un a effectivement récupéré des infos (et ça doit quand même être super tentant avec une base non chiffrée) il n’a pas pu dumper la totalité des enregistrements sans que ça se voit…

    Et si je me trompe, c’est que l’on est dans le second cas de figure : on a affaire à des incompétents de la pire espèce…

  7. Tuxkowo
    mai 25th, 2010 @ 22 h 06 min

    Pourquoi télécharger l’intégralité de la table utilisateurs ? Je me serais limité à certains comptes comme les 5 millions connectés ou inscrits dernièrement ce qui permet d’être plus discret, on évite un fichier de 1 Gio en téléchargement, et d’avoir des données assez « fraîches ».

    @Kenshin : Une suppression n’aurait servi à rien les données sont normalement sauvegardées régulièrement.

    @Paul : Je crois à leur incompétence 🙂

  8. Keeg
    mai 25th, 2010 @ 23 h 04 min

    Article intéressant, mais je ne suis pas forcement en accord avec la conclusion. Je ne sais pas trop comment est foutu l’architecture des BDD de Skyrock, mais elles sont forcement ultra-sollicitées. Du coup 1GO de plus ou de mois, ça ne me semble pas énorme pour eux. Et sur un temps court, il suffit qu’il n’y ait personne qui suive l’utilisation à ce moment là, et le tour est joué.

  9. Paul
    mai 25th, 2010 @ 23 h 11 min

    C’est pas tant sur la quantité que sur la persistance de la connexion que je pense qu’il devrait y avoir des alertes : à part pour faire leur backups, il n’y a aucune raison qu’une connexion reste ouverte aussi longtemps compte tenu de leur contenu habituel (photos de quelques Ko + texte plein de fautes et de couleurs)…

    Et je pense que la table utilisateur doit aller chiffrer dans les 5Go, tous les chiffres utilisés dans l’article sont minimisés pour arriver à la conclusion que même en prenant un cas de figure extrême ils auraient du s’en apercevoir…

  10. val
    mai 26th, 2010 @ 12 h 54 min

    deja pour camouflé le débit de telechargement tu peux faire programmer le download pour faire des pauses toutes les tant octets telechargé, changer l’apparance de l’ip et reprendre le telechargement, …
    Et enfin quel est l’interet de posséder une tel base de donnée ? et bien seul une grosse société peux se permettre d’avoir un quelquonque interet pour ces données, aux meme fins que facebook, et dans quelques années le resultat de tout cela sera monstrueux

  11. Simon
    mai 26th, 2010 @ 18 h 30 min

    On notera qu’une fois de plus les « autorités » ont fait autorité en matière de choix technologiques 🙂

  12. Mr Xhark
    mai 28th, 2010 @ 16 h 29 min

    Ils l’ont remarqué, mais après coup.
    Vu le traffic qui passe sur Skyrock, un pic de 1go doit vraiment pas se noyer dans la masse. Et puis quand t’es incapable de crypter tes mots de passes, pas sûr que tu sois meilleur pour détecter des intrusions en temps réel…

  13. moi
    mai 31st, 2010 @ 9 h 49 min

    5go c’est tellement rien pour ce type de site…
    Nous éditons des sites à trafic medium (+/- 2 millions de pap/jours) et nos bases prennent 2000 rqt/s et des centaines de Go par jours.
    Même si on dumpait toute notre base (+/- 10 go) on le verrais pas alors vu le traf de sky, aucune chance

  14. crashdump.fr
    juin 1st, 2010 @ 14 h 00 min

    Mettons que l’attaquant ai fetché la DB depuis un lien a 100Mb, soit ~ 10Mo/s. Si la base était de l’ordre du Go, ça donne environ… 100s.

    Soit a peine plus d’une minute.. la chose, glissée a 4 heures du mat’ peut facilement passer inaperçue jusqu’au lendemain.. Les données sont déjà loin !

  15. Paul
    juin 1st, 2010 @ 14 h 50 min

    Même si effectivement il télécharge à 10Mo/s ce qui est peu probable étant donné que la personne en question, un minimum intelligent pour avoir percé les défenses de Skyrock, dois se protéger derrière un quelconque système anonymisant (proxy, vpn, tor, …) qui ralentissent fortement la connexion, quel intérêt aurait Skyrock à permettre des connexions aussi longues sur leurs serveurs ?

    D’autant qu’encore une fois 1Go c’est vraiment une estimation très basse de la taille réelle du fichier. Refais tes calculs avec un fichier de 3Go et une connexion de 1Mo/s (relativement commun) planqué derrière un vpn qui la ralentisse de 20%…

  16. rez
    juin 3rd, 2010 @ 16 h 24 min

    cool

  17. moi
    juin 6th, 2010 @ 23 h 36 min

    Rien d’oblige à dumper une base sur une seule rqt (faudrait être tres con d’ailleurs pour faire ça). Une fois que t’a accès à la base tu peux dumper ça à coup de 500 lignes et ça passe completement inaperçu.

Leave a Reply





Edito

Ancien journaliste, ancien entrepreneur, ancien (ir)responsable Pirate, actuel citoyen qui s'intéresse à la politique et à son évolution.

Read moar !.

Retrouvez moi sur :

Suivez moi sur twitter sur facebook sur wikipedia Ajouter ce blog a votre lecteur RSS

Bitcoin

bitcoin logo
1GZnMQ9wXyifxCnDEqg8CSGdngWcKWptHv

Piratons la démocratie

piratons la democratie

One more thing !

0100 0011 0110 1000 0110 0001 0110 1110 0110 0111 0110 0101 0111 0010 0010 0000 0110 1100 0110 0101 0010 0000 0110 1101 0110 1111 0110 1110 0110 0100 0110 0101 0010 0000 0110 0101 0110 1110 0010 0000 0111 0011 0010 0111 0110 0001 0110 1101 0111 0101 0111 0011 0110 0001 0110 1110 0111 0100 0010 0000 0010 1101 0010 0000 0110 1111 0110 1110 0010 0000 0111 0110 0110 0001 0010 0000 0110 0010 0110 1111 0110 1001 0111 0010 0110 0101 0010 0000 0111 0101 0110 1110 0010 0000 0110 0011 0110 1111 0111 0101 0111 0000 0010 0000 0011 1111

Tm9uIGNlbGVsIGzgIGVzdCBqdXN0ZSBwb3VyIHRlIGZhaXJlIHBlcmRyZSA1bW4gOyk=

Relationship Closeness Inventory

Promo code Genesis Mining

Sha 256 cloud mining

Best Bitcoin debit card

Zcash Mining