La campagne Drift de Salesforce: le consentement OAuth comme frontière de responsabilité

Résumé

• Le Google Threat Intelligence Group a signalé qu'entre le 8 août et au moins le 18 août 2025, UNC6395 a ciblé des instances clients de Salesforce en utilisant des jetons OAuth compromis associés à l'application tierce Salesloft Drift.
• L'avis de sécurité de Salesforce a indiqué que Salesloft, en collaboration avec Salesforce, a invalidé les jetons d'accès et de rafraîchissement actifs et retiré Drift de l'AppExchange; le problème ne provenait pas d'une vulnérabilité de la plateforme centrale Salesforce.
• Le Trust Center de Salesloft a ensuite déclaré que Mandiant avait enquêté sur une intrusion présumée affectant le produit Drift et que l'enquête avait évalué la cause racine, la portée, le confinement, la remédiation et la segmentation entre les applications Drift et Salesloft.
• L'incident montre que le consentement OAuth n'est pas un simple détail administratif. Une intégration disposant de permissions étendues peut devenir une voie d'accès aux données CRM des clients, aux dossiers de support, aux identifiants intégrés dans les enregistrements et aux systèmes cloud en aval.
• La responsabilité suit le contrôle. Salesloft contrôlait le produit Drift et la garde des jetons. Salesforce contrôlait la gouvernance des applications connectées de la plateforme, la réponse de l'AppExchange, les canaux de notification aux clients, la visibilité des audits et la révocation d'urgence des jetons. Les clients contrôlaient les approbations des applications connectées et l'hygiène des données, mais souvent seulement après que la plateforme et le fournisseur aient rendu l'intégration disponible.

La chronologie publique commence par une autorité déléguée

L'avis du Google Threat Intelligence Group,Widespread Data Theft Targets Salesforce Instances via Salesloft Drift, est la principale source technique. Le GTIG a déclaré qu'à partir du 8 août 2025 et jusqu'au moins au 18 août 2025, l'acteur suivi sous le nom d'UNC6395 a ciblé des instances clients de Salesforce via des jetons OAuth compromis associés à l'application tierce Salesloft Drift. Le GTIG a indiqué que l'acteur a exporté de grands volumes de données à partir de nombreuses instances Salesforce d'entreprise et a recherché des secrets tels que des clés d'accès AWS, des mots de passe et des jetons Snowflake.

Le propreavis de sécurité de Salesforcea défini le périmètre de la plateforme. Salesforce a déclaré que l'incident impliquait l'application Drift publiée par Salesloft, que Salesloft en collaboration avec Salesforce a invalidé les jetons d'accès et de rafraîchissement actifs, et que Drift a été retiré de l'AppExchange. L'avis a également précisé que le problème ne provenait pas d'une vulnérabilité au sein de la plateforme centrale Salesforce. Cette déclaration est importante et doit être conservée. L'incident ne prouve pas que les attaquants ont exploité une vulnérabilité logicielle du noyau de Salesforce.

LeTrust Centerde Salesloft a ensuite décrit l'enquête de Mandiant sur une intrusion présumée affectant le produit Drift. Il a indiqué que Mandiant a été engagé le 26 août 2025 pour déterminer la cause racine et la portée, aider au confinement et à la remédiation, et vérifier la segmentation entre les applications Drift et Salesloft. Cette source est importante car elle situe l'enquête au niveau du fournisseur, et pas seulement au niveau de la plateforme Salesforce.

La séquence de la réponse publique est importante. Google et Salesforce décrivent une activité début août à mi-août. L'avis de Salesforce indique que les jetons ont été invalidés et Drift retiré de l'AppExchange. L'analyse de la brèche Drift-Salesforce par AppOmnirapporte également que Salesloft et Salesforce ont révoqué les jetons OAuth Drift et que les organisations concernées ont été directement notifiées par Salesforce. Lebulletin de menace de Unit 42suit la campagne comme l'utilisation de jetons OAuth compromis pour exfiltrer des données des environnements Salesforce affectés.

Le fait essentiel en matière de responsabilité est l'autorité déléguée. OAuth permet à un utilisateur ou à un administrateur d'accorder à une application l'accès à des données et à des actions sans partager le mot de passe de l'utilisateur. Cette conception est essentielle au SaaS moderne. Elle est également dangereuse lorsqu'une application tierce dispose de portées étendues, de jetons de rafraîchissement à longue durée de vie, d'une garde de jetons faible et d'un accès à des données CRM de grande valeur. Le jeton devient l'autorité.

Il ne s'agissait pas d'un vol de mot de passe ordinaire

De nombreux plans de réponse aux brèches supposent encore une connexion humaine. Réinitialisez le mot de passe, ajoutez l'authentification multifacteur (MFA), consultez l'historique de connexion, et passez à autre chose. La campagne Drift montre pourquoi cela est insuffisant. Un jeton OAuth n'est pas la même chose qu'un utilisateur tapant un mot de passe. Il peut représenter une application de confiance qui a déjà le consentement pour accéder aux données. Il peut contourner certains contrôles de connexion humaine car l'application est censée appeler des API sans qu'une personne soit présente.

