Salesforce n’a pas réussi à répondre à la vague massive de violations OAuth lors de sa conférence Dreamforce, mais la sécurisation de l’authentification tierce est primordiale pour l’avenir agent qu’elle recherche.
La conférence phare Dreamforce de Salesforce a proposé la semaine dernière aux participants une série de sessions sur les meilleures pratiques pour sécuriser leurs environnements Salesforce et leurs agents d’IA, et sur ce que Salesforce lui-même fait avec l’IA pour améliorer la sécurité. La société a même lancé deux nouveaux agents destinés aux RSSI avant l’événement, un pour gérer les problèmes de sécurité et un agent pour gérer la confidentialité et la conformité.
Dans l’ensemble, la sécurité en tant que responsabilité partagée était le thème principal : Salesforce fait sa part et les clients doivent faire la leur.
Mais ce que la conférence n’a pas abordé, ce sont les faiblesses révélées par la récente vague de violations liées à Salesforce qui ont touché plus de 700 entreprises et près de 1,5 milliard de dossiers, inspirant plus de 70 poursuites.
« J’étais présent à l’événement et j’ai parlé à tous les dirigeants, et cela ne faisait pas partie des sujets », explique Chirag Mehta, vice-président de Constellation Research. « Cela n’a pas été évoqué. »
Cette omission était probablement une occasion manquée, étant donné que les leçons de ce qui s’est passé dans l’écosystème Salesforce au cours des derniers mois sont importantes pour l’avenir de plus en plus connecté et infusé d’IA qui est au cœur de la vision agentique de Salesforce.
Anatomie d’un cyber-catastrophe tiers
Le problème est l’une des plus grandes violations de la chaîne d’approvisionnement SaaS de ces dernières années. Selon le Google Threat Intelligence Group, plus de 700 organisations ont été touchées par une faille du mois d’août au cours de laquelle « l’acteur a systématiquement exporté de gros volumes de données depuis de nombreuses instances Salesforce d’entreprise ».
Étant donné que les données avaient été stockées par Salesforce, les non-professionnels du cyberespace pourraient supposer qu’il s’agissait d’une violation de Salesforce, mais ce n’était pas le cas, explique Mehta.
« Oui, la violation s’est produite dans une instance Salesforce », explique-t-il. « Mais cela n’a pas été causé par quelque chose que Salesforce a fait. Les gens qui comprennent ce qui se passe comprennent ce que Salesforce est censé faire et ce que les clients étaient censés faire. »
Au lieu de cela, la violation s’est produite lorsqu’un acteur malveillant a obtenu des jetons Salesforce OAuth auprès de l’outil de chat IA tiers Salesloft Drift et a utilisé ces jetons pour télécharger de gros volumes de données à partir d’instances Salesforce.
Salesforce, qui a tenté de minimiser la gravité de la violation en affirmant qu' »un petit nombre de clients » étaient concernés, a noté que lorsqu’il a détecté l’activité, il « a invalidé les jetons d’accès et d’actualisation actifs et a supprimé Drift d’AppExchange. Nous avons ensuite informé les clients concernés ».
Mais selon Cloudflare, client de Salesforce, le géant du CDN a vu les premiers signes de reconnaissance liés à la violation le 9 août, avec un attaquant ayant accès au client Salesforce de Cloudflare le 12 août. Le 17 août, les attaquants avaient analysé les flux de travail des dossiers Salesforce de Cloudflare, obtenu des informations sur la façon dont les membres de l’équipe de Cloudflare traitaient différents types de cas et terminé leur exfiltration.
Trois jours plus tard, le 20 août, Salesforce a révoqué les connexions Salesloft Drift et publié son avis sur son site Internet. « À ce stade, Cloudflare n’avait pas encore été informé et nous n’avions aucune indication que cette action du fournisseur pourrait être liée à notre environnement », ont déclaré les responsables de la sécurité de Cloudflare.
Cloudflare n’était pas seul. Des centaines d’entreprises ont été touchées, dont certains des plus grands noms de la cybersécurité.
Idan Cohen, chercheur en sécurité chez Mitiga, a écrit : « Dans l’affaire Drift, les clients n’ont pas été négligents. Les attaquants n’ont pas réussi à se frayer un chemin. Ils se sont connectés en prétendant être un service tiers de confiance. »
Ce n’était pas le seul cas impliquant des comptes Salesforce piratés. En juin, un autre groupe d’attaquants, connu sous le nom de ShinyHunters, s’est fait passer pour le personnel du support informatique, afin d’inciter les utilisateurs à approuver une connexion à une version malveillante de l’application Data Loader de Salesforce qui a ensuite exfiltré les données des environnements Salesforce.
Google, dont l’équipe de renseignement sur les menaces a décrit ces attaques dans un rapport de juin, a lui-même été victime d’une telle attaque en août.
En octobre, les attaquants affirmaient avoir volé plus de 1,5 milliard d’enregistrements Salesforce auprès de 760 entreprises. Ils ont également lancé une campagne d’extorsion contre Salesforce et ses entreprises clientes compromises, notamment Toyota, FedEx, Hulu et UPS.
De nombreuses poursuites ont été intentées contre Salesforce, affirmant que l’entreprise n’en faisait pas assez pour contrôler les applications tierces connectées à ses systèmes, ni pour surveiller les signes d’exfiltration de données et d’autres activités malveillantes.
« Salesforce… avait le devoir et la capacité de contrôler son environnement logiciel et d’empêcher ces attaques de réussir grâce à la mise en œuvre de protocoles de sécurité que d’autres sociétés du secteur de Salesforce mettent régulièrement en œuvre. Mais Salesforce ne l’a pas fait », a déclaré une plainte dans un recours collectif déposé le 29 août en Californie.
Le potentiel d’exploitation d’OAuth « était un risque connu » et Salesforce n’a pas réussi à contrôler les connexions tierces, à mettre en place des protections ou à surveiller ses réseaux contre ce type d’activité malveillante, a déclaré un autre groupe de demandeurs d’un recours collectif dans une plainte déposée en septembre.
Selon le cabinet d’avocats CaseyGerry de San Diego, plus de 70 dossiers ont été déposés à travers le pays concernant la violation de données Salesforce.
Le plus grand angle mort
Lorsque les entreprises délèguent l’accès à des tiers via les intégrations OAuth, cela crée un angle mort de sécurité systémique qui s’étend à tous les secteurs.
En volant ces jetons, les attaquants peuvent accéder à tous les systèmes connectés. « L’autorisation d’une application connectée malveillante contourne de nombreuses défenses traditionnelles telles que l’authentification multifacteur, la réinitialisation des mots de passe et la surveillance des connexions, et comme les jetons OAuth sont émis par Salesforce lui-même, l’activité provenant de l’application malveillante peut ressembler à une intégration fiable », a averti le FBI dans une alerte publiée en septembre.
L’exploitation de ces faiblesses ne fera qu’empirer, d’autant plus que les intégrations liées à l’IA deviennent de plus en plus la norme.
Alors qu’une intégration CRM traditionnelle peut nécessiter des données de contact, « un assistant commercial IA a généralement besoin de contacts, d’historiques de courrier électronique, d’informations de calendrier, de données de pipeline de transactions, de journaux de conversation et de catalogues de produits », a noté Fernando Tucci, expert en sécurité IA de Trend Micro, dans un rapport expliquant pourquoi la violation de Salesloft Drift – un chatbot IA – frappe différemment. « Ce modèle d’accès plus large signifie qu’une seule intégration d’IA compromise peut exposer des informations beaucoup plus sensibles que les solutions ponctuelles traditionnelles. »
Pire encore, les chatbots IA étant spécialement conçus pour accéder à de grands ensembles de données, lorsqu’un acteur malveillant s’appuie sur la même connexion pour voler des données, le modèle de trafic peut sembler légitime.
Comprendre tous ces partenariats et connexions nécessite une coordination étroite avec la direction des fournisseurs, explique Steve Winterfeld, RSSI conseil chez Akamai. « De plus, comprendre où se trouvent vos données nécessite à la fois des politiques axées sur la culture et des contrôles techniques », dit-il.
Avec les services en marque blanche, les API et désormais les LLM, ces deux objectifs sont beaucoup plus complexes. « Si vous n’avez pas encore mené d’exercice de violation de la chaîne d’approvisionnement, c’est le moment », déclare Winterfeld. « Ces événements récents soulignent l’importance de valider votre programme. »
Ironiquement, de nombreuses entreprises de sécurité figuraient parmi les victimes, notamment Zscaler, Cloudflare, Palo Alto Networks, Pager Duty, SpyCloud, Tenable, Proofpoint, Rubrik, BeyondTrust, Bugcrowd, JFrog, CyberArk et Black Duck.
Une entreprise qui n’a pas été victime
Okta, fournisseur d’IAM basé sur le cloud, est une entreprise qui n’a pas été touchée par les violations. Pourquoi? Il autorisait les connexions uniquement à partir d’adresses IP autorisées.
Selon Okta, lorsque l’entreprise a eu connaissance de la compromission, elle a immédiatement examiné ses journaux et trouvé des tentatives d’accès aux ressources avec des jetons volés, mais ces tentatives ont échoué.
« Le contrôle le plus important qui a empêché cette violation a été notre application des restrictions sur les adresses IP entrantes », a déclaré la société. « L’acteur malveillant a tenté d’utiliser un jeton compromis pour accéder à notre instance Salesforce, mais l’attaque a échoué car la connexion provenait d’une adresse IP non autorisée. Cette couche de sécurité s’est avérée essentielle, bloquant la tentative non autorisée d’accès à la porte d’entrée avant qu’un accès ne puisse être obtenu. »
Cette approche de sécurité basée sur une liste blanche est une tactique puissante, mais elle est difficile à mettre en œuvre car elle nécessite beaucoup de discipline.
Un autre défi est que tous les fournisseurs SaaS ne prennent pas en charge cette fonctionnalité. « De nombreux fournisseurs dans un monde axé sur le cloud n’offrent pas cette fonctionnalité de sécurité fondamentale, ce qui crée un défi important pour la protection des systèmes interconnectés », a déclaré Okta.
Les références de sécurité fondamentales pour les fournisseurs SaaS ne sont que maintenant réunies, à la suite du SaaS Security Capability Framework (SSCF) récemment lancé par la Cloud Security Alliance.
Okta a noté que Salesforce propose déjà cette fonctionnalité, mais a ajouté que son utilisation nécessite « des efforts importants », étant donné que des restrictions doivent être configurées pour les API et les utilisateurs.
Une autre façon de protéger les connexions consiste à les limiter à un client spécifique, en utilisant une preuve de possession (DPoP), qui empêche la réutilisation des jetons volés, mais cela est encore plus difficile en pratique car cela nécessite des modifications du flux d’authentification et ajoute de nouvelles exigences pour les clients et les serveurs. Une autre option est le TLS mutuel, qui offre une sécurité encore plus forte, mais à un coût de complexité encore plus élevé.
Dans le secteur financier, par exemple, certains régulateurs imposent le DPoP ou le mTLS ; bien que cela ne soit pas obligatoire dans le domaine des soins de santé, il existe également un cas d’utilisation, selon Tyk Technologies.
De plus en plus d’entreprises devraient envisager de mettre à niveau cette solution à mesure que leur utilisation d’applications SaaS et d’outils d’IA interconnectés augmente.
L’Internet Engineering Task Force a inclus DPoP et mTLS parmi ses meilleures pratiques en matière de sécurité OAuth.
Risque accru à l’avenir
Lorsque les entreprises autorisent les connexions à des systèmes en dehors de leur périmètre, elles doivent comprendre les risques qu’elles assument et les contrôles de sécurité à leur disposition, explique Mehta de Constellation.
Même un contrôle aussi simple et courant que l’authentification multifacteur peut être difficile à mettre en œuvre pour tous les employés, dit-il.
« Du point de vue du fournisseur de solutions, ils fournissent un ensemble spécifique de contrôles et de fonctionnalités de sécurité et il appartient aux clients de s’assurer qu’ils les utilisent réellement. À mon avis, il s’agit d’une responsabilité partagée », explique Mehta.
La responsabilité partagée de la sécurité était une partie importante du message de Dreamforce de la semaine dernière, mais la discussion sur l’incident de Salesloft était manifestement absente – une perte pour les participants.
Car si quelque chose peut être retenu des derniers mois en matière de cybersécurité liée à Salesforce, c’est que la sécurité de la chaîne d’approvisionnement logicielle est plus importante que jamais. Et cela ne fera que gagner en importance à mesure que davantage de systèmes seront connectés – un principe clé de l’objectif de Salesforce de propulser l’entreprise agentique.
La sécurité de la chaîne d’approvisionnement logicielle n’est déjà pas si facile à réaliser et, même si Salesforce promet de rendre cela plus facile avec l’aide de l’IA, c’est l’IA elle-même qui rendra le problème encore plus difficile à résoudre.
