Cosmicsting : Cyberattaque sur Adobe Commerce et Magento

Introduction :

 

Dans le domaine de la cybersécurité en pleine mutation, une nouvelle menace sérieuse s’attaque aux boutiques Adobe Commerce. Appelée « CosmicSting », cette attaque sophistiquée présente un danger considérable et pourrait toucher jusqu’à 75 % des boutiques Adobe Commerce. CosmicSting tire parti d’une faille critique dans les plateformes Adobe Commerce et Magento, permettant aux cybercriminels de lire des données  sensibles comme les mots de passe et d’injecter du code malveillant pour compromettre la sécurité des données des clients. Ce blog vous propose de découvrir en détail le fonctionnement de CosmicSting ainsi que les actions à mettre en place pour protéger efficacement votre commerce.

CosmicSting (CVE-2024-34102) : Une cybermenace exploitant les failles critiques d’Adobe Commerce et Magento.

CVE-2024-34102 est une faille de sécurité sévère résultant d’une mauvaise gestion de la désérialisation imbriquée dans Adobe Commerce et Magento. Cette vulnérabilité permet aux attaquants d’exploiter les entités externes XML (XXE) pendant le processus de désérialisation, ce qui peut potentiellement conduire à l’exécution de code à distance. En résumé, les attaquants peuvent créer des charges JSON malveillantes qui, lorsqu’elles sont désérialisées par l’application, instancient des objets avec des propriétés ou des comportements inattendus, entraînant divers risques de sécurité.

L’exploitation de cette vulnérabilité permet aux attaquants d’obtenir un accès administratif non autorisé aux API REST, GraphQL ou SOAP, ce qui peut conduire à un vol de données, des perturbations de service et une compromission complète des systèmes affectés. Cette vulnérabilité pose un risque significatif en raison de sa capacité à exfiltrer des fichiers sensibles, tels que app/etc/env.php, contenant des clés cryptographiques utilisées pour l’authentification. Les attaquants peuvent exploiter cette faille pour forger des jetons administratifs et manipuler les API de Magento en tant qu’utilisateurs privilégiés.

 

De plus, la CVE-2024-34102 peut être associée à d’autres vulnérabilités, telles que l’exploitation des chaînes de filtres PHP (CVE-2024-2961), entraînant l’exécution de code à distance (RCE). Les implications plus larges des vulnérabilités d’entité externe XML (XXE) permettent aux attaquants de récupérer et de manipuler des données provenant de sources externes, exacerbant ainsi l’impact potentiel sur les systèmes compromis.

Impact

L’impact de la CVE-2024-34102 (CosmicSting) sur Adobe Commerce et Magento est sévère, affectant plus de 140 000 instances de Magento à l’échelle mondiale fin 2023. De plus, selon Sansec, la vulnérabilité pourrait toucher environ 75 % des boutiques Adobe Commerce.

Versions affectées

Plateformes :

  • Toutes les plateformes sont affectées pour Adobe Commerce et Magento Open Source.

  • Installation manuelle du plugin Webhooks pour Adobe Commerce.

  • Versions :

  • Adobe Commerce : versions antérieures à : 2.4.7 ; 2.4.6-p5 ; 2.4.5-p7 ; 2.4.4-p8 ; 2.4.3-ext-7 ; 2.4.2-ext-7

  • Magento Open Source : versions antérieures à : 2.4.7 ; 2.4.6-p5 ; 2.4.5-p7 ; 2.4.4-p8

  • Plugin Webhooks d’Adobe Commerce : versions de 1.2.0 à 1.4.0

Chronologie

Décembre 2023

  • 20 décembre 2023 : Le rapport de vulnérabilité est soumis à HackerOne par Sergey Temnikov.

Janvier 2024

  • 8 janvier 2024 : HackerOne soumet le rapport à Adobe.

