Discussion :

[Stéphane le calme]

Des milliers de vitrines en ligne sont compromises et permettent un vol d'informations de cartes de crédit,
des marchands estiment néanmoins qu'ils sont protégés par HTTPS

Willem de Groot, un chercheur en sécurité, veut tirer la sonnette d’alarme sur la fraude à la carte. Il rappelle dans un billet que, comme dans une fraude physique, les détails de votre carte bancaire sont volés et et d’autres personnes peuvent dépenser votre argent. Cependant, les fraudes en ligne sont plus efficaces dans la mesure où elles sont plus difficiles à détecter mais également qu’il est presque impossible de tracer les voleurs.

Comment cela se passe-t-il ? Dans les cas qu’il a observés, le Néerlandais confie que le pirate se fraie un chemin dans le code source d’une vitrine en ligne en passant par des vulnérabilités logicielles non colmatées. Une fois qu'une plateforme est sous le contrôle d'un pirate, il va installer une écoute électronique, généralement en JavaScript, qui va servir à canaliser les données de paiement vers un serveur off-shore (principalement en Russie). « Cette écoute électronique fonctionne de manière transparente pour les clients et les marchands. Les informations sur les cartes de crédit sont ensuite vendues sur le dark web avec un tarif de 30 dollars la carte », continue-t-il.

Au total, près de 6000 plateformes de e-commerce ont été compromises par des pirates seulement pour le mois de septembre, soit une augmentation annuelle de 69 %. En mars 2016, les vitrines affectées étaient au nombre de 4476 et en novembre 2015 elles étaient 3501.

Concernant les plateformes affectées, elles appartiennent à divers domaines / industries : le chercheur indique que les constructeurs de voitures sont concernés (comme Audi Za), mais également les plateformes gouvernementales (comme NRSC de Malaisie), sans oublier le domaine de la mode (avec Converse ou Heels.com par exemple), de la pop (avec Bjork) ou des ONG (comme Science Museum ou Washington Cathedral). Il a publié une liste complète sur GitHub qui s’est vue retirée.

Selon lui, cette vague d’intrusions sur les plateformes est l’œuvre de plusieurs entités. « En 2015, les cas rapportés de logiciels malveillants étaient tous des variations mineures de la même base de code. En mars 2016, une autre variété de logiciels malveillants a été découverte. Aujourd'hui, au moins 9 variétés et 3 familles de logiciels malveillants distinctes peuvent être identifiées. Cela donne à penser que des personnes ou des groupes multiples sont impliqués », a-t-il avancé.

Selon le chercheur, l’une des raisons pour lesquelles plusieurs piratages passent sous les radars se trouve dans la quantité d’effort mis pour obfusquer le code du logiciel malveillant. « Dans le cas des anciens logiciels malveillants, il y avait des instructions JavaScript plutôt visibles, mais, dans les dernières analyses, des versions plus sophistiquées ont été découvertes. Certains logiciels malveillants se sont servis d’une obfuscation multi-couches, qui va demander au développeur beaucoup plus de temps pour pouvoir appliquer une rétro-ingénierie. Ajoutez à cela le fait que la plupart des obfuscations embarquent un certain niveau d’aléatoire, cela sera encore plus difficile d’y appliquer des filtres statiques ».

Pour piéger l’observateur moyen, le logiciel malveillant s’est parfois fait passer pour un code UPS comme celui-ci :

Le chercheur indique qu’un autre signe de sophistication est la maturité des algorithmes de détection de paiement : « les premiers logiciels malveillants se contentaient d’intercepter les pages où figurait un checkout dans l'URL. Les versions plus récentes sont également à la recherche de plugins de paiement populaires tels que feu Checkout, Onestepcheckout et Paypal ».

Et qu’en disent les marchands ? Le chercheur assure avoir informé manuellement plusieurs plateformes du fait qu’elles avaient été compromises. Certaines lui ont répondu de façon assez curieuse, comme un marchand qui lui a déclaré « on s’en fout. Nos paiements sont gérés par une tierce partie ». À un autre, il a indiqué que si quelqu’un a pu injecter du code JavaScript dans son code source, alors sa base de données est probablement piratée. Il a reçu comme réponse « merci pour votre suggestion, mais notre magasin est parfaitement sécurisé. Il y a juste une erreur JavaScript ennuyeuse ». Ou encore une réponse plus forte que la précédente : « notre magasin est parfaitement sécurisé parce que nous nous servons du HTTPS ».

