Les permissions d'invité mal configurées dans Experience Cloud risquent vos données

Salesforce a récemment mis en garde contre une augmentation de l'activité malveillante qui cible les sites publics construits avec Experience Cloud. La technique décrite n'exploite pas une défaillance de service elle-même, mais plutôt des configurations trop permissives dans le profil d'utilisateur invité que de nombreuses organisations maintiennent pour publier des pages publiques - et qui, si elles ne sont pas correctement ajustées, peuvent permettre aux attaquants d'obtenir des informations qui ne devraient pas être ouvertes au public.

Au centre de l'actualité se trouve une version modifiée d'un outil open source appelé AuraInspector, développé pour vérifier les configurations dans le cadre Aura de Salesforce. L'outil original, lancé par Mandiant, permet d'identifier les objets et les points exposés par des paramètres publics tels que / s / sfsites / aura. Ce qui est inquiétant, c'est que, selon Salesforce, les acteurs malveillants ont adapté cet utilitaire pour automatiser le balayage de masse et passer de la simple détection à l'extraction de données lorsque des configurations trop laxas sont trouvées.

Cela signifie que ce n'est pas une "vulnérabilité" sur la plate-forme en soi, mais des configurations qui permettent aux utilisateurs non authentifiés de consulter sur les objets CRM. Salesforce a explicitement souligné que, jusqu'à présent, ils n'ont pas détecté de défaillance inhérente au système: les tentatives visent les ajustements des clients qui ne suivent pas les recommandations de sécurité publiées par l'entreprise elle-même. La déclaration officielle et les indications peuvent être lues sur le blog Salesforce et dans votre avis public sur la question Voilà. et sur votre page d'état Voilà..

Pour comprendre la mécanique : Experience Les sites publics de Cloud utilisent un profil "invité" spécial pour afficher des contenus publics tels que les entrées d'aide, les FAQ ou les pages d'atterrissage. Ce profil doit être strictement limité. Si la lecture ou l'accès aux API publiques sont accordés par erreur à ce profil, un scanner automatisé pourrait énumérer des objets et même extraire des champs avec des données sensibles sans authentification.

Le risque pratique n'est pas seulement l'exfiltration immédiate de noms ou de téléphones; Salesforce avertit que ces informations peuvent être la matière première d'attaques ultérieures. Des données apparemment inoffensives servent à affiner les campagnes d'ingénierie sociale et les attaques vocales (vishing), qui sont souvent plus efficaces lorsque l'agresseur a déjà des détails vérifiables sur les employés ou les clients. En ce sens, l'activité signalée correspond à ce que l'entreprise qualifie d'un modèle plus large d'attaques « fondées sur l'identité ».

Salesforce a recommandé plusieurs mesures d'atténuation que tout administrateur devrait examiner immédiatement : restreindre l'accès de l'utilisateur invité, établir la visibilité par défaut des objets en privé, désactiver l'accès public aux API à partir des profils d'invités et contrôler l'auto-enregistrement si ce n'est strictement nécessaire. La société a publié des guides avec des étapes concrètes pour vérifier et renforcer ces configurations dans leurs ressources.

L'outil original sur lequel ces attaques sont basées a été publié par Mandiant ; l'existence d'une version modifiée par des acteurs malveillants montre comment les utilitaires conçus pour améliorer la sécurité peuvent également être réutilisés à des fins offensives s'ils tombent entre de mauvaises mains. Ceux qui veulent revoir l'outil public peuvent consulter le dépôt officiel et les notes de publication de Mandiant dans GitHub et sur le site de Mandiant Voilà..

Salesforce attribue la campagne à un groupe de menaces connues sans la nommer expressément, ouvrant la possibilité de relation avec des opérations qui ont déjà dirigé des attaques antérieures sur des écosystèmes CRM par des applications tierces. Quoi qu'il en soit, le message à l'intention des gestionnaires et des responsables de la sécurité est clair : examiner les politiques d'accès, surveiller les consultations inhabituelles et appliquer le principe des privilèges minimaux à tous les profils publics.

Pour les équipements techniques et de sécurité qui doivent prioriser les actions, il n'est pas nécessaire d'attendre une intrusion pour réagir. Un audit des autorisations de profil d'invité, la désactivation des API publiques pour ce profil et la révision des boucles d'accès sont souvent des mesures techniques à impact élevé. En plus de suivre les recommandations de Salesforce, il est approprié d'intégrer des alertes spécifiques dans les systèmes de détection pour capturer des modèles de numérisation de masse ou des consultations qui tentent de lister des objets CRM.

Bref, cet incident rappelle que la sécurité n'est pas seulement une question de correctifs et de mises à jour des fournisseurs : elle dépend également des politiques et des configurations locales. Les outils automatisés peuvent aider à identifier les faiblesses, mais ils peuvent également être réutilisés par les adversaires, « de sorte qu'une configuration soigneuse et un suivi constant restent les meilleurs obstacles à de telles campagnes.