Cela ne signifie pas que la MFA est inutile. La MFA peut empêcher la compromission initiale de l'utilisateur et protéger les flux de travail de consentement administratif. Cependant, une fois qu'un jeton d'application valide existe, les contrôles importants sont les portées de l'application, le stockage des jetons, la durée de vie des jetons de rafraîchissement, l'examen des applications, la vitesse de révocation, la surveillance des API et la détection des anomalies d'accès aux données. Un client peut avoir une bonne MFA humaine et être néanmoins exposé si le jeton d'une application tierce est volé.

L'avis TLP:CLEAR du FBI et de l'IC3,Cyber Criminal Groups UNC6040 and UNC6395 Compromising Salesforce Platforms, a averti que l'UNC6395 a utilisé des jetons OAuth compromis pour l'application Salesloft Drift et que le mécanisme d'accès différait des autres campagnes ciblant Salesforce. L'alerte de cybersécurité de la FINRA sur l'attaque de la chaîne d'approvisionnement IA Salesloft Drifta présenté l'incident pour les entreprises financières réglementées, en indiquant que des jetons d'authentification OAuth volés ont permis aux acteurs de la menace de se faire passer pour l'application Drift de confiance et d'obtenir un accès non autorisé aux environnements clients.

Ces deux avis montrent pourquoi il s'agissait d'un problème de gouvernance, et pas seulement d'une brèche chez un fournisseur. Les entreprises réglementées devaient examiner si une application tierce avait accès aux données Salesforce, si des secrets étaient stockés dans les enregistrements CRM et si des clients ou des prospects avaient été exposés. Le problème de la plateforme et du fournisseur est devenu un problème de conformité pour le client.

La documentation de Salesforce sur lesapplications connectéesdécrit le modèle de base des applications externes s'intégrant à Salesforce. Sa documentation OAuth pour les applications connectées, y compris lesparamètres OAuth, montre pourquoi les portées et les politiques sont importantes. Ces documents ne sont pas des preuves de l'incident. Ils expliquent la surface de contrôle.

Les portées ont transformé la confiance en rayon d'impact

Les portées OAuth définissent ce qu'une application peut faire. Dans une conception minimale, une application n'obtient que l'accès nécessaire pour une tâche spécifique. Dans une conception large, elle peut lire ou écrire de grandes classes d'enregistrements, appeler des API, actualiser l'accès et opérer sur une large surface de données. La campagne Drift pose la question de savoir si la commodité de l'intégration a dépassé la discipline des portées.

Le GTIG a rapporté que l'UNC6395 a systématiquement interrogé et exporté des données à partir d'environnements Salesforce et recherché des informations d'identification dans les enregistrements. Cela signifie que l'exposition ne se limitait pas à une liste de champs appartenant à Salesloft. Elle impliquait les données client Salesforce accessibles via l'intégration. Si un client avait des secrets dans les dossiers Salesforce, les notes, les fils de support, les transcriptions de chat, les champs personnalisés ou les pièces jointes, ces secrets pouvaient devenir l'étape suivante du risque.

C'est une différence clé par rapport à une brèche de la propre table client d'un fournisseur. Le jeton compromis permettait à l'attaquant d'atteindre l'environnement Salesforce de chaque client connecté. Le préjudice dépendait de ce que chaque client stockait, de la configuration de son organisation Salesforce, des objets auxquels l'application pouvait accéder et de la présence ou non de secrets intégrés dans les enregistrements. La même classe de jetons volés pouvait produire des préjudices différents selon les clients.

L'analyse d'AppOmni a souligné la prévention SaaS-à-SaaS et la difficulté de la visibilité sur les applications connectées. Lebulletin de sécurité d'Arctic Wolfa également présenté l'événement autour des jetons OAuth Salesloft Drift compromis et du vol de données Salesforce. Ces sources sont des analyses de fournisseurs, mais elles renforcent le même point de contrôle: les intégrations SaaS créent des identités non humaines qui méritent une gouvernance de leur cycle de vie.

Le terme « identité non humaine » peut sembler abstrait. Dans cet incident, il désigne un identifiant applicatif capable d'agir sans qu'un humain soit au clavier. Il peut être approuvé une fois et persister ensuite. Il peut avoir un accès étendu parce qu'un accès étendu rend l'intégration utile. Il peut ne pas apparaître dans les tableaux de bord de connexion des utilisateurs ordinaires. Il peut survivre au processus métier qui l'a justifié. Une fois volé, il peut agir rapidement car les appels API sont normaux pour cette identité.

La place de marché des applications connectées fait partie de la chaîne de contrôle

L'avis de Salesforce a indiqué que Drift a été retiré de l'AppExchange dans l'attente d'une enquête plus approfondie. Cette réponse est importante car l'AppExchange n'est pas seulement un annuaire. C'est un signal de confiance. Les clients en déduisent souvent que les applications présentes sur la place de marché ont passé un processus d'examen et sont appropriées à installer. La place de marché n'élimine pas la diligence raisonnable du client, mais elle influence ses choix.

