AVERTISSEMENT AUX ADMINES DE SERVICENOW: Correction de vos listes de contrôle d’accès maintenant

Une vulnérabilité dans la façon dont ServiceNow gère les listes de contrôle d’accès des utilisateurs peut facilement permettre à un acteur de menace de voler des données sensibles, explique un fournisseur de sécurité, qui exhorte les administrateurs à examiner ses tables de configuration de données personnalisées et standard pour renforcer la sécurité.

Des chercheurs de Varonis ont parlé à ServiceNow du trou il y a plus d’un an, lui permettant de corriger tranquillement sa plate-forme et d’émettre une mise à jour de sécurité aux clients en mai. Mais après que ServiceNow a publié cette semaine une énumération de faiblesse commune (CVE-2025-3648) décrivant le problème, Varonis a publié les détails.

Espérons que les administrateurs ont maintenant profité du correctif, avec ses nouvelles capacités de sécurité.

« La mise à jour de ServiceNow a abordé une vulnérabilité qui aurait pu permettre aux utilisateurs privilégiés faibles d’accéder aux données restreintes », a déclaré le président de l’IDC, Crawford Del Prete, à CIO.com. «Ces types de situations sont toujours potentiellement graves, compte tenu du type de données que ServiceNow gère.

« En termes de correction, les administrateurs doivent s’assurer que les listes de contrôle d’accès (ACL) sont configurées correctement et bien gérées », a-t-il déclaré dans un e-mail. «Dans un crédit à ServiceNow, la société a modifié sa posture par défaut avec des correctifs récents en une posture« refusée par défaut », en s’assurant que l’accès aux utilisateurs non privilégiés n’est pas accordé par inadvertance.

«Les environnements ServiceNow (comme beaucoup) sont très dynamiques, les utilisateurs et les droits changeant souvent. Garder l’accent sur la garantie des modifications correctement gérés est essentiel», a-t-il ajouté.

‘Agir dès que possible’

Charles Betz, analyste principal de Enterprise Architecture chez Forrester Research, l’a qualifié de «vulnérabilité assez grave».

« Les gens doivent le faire (suivez les conseils de ServiceNow) dès que possible », a-t-il déclaré dans une interview. «Il y a des risques (que les acteurs de la menace) vont suivre leurs données avec la publication du CVE.»

« Si vous dirigez un grand système de production comme ServiceNow et que vous ne faites pas attention aux problèmes de sécurité, vous ne faites pas votre travail », a-t-il ajouté. « Vous avez eu deux mois (depuis la publication de la mise à jour de la sécurité) et maintenant c’est devenu public… d’autres choses doivent reculer dans la file d’attente. »

Dans un e-mail, Yogev Madar, directeur du groupe de recherche sur la sécurité de Varonis, a déclaré que les administrateurs de ServiceNow doivent revoir les ACL dans leur environnement et profiter de nouveaux mécanismes d’accès pour s’assurer que la vulnérabilité ne peut pas être abusée.

Cela inclut de s’assurer que les ACL ne dépendent pas uniquement des données ou des conditions de script qui pourraient conduire à des abus, en utilisant le nouveau mécanisme ACL appelé «  Deny Else  » qui fournit un meilleur contrôle d’accès et en utilisant la nouvelle règle de requête ACL pour limiter les opérateurs qui peuvent être utilisés dans les requêtes et limiter les tentatives d’énumération.

Même les utilisateurs authentifiés peuvent exploiter le bogue

La vulnérabilité de contrôle d’accès permet aux utilisateurs non authentifiés et même authentifiés, dans certaines conditions d’utiliser les demandes de requête pour accéder aux données qu’ils ne sont pas censées obtenir. Pour émousser cette menace, ServiceNow a introduit des cadres de liste de contrôle d’accès supplémentaires dans les versions Xanadu et Yokohama de la plate-forme.

« Cette vulnérabilité était relativement simple à exploiter et ne nécessitait qu’un accès minimal de table, tel qu’un compte utilisateur faible dans l’instance ou même un utilisateur anonyme autoréglée, ce qui pourrait contourner la nécessité d’une élévation des privilèges et a entraîné une exposition sensible aux données », a déclaré Varonis dans son blog.

Il n’est conscient d’aucun cas où cette vulnérabilité a été exploitée avant que ServiceNow n’émettait le patch en mai. Varonis a averti ServiceNow du trou, baptisé le nombre (ER) Strike, en février 2024.

La plate-forme peut contenir une énorme quantité de données sensibles

Une plate-forme basée sur le cloud, ServiceNow offre un large éventail de capacités, notamment la gestion des services informatiques, la gestion des opérations informatiques, la gestion du service client, la prestation des services de ressources humaines, la gouvernance, les risques et la conformité, la gestion des services de santé et les sciences de la vie et plus encore, ce qui signifie qu’elle peut stocker un large éventail de données personnelles sensibles.

Selon Varonis, ServiceNow organise pratiquement toutes les informations en tables, y compris des éléments tels que les incidents et les demandes, les propriétés et configurations d’instance, les données utilisateur, les informations d’identification de l’application et bien plus encore. Chacun de ces éléments est stocké comme enregistrement dans son tableau respectif.

La plate-forme crée des connexions entre les tables à l’aide de champs de référence, qui permettent de partager des informations sur différentes tables. Par exemple, un champ de référence dans le tableau des incidents peut être lié à un enregistrement utilisateur spécifique dans le tableau des utilisateurs, permettant à ces données connexes d’être affichées sur plusieurs tables.

