Plus de 1 000 instances ServiceNow Enterprise mal configurées ont été découvertes exposant des articles de la Base de connaissances (KB) contenant des informations d’entreprise sensibles à des utilisateurs externes et à des acteurs potentiels de la menace.
Les informations exposées comprennent des informations personnelles identifiables (PII), des détails internes du système, des informations d’identification de l’utilisateur, des jetons d’accès pour les systèmes de production en direct et d’autres informations essentielles en fonction du sujet de la base de connaissances.
Aaron Costello, responsable de la recherche sur la sécurité SaaS chez AppOmni, a découvert plus d’un millier d’instances ServiceNow Online qui exposent involontairement les informations de l’entreprise en raison de problèmes de configuration.
C’est toujours un problème important malgré les mises à jour de ServiceNow en 2023 visant explicitement à améliorer les listes de contrôle d’accès (ACL), mais qui ne s’appliquaient pas à KBs.
Articles exposés de la base de connaissances
ServiceNow est une plate-forme logicielle basée sur le cloud que les organisations utilisent pour gérer les flux de travail numériques dans divers départements et processus.
Il s’agit d’une solution complète qui intègre la gestion des services informatiques et des opérations informatiques, les tâches RH, la gestion du service client, l’intégration des outils de sécurité et une base de connaissances.
La fonctionnalité de base de connaissances agit comme un référentiel d’articles où les organisations peuvent partager des guides pratiques, des FAQ et d’autres procédures internes pour les utilisateurs autorisés à les consulter. Cependant, comme bon nombre de ces articles ne sont pas destinés à être consultés publiquement, ils peuvent contenir des informations sensibles sur une organisation.
Après un rapport publié en 2023 par Costello sur l’exposition des données ServiceNow, l’entreprise a déployé une mise à jour de sécurité qui a introduit de nouvelles listes de contrôle d’accès pour empêcher l’accès non authentifié aux données client. Cependant, AppOmni indique que la plupart des KB ServiceNow utilisent le système d’autorisation des critères utilisateur plutôt que les listes de contrôle d’accès, ce qui rend la mise à jour moins utile.
De plus, certains widgets destinés au public qui exposent les informations client n’ont pas reçu la mise à jour de la liste de contrôle d’accès 2023 et continuent d’autoriser un accès non authentifié.
Pour cette raison, Costello indique que des contrôles d’accès mal configurés sur les widgets ServiceNow destinés au public peuvent toujours être utilisés pour interroger des données dans KBs sans nécessiter d’authentification.
« Ces instances ont été considérées par les organisations concernées comme étant de nature sensible, telles que les informations d’identification personnelles, les détails du système interne et les informations d’identification / jetons actifs pour les systèmes de production en direct », explique AppOmni dans un nouveau rapport publié aujourd’hui.
À l’aide d’outils tels que Burp Suite, un acteur malveillant peut envoyer un grand nombre de requêtes HTTP à un point de terminaison vulnérable pour forcer brutalement le numéro d’article de la base de connaissances.
Les chercheurs expliquent que les ID d’article de la base de connaissances sont incrémentiels au format KBXXXXXXX, de sorte qu’un auteur de menace peut forcer brutalement une instance ServiceNow en incrémentant le numéro KB à partir de KB0000001 jusqu’à ce qu’il en trouve un qui est involontairement exposé.
AppOmni a développé une attaque de validation de principe pour illustrer comment un acteur externe peut accéder à une instance ServiceNow sans authentification, capturer un jeton à utiliser dans les requêtes HTTP,interroger le widget public pour récupérer les articles de la base de connaissances et forcer brutalement les IDENTIFIANTS de tous les articles hébergés.
Blocage des accès non autorisés
AppOmni suggère que les administrateurs Secure Now protègent les articles de la base de connaissances en définissant les « Critères d’utilisation » appropriés (Peut lire/Ne peut pas lire), bloquant tous les utilisateurs non autorisés.
Des critères tels que « Tout utilisateur » ou « Utilisateur invité » conduisent à des configurations qui ne protègent pas les articles d’un accès externe arbitraire.
Si l’accès public aux bases de connaissances n’est pas explicitement nécessaire, les administrateurs doivent le désactiver pour empêcher l’accès aux articles sur Internet.
Les chercheurs mettent également en évidence des propriétés de sécurité spécifiques qui peuvent protéger les données contre tout accès non autorisé, même en cas de mauvaise configuration. Ce sont:
- glisse.connaisseur.block_access_with_no_user_criteria (True): Garantit que l’accès est automatiquement refusé aux utilisateurs authentifiés et non authentifiés si aucun critère utilisateur n’est défini pour un article de la base de connaissances.
- glisse.connaisseur.apply_article_read_criteria (True): Exige que les utilisateurs aient un accès explicite « Peut lire » aux articles individuels, même s’ils ont un accès » Peut contribuer » à l’intégralité de la base de connaissances.
- glisse.connaisseur.show_unpublished (False): Empêche les utilisateurs de voir les articles brouillons ou non publiés, qui peuvent contenir des informations sensibles et non révisées.
- glisse.connaisseur.section._voir les rôles.brouillon (Admin): Définit une liste de rôles pouvant afficher les articles de la base de connaissances à l’état brouillon.
- glisse.connaisseur.section._voir les rôles.révision (Admin): Définit une liste de rôles pouvant afficher les articles de la base de connaissances dans un état de révision.
- glisse.connaisseur.section._voir les rôles.étapes et rôles (Admin): Définit une liste de rôles pouvant afficher les articles de la base de connaissances qui sont dans un état personnalisé.
Enfin, il est recommandé d’activer les règles prédéfinies prêtes à l’emploi (OOB) de ServiceNow qui ajoutent automatiquement les utilisateurs invités à la liste « Impossible de lire » pour les KB nouvellement créés, obligeant les administrateurs à leur donner spécifiquement l’accès en cas de besoin.