Vulnérabilité « Count(er) Strike » sur ServiceNow : Une Alerte Sécurité Incontournable

Introduction

La plateforme ServiceNow, utilisée par 85% des entreprises du Fortune 500, propose des solutions cloud pour automatiser et gérer de nombreux processus métiers sensibles, touchant aussi bien à l’ITSM, la gestion RH, la finance, ou encore les données clients. Mais une faille récemment découverte, baptisée « Count(er) Strike », expose ces organisations à des risques d’exfiltration massive de données sensibles, dont les informations personnelles (PII), les identifiants, et bien davantage.

Origine de la menace : comprendre la faille

Découverte et portée

En février 2024, les chercheurs de Varonis Threat Labs ont identifié une vulnérabilité majeure dans ServiceNow, signalée sous le code CVE-2025-3648. Cette faille permettait, via des techniques d’énumération basées sur la fonctionnalité de comptage de lignes dans les listes, d’inférer et d’exposer des données critiques stockées dans des centaines de tables de ServiceNow.

Avant la publication du correctif par ServiceNow en mai 2025, la faille pouvait toucher toute instance, même via des comptes dotés de privilèges très faibles ou obtenus par autoinscription. Cela rendait la faille particulièrement dangereuse, car l’exploitation ne nécessitait aucun privilège particulier.

Fonctionnement technique de l’attaque

• ServiceNow organise toutes ses données en tables, protégées via des Access Control Lists (ACLs) définissant précisément qui a accès à quoi.
• Toutefois, lorsque les ACL ne remplissent que partiellement leur rôle – notamment quand les conditions « Required roles » et « Security attributes » sont peu restrictives ou vides – un utilisateur peut accéder à la page contenant le nombre total de lignes pour une table, même si les valeurs elles-mêmes sont masquées.
• Grâce à des requêtes filtrées (en utilisant des opérateurs tels que STARTSWITH, CONTAINS, etc.), un attaquant peut inférer la valeur de champs sensibles, caractère par caractère, jusqu’à reconstituer entièrement une information ou extraire des listes (ex. identifiants, descriptions).
• L’automatisation de ces requêtes permet l’exfiltration rapide et massive de données alors même que l’accès paraît restreint.

Illustration

Imaginons une table utilisateurs : un attaquant envoie des requêtes telles que :

• active=false
• sys_idSTARTSWITH1
• puis sys_idSTARTSWITH2, etc.

En itérant, il parvient à dévoiler chaque identifiant concerné.

Particularités aggravantes

• Dot-walking : la possibilité de parcourir les relations entre tables (références croisées) permet d’étendre la portée de l’attaque à des données indirectement connectées.
• Autoinscription : certains portails ServiceNow permettent aux utilisateurs externes de s’auto-inscrire sans validation admin, leur donnant automatiquement un accès de base (une configuration plus courante qu’il n’y paraît).

Conséquences et impact potentiel

• Une table vulnérable, même partiellement protégée, peut exposer noms, coordonnées, données RH, informations financières, comptes utilisateurs, voire identifiants de production.
• De telles failles peuvent mener à des pertes financières, des fuites de données réglementées (RGPD, HIPAA…), et une atteinte grave à la réputation.

Réponse de ServiceNow et recommandation

ServiceNow a réagi en déployant :

• Query ACLs : de nouveaux contrôles d’accès pour bloquer les requêtes suspectes utilisant des opérateurs d’énumération (tels que STARTSWITH ou CONTAINS). Ils sont paramétrés pour renforcer la granularité des permissions sur l’exécution de requêtes.
• Security Data Filters : des filtres qui ajoutent automatiquement des restrictions sur les résultats, supprimant toute ligne non autorisée et masquant même les messages d’avertissement signalant des suppressions.
• Les administrateurs sont encouragés à auditer l’ensemble de leurs ACLs, à appliquer ces nouveaux mécanismes, et à être particulièrement vigilants sur les tables personnalisées ou peu utilisées.

Que faire ?

• Réalisez un audit complet de vos permissions ServiceNow (tables standard et personnalisées).
• Appliquez les Query ACLs et Security Data Filters sur les tables à données sensibles.
• Désactivez l’autoinscription si elle n’est pas strictement nécessaire.
• Formez vos équipes à la gestion fine des ACLs et testez régulièrement vos configurations.

Pour aller plus loin et consulter l’analyse complète de Varonis, rendez-vous sur leur article : Varonis – Compte-rendu Count(er) Strike sur ServiceNow