Un vol de données personnelles chez Numericable aux conséquences multiples pour les clients

msg
Envoyer message

9585 points

Posté le 02 octobre 2017 à 10h58 Citer le commentaire

"A première vue, seuls les données nominatives, e-mails, adresses, numéros de téléphone et services souscrits ont ainsi été dérobés sur le serveur du site. “Aucun autre type de données, telles que des données bancaires, d’identification ou d’accès, n’est concerné”, précise l’opérateur dans un mail envoyés aux clients impactés."

On ne sait pas qui a fait ça , mais vous inquiétez pas , on est sûr que c'est des pirates modérés !

wanou
Envoyer message

209 points

Posté le 02 octobre 2017 à 11h07 Citer le commentaire

balibran a écrit

Fuite le 11 Aout, mail la semaine dernière ... sont réactifs chez Miséricable ...

La fuite a eu lieu le 11 août mais on ne sait pas quand elle a été réellement constaté. Soyons prudent avant de porter des jugements à l'emporte pièce.

Par contre, elle est déjà utilisée (depuis une dizaine de jours je dirais) ma belle-mère reçoit des mails très précis avec nom prénom et adresse lui indiquant que son prélèvement avait été rejeté et qu'il fallait rapidement régler par carte bancaire pour ne pas se faire couper son accès. Je pense qu'il va y avoir des dégâts vu la qualité de l'opération.

balibran
Envoyer message

1487 points

Posté le 02 octobre 2017 à 11h18 Citer le commentaire

wanou a écrit

balibran a écrit Fuite le 11 Aout, mail la semaine dernière ... sont réactifs chez Miséricable ...

La fuite a eu lieu le 11 août mais on ne sait pas quand elle a été réellement constaté. Soyons prudent avant de porter des jugements à l'emporte pièce. Par contre, elle est déjà utilisée (depuis une dizaine de jours je dirais) ma belle-mère reçoit des mails très précis avec nom prénom et adresse lui indiquant que son prélèvement avait été rejeté et qu'il fallait rapidement régler par carte bancaire pour ne pas se faire couper son accès. Je pense qu'il va y avoir des dégâts vu la qualité de l'opération.

Et incompétents, en plus ?

Une entreprise de cette stature se doit d'avoir au moins un organe de détection qui réagit (même s'il ne peut l'empêcher) avec un avertissement à ce type de fuites.

Ils l'ont détectée, donc elle est détectable ...

jinge333
Envoyer message

3444 points

Posté le 02 octobre 2017 à 12h53 Citer le commentaire

balibran a écrit

Et incompétents, en plus ? Une entreprise de cette stature se doit d'avoir au moins un organe de détection qui réagit (même s'il ne peut l'empêcher) avec un avertissement à ce type de fuites. Ils l'ont détectée, donc elle est détectable ...

Tous les gros groupes se sont fait pirater. Comme le disait je ne sais plus qui, ça n'est pas une question de "si", mais de "quand".

Il est extrêmement difficile de détecter ce genre de fuites, et encore plus de les contrôler. Une faille, c'est par définition quelque chose qu'on a pas fait exprès de laisser, et donc pas quelque chose que l'on controle, sinon ob bouche la faille...

sperot51

Posté le 02 octobre 2017 à 13h06 Citer le commentaire

jinge333 a écrit

Tous les gros groupes se sont fait pirater. Comme le disait je ne sais plus qui, ça n'est pas une question de "si", mais de "quand".

certes

mais une injection sql c'est quand même dommage, c'est une notion de débutant en programmation que d'éviter de rendre ça possible ...

Premium

taduarial
Envoyer message

16359 points

Posté le 02 octobre 2017 à 17h04 Citer le commentaire

d'une banalité finalement, enfin je crois

christophedlr
Envoyer message

1536 points

Posté le 02 octobre 2017 à 17h19 Citer le commentaire

jinge333 a écrit

balibran a écrit Et incompétents, en plus ? Une entreprise de cette stature se doit d'avoir au moins un organe de détection qui réagit (même s'il ne peut l'empêcher) avec un avertissement à ce type de fuites. Ils l'ont détectée, donc elle est détectable ... Tous les gros groupes se sont fait pirater. Comme le disait je ne sais plus qui, ça n'est pas une question de "si", mais de "quand". Il est extrêmement difficile de détecter ce genre de fuites, et encore plus de les contrôler. Une faille, c'est par définition quelque chose qu'on a pas fait exprès de laisser, et donc pas quelque chose que l'on controle, sinon ob bouche la faille...