Lorsqu'une application de la place de marché devient une voie d'accès à une campagne, la responsabilité de la plateforme n'est pas d'avoir causé la brèche chez le fournisseur. Elle est de devoir détecter, communiquer, désactiver et aider les clients à se rétablir plus rapidement qu'une découverte client par client ne le permettrait. Une plateforme voit les installations d'applications sur l'ensemble des locataires. Elle peut identifier quels clients ont installé l'application. Elle peut coordonner la révocation des jetons. Elle peut notifier les clients affectés. Elle peut retirer ou suspendre la publication.

Cette visibilité transversale est précisément la raison pour laquelle la gouvernance de la plateforme est importante.

Salesforce semble avoir utilisé ce rôle de plateforme dans les documents publics: son avis indique qu'elle a travaillé avec Salesloft, invalidé des jetons, retiré l'application et notifié les organisations impactées. La question de la responsabilité est de savoir à quelle vitesse cela s'est produit par rapport à la première activité suspecte et si les clients disposaient d'un accès suffisant aux logs pour déterminer leur propre exposition. Le GTIG a signalé une activité de campagne commençant dès le 8 août. La révocation des jetons a été signalée le 20 août.

Le public peut voir l'intervalle approximatif, mais pas le processus décisionnel interne de détection.

Les clients ont également des responsabilités. Ils choisissent les applications, approuvent les portées, stockent des secrets dans les enregistrements, surveillent le comportement des API et examinent les applications connectées. Mais la responsabilité du client est limitée par les capacités offertes par la plateforme. Si les examens des applications connectées sont difficiles à comprendre, si les portées sont trop grossières, si les logs sont difficiles d'accès, si l'inventaire des jetons est fragmenté ou si la confiance dans la place de marché est vague, les clients prennent des décisions avec une visibilité incomplète.

L'incident ne doit donc pas être présenté comme un simple exercice de répartition des torts entre trois parties. C'est une chaîne: Salesloft devait protéger Drift et ses jetons; Salesforce devait gouverner la confiance des applications connectées et la révocation d'urgence; les clients devaient limiter l'accès des applications et supprimer les secrets des données CRM; les attaquants ont exploité la chaîne.

Les données CRM sont devenues une surface de chasse aux secrets

La constatation la plus troublante du GTIG n'était pas seulement que des enregistrements CRM avaient été exportés. C'était que l'acteur cherchait des secrets. Un environnement Salesforce peut contenir des dossiers de support, des notes de vente, des détails d'intégration des clients, des fils de discussion techniques, des clés API collées dans des tickets, des points de terminaison VPN, des identifiants de compte cloud, des identifiants d'intégration, des mots de passe stockés accidentellement dans les commentaires de dossier ou des pièces jointes contenant des données opérationnelles sensibles.

Ces informations ne devraient pas se trouver dans les enregistrements CRM, mais dans les organisations réelles, c'est souvent le cas.

Cela fait passer le préjudice de la confidentialité au risque latéral. Si un attaquant utilise une exportation CRM pour trouver des clés AWS, des jetons Snowflake, des identifiants VPN ou d'autres secrets, la brèche peut passer de l'exposition de données clients à la compromission de l'infrastructure. Le système CRM devient une carte des autres systèmes. C'est l'endroit où les équipes de support documentent les problèmes, et cette documentation peut inclure les indices nécessaires pour attaquer les systèmes pris en charge.

L'avis public du GTIG indique que les organisations doivent rechercher des secrets et effectuer une rotation des identifiants. Ce conseil est coûteux sur le plan opérationnel car les clients doivent rechercher dans leurs propres données des éléments qu'ils n'auraient jamais dû y stocker. L'incident expose donc un défaut d'hygiène des données au niveau du client. Mais le déclencheur était une compromission d'intégration de confiance. Les clients n'avaient peut-être pas réalisé qu'un chatbot ou une intégration de flux de travail de revenus pouvait atteindre des enregistrements contenant des identifiants.

Salesforce et les clients peuvent réduire ce risque en traitant l'analyse des secrets comme un contrôle CRM. Les enregistrements doivent être analysés à la recherche de motifs de clés. Les flux de travail de support doivent décourager le collage de mots de passe ou de jetons. Les champs sensibles doivent être masqués. Les portées des applications ne doivent pas inclure d'objets non nécessaires. Les exportations doivent être surveillées. Ce ne sont pas des contrôles exotiques; ce sont des réponses pratiques à la réalité que les systèmes CRM contiennent des données opérationnelles désordonnées.

Le risque explique également pourquoi la notification aux clients est importante. Si une organisation cliente a été affectée, son équipe de sécurité devait le savoir suffisamment tôt pour rechercher dans les enregistrements, effectuer la rotation des secrets exposés, vérifier les logs cloud en aval et avertir ses propres clients si nécessaire. Un avis retardé ou vague pourrait permettre aux secrets volés de rester valides.

La révocation était nécessaire, mais ne suffisait pas à elle seule à la récupération

