Les lettres de créances CDN déclenchent une attaque silencieuse qui a exposé des centaines de milliers de sites WordPress

Une attaque sur la chaîne d'approvisionnement qui a profité des références CD d'Awesome Motive a compromis les scripts distribués par WordPress OptinMonster, TrustPulse et, au moins partiellement, les plugins PushEngage, exposant des centaines de milliers de sites à une intrusion silencieuse et dirigé vers les administrateurs web.

Selon l'analyse publique réalisée par la société Sansec, les agresseurs ont modifié les fichiers JavaScript servis des sous-domaines fournisseurs - sur des itinéraires tels que / application / js / api.min.js- exécuter du code malveillant sur les pages qui ont chargé ces ressources ; OptinMonster, la solution la plus répandue du trio, a plus d'un million d'installations et concentre donc le plus grand risque d'impact de masse. Le rapport technique est disponible ici: Rapport Sansec.

Le vecteur initial n'était pas un échec dans OptinMonster mais l'exploitation d'une vulnérabilité connue dans le plugin UpdatPlus sur un serveur de marketing d'Awesome Motive qui, bien que séparé de l'infrastructure de production, stockait des identifiants CDN. Avec cette clé, les attaquants ont modifié les scripts distribués, une illustration de la façon dont la perte d'un titre apparemment périphérique peut déclencher un engagement en chaîne.

La campagne n'a été conçue pour être activée que lorsqu'un administrateur WordPress a visité le site : l'authentification JavaScript capturée et les jetons nonces, les ont utilisés pour créer de faux comptes d'administrateur, ont installé un plugin backdoor qui était caché avec des noms changeants et ont déployé un web shell qui a permis l'exécution arbitraire de PHP et la télécommande totale du site. Awesome Motive a publié sa propre communication sur l'incident, qui devrait être revue: déclaration de Awesome Motive.

Le scénario est préoccupant pour plusieurs raisons: premièrement, l'invasion s'est produite sans toucher le dépôt de code du fournisseur ou les serveurs de production, ce qui complique la détection; deuxièmement, l'activation conditionnée à l'accès d'un administrateur permet de rester latente pour obtenir des identifiants précieux; et troisièmement, la technique de renommer le plugin malveillant tout en maintenant la logique intacte rend difficile la détection basée sur des signatures ou des noms de fichiers.

Si vous gérez un WordPress en utilisant l'un de ces plugins, vous devez vous engager et agir d'urgence : rechercher et supprimer des comptes administratifs inconnus (Sansec et Awesome Motive ont identifié des noms d'exemple utilisés par les attaquants), inspecter manuellement le contenu de wp-content / plugins pour détecter des dossiers ou des fichiers cachés avec des noms inhabituels ou changeants, et exécuter des analyses de malware à partir du serveur. Pour des guides pratiques sur le durcissement et les bonnes pratiques, voir la documentation officielle : WordPress durcissement Guide.

Il est également essentiel de faire pivoter tous les identifiants potentiellement compromis : mots de passe de compte de gestion, clés API (surtout CDN), identifiants de base de données et sauts WordPress. Si vous avez la capacité, restaure à partir d'une sauvegarde avant la date de l'incident et compare les hachages et les listes d'utilisateurs à l'installation actuelle; ne supprime aucune trace sans d'abord faire une copie médico-légale si vous avez besoin d'enquêter sur la portée et les vecteurs.

Au niveau de l'organisation, les fournisseurs de services de sécurité et les organismes devraient revoir le principe du privilège minimum : les pouvoirs sensibles ne devraient pas être stockés dans des environnements de marketing ou des serveurs moins rigoureux; la séparation des fonctions, la rotation automatique des clés et l'audit d'accès réduisent la probabilité qu'un seul défaut entraîne un engagement à grande échelle.

Pour les propriétaires de site qui ont déjà nettoyé les charges malveillantes, attention : la simple suppression du script modifié dans le CDN ne garantit pas la sécurité tant qu'il y a des comptes administratifs illégaux ou des plugins cachés qui permettent de rétablir l'accès. Il est nécessaire de vérifier les tâches programmées, vérifier l'intégrité des fichiers PHP et surveiller les connexions sortantes aux domaines suspects utilisés pour exfilter des données.

Enfin, cet incident renforce une leçon clé en matière de cybersécurité dans les écosystèmes complexes : les chaînes d'approvisionnement et les services partagés tels que les CDN sont des points de concentration des risques qui nécessitent des contrôles techniques (AMF, rotation des clés, registres immuables), opérationnels (procédures d'intervention rapides) et contractuels (exigences de sécurité pour les fournisseurs) afin de minimiser la portée lorsque quelque chose échoue.