Fais ça maintenant
Fermez d’abord le chemin vulnérable. Si vous constatez des preuves de compromission, conservez-les avant de commencer le nettoyage.
- 1Préserver les preuves en cas de suspicion de compromission
Enregistrez les journaux actuels et effectuez une sauvegarde complète des fichiers et de la base de données avant de supprimer des comptes, des fichiers ou des tâches planifiées. Restreignez l'accès ou demandez de l'aide à votre hébergeur si les changements se poursuivent.
- 2Mettre à jour WooPayments
Installez la dernière version prise en charge par votre environnement WordPress et WooCommerce. Ne passez pas à la version 5.6.2, historiquement importante.
- 3Confirmer la version active
Dans WordPress, ouvrez Plugins et vérifiez la version affichée pour WooPayments, anciennement nommé WooCommerce Payments.
- 4Enquêter sur la période d’exposition
Si la version 5.6.1 ou une branche antérieure affectée était active, examinez les comptes privilégiés, le contenu, les logiciels, les tâches, les fichiers et les journaux d'audit disponibles.
Faits en bref
La gamme affectée est historique. Le choix opérationnel sûr aujourd’hui est la dernière version prise en charge.
- CVE
- CVE-2023-28121
- Produit
- WooPayments, anciennement WooCommerce Payments
- Versions concernées
- NVD décrit 5.6.1 et versions antérieures ; L’avis original de Woo concerne les branches vulnérables 4.8.0–5.6.1.
- Correctif historique
- La version 5.6.2 était la première version corrigée de la branche 5.6 ; Woo a également publié des versions corrigées pour les anciennes branches.
- Résultat potentiel
- Un attaquant non authentifié pourrait agir en tant qu'utilisateur élevé, y compris un administrateur.
- Gravité de la MVN
- CVSS 3.1 : 9,8 Critique (évaluation NVD)
« Affecté » signifie que le code vulnérable était présent. Cela ne signifie pas que tous les magasins exécutant cette version ont été ciblés ou compromis. Cet article ne répète pas intentionnellement la vieille affirmation selon laquelle des centaines de milliers de magasins ont été piratés ; les sources disponibles ne le supportent pas.
Comment fonctionnait le contournement de l'authentification
L’erreur s’est produite pendant que WordPress décidait quel utilisateur, le cas échéant, appartenait à la requête.
WordPress utilise le determine_current_user filtrer lors de l’établissement de l’utilisateur actuel. L’examen des sources de BitFire en 2023 a identifié la logique de WooCommerce Payments pour le paiement sur la plateforme qui acceptait les informations d’identité contrôlées par la demande lors de cette décision sans établir au préalable que l’appelant était digne de confiance.
Cette erreur a dépassé les limites de la confiance : les données fournies par une requête distante ont influencé l’identité de l’utilisateur de confiance du serveur. Le chemin de code vulnérable pourrait donc effectuer des vérifications ultérieures des autorisations WordPress en tant que compte élevé. Cette description explique l'échec de l'autorisation sans publier de demande de travail ou de charge utile.
Ma boutique a-t-elle été compromise ?
Aucune ligne de journal d’accès ne peut répondre à cette question. Examinez plusieurs sources de preuves indépendantes.
- 1Comptes d'administrateur et utilisateurs
Recherchez les comptes que vous ne reconnaissez pas, les changements de privilèges inexpliqués, les adresses e-mail inhabituelles et les heures de création qui chevauchent la période d'exposition.
- 2Articles, pages, plugins et thèmes
Examinez le contenu récemment créé, les logiciels installés, les composants activés et les modifications apportées aux fichiers de thème ou de plug-in.
- 3Travail planifié et persévérance
Inspectez le cron de WordPress, le cron du serveur, les plugins indispensables, les fichiers de démarrage et les fichiers PHP inattendus, en particulier dans les emplacements destinés aux médias.
- 4Journaux de sécurité, d'accès et d'audit
Créez une chronologie à partir des événements disponibles. Corrélez les demandes suspectes avec la création d’utilisateurs, les modifications de fichiers, les connexions et les activités sortantes.
Il indique seulement que le serveur a renvoyé une réponse HTTP réussie. De nombreuses demandes inoffensives font cela.
Cela peut montrer qu'une demande a été bloquée, mais pas que toutes les tentatives précédentes ou alternatives ont échoué.
L'adresse IP, la taille de la réponse et le modèle de requête unique imprimés dans l'ancien article ne sont pas des indicateurs autonomes fiables et ont été supprimés.
Liste de contrôle de récupération
Contenez les accès malveillants, conservez suffisamment de preuves pour les comprendre, puis supprimez la persistance et alternez les secrets.
- 1Préserver les journaux et une sauvegarde complète
Conservez des copies en dehors du compte d'hébergement concerné lorsque cela est possible.
- 2Enregistrez et désactivez les administrateurs non autorisés
Capturez les détails du compte et les heures pertinentes avant de supprimer l’accès. Confirmez que les comptes inconnus ne sont pas gérés par votre hôte, votre agence ou votre intégration.
- 3Analyser et étudier la persistance
Examinez les fichiers, le contenu de la base de données, les tâches planifiées, les sessions actives et les connexions sortantes. Suivez le Guide d'analyse et de nettoyage des logiciels malveillants BitFire.
- 4Contenir le code malveillant avant de modifier les secrets
Les logiciels malveillants actifs peuvent capturer de nouvelles informations d'identification. Isolez-le ou retirez-le d’abord chaque fois que l’incident le permet.
- 5Faites pivoter les informations d'identification que le magasin peut atteindre
Le cas échéant, réinitialisez les mots de passe d'administrateur, les sels et sessions WordPress, les clés d'API et de service de paiement, les informations d'identification d'hébergement et SFTP, ainsi que les informations d'identification de la base de données.
- 6Mettre à jour, tester et surveiller
Mettez à jour tous les logiciels pris en charge, supprimez les composants inutilisés, testez le paiement et les intégrations, et surveillez le retour des comportements suspects.
Pourquoi une protection multicouche est importante
La mise à jour du fournisseur est le correctif principal. Des contrôles indépendants peuvent réduire les risques avant l'installation d'un correctif ou si une autre erreur d'application apparaît.
Supprimer la faille connue
La mise à jour modifie la logique de l'application vulnérable et constitue le contrôle le plus direct et le plus fiable pour ce CVE.
Inspecter et restreindre les clients
Les contrôles des robots et les règles WAF peuvent réduire le trafic hostile, même si un exploit de logique d'identité peut ressembler à une demande d'application légitime.
Appliquer les opérations privilégiées
Les contrôles d'autorisation d'exécution peuvent ajouter une autre limite lorsqu'une demande non authentifiée tente une opération de compte, de fichier ou de base de données réservée à l'administrateur.
Ces contrôles sont complémentaires et non des garanties. Un WAF de signature de requête peut arrêter les modèles connus ; les contrôles d'exécution peuvent arrêter un résultat dangereux ; la surveillance peut révéler ce qui a été tenté. Aucun ne remplace les correctifs, le code d’application sécurisé, les sauvegardes testées ou la réponse aux incidents.
Chronologie et sources
Le tableau de l’exploitation a changé en mars 2023. Ces déclarations préservent les dates et le niveau de certitude de Woo.
- Vulnérabilité signalée
Woo dit que Michael Mazzolini de GoldNetwork a signalé le problème via son programme HackerOne.
- Woo a publié son avis
Woo a déclaré qu'il n'avait aucune preuve d'utilisation en dehors de ses propres tests de sécurité à l'époque et qu'il avait travaillé avec WordPress.org sur des mises à jour automatiques corrigées.
- D’éventuels rapports d’exploitation ont fait l’objet d’une enquête
Woo a mis à jour l'avis pour indiquer que quelques clients avaient signalé des exploits potentiels et qu'il enquêtait sur chaque rapport.
- NVD a publié CVE-2023-28121
NVD décrit l'accès administrateur à distance non authentifié et attribue un score de base CVSS 3.1 de 9,8.
Références
- Enregistrement NVD pour CVE-2023-28121
Description de la version concernée, évaluation CVSS et classification des faiblesses.
- Avis aux développeurs Woo et mises à jour datées
Correction du fournisseur, branches historiques corrigées et déclarations d'exploitation.
- Page officielle du plugin WooPayments
Informations sur la version actuelle et l'installation.
- Démonstration de contournement d'authentification 2023 de BitFire
Démonstration historique écrite par BitFire ; pas nécessaire pour appliquer la mise à jour.
FAQ CVE de WooPayments
Les numéros de version historiques sont utiles à des fins d’enquête et non comme cibles de rétrogradation.
La version 5.6.2 est-elle toujours la version que je dois installer ?
Non. La version 5.6.2 est historiquement importante en tant que premier correctif de la branche 5.6. Installez la dernière version de WooPayments prise en charge disponible pour votre environnement géré.
La mise à jour supprime-t-elle une porte dérobée existante ?
Non. La mise à jour ferme ce chemin vulnérable. Il ne supprime pas les fichiers, comptes, tâches, sessions ou modifications de base de données malveillants créés précédemment.
Chaque client devrait-il réinitialiser un mot de passe ?
L’avis de Woo indiquait que les mots de passe WordPress standard étaient hachés et ne prétendait pas que chaque mot de passe était exposé. Utilisez les preuves et la période d’exposition pour guider la réponse. En cas d'activité suspecte, contientz du code malveillant, puis alternez les mots de passe d'administrateur, les sessions, les sels, les clés API, les clés de paiement ou de service et les informations d'identification de l'infrastructure concernés, le cas échéant.
Une version concernée signifie-t-elle que ma boutique a été piratée ?
Non, cela signifie que le code vulnérable était présent. Les termes « vulnérable », « ciblé » et « confirmé compromis » décrivent différentes conditions et ne doivent pas être traités comme des synonymes.