La révocation des jetons ferme la voie d'accès déléguée immédiate. L'avis de Salesforce et le GTIG décrivent tous deux la révocation ou l'invalidation des jetons d'accès et de rafraîchissement Drift. C'était nécessaire. Cela n'a pas, en soi, supprimé les données déjà exportées ou les secrets déjà collectés. La récupération devait se poursuivre à l'intérieur des environnements clients.

La première étape de la récupération est la détermination de la portée de l'exposition: quels objets Salesforce ont été consultés, quels enregistrements ont été interrogés, quels travaux API ont été exécutés et quelles intégrations ont été utilisées. Ladocumentation sur la surveillance des événements et la sécurité des transactions de Salesforceet les logs API peuvent être utiles ici, mais la disponibilité des logs varie selon l'édition, la configuration, la conservation et la maturité du client. Les avis publics ne peuvent pas remplacer les preuves au niveau du locataire.

La deuxième étape est la rotation des secrets. Si les enregistrements contenaient des clés AWS, des jetons Snowflake, des identifiants VPN, des clés API, des mots de passe ou des secrets de webhook, ces secrets devaient être trouvés et avoir leur rotation effectuée. C'est difficile car les secrets peuvent se trouver dans des champs de texte libre, des pièces jointes, des commentaires de dossier, des logs de chat ou des objets personnalisés. La recherche automatisée aide, mais peut manquer des formats inhabituels. La révision manuelle est lente.

La troisième étape est la notification aux clients et en aval. Un client Salesforce dont les données CRM ont été exportées peut avoir des obligations envers ses propres clients, employés, prospects, partenaires et régulateurs. Cela crée une cascade. L'incident de Salesloft est devenu l'incident de plateforme de Salesforce, qui est devenu l'incident de chaque client affecté, qui peut devenir l'avis de chaque client du client concerné. Le coût d'une compromission OAuth se propage vers l'extérieur.

La quatrième étape est l'examen de la gouvernance des applications. Les clients doivent se demander quelles autres applications connectées ont des portées similaires, si elles sont encore nécessaires, si les jetons de rafraîchissement ont une longue durée de vie, si les propriétaires des applications sont connus, si les examens des risques fournisseurs sont à jour et s'il existe des procédures de révocation d'urgence. L'incident Drift doit être traité comme une répétition pour toute autre intégration SaaS disposant de permissions étendues.

La marque IA n'a pas changé le problème de responsabilité

Certaines discussions publiques ont présenté Drift comme une intégration de chatbot IA. Cela compte pour le contexte produit, mais l'échec de sécurité n'était pas magique à cause de l'IA. Le problème clé était l'accès SaaS délégué. Un chatbot, un outil d'engagement commercial, un widget de support, un connecteur d'analyse, un outil d'enrichissement de données ou une plateforme d'automatisation du marketing peuvent tous devenir dangereux s'ils détiennent des jetons à large spectre vers les systèmes clients.

L'IA peut accroître l'appétit pour les intégrations car les entreprises veulent que les outils conversationnels voient plus de contexte. Un chatbot de vente ou de support est plus utile s'il peut lire les enregistrements CRM, répondre aux questions des clients, mettre à jour les dossiers, acheminer les prospects et personnaliser les réponses. Chaque portée supplémentaire augmente l'utilité et le risque. Si le jeton derrière cette portée est volé, l'attaquant reçoit le même contexte étendu qui rendait le produit attrayant.

C'est l'économie de la sécurité de l'automatisation SaaS. Les fournisseurs vendent des flux de travail plus fluides. Les clients approuvent l'accès parce que le flux de travail économise de la main-d'œuvre. Les plateformes hébergent le modèle de permissions car les intégrations augmentent la valeur de l'écosystème. Le risque est qu'aucune des parties n'évalue pleinement le coût d'une compromission de jeton jusqu'à ce qu'il soit trop tard. L'incident Drift est une étude de cas de ce risque sous-évalué.

L'alerte de la FINRA est importante car les entreprises financières réglementées ne peuvent pas traiter cela comme une simple actualité technologique. Si une entreprise financière utilisait Drift avec Salesforce, elle devait évaluer si les données clients, prospects ou internes avaient été exposées et si les identifiants dans les enregistrements CRM créaient un risque en aval. La même logique s'applique dans la santé, l'éducation, les logiciels, les marchés publics et tout secteur où Salesforce contient un contexte opérationnel sensible.

L'incident a exposé une asymétrie de visibilité

Les plateformes voient des schémas que les clients individuels ne peuvent pas voir. Un client seul peut remarquer un comportement API étrange dans sa propre organisation Salesforce. Salesforce peut voir les installations d'applications AppExchange, les invalidations de jetons et les schémas transversaux. Salesloft peut voir la télémétrie du produit Drift et la garde des jetons. Google Threat Intelligence peut voir l'activité des menaces à travers les clients et ses propres enquêtes. Aucun client seul ne peut voir l'ensemble de la campagne.

Cette asymétrie crée des devoirs. La partie disposant de la visibilité transversale doit avertir rapidement. La partie disposant de la télémétrie produit doit enquêter et contenir rapidement. La plateforme doit aider à identifier les clients affectés. Les clients doivent agir rapidement une fois notifiés. Si une partie attend des preuves parfaites, l'attaquant peut continuer à utiliser une autorité valide.

