City-Forum : comment un unique serveur a siphonné les données de Salesforce et ServiceNow pendant 17 mois sans exploiter la moindre vulnérabilité

Fonctionnement de l'exploitation : aucune vulnérabilité requise

Salesforce et ServiceNow sont tous deux livrés avec des comptes invités permanents pour les visiteurs non authentifiés. Ces comptes invités ne peuvent pas être supprimés. Leurs permissions — les enregistrements et objets qu'ils peuvent lire — sont configurées par chaque organisation. Si le profil invité a un accès en lecture à un enregistrement, n'importe qui sur Internet peut le récupérer via des points de terminaison d'API parfaitement légitimes.

Sur Salesforce (framework Aura) :

• L'outil envoie des requêtes POST aux endpoints /aura ou /s/sfsites/aura.
• Il appelle d'abord HostConfigController.getConfigData pour énumérer quels objets (Account, Contact, Case, Lead, User, ContentDocument, etc.) sont accessibles à l'invité.
• Il utilise ensuite SelectableListDataProviderController.getItems pour parcourir tous les enregistrements de chaque objet accessible.
• La cible la plus active a enregistré plus de 560 000 événements depuis l'IP de l'attaquant, presque tous de l'énumération Aura en mode invité.

Sur Salesforce (framework LWR — Lightning Web Runtime) :

• Il s'agit de la première exploitation observée dans la nature de la surface d'attaque UI-API de Salesforce sur les sites LWR.
• L'outil cible un endpoint GraphQL à

  POST /webruntime/api/services/data/{version}/graphql?asGuest=true

  , en énumérant d'abord le schéma via EntityDefinition, puis en lisant les enregistrements avec une pagination basée sur un curseur.
• Il balaie les versions d'API v56.0 à v66.0 en séquence contre chaque site LWR découvert.

Sur ServiceNow :

• L'outil cible l'endpoint /api/now/sp/search — une API de recherche native du portail ServiceNow qui est largement non documentée et pour laquelle il n'existe quasiment aucune documentation en ligne ou outil open source.
• Cet endpoint est public par conception. Les données qu'il renvoie dépendent entièrement des sources de recherche attachées à un portail public et du fait que ces sources appliquent ou non des contrôles d'accès.

Sondage d'auto-inscription (Salesforce) :

• L'outil ajoute /SiteRegister et /CommunitiesSelfReg à chaque chemin de site découvert pour tester si l'auto-inscription est activée. Si c'est le cas, un invité peut s'élever au rang d'utilisateur externe authentifié, obtenant ainsi l'accès à beaucoup plus de données.

La boîte à outils personnalisée et l'infrastructure

• IP source : 158.220.87.79, hébergée sur un VPS Contabo (hébergeur allemand), résolvant le domaine city-forum.com (un domaine enregistré en 2002, abandonné, puis réutilisé).
• La même IP porte le même domaine depuis mars 2025 sans rotation — au moins 17 mois sur une seule adresse.
• Binaire Go personnalisé : Un seul outil compilé en Go qui cible Salesforce à la fois sur les frameworks Aura et LWR ainsi que ServiceNow — tout cela depuis le même serveur. Il s'agit d'un ensemble d'outils multiplateformes personnalisé, et non d'un outil standard comme AuraInspector.
• L'outil utilise la chaîne Go-http-client par défaut de Go comme User-Agent, ce qui le rend facile à identifier dans les logs.

Organisations ciblées

Reco rapporte que les principales cibles incluent :

• Opérateurs télécoms
• Banques et sociétés de services financiers
• Éditeurs de logiciels d'entreprise (y compris les sociétés de sécurité et de protection des données)
• Portails du secteur public

Pourquoi les logs d'audit standard ne peuvent pas révéler quelles données ont été dérobées

Pour ServiceNow : Les logs de transaction de la plateforme (syslog_transaction) n'enregistrent pas le corps des requêtes POST vers /api/now/sp/search. Les défenseurs peuvent voir que des recherches automatisées ont eu lieu et la quantité de données renvoyées (via la colonne de longueur de sortie), mais ne peuvent pas déterminer les termes de recherche exacts ni les enregistrements spécifiques qui ont été récupérés.

Pour Salesforce : Le trafic d'énumération des invités est constitué d'appels API légitimes et conformes aux protocoles qui ressemblent à du trafic de site normal. Bien que la surveillance des événements (Event Monitoring) puisse montrer le volume d'événements AuraRequest et Sites provenant d'utilisateurs invités, les logs indiquent que des données ont été demandées mais pas le contenu spécifique de ce qui a été renvoyé dans les réponses GraphQL ou Aura.

En d'autres termes, vous pouvez voir que l'attaquant était présent et la quantité de données extraites, mais vous ne pouvez pas reconstituer exactement quels enregistrements ou champs ont été extraits.

Étapes de correction recommandées

Pour Salesforce (recommandations de Reco) :

1. Resserrez les règles de partage invité — le contrôle le plus efficace. Supprimez toute règle de partage qui partage des enregistrements avec l'utilisateur invité au-delà de ce dont le site a réellement besoin pour le service public.
2. Supprimez les permissions d'objet et de champ du profil invité. Retirez l'accès en lecture aux objets dont le site n'a pas besoin pour les visiteurs anonymes.
3. Supprimez la permission "Accéder aux activités" du profil invité (qui expose les tâches et événements).
4. Désactivez "API activée" sur l'utilisateur invité.
5. Désactivez l'auto-inscription sauf si le site en a vraiment besoin.
6. Désactivez l'accès aux fichiers invités et la visibilité des membres afin que les invités ne puissent pas récupérer les fichiers ContentDocument ou énumérer les autres membres du site.
7. Pour les sites LWR uniquement : Dans Experience Builder → Espaces de travail → Administration → Préférences, décochez "Autoriser les utilisateurs invités à accéder aux API publiques." Cela ferme GraphQL et les endpoints REST UI-API en une seule action.

Pour ServiceNow (recommandations de Reco) :

1. Cartographiez les portails publics avec leurs sources de recherche. Vérifiez les tables sp_portal, m2m_sp_portal_search_source et sp_search_source. Détachez toute source de recherche dont un portail public n'a pas besoin.
2. Examinez la logique de chaque source de recherche — en particulier is_scripted_source, data_fetch_script, et si elle utilise GlideRecordSecure (qui applique les ACL) ou GlideRecord (qui ne le fait pas).
3. Examinez les critères utilisateur "Peut lire" des bases de connaissances — recherchez les accès "Tout utilisateur" non contraints qui exposent des bases de connaissances sensibles via la recherche invitée.
4. Détachez les mauvais liens kb_uc_can_read_mtom plutôt que de modifier aveuglément les règles de partage.

Conseils de détection :

• Salesforce Event Monitoring : Recherchez des volumes élevés de getItems et getConfigData provenant de

  USER_TYPE = 'Guest'

  , des balayages de versions /webruntime/.../vNN.0/graphql, et des accès à /SiteRegister et /CommunitiesSelfReg.
• ServiceNow syslog_transaction : Recherchez les requêtes /api/now/sp/search faites en tant qu'invité. Triez par longueur de sortie — les lignes renvoyant significativement plus que la petite ligne de base de résultat vide indiquent des recherches qui ont renvoyé du contenu.