Sauf que excuse moi, mais en tan que Développeur Web je me dois de réagir. L'injection SQL est une technique qui n'est pas nouvelle et que n'importe qui peut utilisée. Le principe est que quand tu remplis ton formulaire sur le site (par exemple formulaire de connexion), dans un des champs tu met une partie d'une requête SQL.

Par exemple, le cas le plus basique qu'on apprends, c'est pour s'identifier sans avoir le mot de passe. Au moment de donné le mot de passe, tu met une condition SQL : 1 = 1. Cette condition t'assure que la requête ressortira des données même sans avoir le mot de passe, car cette vérification se fait pas, mais comme tu lui dis : "OR 1 = 1" cela veut dire (sinon si c'est 1 = 1), hors là la condition est vérifiée donc tu t'identifies sans mot de passe valable.

Par des éléments de requêtes SQL, tu peux donc aller jusqu'à faire tout une requête complète qui va te remonter toutes les données, c'est le principe de l'injection SQL.

Pour ceux utilisant une base MySQL par exemple, la première chose qu'on nous apprend c'est utiliser mysql_real_escape sur TOUTES les données rentrées par l'utilisateur, ainsi comme un échappement se fait l'injection SQL n'est plus permise, car se sera plus une condition SQL rajoutée à la suite, mais ce sera ce que l'on a écrit qui sera la donnée fournie dans le formulaire.

L'équivalent existe pour les bases PostgreSQL et Oracle (travaillant qu'avec MySQL/MariaDB, je ne les connais cependant pas). Si maintenant le boulot est fait correctement, c'est PDO qui est utilisé, normalisant alors les appels de fonctions pour les requêtes SQL (d'une part), d'autre part l'usage du système de paramètres avec le bindParam par exemple ou bindValue, permet de procéder au fameux échappement et empêché donc l'injection SQL.

C'est un truc vieux comme le monde, et cela montre que chez Altice, ils sont totalement incompétent et ce depuis toujours vu qu'ils sont même pas capable de réaliser un site internet de base.

frederic76
Envoyer message

15787 points

Posté le 02 octobre 2017 à 19h03 Citer le commentaire

jinge333 a écrit

Tous les gros groupes se sont fait pirater. Comme le disait je ne sais plus qui, ça n'est pas une question de "si", mais de "quand". Il est extrêmement difficile de détecter ce genre de fuites, et encore plus de les contrôler. Une faille, c'est par définition quelque chose qu'on a pas fait exprès de laisser, et donc pas quelque chose que l'on controle, sinon ob bouche la faille...

Pas forcément et surtout pas n'importe comment pour peu qu'il y ai de la sécurité !

Normalement toute société et même particulier doit avoir plusieurs réseaux distincts, l'un internet, l'autre intranet. Chacun des réseaux ne doit pas interagir avec l'autre. Il ne doit rien y avoir de sensible, confidentiel ou important qui '' peut'' être sur celui mis sur internet même si id/mdp complexe, on met tt sur celui local intranet. Les maj des os, programmes... Se font manuellement depuis le terminal Internet et l' on met sur une clé par ex. Sur le intranet on fait xxxxxxxxxx sauvegardes avant tt ajout venant de l'extérieur, avant modification système ou risquée et on conserve au moins 3 à 4 versions de sauvegardes en plus de la 1ere. On branche en intranet sans autorun bien sur, on scan bien tt nickel avant de lancer, si possible sous un Linux, et si ok, alors on peut installer ou autre.

Les bases de données doivent si possible être fragmentées sur plusieurs serveurs et no' accessible depuis l'extérieur.

Les employés ne sont pas censés avoir internet sur leur poste, uniquement intranet. Si besoin d'internet alors un ordi dédié coupé de l'intranet.

Tte donnée sensible... Verrouillée, cryptée... Et inutilisable hors du système (serveur ou poste x ou y car pb de droits )De sorte que si kkun tente hors de là, ça 'est fonctionne pas

