Que faire contre la dernière vulnérabilité: les données de carte de crédit volées?


11

Après que la nouvelle soit sortie il y a quelques jours, je n'ai pas beaucoup entendu parler - et aucune déclaration officielle - de la toute dernière vulnérabilité. Sucuri dit qu'il est possible de recevoir des informations de carte de crédit, ou même toutes les données, $_POSTy compris les mots de passe administrateur et autres.

Je n'ai pas encore eu de cas où un client a été piraté, mais je ne veux pas attendre que cela se produise pour agir. Quelqu'un a-t-il déjà vu un patch?


Étant donné le dernier article de Sucuri, vous pourriez également être intéressé par les réponses de @Ben Lessani (Sonassi) ici: magento.stackexchange.com/a/72697/231
Anna Völkl

Réponses:


8

À quel type de patch ou de déclaration officielle vous attendez-vous? Le billet de blog indique seulement qu'une application Web peut être compromise une fois que l'attaquant a accès au code. Cela s'applique à chaque application Web. Le terme Magento y est totalement interchangeable. Actuellement, ils ne savent pas comment l'hôte affecté a été compromis. La porte ouverte dans les exemples donnés pourrait être tout, allant des problèmes de serveur à la "couche 8".

Tant qu'ils restent vagues et ne fournissent pas d'informations précieuses, tout cela est à peu près du marketing, comme répandre le nom de leur entreprise, faire des vagues, se positionner en tant qu'experts en sécurité, etc. Combiner des mots à la mode comme "voler" "carte de crédit" " Magento "fait évidemment une bonne histoire.

Ce que nous pouvons encore apprendre de ce post:

  • Surveillez régulièrement votre base de code pour tout changement inattendu.
  • Laissez la gestion des données de paiement à une PSP.

Mise à jour: Il y a maintenant une déclaration officielle de Ben Marks .


Oui, je sais que la source est assez peu spécifique. Je ne sais pas non plus s'ils ont contacté Magento / eBay à propos de ce problème. Quoi qu'il en soit, il est toujours possible (et cela s'est produit deux fois au cours des derniers mois) qu'il s'agit d'un bogue de base, et je m'attendais au moins à une déclaration comme "nous enquêtons" ou "pas notre faute, un module".
simonthesorcerer

Je conviens que la cause de base peut également être l'une des milliers d'extensions disponibles ou toute version (non corrigée) de Magento. Encore trop peu d'informations pour prendre des mesures ciblées à mon humble avis.
mam08ixo

3

Tant que votre version de Magento est à jour, vous avez installé tous les derniers correctifs et votre serveur répond aux meilleures pratiques en matière de configuration (autorisations de fichiers, pas un autre logiciel / site Web en cours d'exécution, pare-feu, etc.), c'est tout ce que vous pouvez faire pour l'instant .

Je pense qu'il est important de mentionner qu'il n'y a pas encore de vecteur d'attaque spécifique:

Alors, comment fonctionne l'attaque? Nous enquêtons toujours sur les vecteurs d'attaque. Il semble cependant que l'attaquant exploite une vulnérabilité dans le noyau Magento ou un module / extension largement utilisé.

Éditer:

Comme mentionné dans mon commentaire ci-dessus, vous pouvez également consulter la réponse détaillée de Ben Lessani à une autre question connexe qui fournit des informations générales: /magento//a/72697/231


2

Pas (seulement) Magento

J'ai vu de nombreux autres sites Web piratés de cette façon, insérant du code malveillant dans la base de code, et pas seulement dans Magento. Et il existe de nombreuses variantes: scripts volant des données POST, scripts ajoutant XSS, scripts essayant de voler les mots de passe root, scripts permettant aux appels entrants de traiter les données (pour le minage Bitcoin, d'envoyer des spams depuis ce serveur), etc ...

Dans certains cas, la cause a été volée des informations d'identification FTP (par des virus / programmes malveillants) sur un ordinateur client, dans d'autres cas, il a utilisé un exploit dans l'application.

Il existe de nombreuses autres applications qui peuvent fournir un accès au serveur via des exploits, par exemple WordPress.

Il n'y a qu'un seul cas où Magento serait à blâmer et une action de Magento est à prévoir et c'est: si l'application exploitée devait être Magento de la dernière version et entièrement corrigée.

Il n'y a donc qu'une faible chance que ce cas mis en évidence ait été causé par une défaillance de Magento en premier lieu. C'est pourquoi vous n'entendez rien de Magento.

La nouveauté ici est que le code inséré cible très spécifiquement Magento et utilise l'architecture et les principes de code de Magento.

Que faire

Maintenant, pour donner une réponse à votre question "Que faire contre cela?"

  • Ne jamais exécuter deux applications différentes sur la même instance de serveur
    comme WordPress + Magento. Parfois, vous voyez WordPress fonctionner comme dans www.magentoshop.com/blog/ ou Magento s'exécuter sur www.wordpresswebsite.com/shop/. Ne fais pas ça. Les exploits dans WordPress peuvent donner à l'attaquant l'accès à vos données Magento.

  • Utilisez un système de contrôle de version
    J'utilise GIT et je l'ai également sur le serveur (accès en lecture seule) pour déployer le site Web. Cela me donne également un aperçu rapide des modifications du système en cours d'exécution git status.

  • N'utilisez jamais FTP, seulement SFTP, ne stockez jamais les mots de passe
    J'ai mentionné ci-dessus que les mots de passe FTP ont été volés sur un ordinateur client. L'utilisation de FTP n'est pas non plus sécurisée car elle enverra des données non cryptées via Internet. Utilisez donc SFTP et ne stockez jamais vos mots de passe dans votre application FTP, ne soyez pas paresseux et saisissez-les à chaque fois que vous vous connectez à votre serveur.


En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.