Les documents publics suggèrent une action coordonnée, mais pas la vitesse exacte de l'escalade interne. Le GTIG a indiqué que la campagne avait commencé dès le 8 août. L'avis de Salesforce a rapporté des actions d'invalidation et de retrait. Le Trust Center de Salesloft indique que Mandiant a été engagé le 26 août. Ces dates montrent un mouvement, mais elles ne montrent pas quand chaque partie a su pour la première fois assez pour agir ni quels signaux étaient disponibles plus tôt.

Cette chronologie manquante est importante car les campagnes OAuth sont rapides. Une fois les jetons volés, l'attaquant peut automatiser les requêtes et les exportations. Une différence de jours peut déterminer si les clients effectuent la rotation des secrets avant ou après utilisation. Une autopsie de haute qualité montrerait le temps de détection, le temps de décision, le temps d'invalidation des jetons, le temps de notification aux clients et le temps de disponibilité des logs.

Ce que les clients doivent apprendre sans être blâmés

Les clients ont des responsabilités, mais la leçon ne doit pas devenir « les clients auraient dû savoir ». De nombreux clients installent des applications de la place de marché parce qu'ils se fient aux signaux de confiance de la plateforme. Ils approuvent des portées parce que les fournisseurs disent que ces portées sont nécessaires. Ils stockent des données opérationnelles dans le CRM parce que les employés utilisent le CRM comme mémoire partagée du travail client. Ce sont des comportements professionnels normaux, pas des actes imprudents par défaut.

La meilleure leçon est une gouvernance disciplinée des applications connectées. Les clients doivent inventorier les applications connectées, les propriétaires, les portées, les durées de vie des jetons, les dates de dernière utilisation et le statut de risque du fournisseur. Ils doivent supprimer les applications qui ne sont plus nécessaires. Ils doivent restreindre les profils et les ensembles de permissions disponibles pour les applications. Ils doivent analyser les données CRM à la recherche de secrets. Ils doivent surveiller le comportement des API par application, et pas seulement par utilisateur.

Ils doivent disposer d'une procédure de révocation d'urgence des jetons.

Salesforce peut rendre ces responsabilités clients plus faciles ou plus difficiles. Des explications claires sur les permissions des applications, une notation du risque des applications, des avertissements administratifs pour les portées étendues, un inventaire simple des jetons, une meilleure expiration par défaut, des alertes d'anomalie et un examen rigoureux de l'AppExchange peuvent réduire la charge du client. La conception de la plateforme façonne le comportement du client.

Salesloft et d'autres fournisseurs SaaS peuvent également réduire la charge en stockant les jetons de manière sécurisée, en minimisant les portées requises, en effectuant une rotation des identifiants, en publiant rapidement des mises à jour sur les incidents et en prouvant la segmentation. La référence du Trust Center de Salesloft à la vérification de la segmentation entre les applications Drift et Salesloft est importante car les clients ont besoin de la confiance que la compromission d'un produit n'est pas devenue une compromission plus large du fournisseur.

Les normes OAuth expliquent pourquoi les jetons porteurs exigent une discipline supplémentaire

OAuth est conçu pour l'autorisation déléguée. La spécification de base OAuth 2.0,RFC 6749, permet à un client d'obtenir des jetons d'accès à des ressources avec l'autorisation du propriétaire de la ressource. La conception est puissante car l'utilisateur n'a pas besoin de donner son mot de passe au client. Le risque est qu'un jeton d'accès est souvent un justificatif porteur: quiconque le détient peut l'utiliser dans les limites de sa portée jusqu'à son expiration ou sa révocation.

Le modèle de menace OAuth et les considérations de sécurité de laRFC 6819mettent en garde contre la fuite de jetons, le stockage des jetons, la rejeu, l'hameçonnage, l'abus de redirection et la nécessité de limiter la portée et la durée de vie. La nouvelle meilleure pratique de sécurité OAuth 2.0,RFC 9700, poursuit cette direction en mettant l'accent sur des schémas défensifs modernes. Ces normes ne sont pas des rapports d'incident Salesforce. Elles expliquent pourquoi la campagne Drift était structurellement dangereuse.

Si un jeton Drift avait un large accès à Salesforce, le jeton lui-même incarnait la confiance. Une équipe de sécurité pouvait supprimer le mot de passe de l'utilisateur, appliquer la MFA, et néanmoins faire face à un risque si le jeton de l'application restait valide. C'est pourquoi la révocation des jetons était l'action d'urgence. C'est aussi pourquoi le niveau suivant est la minimisation des portées. Un jeton volé avec une portée étroite peut être nuisible mais limité. Un jeton volé avec une large portée de lecture peut devenir un outil d'exportation de données.

La technique MITRE ATT&CKSteal Application Access Tokendécrit les adversaires volant des jetons d'accès applicatifs pour accéder à des systèmes et API distants. Sa techniqueUse Alternate Authentication Materialcouvre le schéma plus large consistant à utiliser des artefacts d'authentification valides au lieu de mots de passe. Ces cadres aident à nommer la classe d'attaque sans exagérer les faits spécifiques à Salesforce: le problème était un matériel délégué valide entre de mauvaises mains.

