ServiceNow corrige un problème d’API après des rapports d’activité suspecte de locataire

Lucas Morel

ServiceNow affirme que les chercheurs en sécurité étaient à l’origine d’une activité liée à une faille d’authentification récemment corrigée, mais la société continue d’enquêter sur une exposition potentielle.

ServiceNow informe les clients après avoir découvert et corrigé une vulnérabilité qui aurait pu exposer des données via un point de terminaison d’API non authentifié sur les instances concernées.

Le problème est apparu publiquement après que les clients ont commencé à discuter des notifications de sécurité de ServiceNow et des rapports d’activités suspectes liées à leurs environnements.

Selon l’avis de la société, la vulnérabilité a été initialement signalée via le programme de bug bounty de ServiceNow en avril, ce qui a déclenché une enquête et des mises à jour de sécurité ultérieures. ServiceNow a déclaré que les clients hébergés avaient reçu une mise à jour de sécurité (KB3067321) le 5 juin, tandis que des conseils (KB3067372) avaient été publiés pour les déploiements auto-hébergés.

La faille semble avoir affecté les locataires exécutant des versions et des configurations spécifiques. Cory Michal, RSSI chez AppOmni, société de sécurité SaaS et IA, a déclaré que le problème impliquait « un point de terminaison d’API ServiceNow non authentifié et accessible sur Internet » auquel on pouvait accéder sans authentification lorsque certaines conditions étaient présentes.

« En termes pratiques, toute personne connaissant l’URL du point de terminaison et sachant structurer la demande pouvait accéder aux données du locataire ServiceNow concerné sans s’authentifier au préalable », a déclaré Michal.

Étant donné que ServiceNow stocke souvent les demandes de services informatiques, les informations sur les employés et les données de sécurité interne, l’accès non autorisé aux instances des clients peut présenter des risques importants pour les entreprises.

L’avis indique que les activités suspectes mises en évidence dans les notifications de sécurité envoyées aux clients peuvent, jusqu’à présent, être liées aux chercheurs en sécurité enquêtant sur la vulnérabilité.

Un point de terminaison d’API d’une version spécifique a été impacté

Bien que l’avis de ServiceNow fournisse peu de détails techniques sur la vulnérabilité elle-même, les clients discutant du problème sur Reddit ont mentionné le point de terminaison concerné comme « /api/now/rated_list_edit/create », une API qui pourrait être interrogée sans authentification dans certaines circonstances. L’API est livrée avec « require_authentication = false ».

Les mêmes discussions indiquent que seule la version australienne de ServiceNow est affectée, comme ServiceNow l’aurait indiqué aux clients via des notifications de sécurité privées. Cela suggère que des changements spécifiques à la libération pourraient avoir joué un rôle dans l’exposition.

Cependant, les clients étaient loin d’être convaincus que le problème se limitait à une seule version. Plusieurs participants ont émis l’hypothèse que les versions plus anciennes avec des configurations particulières pourraient également avoir été vulnérables.

« Ne présumez pas que vous êtes en sécurité simplement parce que vous utilisez une version différente », a commenté l’un d’eux. En parlant de l’API concernée, l’utilisateur a ajouté : « Il s’agit d’un indicateur de configuration, pas d’un changement de code spécifique à la version. Cela vaut la peine d’extraire la table API REST scriptée de votre propre instance et d’auditer toutes les ressources pour lesquelles cette case n’est pas cochée, en particulier tout ce qui n’a pas été touché depuis avant 2022. « 

Chercheurs, attaquants, ou les deux ?

La question importante entourant l’incident est de savoir si l’activité observée dans les environnements ServiceNow concernés était uniquement le travail de chercheurs en sécurité ou si des acteurs malveillants auraient également pu profiter de la faille.

ServiceNow a confirmé que les accès non autorisés pouvaient tous être attribués à des tentatives de recherche. « Nous avons des raisons de croire que l’activité observée peut être attribuée à des chercheurs en sécurité ou à des clients menant leurs propres recherches », a déclaré la société, ajoutant un « cependant ». « Notre enquête est cependant en cours et est soumise à une validation supplémentaire. »

Michal a exhorté à la prudence avant de supposer que toutes les activités observées étaient bénignes.

« La question de l’attribution est moins claire », a-t-il déclaré. « Au moins un système publiquement associé à l’exploitation de cette vulnérabilité semble avoir ciblé les locataires d’autres plates-formes SaaS présentant des faiblesses similaires en matière d’accès non authentifié. Ainsi, bien que des activités de chercheurs aient clairement eu lieu, je serais prudent de dire que toutes les activités observées étaient des recherches bénignes jusqu’à ce que l’enquête soit terminée. « 

Les clients sont invités à enquêter, pas seulement à appliquer des correctifs

Alors que ServiceNow indique que des correctifs et des atténuations sont disponibles, Michal prévient que l’application des mises à jour ne devrait être que la première étape.

Selon lui, les organisations doivent absolument vérifier que la mise à jour de sécurité du 5 juin a été appliquée ou que les mesures d’atténuation recommandées ont été mises en œuvre pour les déploiements auto-hébergés. Tout aussi important, ils devraient également examiner les journaux historiques à la recherche de preuves d’exploitation.

« Examinez les journaux d’accès et de transactions de ServiceNow pour les IoC connus, les requêtes non authentifiées adressées au point de terminaison de l’API concerné et les requêtes de table ou de champ inhabituelles, couvrant idéalement au moins les 90 derniers jours », a-t-il déclaré. « Si une activité suspecte est détectée, déterminez quelles données ont été consultées et traitez-la comme une enquête sur un incident, et non comme un simple exercice de correctif. »

ServiceNow a rassuré ses clients sur le fait que des mesures d’atténuation ont été appliquées et qu’il continue d’enquêter sur l’incident en interne. « Sur la base de notre enquête à ce jour, il semble qu’un sous-ensemble d’instances client ait été interrogé avec succès dans le cadre de cette activité, et des dossiers de support dédiés ont été créés pour les clients concernés », a noté la société dans son avis.

Les activités associées aux adresses IP confirmées des chercheurs ont été étudiées pour un éventuel partage, utilisation ou conservation des données. Les chercheurs impliqués auraient déclaré à ServiceNow « qu’ils ont interrogé les tables et les champs uniquement dans le but de valider leurs découvertes et de soumettre des rapports de bug bounty ».

ApisSécuritéVulnérabilités