jinge333
Envoyer message

3444 points

Posté le 02 octobre 2017 à 20h37 Citer le commentaire

christophedlr a écrit

Sauf que excuse moi, mais en tan que Développeur Web je me dois de réagir. L'injection SQL est une technique qui n'est pas nouvelle et que n'importe qui peut utilisée. Le principe est que quand tu remplis ton formulaire sur le site (par exemple formulaire de connexion), dans un des champs tu met une partie d'une requête SQL. Par exemple, le cas le plus basique qu'on apprends, c'est pour s'identifier sans avoir le mot de passe. Au moment de donné le mot de passe, tu met une condition SQL : 1 = 1. Cette condition t'assure que la requête ressortira des données même sans avoir le mot de passe, car cette vérification se fait pas, mais comme tu lui dis : "OR 1 = 1" cela veut dire (sinon si c'est 1 = 1), hors là la condition est vérifiée donc tu t'identifies sans mot de passe valable. Par des éléments de requêtes SQL, tu peux donc aller jusqu'à faire tout une requête complète qui va te remonter toutes les données, c'est le principe de l'injection SQL. Pour ceux utilisant une base MySQL par exemple, la première chose qu'on nous apprend c'est utiliser mysql_real_escape sur TOUTES les données rentrées par l'utilisateur, ainsi comme un échappement se fait l'injection SQL n'est plus permise, car se sera plus une condition SQL rajoutée à la suite, mais ce sera ce que l'on a écrit qui sera la donnée fournie dans le formulaire. L'équivalent existe pour les bases PostgreSQL et Oracle (travaillant qu'avec MySQL/MariaDB, je ne les connais cependant pas). Si maintenant le boulot est fait correctement, c'est PDO qui est utilisé, normalisant alors les appels de fonctions pour les requêtes SQL (d'une part), d'autre part l'usage du système de paramètres avec le bindParam par exemple ou bindValue, permet de procéder au fameux échappement et empêché donc l'injection SQL. C'est un truc vieux comme le monde, et cela montre que chez Altice, ils sont totalement incompétent et ce depuis toujours vu qu'ils sont même pas capable de réaliser un site internet de base.

Je suis tout à fait que l'injection SQL est une faille qui ne devrait pas arriver, et qu'il y aurait du y avoir plus de contrôle. Mais il s'agit plus que probablement d'un reste d'un petit morceau d'un vieux SI qui traîne depuis plus d'une dizaine d'années... (j'espère pour eux sinon c'est assez ridicule!). Il faut se rappeler que Numéricable c'est l'agrégation d'un nombre important de petits opérateurs, et il reste probablement des traces de ceux-ci...

C'est pas qu'ils sont incompétents, c'est qu'ils doivent avoir une quantité monstrueuse de code à gérer, qui doit disparaitre au fur et à mesure bien sûr. Ils ne disent pas de quel site il s'agit, ni quel service non plus...

sebc22
Envoyer message

2728 points

Posté le 03 octobre 2017 à 10h53 Citer le commentaire

christophedlr a écrit

jinge333 a écrit balibran a écrit Et incompétents, en plus ? Une entreprise de cette stature se doit d'avoir au moins un organe de détection qui réagit (même s'il ne peut l'empêcher) avec un avertissement à ce type de fuites. Ils l'ont détectée, donc elle est détectable ... Tous les gros groupes se sont fait pirater. Comme le disait je ne sais plus qui, ça n'est pas une question de "si", mais de "quand". Il est extrêmement difficile de détecter ce genre de fuites, et encore plus de les contrôler. Une faille, c'est par définition quelque chose qu'on a pas fait exprès de laisser, et donc pas quelque chose que l'on controle, sinon ob bouche la faille... Sauf que excuse moi, mais en tan que Développeur Web je me dois de réagir. L'injection SQL est une technique qui n'est pas nouvelle et que n'importe qui peut utilisée. Le principe est que quand tu remplis ton formulaire sur le site (par exemple formulaire de connexion), dans un des champs tu met une partie d'une requête SQL. Par exemple, le cas le plus basique qu'on apprends, c'est pour s'identifier sans avoir le mot de passe. Au moment de donné le mot de passe, tu met une condition SQL : 1 = 1. Cette condition t'assure que la requête ressortira des données même sans avoir le mot de passe, car cette vérification se fait pas, mais comme tu lui dis : "OR 1 = 1" cela veut dire (sinon si c'est 1 = 1), hors là la condition est vérifiée donc tu t'identifies sans mot de passe valable. Par des éléments de requêtes SQL, tu peux donc aller jusqu'à faire tout une requête complète qui va te remonter toutes les données, c'est le principe de l'injection SQL. Pour ceux utilisant une base MySQL par exemple, la première chose qu'on nous apprend c'est utiliser mysql_real_escape sur TOUTES les données rentrées par l'utilisateur, ainsi comme un échappement se fait l'injection SQL n'est plus permise, car se sera plus une condition SQL rajoutée à la suite, mais ce sera ce que l'on a écrit qui sera la donnée fournie dans le formulaire. L'équivalent existe pour les bases PostgreSQL et Oracle (travaillant qu'avec MySQL/MariaDB, je ne les connais cependant pas). Si maintenant le boulot est fait correctement, c'est PDO qui est utilisé, normalisant alors les appels de fonctions pour les requêtes SQL (d'une part), d'autre part l'usage du système de paramètres avec le bindParam par exemple ou bindValue, permet de procéder au fameux échappement et empêché donc l'injection SQL. C'est un truc vieux comme le monde, et cela montre que chez Altice, ils sont totalement incompétent et ce depuis toujours vu qu'ils sont même pas capable de réaliser un site internet de base.

Tu supposes que le site est en php, ce qui n'est pas nécessairement vrai (n'importe quel Service Web un peu sérieux évitera ce langage piégeux comme la peste) ; mais tu as raison sur le fond : pas de concaténation de données dans une requêet SQL sans prendre les mesures adéquates.

A ce niveau là, le problème de fond est surtout un problème de formation : les écoles françaises produisent des développeurs, mais quand tu sais que la sécurité dans les développement fait l'objet d'une heure dans le cursus annuel, il n'y a pas de raison d'être surpris que ce ne soit pas pris en compte. Du coup, les développeurs l'apprennent "à la dure", ie la première fois qu'ils se font prendre.

Quand à avoir des éditeurs de service qui prennent leur responsabilité et paient pour avoir un devpt sécurisé et s'assurent qu'il y a une revue de code , et/ou des tests de sécurité et/ou un pentest régulier, on en est encore loin. Il faut tout de même s'attendre à un choc psychologique après mai 2018 (RGPD).

reno69
Envoyer message

21748 points

Posté le 06 octobre 2017 à 00h19 Citer le commentaire

Bonjour, les vols de données sont récurrents et il est difficile de s'en prémunir totalement pas mal de grandes entreprises dont Orange en ont fait l'objet, et malheureusement certains clients en feront la triste expérience.

Premium

Normand BZH
Envoyer message

10809 points

Posté le 03 janvier 2018 à 16h42 Citer le commentaire

reno69 a écrit

Bonjour, les vols de données sont récurrents et il est difficile de s'en prémunir totalement pas mal de grandes entreprises dont Orange en ont fait l'objet, et malheureusement certains clients en feront la triste expérience.

J'ai quand même du mal à croire que l'on ne peut pas y faire grand chose, question de moyen

On en met ou pas ...

reno69
Envoyer message

21748 points

Posté le 03 janvier 2018 à 18h21 Citer le commentaire

Normand BZH a écrit

reno69 a écrit Bonjour, les vols de données sont récurrents et il est difficile de s'en prémunir totalement pas mal de grandes entreprises dont Orange en ont fait l'objet, et malheureusement certains clients en feront la triste expérience. J'ai quand même du mal à croire que l'on ne peut pas y faire grand chose, question de moyen On en met ou pas ...

Bonjour, Normand BZH je ne suis pas aussi catégorique que vous, car comme on peu le constater même les fournisseurs d'antivirus doivent faire face à de nouveaux virus qu'ils doivent combattre après coup, c'est un peu comme le Gendarme et le voleur, le voleur à un coup d'avance car il choisi le moment propice et le lieu etc ...

Après il faut malgré cela essayer d'anticiper et se donner les moyens, mais ce n'est jamais gagné d'avance !!!