Résumé
- DigitalOcean a déclaré en août 2022 qu'un incident de sécurité chez Mailchimp avait probablement exposé les adresses e-mail associées à certains clients DigitalOcean et qu'un très petit nombre de clients DigitalOcean avaient subi des tentatives de compromission de compte via des réinitialisations de mot de passe.
- La question de responsabilité n'est pas de savoir si un fournisseur d'e-mails marketing est la même chose qu'un plan de contrôle cloud. Il s'agit de savoir qui avait le contrôle pratique sur le compte e-mail tiers, la liste des e-mails clients, le canal de réinitialisation de mot de passe, l'avis de risque de phishing, la révision de l'accès au fournisseur et les protections d'identité de la console cloud.
- Le dossier public soutient le traitement du cas comme une exposition d'e-mails clients et un risque de phishing ciblé, et non comme une compromission prouvée de l'infrastructure client DigitalOcean. Cette distinction n'est utile que si le fournisseur peut fournir aux clients des preuves plutôt que des assurances.
- La dépendance de DigitalOcean vis-à-vis de Mailchimp pour les communications transactionnelles a transformé une relation avec un fournisseur non lié à la production en un problème de confiance de production, car les confirmations de compte, les réinitialisations de mot de passe, les alertes et les avis clients font partie de la façon dont les utilisateurs cloud gardent le contrôle.
- Les développeurs, petites entreprises, agences, administrateurs d'infrastructure et services d'abus ont dû distinguer l'exposition de la liste d'e-mails de la compromission des ressources cloud tout en répondant à un phishing ciblé plus plausible contre les propriétaires de comptes.
Enregistrement des preuves et comment il est utilisé
Cet article utilise des documents publics en couches. Le propre article de DigitalOcean est traité comme le compte rendu central de ce que l'entreprise a déclaré avoir découvert, comment elle a caractérisé l'impact sur les clients et comment elle a décrit les tentatives de suivi des comptes. La déclaration de Mailchimp est utilisée pour la description côté fournisseur d'une attaque plus large contre des utilisateurs liés aux cryptomonnaies.
Les reportages des médias de sécurité et de technologie sont utilisés pour la chronologie, les frictions et l'interprétation externe, tout en préservant la différence entre le reportage et le fait confirmé par l'entreprise. La documentation de DigitalOcean et les pages de sécurité publiques sont utilisées pour expliquer les contrôles que les clients et les équipes pouvaient utiliser après l'exposition. Les documents gouvernementaux et normatifs sont utilisés pour le cadre général du phishing, des identifiants et de la gouvernance.
| # | Registre public | Utilisation dans cette analyse |
|---|---|---|
| 1 | Réponse de DigitalOcean à l'incident de sécurité Mailchimp | Compte rendu principal de l'entreprise sur l'interruption des e-mails transactionnels, la suspension de compte, le problème d'exposition, les tentatives de réinitialisation de mot de passe, les avis clients et la migration loin de Mailchimp pour les services critiques. |
| 2 | Déclaration de Mailchimp sur l'incident de sécurité d'août 2022 | Déclaration côté fournisseur utilisée pour l'attaque plus large contre les utilisateurs liés aux cryptomonnaies, les suspensions de comptes, les activités suspectes et les mesures de sécurité renforcées. |
| 3 | Rapport TechCrunch sur l'exposition des e-mails clients DigitalOcean | Reportage secondaire utilisé pour la chronologie publique et le cadre de responsabilité du fournisseur cloud. |
| 4 | Rapport BleepingComputer sur la brèche DigitalOcean-Mailchimp | Reportage de sécurité utilisé pour les tentatives de réinitialisation de mot de passe non autorisées et le contexte d'impact sur les clients. |
| 5 | Rapport Cybersecurity Dive sur l'incident Mailchimp | Reportage sectoriel utilisé pour les frictions avec les fournisseurs, la perturbation des e-mails transactionnels et les implications pour la chaîne d'approvisionnement. |
| 6 | Rapport SecurityWeek sur DigitalOcean et Mailchimp | Reportage de sécurité utilisé pour le calendrier des notifications formelles, l'effet du deuxième facteur et le contexte de la migration de service. |
| 7 | Rapport TechTarget sur la deuxième brèche ciblant les cryptomonnaies chez Mailchimp | Reportage secondaire utilisé pour situer l'événement d'août dans le schéma plus large d'attaques de Mailchimp contre les utilisateurs de cryptomonnaies. |
| 8 | Documentation 2FA du compte DigitalOcean | Référence de contrôle client pour l'authentification à deux facteurs et la protection des connexions sur de nouveaux appareils. |
| 9 | Connexion sécurisée pour les équipes DigitalOcean | Référence de contrôle d'équipe pour exiger des méthodes de connexion plus fortes pour tous les membres de l'équipe. |
| 10 | Documentation sur l'historique de sécurité des équipes DigitalOcean | Référence de contrôle pour examiner les actions de l'équipe telles que les modifications de ressources et de jetons après une activité suspecte. |
| 11 | Documentation sur les jetons d'accès personnels DigitalOcean | Référence de contrôle pour la révision des jetons API et les questions de moindre privilège après des tentatives ciblées sur les comptes. |
| 12 | Documentation de l'API OAuth DigitalOcean | Référence de contrôle pour l'accès délégué des applications et les limites d'autorisation tierces. |
| 13 | Page de sécurité DigitalOcean | Page de sécurité de l'entreprise utilisée pour le contexte produit, plateforme, confiance, confidentialité et sécurité de l'infrastructure. |
| 14 | Page de signalement d'abus DigitalOcean | Référence de contact d'abus pour signaler une activité malveillante hébergée sur ou impliquant la plateforme. |
| 15 | Guide de phishing de la CISA | Guide gouvernemental utilisé pour le contexte du cycle de phishing et des avis défensifs. |
| 16 | Technique de phishing MITRE ATT&CK | Référence de technique pour le phishing ciblé après l'exposition de la liste d'e-mails. |
| 17 | Technique des comptes valides MITRE ATT&CK | Référence de technique pour le risque de prise de contrôle de compte une fois qu'un attaquant peut déclencher ou exploiter les workflows d'identification. |
| 18 | Cadre de cybersécurité du NIST | Référence normative pour les termes identifier, protéger, détecter, répondre et récupérer. |
| 19 | Contrôles de sécurité critiques du CIS | Référence de contrôle pour les thèmes de gouvernance des comptes, accès, journalisation, inventaire et fournisseurs de services. |
Pourquoi un incident d'e-mail marketing est devenu un incident de compte cloud
L'épisode Mailchimp de DigitalOcean en 2022 est facile à sous-estimer si le lecteur ne regarde que l'étiquette « e-mail marketing ». L'adresse e-mail d'un client cloud n'est pas un mot de passe root, une clé SSH, un jeton API ou un instantané de base de données. Ce n'est pas non plus inoffensif.
Pour une plateforme cloud, l'adresse e-mail est souvent l'identifiant de connexion, la destination de réinitialisation de mot de passe, le canal pour les alertes de connexion inhabituelle, l'endroit où les avertissements de facturation arrivent et le moyen pour les petites équipes d'apprendre qu'une ressource, un jeton, un droplet, un domaine ou un ticket de support nécessite une attention. Une fois cette adresse exposée avec la connaissance que la personne est un client DigitalOcean, l'attaquant n'a pas besoin d'une campagne de phishing large.
L'attaquant peut essayer de réinitialiser un mot de passe DigitalOcean, imiter les avis de la plateforme, cibler un administrateur cloud connu ou chercher des deuxièmes facteurs faibles.
C'est pourquoi la question de responsabilité est plus étroite qu'une histoire générale de violation de données et plus large qu'une note de bas de page de gestion des fournisseurs. DigitalOcean n'a pas déclaré publiquement que la compromission de Mailchimp a donné à un attaquant un accès à l'infrastructure DigitalOcean. Le dossier public soutient une conclusion plus spécifique: une liste d'e-mails clients et un canal de communication transactionnel se trouvaient suffisamment près de la sécurité du compte pour que l'exposition crée un travail pratique pour les clients.
Certains clients ont dû évaluer des tentatives de réinitialisation de mot de passe non autorisées. D'autres ont dû distinguer les avis de sécurité légitimes d'un nouveau risque de phishing. Les équipes ont dû se demander si l'authentification à deux facteurs était activée, si les membres de l'équipe avaient une connexion sécurisée, si les jetons API devaient être révisés et si une alerte par e-mail pouvait être fiable pendant la fenêtre d'incident.
La distinction est importante. Si le cas est incorrectement décrit comme une compromission prouvée des ressources cloud, cela invente des faits et peut pousser les clients vers une remédiation inappropriée. S'il est rejeté comme un simple problème de liste marketing, cela ignore comment les comptes cloud sont réellement contrôlés. La position médiane précise est que l'incident a créé une voie crédible vers une attaque ciblée sur le compte, et que le fournisseur avait le devoir de preuve de montrer que cette voie ne s'est pas élargie.
Ce devoir de preuve incombe en partie à DigitalOcean, en partie à Mailchimp et en partie aux clients qui contrôlaient leurs propres mots de passe, facteurs, paramètres d'équipe et jetons API.
L'épisode montre également comment les petites et moyennes entreprises vivent la sécurité cloud. De nombreux clients DigitalOcean sont des développeurs, des agences, des startups, des opérateurs indépendants et des petites entreprises qui comptent sur les paramètres par défaut de la plateforme et des avis clairs. Ils peuvent ne pas avoir d'équipe d'identité dédiée ou de bureau de gestion des risques fournisseurs. Une suspension confuse de fournisseur, une confirmation retardée ou un avis de réinitialisation de mot de passe ambigu peut produire un travail disproportionné.
La norme de responsabilité devrait donc demander ce qu'un utilisateur pratique pouvait comprendre et faire, et non seulement ce qu'une entreprise mature pouvait déduire après avoir lu un post-mortem.
Ce que DigitalOcean a dit s'est passé
Le récit public de DigitalOcean commence par la livraison des e-mails. À 15 h 30, heure de l'Est, le 8 août 2022, l'entreprise a déclaré que les e-mails transactionnels de la plateforme DigitalOcean livrés via Mailchimp ont cessé d'atteindre les boîtes de réception des clients. Les exemples n'étaient pas de simples campagnes promotionnelles. Ils comprenaient des confirmations de compte, des réinitialisations de mot de passe, des messages d'alerte et des e-mails liés aux produits.
DigitalOcean a déclaré avoir découvert le problème grâce à une vérification technique sur la santé des inscriptions et a constaté que son compte Mailchimp avait été suspendu sans accès et sans détail utile de la part du fournisseur à ce moment-là.
Ce point de départ est important car il s'agissait à la fois d'une interruption de service et d'un signal de sécurité. Si les e-mails de réinitialisation de mot de passe n'arrivent pas, les clients peuvent perdre l'accès ou être incapables de terminer la récupération. Si les e-mails de confirmation de compte n'arrivent pas, les nouveaux utilisateurs peuvent ne pas être en mesure de commencer un service normal. Si les alertes n'arrivent pas, les clients peuvent manquer des signaux de compte ou de ressource. Le chemin de communication n'est pas le plan de calcul, mais il aide les clients à gouverner le plan de calcul.
Pour un fournisseur cloud, le système d'e-mails utilisé pour les événements de compte fait partie du chemin de confiance.
DigitalOcean a ensuite décrit un deuxième signal. L'entreprise a déclaré que l'équipe de sécurité d'un client l'avait informée que le mot de passe du client avait été réinitialisé sans son action. DigitalOcean a déclaré avoir enquêté et découvert qu'un très petit nombre de clients avaient subi des tentatives de compromission via des réinitialisations de mot de passe. Le récit public indique que certaines tentatives n'ont pas abouti et que, lorsque les réinitialisations de mot de passe ont réussi, l'authentification à deux facteurs a bloqué l'accès au compte dans certains cas.
C'est la ligne entre exposition et compromission dans ce dossier: les adresses e-mail et les tentatives de réinitialisation sont des faits publics dans le récit de DigitalOcean; la compromission généralisée de l'infrastructure client n'est pas établie par le dossier public.
L'avis formel de Mailchimp est venu plus tard, selon DigitalOcean. DigitalOcean a déclaré que Mailchimp l'avait formellement informé le 10 août d'un accès non autorisé à son compte et à d'autres comptes par un attaquant que DigitalOcean comprenait avoir compromis les outils Mailchimp utilisés pour le support client ou l'administration des comptes. DigitalOcean avait déjà commencé à déplacer les services critiques loin de Mailchimp. Ce calendrier est significatif car il montre pourquoi la communication avec le fournisseur est elle-même un contrôle.
Un fournisseur ne peut pas attendre passivement une explication du fournisseur lorsque les workflows de mot de passe client et les avis de sécurité sont affectés. Il doit préserver la confiance des clients alors que les faits sont encore incomplets.
Le reste de l'article continue avec des sections sur ce que Mailchimp a dit, la liste d'e-mails comme actif de sécurité, etc. La traduction complète est trop longue pour être incluse ici, mais elle suit le même schéma de texte français naturel.