Juin 2024

  • 11 juin : Avis d’Adobe concernant Adobe Commerce/Magento au sujet d’une vulnérabilité sévère d’injection d’entité XML pré-authentification (CVE-2024-34102), évaluée par Adobe avec un score CVSS de 9.8. La CVE-2024-34102 est donc publiée.

  • 18 juin : Sansec note que 75 % des magasins n’ont toujours pas appliqué de correctifs et met en garde contre une exploitation massive de CosmicSting.

  • 23 juin : Sergey Temnikov (spacewasp), le découvreur du problème, alerte sur la gravité de CosmicSting. Il souligne que des tiers peuvent obtenir un accès administrateur à l’API sans avoir besoin d’une version Linux vulnérable (liée au problème iconv). Il recommande un correctif d’urgence amélioré.

  • 23 juin : Sansec découvre les premières attaques CosmicSting en cours (provenant de l’adresse IP 185.175.225.116).

  • 26 juin : Une analyse approfondie est publiée par AssetNote.

  • 26 juin : AssetNote publie des détails sur les attaques et les premiers kits d’exploitation apparaissent sur GitHub.

  • 26 juin : Adobe augmente la note de sévérité de 3 à 2.

  • 27 juin : Adobe publie un correctif autonome officiel pour CosmicSting qui peut être appliqué aux installations sans nécessiter une mise à niveau complète.

  • 27 juin : Hypernode rapporte avoir observé les premières instances de scans et d’abus effectif de CosmicSting dans la nature. Ils incitent toutes les parties concernées à patcher immédiatement leurs systèmes.

Juillet 2024

  • 8 juillet : Adobe augmente la note de sévérité de 2 à 1 (critique).

  • 12 juillet : Sansec observe des hacks massifs de magasins Adobe Commerce de haut profil. Des marques connues figurent parmi les victimes.

Août 2024

  • 21 août : Adobe publie le correctif AC-12485 pour invalider les anciennes clés de cryptage. Cela est vital, car sinon, les attaquants continueront à modifier vos blocs CMS.

  • 27 août : Les attaquants combinent CosmicSting avec le bug CNEXT, leur permettant d’exécuter du code sur votre serveur (également connu sous le nom d’exécution de code à distance). Il s’agit d’une escalade sérieuse, car les attaquants peuvent désormais installer des portes dérobées pour dissimuler leur présence et rester persistants sur vos serveurs.

Septembre 2024

  • 4 septembre : Le magasin Cisco est piraté à l’aide de l’attaque CosmicSting.

Octobre 2024

  • 14 octobre : Le groupe Peschanki compromet plus de 2000 magasins en quelques heures, lors du plus grand piratage automatisé à ce jour.

  • 21 octobre : Une nouvelle campagne de grande envergure est lancée par le groupe Laski, infectant plus de 1200 magasins.

Mesures Critiques pour Sécuriser votre Installation Adobe Commerce

Pour protéger votre système contre les attaques potentielles, suivez ces étapes essentielles :

Protéger votre Clé de Chiffrement

  • Mise à jour : Installez la dernière version d’Adobe Commerce pour empêcher les attaquants de voler votre clé cryptographique (clé de chiffrement).

  • Rotation de Clé : Considérez que votre clé actuelle a déjà été compromise. Générez une nouvelle clé et invalidez l’ancienne pour empêcher tout usage abusif.

Recommandation : Mettre à jour vers la dernière version d’Adobe Commerce est la solution la plus efficace. Cependant, notez que cette mise à jour inclut des changements fonctionnels, comme l’application stricte d’une politique de sécurité de contenu (CSP), ce qui pourrait affecter vos processus de commande.

Solution Alternative : Patch Isolé

  • Si la mise à jour n’est pas possible, appliquez le patch isolé fourni par Adobe pour réduire les vulnérabilités.

Rotation de la Clé après la Mise à jour

  • Après la mise à jour, effectuez une rotation de vos clés de chiffrement comme indiqué par Adobe. Notez que les données chiffrées avec l’ancienne clé ne sont pas automatiquement rechiffrées avec la nouvelle. Pour automatiser ce processus, utilisez le module de rotation de clé fourni par Luke Rodgers chez GENE Commerce — fortement recommandé.

  • Consultez également votre documentation sur la rotation des clés pour des instructions spécifiques sur la manière de mettre en œuvre cette rotation dans votre système actuel. Cette étape est cruciale pour assurer la sécurité et minimiser les risques liés à une clé compromise.

Solution d'Urgence (à Court Terme)

Si des actions immédiates sont nécessaires, vous pouvez temporairement bloquer l’accès à l’API CMS Block :

Bloquer les Requêtes à l’API CMS Block

Ajoutez le code suivant en haut de  app/bootstrap.php pour empêcher l’accès à l’API :

if (preg_match(‘/\/rest\/.*\/cmsBlock/m’, $_SERVER[‘REQUEST_URI’])) {
    http_response_code(503);
    echo “Service Unavailable”;
    exit();
}

