Une nouvelle vulnérabilité dans ServiceNow, baptisée Count (er) Strike, permet aux utilisateurs à faibles privilèges d’extraire des données sensibles à partir de tables auxquelles ils ne devraient pas avoir accès.
ServiceNow est une plate-forme basée sur le cloud qui permet aux organisations de gérer les flux de travail numériques pour leurs opérations d’entreprise. Il est largement adopté dans divers secteurs, notamment les organisations du secteur public, les soins de santé, les institutions financières et les grandes entreprises.
La faille a été découverte par Varonis Threat Labs en février 2025 et a attribué l’identifiant CVE-2025-3648, et peut avoir un impact sur les configurations avec des listes de contrôle d’accès mal configurées ou trop permissives.
ServiceNow a publié des frameworks de contrôle d’accès supplémentaires dans les versions Xanadu et Yokohama, publiées le mois dernier, pour résoudre le problème. Cependant, tous les administrateurs doivent examiner les tables existantes pour s’assurer que leurs données sont correctement verrouillées.
Le défaut de frappe du comte(er)
ServiceNow utilise des listes de contrôle d’accès (ACL) pour restreindre l’accès aux données dans ses tables. Chaque ACL évalue quatre conditions pour déterminer si un utilisateur doit avoir accès à une ressource spécifique:
- Rôles requis
- Attributs de sécurité
- Conditions des données
- Conditions du script
Pour qu’un utilisateur puisse accéder à une ressource, toutes ces conditions doivent être remplies.
Cependant, si une ressource est protégée avec plusieurs listes de contrôle d’accès, ServiceNow utilisait auparavant une condition « Autoriser si », ce qui signifie que si un utilisateur satisfaisait une seule liste de contrôle d’accès, il pouvait y accéder, même si d’autres listes de contrôle d’accès les auraient bloquées.
Dans certains cas, cela accordait un accès complet. Cependant, dans d’autres, il autorisait un accès partiel, tel que le nombre d’enregistrements pouvant être exploités, comme expliqué plus loin dans l’article.
« Chaque ressource ou table dans ServiceNow peut avoir de nombreuses listes de contrôle d’accès, chacune définissant des conditions d’accès différentes », explique le rapport Varonis..
« Cependant, si un utilisateur transmet une seule liste de contrôle d’accès, il accède à la ressource, même si d’autres listes de contrôle d’accès peuvent ne pas accorder l’accès. Si aucune liste de contrôle d’accès n’est présente pour la ressource, access utilisera par défaut la propriété d’accès par défaut qui est définie sur refuser dans la plupart des cas. »
Ce modèle permissif a conduit Varonis à découvrir qu’il était possible d’obtenir un accès partiel, qui pouvait être utilisé pour énumérer des données protégées, même si l’utilisateur avait peut-être échoué à des listes de contrôle d’accès plus restrictives.
Varonis a constaté que si un utilisateur échoue à la condition de données ou à la condition de script, ServiceNow renvoie toujours le nombre d’enregistrements dans l’interface utilisateur et le code HTML source. La page indique également que certains résultats ont été supprimés en raison de contraintes de sécurité.
Avec ces données partielles, Varonis a commencé à manipuler des filtres basés sur des URL, tels que STARTSWITH, CONTAINS, = et != pour énumérer le contenu des enregistrements un caractère ou une condition à la fois.
Par exemple:
https://[my_company].service-now.com/task_list.do?sysparm_query=short_descriptionSTARTSWITHpLa répétition de ce processus avec différentes valeurs et requêtes permet de récupérer les données un caractère ou un chiffre à la fois.
Pour automatiser cette procédure, Varonis a créé un script qui énumérait avec succès les enregistrements de données d’une table à laquelle ils avaient un accès limité.
Même lorsque les données d’enregistrement ne sont pas affichées, le nombre d’enregistrements laisse échapper suffisamment d’informations pour déterminer les champs, y compris les informations d’identification, les informations d’identification personnelles et les données de configuration internes.
Varonis a averti que les utilisateurs auto-enregistrés pourraient également utiliser cette attaque. L’auto-inscription est une fonctionnalité qui permet aux utilisateurs de créer des comptes et d’accéder à l’instance avec des privilèges minimaux, qui peuvent toujours être utilisés pour lancer une attaque.
« Bien qu’il soit rare que les instances autorisent l’enregistrement et l’accès anonymes, cette configuration a été trouvée dans les systèmes ServiceNow de plusieurs sociétés Fortune 500 », a averti Varonis.
Atténuer l’attaque
Varonis a déclaré à Breachtrace qu’ils avaient testé l’attaque contre le produit ITSM Servicenow, mais a déclaré qu’elle devrait également s’appliquer à tous les produits ServiceNow qui utilisent la même logique ACL.
Service Now a maintenant résolu l’attaque en:
- Introduction des listes de contrôle d’accès « Refuser sauf si », qui obligent les utilisateurs à transmettre toutes les listes de contrôle d’accès pour accéder à un ensemble de données.
- Ajout de listes de contrôle d’accès de requête, qui restreignent ces types de requêtes d’énumération à l’aide d’opérateurs de plage.
- Recommander l’utilisation de filtres de données de sécurité, qui masquent le nombre de lignes et suppriment les indices d’inférence.
Cependant, les clients doivent toujours examiner manuellement leurs tables et modifier les listes de contrôle d’accès pour s’assurer qu’elles ne sont pas trop permissives et donc vulnérables à cette attaque.
Varonis dit qu’il n’a vu aucune preuve que cette vulnérabilité a été exploitée à l’état sauvage.