liste des vitrines impactées

Source : blog Gwillem

[atha2]

Les navigateurs modernes implémentent la Same Origin Policy qui devrait prévenir ce type d'attaque non ?

[Vulcania]

Et qu’en disent les marchands ? Le chercheur assure avoir informé manuellement plusieurs plateformes du fait qu’elles avaient été compromises. Certaines lui ont répondu de façon assez curieuse, comme un marchand qui lui a déclaré « on s’en fout. Nos paiements sont gérés par une tierce partie ». À un autre, il a indiqué que si quelqu’un a pu injecter du code JavaScript dans son code source, alors sa base de données est probablement piratée. Il a reçu comme réponse « merci pour votre suggestion, mais notre magasin est parfaitement sécurisé. Il y a juste une erreur JavaScript ennuyeuse ». Ou encore une réponse plus forte que la précédente : « notre magasin est parfaitement sécurisé parce que nous nous servons du HTTPS ».

Personnellement, je suis pour que les gens se prennent leurs responsabilité dans la face, genre que les assurances aillent taper sur les marchands "qui-s'en-foutent" qui perdent de l'argent à cause de ce genre de comportement .
Encore mieux, que les sites marchands ayant des failles connues soient signalés dans les moteurs de recherche, là ils se bougeront le cul parce que ça touche directement leurs tunes.

[vttman]

Certains règlements se sont par e-carte bleue mais je ne sais pas dans quelle proportion ...
Voler les infos d'une e-carte ne sert à rien je suppose, mais je peux me tromper ?

[tomlev]

Et qu’en disent les marchands ? Le chercheur assure avoir informé manuellement plusieurs plateformes du fait qu’elles avaient été compromises. Certaines lui ont répondu de façon assez curieuse, comme un marchand qui lui a déclaré « on s’en fout. Nos paiements sont gérés par une tierce partie ». À un autre, il a indiqué que si quelqu’un a pu injecter du code JavaScript dans son code source, alors sa base de données est probablement piratée. Il a reçu comme réponse « merci pour votre suggestion, mais notre magasin est parfaitement sécurisé. Il y a juste une erreur JavaScript ennuyeuse ». Ou encore une réponse plus forte que la précédente : « notre magasin est parfaitement sécurisé parce que nous nous servons du HTTPS ».

Quand on voit ce genre de réaction, on se dit qu'il y a encore beaucoup de chemin à parcourir pour changer les mentalités en matière de sécurité

[earhater]

Les navigateurs modernes implémentent la Same Origin Policy qui devrait prévenir ce type d'attaque non ?

Non, tu peux mettre un entête HTTP qui va permettre au navigateur de faire des requêtes ajax provenant de n'importe quel domaine;

[Iradrille]

Quand on voit ce genre de réaction, on se dit qu'il y a encore beaucoup de chemin à parcourir pour changer les mentalités en matière de sécurité

On pourrait rapidement changer la mentalité des gens en les condamnant pour complicité.

[gretro]

Je travaille dans le domain du e-commerce, et laissez-moi vous dire que ce n'est pas que les marchands qui ont des problèmes de sécurité. La plupart des fournisseurs de paiements sont des passoirs et des trous à sécurité, en plus d'avoir une API horrible et brisée.

Certains fournisseurs testent directement en environnement de test. C'est assez horrible de voir ses tests d'intégration échouer à cause que la tierce-partie a décidé qu'elle déployait directement en environnement de test, sans aviser personne et sans mettre-à-jour sa page de statut de service. Il en existe bien quelques-un qui s'intègrent à merveille, mais c'est l'exception plutôt que la règle. On serait donc peut-être dû pour sécuriser à la source même.

[athlon64]

Bonjour,

si on utilise des solutions de payement comme paypal(double authentification) ou e-Carte Bleue, ce problème est inexistant...

De mon côté je n'utilise quasiment pas la CB en ligne. Si j'avais le choix je ne ferai des achats que chez des vendeurs qui laisse la possibilité

de payer avec des moyens autre que la CB.

[alpha.omega]

Merci pour cet article intéressant

Je travaille dans le domain du e-commerce, et laissez-moi vous dire que ce n'est pas que les marchands qui ont des problèmes de sécurité. La plupart des fournisseurs de paiements sont des passoirs et des trous à sécurité, en plus d'avoir une API horrible et brisée.

