Avec un score CVSS de 9.0, le bug en question n’a pas encore de numéro CVE pour l’identifier, mais Magento y fait référence dans sa liste de correctifs sous le nom PRODSECBUG-2198 (le chiffre mentionné étant l’information la plus importante ici).
C’est une faille d’injection SQL qui peut être exploitée sans authentification, ni privilège. C’est pourquoi, pour les administrateurs qui s’occupent de sites utilisant Magento, la priorité est la suivante : arrêtez immédiatement ce que vous faites et installer le correctif au plus vite.
Ce n’est pas difficile, car Magento, propriété d’Adobe, a corrigé ce problème en même temps que plusieurs dizaines d’autres failles de sécurité dans le cadre d’une mise à jour de sécurité publiée tout récemment. Les versions concernées sont :
- Version 1 avant 2.1.17
- Version 2.2 avant 2.8
- Version 2.3 avant 3.1
- Magento Open Source avant 9.4.1
- Magento Commerce avant 14.4.1
Le correctif pour 2198 peut être installé seul, mais idéalement, les sites doivent installer la mise à jour complète. Voici l’annonce faite par Magento :
Pour vous protéger contre cette vulnérabilité mais aussi contre d’autres, vous devez mettre à niveau votre système vers Magento Commerce ou Open Source 2.3.1 ou 2.2.8. Nous vous suggérons fortement d’installer ces correctifs complets dès que possible.
Sur un total de 37 failles allant du Cross-Site Request Forgery (CSRF) au Cross-Site Scripting (XSS), il existe également une faille sérieuse (score CVSS de 9.8) de type RCE, identifiée comme PRODSECBUG-2192, et qui mérite une attention particulière.
Malheur aux retardataires
Qu’en est-il des attaques ciblant des sites Magento ? Cette histoire a débuté le 25 mars lorsque l’entreprise française peu connue Pentesting Ambionics Security (qui a également révélé le fameux bug Carpe Diem dans Apache récemment) a tweeté ce qui suit :
Tomorrow, #Magento releases a patch for an unauthenticated #SQLi and #RCE we reported a few months ago. We’ll describe the vulnerabilities, and how they can be exploited, in our next blog post. Patch your systems ! pic.twitter.com/aGnZ2m4Zbu
— Ambionics Security (@ambionics) 25 mars 2019
Fidèle à sa parole, Ambionics a publié le 29 mars un article de blog présentant plus de détails sur 2198, indiquant notamment que Magento avait versé une prime bug bounty à l’entreprise pour l’avoir révélée de manière responsable en novembre dernier.
L’article de blog incluait un lien GitHub vers un code d’exploitation de type preuve-de-concept (POC) sans indiquer clairement qui l’avait développé.
Le même jour, Pete Jaap Blaakmeer, CTO d’Elgentos Ecommerce, a tweeté qu’il avait remarqué des attaques basées sur le POC de 2198 :
Magento devs, if you haven’t patched already, do it ASAP. We’ve already seen attempts at two of our shops using the published POC. We’re safe because we already patched every shop on Wednesday. https://t.co/5nZjMGBEUu
— Peter Jaap Blaakmeer (@PeterJaap) 29 mars 2019
Par ailleurs, Blaakmeer l’a aussi confirmé à un journaliste.
Les chercheurs ont rendu publique le code POC très peu de temps après la mise à disposition d’un correctif. Une telle situation n’est pas exceptionnelle mais pose un problème car cela met les sites sous une pression énorme pour la mise à jour.
Une autre façon de voir les choses est de dire que les administrateurs de Magento doivent simplement s’adapter à la nécessité d’appliquer les mises à jour de sécurité en tant que priorité absolue, et ce en quelques heures à peine.
Ce n’est pas comme s’il n’y avait pas eu d’avertissements indiquant que Magento et d’autres plateformes étaient ciblées.
En août dernier, le malware MagentoCore, de type skimming de cartes, a été découvert sur des milliers de sites Magento, dont certains semblaient être infectés depuis des mois.
Plus récemment, un rapport a révélé que les sites Magento étaient utilisés pour tester des cartes de crédit récupérées en utilisant des transactions à “zéro dollar” afin de déterminer celles qui pouvaient être vulnérables vis-à-vis d’éventuelles fraudes.
Billet inspiré de Patch now! Magento e-commerce sites targeted by SQLi attacks, sur Sophos nakedsecurity.