L’accès à ces tableaux est géré principalement via des règles de liste de contrôle d’accès (ACL). qui déterminent à quoi les utilisateurs de données peuvent accéder et comment ils peuvent interagir avec lui.

Une instance ServiceNow peut contenir des dizaines de milliers de règles ACL, dit Varonis.

Les composantes clés d’une règle ACL dans ServiceNow sont les ressources que l’administrateur souhaite protéger (comme une table, un champ ou un enregistrement), l’opération, qui spécifie le type d’accès contrôlé (tel que lire, écrire, créer ou supprimer), et les conditions qui doivent être remplies pour la règle à s’appliquer.

Quatre conditions d’accès

Quatre conditions dans chaque ACL déterminent si un utilisateur répond aux exigences pour accéder à une ressource spécifique:

• Rôles requis: Cette condition spécifie les rôles requis pour accéder à une ressource particulière. Si un utilisateur a l’un des rôles répertoriés dans l’ACL, il est accordé à l’accès;
• Condition d’attribut de sécuritéqui utilise des attributs de sécurité pour déterminer l’accès;
• Condition de données: Cette condition évalue des critères spécifiques liés aux données elle-même. Par exemple, vous pouvez définir une condition qui limite l’accès aux enregistrements uniquement avec un certain statut ou dans une plage de dates spécifique.
• Script: Cette condition permet l’exécution de la logique personnalisée. Les administrateurs peuvent écrire des scripts pour implémenter des règles de sécurité complexes au-delà des simples conditions de rôle ou de données. Un script ne peut être écrit pour accorder l’accès que lorsqu’une certaine configuration de l’instance est définie, ou uniquement lorsqu’un utilisateur est authentifié.

Ces quatre conditions de LCA pour l’accès sont évaluées par ServiceNow dans cet ordre.

Varonis a découvert que ServiceNow nie l’accès en fonction des conditions de LCA non satisfaites. Si l’accès à une ressource est bloqué en raison de l’une des deux premières conditions – les «rôles requis» ou la «condition d’attribut de sécurité» – l’accès est refusé.

Cependant, si l’accès est refusé en raison de l’échec de la «condition de données» ou de la «condition de script», l’utilisateur est présenté avec une page qui montre le nombre total des enregistrements renvoyés par la requête, même si aucun enregistrement n’est visible. Un acteur de menace peut ensuite utiliser les paramètres de requête de l’application pour déduire des données détaillées par énumération. Pire encore, un acteur de menace pourrait automatiser ce processus en écrivant un script simple pour l’énumération, a déclaré Varonis, leur permettant de récupérer des données d’enregistrement complètes du tableau. Ils peuvent alors commencer à récupérer les résultats de la source HTML.

« Aucune configuration ou plug-ins spéciaux n’est nécessaire », a noté Varonis, « juste un compte utilisateur dans l’instance ServiceNow avec un accès partiel de table ou de colonne. »

De nouvelles règles ACL peuvent être créées

S’il est activé, la fonction d’auto-inscription de ServiceNow permet aux nouveaux utilisateurs de créer des comptes et d’accéder à une instance sans l’approbation préalable de l’administrateur, a ajouté Varonis. Bien que cela simplifie l’intégration pour les utilisateurs externes pour un accès de base, il pourrait également permettre à un acteur de menace d’obtenir ce même accès.

« Bien qu’il soit rare que les cas permettent l’enregistrement et l’accès anonymes, cette configuration a été trouvée dans les systèmes ServiceNow de plusieurs sociétés du Fortune 500 », a noté Varonis.

Les tableaux susceptibles de l’attaque sont ceux avec des ACL avec des sections «exigent des rôles» et des «conditions d’attribut de sécurité» vides ou trop larges. « Cela signifie que toute table protégée uniquement par les données ou la condition de script est entièrement exposée à l’attaque », a déclaré Varonis.

Pour répondre à la vulnérabilité, ServiceNow a créé plusieurs nouvelles règles de LCA que les administrateurs peuvent mettre en œuvre. L’un est appelé Query ACL, qui ajoute des restrictions sur les requêtes qu’un utilisateur peut exécuter sur une table pour récupérer des enregistrements. Les nouveaux filtres de données de sécurité peuvent également restreindre l’accès aux enregistrements en fonction des attributs de rôle ou de sécurité liés aux affirmations.

ServiceNow propose des conseils pour gérer les listes de contrôle d’accès, ainsi que des conseils pour les administrateurs et les développeurs.

« Cette vulnérabilité à ServiceNow est un puissant rappel que les plates-formes même bien établies peuvent avoir des angles morts dangereux en ce qui concerne l’accès au contrôle », a déclaré Gal Nakash, chef de produit de Reco, un fournisseur de solutions de sécurité SaaS, dans un e-mail.

« Ce qui rend ce défaut particulièrement préoccupant, c’est la facilité d’exploitation. Il ne nécessite pas une escalade de privilèges ou une expertise technique profonde, juste des ACL défient et une utilisation intelligente des filtres de requête. C’est une barre faible pour une exfiltration de données potentiellement à fort impact », a-t-il écrit.

«Pour les organisations, en particulier celles des secteurs réglementés comme les soins de santé, la finance ou le gouvernement, il s’agit d’un signal d’appel. Surveillez en continu des anomalies telles que des modèles de requête inhabituels ou l’accès par des utilisateurs à faible privile et des modifications de l’autorisation d’audit entre les tables et les rôles. »