ButterCMS est un outil populaire utilisé pour gérer le contenu des blogs. Plus tôt cette semaine, nous avons remarqué un incident de sécurité potentiellement grave qui a incité l'équipe à retirer ButterCMS de notre site, et à lancer une enquête approfondie sur ce qui s'est passé. Potentiellement 1 660 sites web et plus de 5 800 domaines ont été impactés.
Notre objectif est de partager les conclusions de notre enquête pour montrer ce qui peut arriver lorsque vous faites confiance à des tiers dynamiques sans vérification continue.
L'incident ButterCMS
Nous avons observé le début de l'incident à 08h00 (PT) le 9 septembre, lorsque nous avons remarqué une augmentation significative des erreurs car le DNS ne parvenait pas à résoudre le nom d'hôte. Cela a entraîné une panne du blog sur notre site web.
Peu après, nous avons remarqué que le site ButterCMS était hors service car aucun enregistrement DNS n'était servi.
En creusant davantage, nous avons remarqué que le domaine ButterCMS avait une mise à jour WhoIs au même moment où nos problèmes ont commencé. Une raison logique à cela aurait pu être un renouvellement ou un changement de propriété du domaine. Ce dernier cas aurait été très préoccupant.
Si le domaine avait été « capturé » et était tombé entre des mains malveillantes, cela aurait pu poser un risque de sécurité sérieux, similaire à l'incident Polyfill, où un changement de propriété de domaine a causé une attaque majeure de la chaîne d'approvisionnement des navigateurs sur près de 500 000 sites web. Cela a entraîné l'injection de code malveillant dans les navigateurs de millions de visiteurs, provoquant des redirections malveillantes et potentiellement d'autres attaques furtives qui n'ont pas été remarquées en raison de la sous-utilisation de la surveillance de sécurité côté client.
À ce stade, nous avons entièrement désactivé l'intégration ButterCMS pour empêcher que des données soient servies depuis le domaine potentiellement compromis. La désactivation du CMS élimine le risque d'injection de code malveillant dans notre site.
Nous avons contacté l'équipe ButterCMS via X (Twitter) pour les notifier :
Nous rencontrons des problèmes DNS avec
, il semble que votre DNS ait été entièrement effacé sur plusieurs réseaux différents.
Comme je ne peux pas accéder au site web, je n'ai aucun autre moyen de contacter votre équipe de support.— cody (@devlooskie)
Ils n'ont pas répondu à notre message.
À 08h30, nous avons observé que les enregistrements DNS de ButterCMS étaient en cours de restauration et, surtout, pointaient vers les mêmes adresses IP qu'avant le temps d'arrêt. Cela suggère que le problème était probablement dû à une mauvaise configuration ou à un temps d'arrêt du fournisseur DNS utilisé pour leur domaine. Pendant le temps d'arrêt, nous n'avons vu aucun enregistrement présent. Ni pour le site, ni pour l'API.
Une fois que nous avons confirmé que le service était revenu à la normale, nous avons annulé nos modifications.
Nous avons finalement contacté l'équipe ButterCMS via leur service de chat :
Dans le message complet, l'opérateur de support a affirmé que son équipe n'était pas au courant du problème mais a commencé à enquêter. Nous ne pouvons pas partager l'historique complet des messages, car après avoir demandé un numéro de dossier, ils ont répondu qu'ils n'en avaient pas. Intercom devrait en avoir par défaut.
Nous avons vérifié la page de statut de ButterCMS, qui à ce jour ne montre aucun temps d'arrêt. Cela nous a initialement fait croire que le problème était soit de notre côté, soit plus important qu'il ne s'est avéré.
La correspondance infructueuse avec ButterCMS
Après tout cela, nous les avons contactés par e-mail. Voici leur réponse :
Ils mentionnent une acquisition récente de ButterCMS par Tiugo Technologies. Pourtant cela a été signalé fin 2022, il y a plus d'un an et demi. Bien que cela montre maintenant la raison du transfert de domaine, nous n'avons pas été informés ou notifiés avant les changements.
Nous avons fait un suivi et avons reçu le message suivant :
Un problème de vérification aurait pu être le problème. Nous en saurons plus dans leur déclaration post-mortem qui sera publiée prochainement.
Dans un dernier e-mail de suivi le 12 septembre, voici leur réponse :
Nous pensons que la communication sur ces types de changements est vitale. Lorsque des changements planifiés tournent mal, même légèrement, cela met les clients en danger significatif. Un e-mail rapide pour notifier les utilisateurs est très utile dans ce type de scénarios.
Ces changements pourraient même interférer avec les exigences du RGPD, sachant maintenant que la propriété du domaine a changé après une acquisition. Le RGPD ne mentionne pas spécifiquement les transferts de domaine mais se concentre sur le transfert de contrôle des données personnelles. Si le changement de propriété conduit à un nouveau responsable du traitement gérant les données personnelles, les clients (personnes concernées) devraient être informés. Cela relève des principes de transparence et d'équité du RGPD (Articles 13, 14).
Les clients doivent être informés de l'identité du nouveau responsable et de tout changement dans la manière dont leurs données seront traitées. La notification doit avoir lieu dans un délai raisonnable.
Nous avons attendu pour publier ceci pendant un certain temps pour voir si une communication pourrait encore venir avant le webinaire prévu. Jusqu'à présent, nous n'en avons vu aucune.
MISE À JOUR : Même après le webinaire, aucun enregistrement et aucun article de blog ou déclaration.
Plus tard, nous avons essayé de chercher d'autres entreprises commentant ce problème, mais n'en avons trouvé aucune. Bien que nous ne puissions pas connaître leur nombre exact de clients, potentiellement 1 660 sites web et plus de 5 800 domaines supplémentaires ont été impactés :
Le risque avec les tiers dynamiques
C'est plus grave que de simples changements d'enregistrements. Ce schéma est exactement ce qui se passe lorsque le domaine change de propriétaire, ou que des détails WhoIs majeurs sont mis à jour.
Bien que le problème soit maintenant résolu, cette situation a montré une vulnérabilité de sécurité potentielle.
La leçon plus large de cet incident est le risque que vous prenez lorsque vous comptez sur des services tiers qui injectent dynamiquement du contenu dans les sites web. Un problème que nous connaissons bien et contre lequel nous protégeons côté client.
Les domaines utilisés dans les intégrations peuvent être achetés par des acteurs malveillants et exploités pour des attaques. Le contenu qu'ils injectent est dynamique. Cela signifie que le contenu peut changer en fonction de divers facteurs comme l'heure, la région et d'autres données spécifiques à l'utilisateur, ce qui facilite la tâche des acteurs malveillants pour contourner la détection.
Dans ce cas, le renouvellement du domaine ButterCMS et le manque de clarté autour de la mise à jour WhoIs ont levé un drapeau rouge pour nous rappeler de surveiller les dépendances tierces.
La façon dont un site web est construit affecte considérablement sa vulnérabilité à ce type de problème. Idéalement, toute entrée devrait être correctement nettoyée. Les entrées utilisateur doivent être nettoyées pour empêcher l'injection de code malveillant dans le site.
De nombreux développeurs n'implémentent pas un nettoyage approprié, surtout lorsque ce n'est pas explicitement abordé dans la documentation.
Si vous recherchez « dangerouslySetInnerHTML », il n'y a pas de conseils clairs sur la façon d'utiliser cette prop en toute sécurité. Sans nettoyage approprié, tout HTML valide peut être injecté, ce qui crée une vulnérabilité XSS (Cross-Site Scripting) sérieuse.
Lorsque du HTML est injecté dans le client, la page web entière peut être compromise par des injections de script. Sans garde-fous, le HTML injecté pourrait exécuter des scripts nuisibles ou rediriger les utilisateurs vers des sites malveillants, transformant effectivement la fonctionnalité en un portail ouvert pour les risques de sécurité.
Comment cela est géré côté client
Bien sûr, le risque de changement de domaine n'est pas nouveau pour nous. C'est un vecteur d'attaque courant dans le monde de la sécurité côté client. cside vérifie déjà l'historique des enregistrements DNS, les informations WhoIs et les métadonnées.
Tant que le site web reste en ligne (et par conséquent, notre proxy aussi) et que des changements ou anomalies se produisent, notre moteur les détecte. Et, après avoir vérifié d'autres activités malveillantes possibles, il alertera et/ou bloquera le domaine, le script, et donc une attaque possible.
Vous pouvez protéger votre site rapidement et gratuitement en utilisant cside.
