Piratage et fuite de données personnelles chez le fabricant de jouets VTech

Piratage et fuite de données personnelles chez le fabricant de jouets VTech

Florilège des (très) mauvaises pratiques

Avatar de l'auteur
Vincent Hermann

Publié dans

Internet

01/12/2015 7 minutes
32

Piratage et fuite de données personnelles chez le fabricant de jouets VTech

Le fabricant de jouets VTech a été victime d’une importante fuite de données. Les informations personnelles de cinq millions d’adultes et de 200 000 enfants ont ainsi été exposées. De nombreux pays sont touchés, dont la France, et la société a été obligée de fermer son service Learning Lodge.

Dans un communiqué publié hier, la société VTech a confirmé avoir été victime d’une importante attaque qui a abouti au vol d’une très importante quantité d’informations sur sa clientèle. Ces données émanent de pas moins de cinq millions de comptes créés sur les différents sites et services reliés à VTech. Parmi ces informations, on retrouve l’adresse email, le nom, le mot de passe, la question secrète et sa réponse, l’adresse IP, l’adresse postale ou encore l’historique de téléchargement.

5 millions d'adultes, 200 000 enfants, 13 sites

Cette masse de données contient également des informations sur environ 200 000 enfants : nom, sexe et date de naissance. Cependant, aucune donnée à caractère très sensible n’est stockée de cette manière, notamment tout ce qui touche aux paiements. On ne retrouve donc pas de numéro de carte bancaire, de sécurité sociale, de carte d’identité ou de permis de conduire. Dans son communiqué, VTech a indiqué hier que tous les clients touchés avaient été contactés par email pour les informer de la brèche et de la fuite des données. Des adresses email spéciales de contact ont par ailleurs été mises en place. En France, il s’agit de « [email protected] ».

Il y a cependant plus grave, et Vtech ne le dit pas dans son communiqué. Comme l'indiquait hier Motherboard, le pirates ont été capables d'obtenir également des selfies pris par les enfants ainsi que des journaux de conversation entre eux et leurs parents. Dans un entretien chiffré avec le site, le pirate a indiqué qu'il existait au total 190 Go de photos, dont un échantillon de 3 832 clichés a été fourni pour preuve à nos confrères.

vtech
Crédits : Motherboard

Évidemment, une enquête est en cours. Durant la première phase, le constructeur a préféré couper l’accès à 13 sites au total dont, en France, planetvtech.com, lumibeauxreves.com et planetvtech.fr. Parallèlement, l’entreprise a préféré fermer son service Learning Lodge, qui est en fait une boutique contenant de multiples contenus pour les enfants : musique, petites applications, livres électroniques et jeux.

La brèche a été repérée par un journaliste

C’est d’ailleurs dans Learning Lodge que tout a commencé le 14 novembre, quand des pirates ont réussi à percer les défenses de la société hongkongaise. Ce qui est clairement l’une des plus grosses fuites de données enregistrées a d’abord été repéré par le journaliste Lorenzo Franceschi-Bicchierai. Pour mieux comprendre ce qui lui semblait être un souci de sécurité, il s’est adressé à Troy Hunt, MVP Microsoft.

C’est l’analyse de ce dernier, publiée pendant le week-end, qui a montré l’ampleur de la brèche et la manière dont toutes ces données ont pu être récupérées. Il a commencé par vérifier la validité des données en passant par un outil de sa composition, baptisé HIBP (pour « have i been pwned? »). Par son intermédiaire, il a reçu six réponses durant les premières 24 heures qui pointaient vers une confirmation de la fuite.

vtech
Crédits : Troy Hunt

Chiffrement MD5, pas de SSL, mots de passe des enfants en clair...

Dans les données elles-mêmes se trouvait notamment un fichier « parents.csv » pesant pas moins de 1,7 Go. À l’intérieur, 4 833 678 adresses email uniques (elles étaient parfois répétées) accompagnées des données citées plus haut. Malheureusement, VTech n’a accompli qu’un faible travail de protection pour les données de ces clients. Troy Hunt s’est en effet rendu compte que les mots de passe, s’ils avaient bien été chiffrés, n’étaient passés qu’à la moulinette hacheuse MD5, que les pirates un tant soit peu équipés peuvent décrypter très rapidement (quelques minutes).