La leçon standard est simple mais opérationnellement difficile. Les jetons doivent être traités comme des secrets. Les jetons de rafraîchissement doivent être traités comme des secrets particulièrement sensibles car ils peuvent générer des accès futurs. Les portées doivent être aussi étroites que le produit peut le tolérer. Les jetons doivent pouvoir faire l'objet d'une rotation et être révocables. Les logs doivent montrer l'utilisation des jetons par application et par objet. Les clients doivent savoir quelles identités non humaines peuvent lire leurs données.

Les plateformes doivent rendre difficiles l'approbation silencieuse des portées dangereuses.

L'hygiène des applications connectées nécessite un propriétaire, pas un tableur après la brèche

De nombreuses organisations découvrent leurs applications connectées lors d'un incident. C'est trop tard. Un inventaire des applications connectées devrait exister avant la campagne: nom de l'application, fournisseur, propriétaire métier, propriétaire technique, portées, profils installés, dernière utilisation, politique de jetons de rafraîchissement, objets de données touchés, statut du contrat et procédure de suppression. Si personne n'est propriétaire de l'application, personne n'est propriétaire du risque.

La documentation de Salesforce pour lagestion des applications connectéeset lespolitiques OAuth pour les applications connectéesmontre que la plateforme offre des contrôles administratifs. La question est de savoir si les clients disposent du personnel, des connaissances et des incitations pour bien les utiliser. Une petite entreprise peut installer un outil de chat commercial et ne jamais revoir ses portées. Une grande entreprise peut avoir des centaines d'applications connectées et aucune cadence d'examen unifiée.

C'est là que la conception de la plateforme devrait réduire les erreurs. Les portées dangereuses devraient être visibles en langage clair. Les applications connectées inutilisées devraient être faciles à trouver. Les applications avec des jetons de rafraîchissement devraient être mises en évidence. Les applications à haut risque devraient avoir des options d'expiration ou de réautorisation périodique. Les administrateurs devraient pouvoir révoquer l'accès d'une application sans rompre les flux de travail non liés. Les équipes de sécurité devraient recevoir des alertes d'anomalie API spécifiques aux applications.

Les clients ont également besoin d'une politique. Aucune application ne devrait recevoir un large accès sans un propriétaire désigné et une date d'examen. Aucune application ne devrait rester installée après le départ du propriétaire métier. Aucune application ne devrait stocker des secrets dans les enregistrements CRM simplement parce que c'est pratique. Aucune application ne devrait être exemptée des procédures d'incident parce qu'il s'agit « juste d'un outil commercial ». La campagne Drift a montré qu'un outil commercial peut devenir un chemin d'incident de sécurité.

Le problème est en partie économique. Les applications connectées économisent du travail. L'examen coûte du travail. Si le bénéfice est immédiat et le risque rare, les organisations sous-investissent dans l'examen. La plateforme et le fournisseur peuvent réduire ce déséquilibre en abaissant le coût d'une bonne gouvernance: tableaux de bord clairs, scores de risque, recommandations automatisées et valeurs par défaut plus sûres.

Les logs doivent répondre aux questions sur lesquelles un client peut agir

Les conseils en cas d'incident disent souvent aux clients d'examiner les logs. Ce conseil n'est utile que si les logs répondent aux bonnes questions. Pour la campagne Drift, les clients devaient savoir quels jetons d'application ont été utilisés, quels objets Salesforce ont été interrogés, quels enregistrements ont été exportés, à partir de quelles adresses IP, avec quel contexte utilisateur, sur quelle fenêtre de temps et si les requêtes recherchaient des chaînes de type secret.

La surveillance des événements Salesforce, les logs API et les rapports d'applications connectées peuvent aider, mais l'accès à des preuves complètes peut dépendre de la licence, de la conservation et de la configuration. Un client qui ne dispose pas de la bonne édition ou d'un pipeline d'exportation de logs peut recevoir un avis et avoir néanmoins du mal à déterminer l'exposition. C'est un problème de gouvernance de la plateforme. Lorsqu'une intégration de place de marché fait l'objet d'un abus transversal, la plateforme est la mieux placée pour fournir des ensembles de preuves normalisées.

Les clients ont également besoin d'un chemin de triage reproductible. Premièrement, identifier si Drift a été installé et connecté. Deuxièmement, déterminer si les jetons étaient actifs pendant la fenêtre de la campagne. Troisièmement, inspecter l'activité API attribuée à l'application. Quatrièmement, identifier l'accès aux objets et aux champs. Cinquièmement, rechercher dans les enregistrements exportés ou accessibles des secrets. Sixièmement, effectuer la rotation de tous les secrets qui ont pu être exposés. Septièmement, notifier les parties en aval si des données réglementées ou clients sont impliquées.

L'avis du FBI/IC3 et les conseils du GTIG orientent les clients vers ce type d'action, mais l'exécution varie considérablement. Une grande entreprise financière peut disposer d'une équipe d'opérations de sécurité et d'un lac de logs. Une petite entreprise SaaS peut avoir un administrateur Salesforce, un fournisseur de sécurité géré et un retard. La même campagne crée donc des charges de récupération inégales.