Certains fournisseurs testent directement en environnement de test. C'est assez horrible de voir ses tests d'intégration échouer à cause que la tierce-partie a décidé qu'elle déployait directement en environnement de test, sans aviser personne et sans mettre-à-jour sa page de statut de service. Il en existe bien quelques-un qui s'intègrent à merveille, mais c'est l'exception plutôt que la règle. On serait donc peut-être dû pour sécuriser à la source même.

Je serai curieux de connaître les sources qui vous permettent d'avancer que "la plupart des passerelles de paiement sont des passoires"
OK pour les API obscures, mais cela n'a rien à voir avec la sécurité...
Je n'ai pas compris la dernière phrase.

[gretro]

Merci pour cet article intéressant

Je serai curieux de connaître les sources qui vous permettent d'avancer que "la plupart des passerelles de paiement sont des passoires"
OK pour les API obscures, mais cela n'a rien à voir avec la sécurité...
Je n'ai pas compris la dernière phrase.

Beaucoup de marchands ont de gros problème de fraude avec ces plateformes. Parfois, sécuriser le paiement peut être très difficile ou coûteux. Je parlais de sécurité en terme de fraude, plus qu'en terme technique. Bien que j'aie eu à intégrer certains systèmes (surtout du côté front-end), je n'ai jamais trop osé m'aventurer à pousser l'aspect sécuritaire technique (j'aurais peut-être dû essayer). Cependant, à voir comment la plupart de ces marchands sont en retard techniquement, je serais bien peu étonné d'apprendre l'existence de ces trous de sécurité (techniques).

[massimo16]

Quelques liens de recherche plus tard, on peut consulter ça :
https://gitlab.com/gwillem/public-sn...snippets/28813

[leonard08]

LE

[alpha.omega]

Beaucoup de marchands ont de gros problème de fraude avec ces plateformes. Parfois, sécuriser le paiement peut être très difficile ou coûteux. Je parlais de sécurité en terme de fraude, plus qu'en terme technique. Bien que j'aie eu à intégrer certains systèmes (surtout du côté front-end), je n'ai jamais trop osé m'aventurer à pousser l'aspect sécuritaire technique (j'aurais peut-être dû essayer). Cependant, à voir comment la plupart de ces marchands sont en retard techniquement, je serais bien peu étonné d'apprendre l'existence de ces trous de sécurité (techniques).

OK donc les trous de sécurité donc vous parlez sont chez les marchands et non les plateformes de paiement comme vous le disiez précédemment. La sécurité est justement la préoccupation n°1 des PSP...
Concernant la fraude, en France 3DSecure est un bon moyen de la réduire mais souffre d'une très mauvaise réputation en terme de taux de conversion. Sinon les PSP sérieux proposent des solutions à base de règles statiques et demain des solutions basées sur la data science voire l'analyse comportementale vont se démocratiser.

[cdubet]

pour la plupart des sites, la securite c est juste un cout, donc on minimise au max. Par ex en employant des gens incompetants (le coup du https est quand meme tres fort. il a meme pas essaye de comprendre le probleme)
Apres c est sur que certains site s en moquent vu que ca touche par leur business. C est le client qui aura des problemes s il se fait debiter.
Franchement ce type de reaction ne m etonne pas. j ai jamais travaille sur des site de commerce electroiques mais frequente longuements commerciaux et patrons de SSII.
C est exactement la meme mentalité: rien a foutre du moment que ca n impacte pas leur portefeuille a eux

Tant que le sites ne seront pas severement santionné (amende, liste doire sur le navigatuer (genre un message qui s affiche en disant que le site a ete comprmis , etes vous sur de vouloir risquer d y faire des achats) rien ne changera

[Cyrilh7]

Je pense qu'il faut prendre le problème à sa source. Il n'est pas normal de pouvoir faire un paiement avec que des informations qui sont toutes écrites en claire sur une CB! Il faut revoir tous les protocoles bancaires qui permette de faire deS paiements par carte. Il ne doit pas y en avoir tant que ça. Au lieu de mettre des normes PCI dans toutes les entreprises qui font du commerce. Autant essayer de sécurisé tout internet

[petitours]

Bonjour

Moi je viens de vivre ça sur le site d'un organisme pourtant pas petit
http://www.developpez.net/forums/d16...non-securisee/

Je ne sais même pas comment faire...