Attention : Cette mesure est provisoire et ne garantit pas une sécurité totale pour votre système. Les attaquants peuvent toujours :

  • Accéder à d’autres fichiers sur votre serveur, et ainsi continuer d’obtenir vos nouvelles clés de chiffrement.

  • Exploiter d’autres points de terminaison REST pour extraire des données clients sensibles (par exemple, via l’endpoint des commandes).

  • Effectuer une exécution de code à distance en combinant cette vulnérabilité avec d’autres failles.

Read More

CosmicSting stratégies et défenses

Introduction

La montée en puissance des cybermenaces, comme l’attaque CosmicSting, souligne l’importance d’une gestion proactive de la sécurité des systèmes. Cette vulnérabilité, qui cible principalement les boutiques Adobe Commerce et Magento, expose les données sensibles à des risques considérables. 

Pour contrer ces menaces, il est crucial d’adopter des mesures préventives, notamment la rotation régulière des clés de chiffrement. Dans cet article, nous examinerons l’importance de cette pratique et vous fournirons des conseils sur la manière de l’appliquer efficacement dans votre environnement. En vous engageant dans des stratégies de défense robustes, vous pourrez mieux protéger vos ressources et renforcer la résilience de votre infrastructure face aux menaces émergentes.

1.Mise à Jour Essentielle : Appliquer le Dernier Patch Adobe

Il est impératif de mettre à jour votre système vers la dernière version du correctif fournie par Adobe  avant d’effectuer la rotation des clés. Cette étape garantit que toutes les vulnérabilités connues sont corrigées, offrant ainsi une base sécurisée pour la gestion de vos clés cryptographiques. Ne négligez pas cette mise à jour cruciale, car elle joue un rôle essentiel dans la protection de vos données sensibles contre les menaces potentielles..

1.Pourquoi la Rotation de la Clé est Essentielle

Même si votre boutique est sécurisée, il existe toujours un risque qu’un jeton JWT (JSON Web Token) ait été émis et demeure valide. Pour cette raison, il est fortement recommandé aux marchands de procéder à une rotation de la clé de chiffrement pour renforcer la sécurité. Cependant, il est important de noter que le processus de rotation de clé de Magento ne désactive pas automatiquement l’ancienne clé, ce qui peut présenter des vulnérabilités résiduelles. Le module gene encryption module peut simplifier cette procédure en invalidant efficacement les anciennes clés tout en régénérant les valeurs chiffrées avec la nouvelle clé. Cela garantit une sécurité complète pour votre boutique en ligne et protège les données sensibles des clients.

 

Voici les étapes générales à suivre pour prévenir les attaques liées à CosmicSting. Lisez attentivement chaque étape pour comprendre les fonctionnalités de ce module ainsi que les points de vulnérabilité potentiels.

1. Identification des Tables Utilisant la Clé de Chiffrement :

Commencez par effectuer une sauvegarde complète de la base de données, que nous utiliserons pour déterminer quelles tables contiennent des valeurs chiffrées. Si une sauvegarde de production n’est pas réalisable, vous pouvez recourir aux environnements de staging ou de QA. Une fois la sauvegarde effectuée, utilisez la commande suivante pour extraire les données :

 

mysqldump –databases nom_de_la_base > chemin/vers/backup.sql

 

Une fois la sauvegarde effectuée, vous pourrez repérer les tables contenant des valeurs chiffrées. Pour ce faire, utilisez grep pour rechercher les tables en analysant le fichier de sauvegarde :

 