Cette inégalité est importante pour la responsabilité. Les plateformes qui servent des entreprises de niveaux de maturité très différents ne devraient pas supposer que tous les clients peuvent interpréter les logs bruts ou les indicateurs de renseignement sur les menaces. Des preuves exploitables et spécifiques au locataire réduisent le coût de la réponse et le risque que les secrets volés restent valides.

Les secrets dans les enregistrements CRM sont une défaillance évitable mais courante

Une leçon inconfortable est que les clients doivent cesser de considérer le CRM comme un endroit sûr pour les secrets opérationnels. Les équipes de support et de vente collent souvent des clés API, des identifiants, des jetons porteurs, des secrets de webhook, des détails VPN ou des captures d'écran dans les dossiers et les notes parce qu'elles essaient de résoudre un problème. Le CRM devient une archive de commodité. Lorsqu'une intégration peut la lire, l'archive de commodité devient un dépôt de secrets.

Lafiche de gestion des secrets d'OWASPexplique pourquoi les secrets nécessitent un stockage contrôlé, une rotation et une discipline d'accès. La campagne Drift applique ce principe aux données CRM. Si des secrets apparaissent dans les enregistrements, une exportation CRM peut devenir un trousseau de clés.

La réparation est en partie technique: analyser les enregistrements à la recherche de motifs de secrets, masquer les champs sensibles, restreindre les pièces jointes et alerter lorsque des formats de clés connus apparaissent. Elle est aussi culturelle: former les équipes de support à ne pas demander ni stocker de secrets, fournir des canaux de collecte sécurisés pour le matériel de diagnostic nécessaire et faciliter la purge des secrets lorsqu'ils sont découverts. Si l'organisation pénalise la lenteur du support mais pas les notes de support non sécurisées, les employés continueront à prendre des raccourcis.

Salesforce et les fournisseurs d'intégration peuvent aider en intégrant des fonctionnalités de détection de secrets et en avertissant les clients lorsque des portées d'application étendues incluent des objets susceptibles de contenir des données opérationnelles sensibles. Mais les clients restent responsables de l'hygiène des données à l'intérieur de leurs organisations. L'incident Drift n'a pas créé la mauvaise pratique de stocker des secrets dans le CRM; il a révélé comment cette pratique peut amplifier une compromission d'un jeton tiers.

Le dossier public doit conserver ce qui ne s'est pas produit

Il est tout aussi important d'indiquer ce que le dossier public ne montre pas. Les sources ne montrent pas que les attaquants ont exploité une vulnérabilité du noyau de Salesforce. Elles ne montrent pas que chaque client Salesforce a été affecté. Elles ne montrent pas que tous les clients connectés à Drift ont vu les mêmes données exportées. Elles ne montrent pas que chaque enregistrement exporté contenait des secrets. Elles ne montrent pas que la suite de produits plus large de Salesloft a été compromise au-delà de ce que l'enquête de Salesloft a décrit.

Ces limites protègent l'équité. Elles rendent également la véritable leçon plus nette. L'incident est grave sans exagération car une intégration de confiance est devenue une voie d'accès déléguée aux environnements clients. La gravité vient du modèle de confiance, pas de la nécessité d'inventer une vulnérabilité zero-day de la plateforme.

L'incident ne doit pas non plus être réduit à un « risque tiers » au sens vague. Le risque tiers spécifique était la garde des jetons et l'autorité des applications connectées. Un fournisseur peut avoir des rapports SOC, des contrats et des questionnaires de sécurité tout en détenant des jetons qui nécessitent une protection exceptionnelle. Les examens des risques fournisseurs par les clients doivent demander comment les intégrations SaaS stockent les jetons, quelles portées elles exigent, à quelle vitesse les jetons peuvent être révoqués et quelles preuves le fournisseur peut fournir après un incident.

L'examen de l'AppExchange de la plateforme nécessite également de la spécificité. Il ne doit pas seulement vérifier qu'une application fonctionne et répond aux exigences de sécurité de base au moment de la publication. Il doit prendre en charge une surveillance continue, une suspension rapide, la notification des clients et une revalidation post-incident. La confiance dans une place de marché est une obligation continue, pas un badge unique.

Quels éléments de preuve modifieraient l'évaluation

L'évaluation pourrait évoluer dans un sens ou dans l'autre avec davantage de preuves. Si des détails médico-légaux ultérieurs montrent que les jetons compromis étaient extrêmement limités, que les exportations étaient restreintes et que les clients affectés ont reçu rapidement des logs complets au niveau des objets, la gravité opérationnelle devrait être réduite. Si des preuves ultérieures montrent des portées plus larges, des jetons à longue durée de vie, un stockage de jetons faible, une révocation retardée ou une exposition étendue des secrets, la gravité devrait augmenter.