Et les erreurs de VTech s’enchainent. D’une part, toutes les communications des clients sur les sites concernés se sont faites sur la base de connexions non chiffrées : le SSL avait été mis de côté. De fait, tout ce qui touchait aux identifiants et mots de passe transitait par des connexions HTTP classiques. D’autre part, les mots de passe des comptes enfants étaient stockés en clair, et les pirates n’avaient donc aucun effort à faire pour les obtenir. Enfin, et c’est un très sérieux problème, Troy Hunt a montré qu’il était en fait très facile de relier les données des comptes enfants à celles des comptes parents. Traduction, les pirates peuvent facilement obtenir les adresses postales des enfants.

VTech n’a par ailleurs pas été très alerte. L’entreprise n’était en effet au courant de rien avant que Motherboard, qui a obtenu les informations du journaliste Lorenzo Franceschi-Bicchierai, ne l’en avertisse. Le communiqué publié ce week-end est d’ailleurs assez avare en informations et il n’est nulle part mention de l’ampleur de la fuite de données. En somme, comme l’indique The Next Web, ce piratage est pratiquement un cas d’école résumant tout ce qu’il est possible de rater sur le plan de la sécurité.

Le tout juste avant les fêtes de fin d'année

VTech indique quand même que l’enquête est en cours et que des mesures sont en train d’être prises pour renforcer la sécurité des informations personnelles. Malheureusement, il a encore une fois été nécessaire qu’une véritable catastrophe de ce genre survienne pour qu’une entreprise se penche sur un sujet qui devrait être pris au sérieux dès la création d’un fichier client.

Le calendrier est également intéressant puisque l’attaque a eu lieu à quelques semaines à peine des fêtes de fin d’année. Il n’est pas dit que la grande majorité des clients potentiels soient informés d’une telle fuite avant de faire leurs achats, d’autant que les produits VTech se trouvent très facilement dans les grandes surfaces et les magasins de jouets. VTech précise que d’autres informations seront publiées en temps et en heure quand elle aura avancé dans son enquête.

On rappellera que la CNIL avait publié le 2 septembre un compte-rendu faisant justement état du manque flagrant de protection des données personnelles sur les sites dédiés aux enfants. La Commission avait également mis en ligne des conseils pour les parents ainsi que pour les éditeurs de ce type de service. Mais l'article 34 de la loi Informatique et Libertés impose à toute entreprise - et plus globalement à toute entité responsable d'un fichier contenant des données personnelles - de « prendre toutes précautions utiles, au regard de la nature des données et des risques présentés par le traitement, pour préserver la sécurité des données ». VTech pourrait donc en Europe être tenue pour responsable de cette fuite si elle ne parvient pas à prouver qu'elle avait mis en place toutes les mesures nécessaires.

Écrit par Vincent Hermann

Tiens, en parlant de ça :

Sommaire de l'article

Introduction

5 millions d'adultes, 200 000 enfants, 13 sites

La brèche a été repérée par un journaliste

Chiffrement MD5, pas de SSL, mots de passe des enfants en clair...

Le tout juste avant les fêtes de fin d'année

Le brief de ce matin n'est pas encore là

Partez acheter vos croissants
Et faites chauffer votre bouilloire,
Le brief arrive dans un instant,
Tout frais du matin, gardez espoir.

Commentaires (32)


Fallait pas qu’ils utilisent les ordinateurs qu’ils vendent comme jouets pour la gestion de leur boîte…



<img data-src=" /><img data-src=" /><img data-src=" /><img data-src=" /><img data-src=" />


Ils ne peuvent pas être en cause étant donné qu’ils ne peuvent être connecté à internet. <img data-src=" />


grmbl, suis dedans … un de mes mdp à la con dans les dicos, fais suer …


P’tain… elle est terrible cette fuite-là.&nbsp; <img data-src=" />


Quand on met cette news et celle-ci à coté, on se demande comment on peut vouloir laisser une entreprise profiler ses enfants :&nbsphttp://www.zataz.com/la-nouvelle-barbie-est-dangereuse-pour-les-enfants/



Pas encore actifs sur internet que les bambins sont déjà traqués :/