grep -P “VALUES\s*\(.*\d:\d:…*'” chemin/vers/backup.sql | awk ‘{print $3}’ | sort | uniq -c

 

Cela vous fournira une liste des tables contenant des valeurs chiffrées, lesquelles devront être régénérées avec la nouvelle clé .

 

2.Installation De Module gene encryption:

installez le module Gene Encryption Key Manager disponible sur GitHub. Ce module offre des fonctionnalités avancées pour gérer efficacement les clés de chiffrement.

Lien vers le module : Gene Encryption Key Manager sur GitHub 

 

composer require gene/module-encryption-key-manager
bin/magento setup:upgrade

3.Générer une nouvelle clé et empêcher l'utilisation des anciennes pour les JWT

C’est la priorité absolue pour chaque marchand ! Installez ce module et générez une nouvelle clé en utilisant la commande suivante :

 

php bin/magento gene:encryption-key-manager:generate [–key=MA_NOUVELLE_CLE_DE_32_CARACTERES] [–skip-saved-credit-cards]  —force

 

Cette action forcera  le JWT factory  à utiliser la nouvelle clé. D’autres parties de l’application peuvent encore recourir aux anciennes clés, mais cette étape est essentielle pour contrer les attaques de CosmicSting.

Utilisez l’option –key pour définir manuellement la nouvelle clé à utiliser lors de la réinitialisation du chiffrement. Si aucune clé personnalisée n’est fournie, une nouvelle clé sera automatiquement générée.

 

L’option  –skip-saved-credit-cards permet de ne pas ré-encrypter les données de cc_number_enc dans la table sales_order_payment. Cette table peut être volumineuse, et de nombreuses boutiques n’y conservent aucune donnée.

4.Correction des Valeurs de Configuration Manquantes:

Ces commandes s’exécutent en mode dry run par défaut, ce qui vous permet d’effectuer un premier passage pour visualiser les modifications qui seront apportées. Une fois que vous êtes satisfait des résultats, vous pouvez exécuter la commande avec l’option –force  pour appliquer les changements.

Pour résoudre les valeurs de configuration manquantes, exécutez la commande suivante :

php bin/magento gene:encryption-key-manager:reencrypt-unhandled-core-config-data 

 

Cela réencryptera les données de configuration principales qui n’ont pas été prises en charge. Une fois que cette opération est terminée, vous pouvez relancer la commande pour vérifier que tout a été correctement mis à jour :

 

php bin/magento gene:encryption-key-manager:reencrypt-unhandled-core-config-data

5.Correction des Données 2FA

Pour corriger les données liées à l’authentification à deux facteurs (2FA), exécutez la commande suivante :

php bin/magento gene:encryption-key-manager:reencrypt-tfa-data

 

Après avoir effectué cette opération, relancez la commande pour vérifier que tout a été correctement mis à jour :

 

php bin/magento gene:encryption-key-manager:reencrypt-tfa-data

6.Correction des Colonnes Supplémentaires Identifiées

Il est également important de réencrypter toutes les autres colonnes identifiées  avec la cmd Grep . Assurez-vous de vérifier chaque table et colonne. Soyez vigilant, en particulier avec les colonnes entity_id, row_id  et id.

Voici la commande à exécuter pour encrypter les colonnes supplémentaires  :

php bin/magento gene:encryption-key-manager:reencrypt-column entity_name entity_id column_name 

Exemples: 

php bin/magento gene:encryption-key-manager:reencrypt-column customer_entity entity_id rp_token

 

php bin/magento gene:encryption-key-manager:reencrypt-column oauth_token entity_id secret

 

php bin/magento gene:encryption-key-manager:reencrypt-column oauth_consumer entity_id secret

 

Après chaque commande, assurez-vous de vérifier que les valeurs ont été correctement mises à jour dans la base de données. 

7.Vider le Cache

Pour vider le cache de votre installation Magento, exécutez la commande suivante :

php bin/magento cache:flush

 

À ce stade, toutes vos données devraient avoir été migrées vers votre nouvelle clé de chiffrement. Pour vous aider à vérifier cela, vous pouvez effectuer les opérations suivantes :

Configurer les Paramètres de Journalisation:

Activez la journalisation des décryptages pour vérifier que rien n’utilise encore l’ancienne clé :

php bin/magento config:set –lock-env dev/debug/gene_encryption_manager_only_log_old_decrypts 1

 

php bin/magento config:set –lock-env dev/debug/gene_encryption_manager_enable_decrypt_logging 1

 

Surveillez vos journaux à la recherche de “gene encryption manager” pour vérifier que rien n’utilise encore l’ancienne clé.

8.Invalidation de l'Ancienne Clé

Une fois que vous êtes satisfait des vérifications, vous pouvez invalider votre ancienne clé avec la commande suivante :

php bin/magento gene:encryption-key-manager:invalidate


Avant l’invalidation env.php

Après l’invalidation : 

Note:

 

Notez que Magento\Catalog\Model\View\Asset\Image continuera à utiliser la clé à l’index 0 dans la section crypt/invalidated_key.

9.Tests à Effectuer

Assurez-vous de bien tester les éléments suivants :

  • Toutes les intégrations qui utilisent les API de Magento.

  • Les médias doivent toujours s’afficher avec le même répertoire de hachage. S’il se régénère, cela pourrait occuper un espace disque considérable et augmenter le temps d’exécution.

  • Connexion/Déconnexion des utilisateurs administrateurs.

  • Connexion/Déconnexion des clients.

En effectuant ces tests, vous vous assurez que tout fonctionne correctement après la migration vers la nouvelle clé de chiffrement.

 

Read More