Si Salesforce publie plus de détails sur les améliorations de la surveillance de l'AppExchange, les fonctionnalités d'inventaire des jetons, les packages de logs clients ou des valeurs par défaut plus sûres pour les applications connectées, cela renforcerait le dossier de réparation. Si Salesloft publie plus de détails sur la cause racine, la garde des jetons, la segmentation et la remédiation client, cela renforcerait la responsabilité du fournisseur. Si des régulateurs émettent des conclusions, celles-ci doivent être évaluées séparément du dossier d'avis public actuel.

En attendant, les preuves soutiennent une conclusion de contrôle à haut niveau de confiance: les écosystèmes SaaS ont besoin d'une gouvernance des applications connectées qui traite les jetons délégués comme des identifiants de production, et non comme une plomberie d'intégration.

Cette conclusion est utile précisément parce qu'elle évite de trop revendiquer. Elle permet aux clients de renforcer les applications connectées sans attendre un dossier judiciaire définitif. Elle permet aux plateformes d'améliorer les contrôles de place de marché et de jetons sans admettre une faille de la plateforme centrale que les preuves ne montrent pas. Elle permet aux fournisseurs de traiter la garde des jetons comme une obligation de sécurité produit.

La leçon de la campagne n'est pas spéculative: l'accès délégué peut être volé, et lorsqu'il l'est, l'écosystème doit savoir qui peut le révoquer, qui peut l'expliquer et qui peut prouver ce qu'il a touché.

Les exercices de révocation doivent être routiniers

Le moyen le plus rapide d'apprendre si la gouvernance OAuth est réelle est d'effectuer un exercice de révocation avant un incident. Choisissez une application connectée non critique. Identifiez le propriétaire métier, les portées, les utilisateurs, les jetons, les logs, les flux de travail dépendants et le chemin de retour en arrière. Révoquez l'accès dans une fenêtre contrôlée et mesurez ce qui se casse. Documentez ensuite qui a approuvé la restauration et quelles preuves ont montré que l'application pouvait être reconnectée en toute sécurité.

Cet exercice transforme l'inventaire abstrait des applications en connaissances opérationnelles. Il montre si la sécurité peut trouver l'application, si les administrateurs peuvent la révoquer, si l'entreprise comprend le flux de travail, si les utilisateurs reçoivent des instructions claires et si les logs peuvent prouver ce à quoi l'application a accédé. Il révèle également où les équipes ont peur de toucher aux anciennes intégrations parce que personne ne sait pourquoi elles existent.

La campagne Drift montre pourquoi cette pratique est importante. Dans une compromission réelle, l'organisation ne peut pas passer des jours à découvrir qui possède une intégration pendant que les attaquants utilisent des jetons volés. Un client préparé peut révoquer d'abord, enquêter rapidement et ne reconnecter qu'avec des preuves. Un client non préparé peut hésiter parce que chaque jeton ressemble à la continuité des activités.

Le test de responsabilité

La campagne Drift-Salesforce doit être jugée à travers sept contrôles.

Premièrement, la garde des jetons: Salesloft a-t-il protégé les jetons d'accès et de rafraîchissement comme des identifiants hautement sensibles, et son architecture a-t-elle minimisé l'exposition des jetons entre Drift et d'autres produits?

Deuxièmement, la conception des portées: l'intégration Drift a-t-elle demandé uniquement les permissions Salesforce dont elle avait besoin, et les clients ont-ils compris le rayon d'impact de l'approbation de ces permissions?

Troisièmement, la gouvernance de la place de marché: l'examen, la surveillance et le processus de retrait d'urgence de l'AppExchange de Salesforce ont-ils réduit le risque client assez rapidement une fois que l'application du fournisseur est devenue dangereuse?

Quatrièmement, la détection transversale: Salesforce, Salesloft et les partenaires de renseignement sur les menaces ont-ils identifié les schémas de la campagne assez rapidement pour révoquer les jetons avant de nouvelles exportations?

Cinquièmement, les preuves au niveau du locataire: les clients affectés ont-ils reçu suffisamment de logs, de preuves d'accès aux objets et de conseils pour déterminer ce qui a été interrogé et si des secrets ont été exposés?

Sixièmement, l'hygiène des secrets: les clients ont-ils stocké des mots de passe, des clés API, des jetons cloud ou des identifiants VPN dans les enregistrements Salesforce, et les ont-ils fait tourner après exposition?

Septièmement, la communication publique: les avis ont-ils préservé la distinction essentielle que le noyau de Salesforce n'a pas été exploité tout en indiquant clairement que les données des clients Salesforce ont été consultées via des jetons d'application de confiance?

La conclusion finale n'est pas que Salesforce était le produit vulnérable. Le dossier public dit le contraire: le problème ne provenait pas d'une vulnérabilité de la plateforme centrale Salesforce. La conclusion est que le périmètre de confiance de Salesforce inclut les applications connectées, car les clients font l'expérience de la plateforme à travers son écosystème. Les jetons OAuth sont une autorité déléguée. Lorsqu'une intégration de confiance perd cette autorité, la plateforme, le fournisseur et le client ont tous des devoirs distincts.

La campagne Drift a rendu ces devoirs visibles de la manière la plus inconfortable: en transformant une intégration de productivité approuvée en une clé détenue par un attaquant.