Mais c’est pas possible… du MD5… mais putain, c’est aussi simple d’écrire md5( que sha-5( et sécurise un peu mieux. Mais moi dans ma petite boite de dev web, on sécurise mieux que ça en quelques minutes de code&nbsp;<img data-src=" />



Vas’y tout en clair, vas y en http, vas y à l’arrache le code…



ils connaissent peut être pas fail2ban, ou artillery&nbsphttps://github.com/BinaryDefense/artillery je te dis pas…


Autant la fuite est… autant VTech est indéfendable sur le coup.


Le seul moyen de vraiment sécuriser serait d’interdire de stocker les informations personnelles tel que l’adresse, les photos quand on fait un achat en ligne. C’est peut-être compliqué mais c’est la meilleure solution.



Le ponpon, c’est qu’ils ont fait comme les grenouilles, alors forcément ils avaient pas vu l’eau bouillir. la connexion chiffrée doit être obligatoire.


La sécurité , c’est un jeu d’enfants <img data-src=" />


Grosse erreur : le md5 ne se décrypte pas (par construction), il se casse par comparaison (rainbow table). Du coup si le mot de passe est unique (ce qu’ils devraient tous être), avoir le md5 d’un mot de passe ou rien c’est du pareil au même.



Et j’ai pas bien compris le coup du SSL…. ok, y avait pas de SSL et les identifiants transitaient par HTTP non chiffré. C’est pas bien, ça ouvre la porte au man in the middle tout ça, mais quel rapport ici ?








boogieplayer a écrit :



Mais c’est pas possible… du MD5… mais putain, c’est aussi simple d’écrire md5( que sha-5( et sécurise un peu mieux. Mais moi dans ma petite boite de dev web, on sécurise mieux que ça en quelques minutes de code <img data-src=" />



Vas’y tout en clair, vas y en http, vas y à l’arrache le code…



ils connaissent peut être pas fail2ban, ou artillery&#160https://github.com/BinaryDefense/artillery je te dis pas…







C’est aussi rapide mais ça ne change pas grand chose sinon la longueur de la chaine générée (et donc le risque de collision), surtout que, pour le md5 ou le sha256, les rainbow table sont les mêmes (avec les mêmes mot de passe de base).

Non, faudrait salté, mais là ça devient nettement plus complexe à mettre en oeuvre, surtout dans un gros CMS… et si dans ta boîte de dev web vous le faites sans prendre en considération le soft dans son ensemble jamais je ne passerai par vous…



C’est quoi ton problème avec le HTTP exactement ? Sais tu au moins en quoi ça diffère du HTTPS ? Tu ne te fais pas hack parce que tu es ou pas pas HTTP hein….



Pareil pour fail2ban, je vois pas le rapport….









Commentaire_supprime a écrit :



Fallait pas qu’ils utilisent les ordinateurs qu’ils vendent comme jouets pour la gestion de leur boîte…



<img data-src=" /><img data-src=" /><img data-src=" /><img data-src=" /><img data-src=" />





Il y en a qui ont eu leur diplome de sysadmin dans une pochette surprise &nbsp;<img data-src=" />

Bon c’est pas forcément leur faute, ça peut aussi venir des décideurs qui voient le renforcement des infra comme inutile et coûteux. Mais dans le doute.



Dans le doute abstiens toi <img data-src=" />



On va encore nous dire que la sécurité leur a mal été présentée et que c’est apparu trop couteux par rapport au risque et qu’il a donc été accepté.



La fameuse arme secrète de la sécurité “Ok, nous vous avons prévenus, faites moi un mail, pour mes archives, comme quoi vous acceptez le risque en toute connaissance de cause.” <img data-src=" />



Tant que la sécurité sera présentée, perçue… comme relevant uniquement du technique et non du point de vue de la sécurité de l’entreprise, incluant la réputation, l’image de marque… Les mêmes causes produisant les mêmes effets <img data-src=" />


Il serait bon qu’ils se prennent une condamnation record, histoire de faire réfléchir les autres sur l’avenir.


Ouch… Bien content de ne pas avoir enregistré le produit, au moins ils n’ont aucune donnée sur ma famille…








boogieplayer a écrit :



Mais c’est pas possible… du MD5… mais putain, c’est aussi simple d’écrire md5( que sha-5( et sécurise un peu mieux. Mais moi dans ma petite boite de dev web, on sécurise mieux que ça en quelques minutes de code&nbsp;<img data-src=" />



Vas’y tout en clair, vas y en http, vas y à l’arrache le code…



ils connaissent peut être pas fail2ban, ou artillery&nbsp;https://github.com/BinaryDefense/artillery je te dis pas…





MD5 ou SHA le principal risque c’est les rainbow tables et avec 1 millions d’itérations par secondes en sha256 sur un simple core i7 6700K ça se crée très vite.



Ce qu’il faut c’est saler (et si possible avec un grain différend pour chaque entrée) les mots de passes avant de le hasher, voir utiliser la fonction crypt() qui fait ça toute seule comme une grande.



Quand on voit le coût d’un certif SSL et les différentes “bonnes pratiques” pour protéger des systèmes, ce genre de truc laisse vraiment perplexe.



&nbsp;J’ai l’impression que plus la boite est grosse et plus le laisser aller à important. Surtout que VTech est une boite spécialisée dans l’informatique / numérique depuis 40 ans. À ce point, c’est juste inexcusable.



Les parents sont aussi à blâmer, car on ne fait pas transiter des infos concernant ses gamins sur internet ! C’est bien beau de faire “Bouh le méchant cloud” après…








bilbonsacquet a écrit :



Quand on voit le coût d’un certif SSL et les différentes “bonnes pratiques” pour protéger des systèmes, ce genre de truc laisse vraiment perplexe.







Ce qui me laisse perplexe, moi, c’est le nombre d’interventions où l’on peut lire ce genre de choses à chaque piratage. Genre le SSL serait LA méthode magique pour sécuriser un serveur…



Concrètement le SSL ne sert à rien pour le serveur hein, ça ne sert qu’à empêcher un man in the middle - et encore, car les divers proxy ont très bien possibilité de ré-émettre les requêtes ( en gros ordi =&gt; cryptage SSL =&gt; proxy =&gt; autre cryptage SSL =&gt; serveur), du coup le proxy a le message en clair.









Fuinril a écrit :



Ce qui me laisse perplexe, moi, c’est le nombre d’interventions où l’on peut lire ce genre de choses à chaque piratage. Genre le SSL serait LA méthode magique pour sécuriser un serveur…



Concrètement le SSL ne sert à rien pour le serveur hein, ça ne sert qu’à empêcher un man in the middle - et encore, car les divers proxy ont très bien possibilité de ré-émettre les requêtes ( en gros ordi =&gt; cryptage SSL =&gt; proxy =&gt; autre cryptage SSL =&gt; serveur), du coup le proxy a le message en clair.





peut être voulait il signifier que s’ils ne font déjà pas d’effort au niveau du ssl ce qui est la base, le reste du réseau ne doit pas être beau à voir.



De toutes façons pour pas mal de boite la sécurité it c’est cher et ça sert à rien jusqu’au jour…..&nbsp;









bilbonsacquet a écrit :



Les parents sont aussi à blâmer, car on ne fait pas transiter des infos concernant ses gamins sur internet ! C’est bien beau de faire “Bouh le méchant cloud” après…







Au fond, le cloud le plus sécurisé est encore celui dont on ne se sert pas <img data-src=" />









Fuinril a écrit :



les divers proxy ont très bien possibilité de ré-émettre les requêtes ( en gros ordi =&gt; cryptage SSL =&gt; proxy =&gt; autre cryptage SSL =&gt; serveur), du coup le proxy a le message en clair.







Une configuration proxy seule ne permet pas l’accès au message en clair : il faut en plus pousser le certificat root du proxy sur les navigateurs clients (et activer l’option qui va bien sur le proxy). Par défaut, un proxy a juste accès au nom de domaine exact (vu qu’il reçoit un HTTP CONNECT www.nextinpact.com:443).









darkbeast a écrit :



peut être voulait il signifier que s’ils ne font déjà pas d’effort au niveau du ssl ce qui est la base, le reste du réseau ne doit pas être beau à voir.



Tout à fait ! Surtout que Fuinril n’a pas lu ce qu’il y avait après SSL dans mon commentaire…



Bref… Si en plus faut obliger les gens à lire les commentaires en entier, où vas t’on !&nbsp; <img data-src=" />





Traduction, les pirates peuvent facilement obtenir les adresses postales des enfants.



C’est un jeu de données en or qu’ils ont volé là.

Ca peut se revendre très cher à un pédophile ca. L’adresse des gamins, ce à quoi ils jouent, leur photos, etc…


“Dans les données elles-mêmes se trouvait notamment un fichier

«&nbsp;parents.csv&nbsp;» pesant pas moins de 1,7 Go. À l’intérieur, 4&nbsp;833&nbsp;678

adresses email uniques (elles étaient parfois répétées) accompagnées des

données citées plus haut”



<img data-src=" />








Gundar a écrit :



Au fond, le cloud le plus sécurisé est encore celui dont on ne se sert pas <img data-src=" />





Au fond la meilleure sécurité c’est de ne pas faire d’enfants.&nbsp;<img data-src=" />









Guyom_P a écrit :



Au fond la meilleure (snip) tranquillité c’est de ne pas faire d’enfants.&nbsp;<img data-src=" />





&nbsp;<img data-src=" />









Fuinril a écrit :



C’est aussi rapide mais ça ne change pas grand chose sinon la longueur de la chaine générée (et donc le risque de collision), surtout que, pour le md5 ou le sha256, les rainbow table sont les mêmes (avec les mêmes mot de passe de base).

Non, faudrait salté, mais là ça devient nettement plus complexe à mettre en oeuvre, surtout dans un gros CMS… et si dans ta boîte de dev web vous le faites sans prendre en considération le soft dans son ensemble jamais je ne passerai par vous…



C’est quoi ton problème avec le HTTP exactement ? Sais tu au moins en quoi ça diffère du HTTPS ? Tu ne te fais pas hack parce que tu es ou pas pas HTTP hein….



Pareil pour fail2ban, je vois pas le rapport….

&nbsp;



Oui, je sais bien, mais je digressais, pour augmenter la protée des incompétences en général. &nbsp;Si les mots de passe sont en clairs, tu peux te dire que toutes la chaine de sécu est pourrie.



&nbsp;



GentooUser a écrit :



MD5 ou SHA le principal risque c’est les rainbow tables et avec 1 millions d’itérations par secondes en sha256 sur un simple core i7 6700K ça se crée très vite.



Ce qu’il faut c’est saler (et si possible avec un grain différend pour chaque entrée) les mots de passes avant de le hasher, voir utiliser la fonction crypt() qui fait ça toute seule comme une grande.





C’est pour cela qu’on sale en effet les mdp de manière variables dans la BDD et en plus on chiffre le mdp chiffré+salé avec le chiffrage de SQL.&nbsp;



crypt() n’est pas conseillé, car le chiffrage est faible. Préférer password_hash()https://secure.php.net/manual/fr/function.password-hash.php&nbsp;<img data-src=" />









boogieplayer a écrit :



Oui, je sais bien, mais je digressais, pour augmenter la protée des incompétences en général. &nbsp;Si les mots de passe sont en clairs, tu peux te dire que toutes la chaine de sécu est pourrie.



&nbsp;

C’est pour cela qu’on sale en effet les mdp de manière variables dans la BDD et en plus on chiffre le mdp chiffré+salé avec le chiffrage de SQL.&nbsp;



crypt() n’est pas conseillé, car le chiffrage est faible. Préférer password_hash()https://secure.php.net/manual/fr/function.password-hash.php&nbsp;<img data-src=" />





Le formulaire de commentaires faisant encore des merveilles, réessayons le lien sans les caractères magiques ajoutés par NXI :

https://secure.php.net/manual/fr/function.password-hash.php



Hallucinant. Ca me concernerait, je porterais plainte direct.




boogieplayer a écrit :

crypt() n’est pas conseillé, car le chiffrage est faible. Préférer password_hash()https://secure.php.net/manual/fr/function.password-hash.php&nbsp;<img data-src=" />



crypt() est configurable, on peut même rajouter des itérations (bon, pas conseillé).



L’avantage password_hash() est de rajouter le support de bcrypt, mais il faut une version de php très récente.


Ouep, depuis son support natif dans php je l’utilise dans nos devs pour nos clients&nbsp;<img data-src=" />


brypt et puis c’est tout <img data-src=" />