Un méchant bogue d’injection SQL dans Zendesk met en danger les données sensibles des clients

De multiples vulnérabilités de sécurité dans la plate-forme Web de gestion de la relation client (CRM) de Zendesk auraient pu permettre aux attaquants d’accéder à des informations sensibles à partir de potentiellement n’importe quel compte client – une découverte qui met en évidence les faiblesses des points terminaux de l’interface de programmation d’application (API) dans les logiciels d’entreprise en tant que solution applications (SaaS).

Des chercheurs de Varonis Threat Labs ont découvert les problèmes – en particulier une vulnérabilité d’injection SQL et une faille d’accès logique – dans Zendesk Explore, un composant de la plate-forme de Zendesk, ont-ils déclaré dans un article de blog publié le 2 novembre. 15ème.

Plus de 100 000 clients utilisent actuellement Zendesk pour leur solution d’expérience client, selon le site Web de l’entreprise. Zendesk Explore est l’aspect de la suite visant à aider ces clients à analyser, comprendre et partager des données sur leurs activités respectives.

Les chercheurs ont découvert qu’ils pouvaient utiliser les failles pour extraire des données de Zendesk Explore, y compris la liste des tables de l’instance du service de base de données relationnelle (RDS) de Zendesk ainsi que toutes les informations stockées dans la base de données. Ces informations comprenaient les adresses e-mail des utilisateurs, les prospects, les offres du CRM, les conversations en direct avec les agents, les tickets, les articles du centre d’aide, etc., ont-ils déclaré.

Pour une exploitation réussie, une victime potentielle devrait avoir activé Zendesk Explore, et un attaquant devrait d’abord s’inscrire au service de billetterie du compte Zendesk d’une victime en tant que nouvel utilisateur externe, ont expliqué les chercheurs.

Cependant, “l’enregistrement est activé par défaut car de nombreux clients Zendesk comptent sur les utilisateurs finaux qui soumettent des tickets d’assistance directement via le Web”, ont-ils écrit dans le message. Zendesk Explore, en revanche, n’est pas activé par défaut, mais il est “fortement annoncé comme une exigence pour la page d’informations analytiques”, ont noté les chercheurs.

Varonis a travaillé avec Zendesk pour corriger les failles, ce que la société a réussi à faire rapidement, en publiant un correctif qui ne nécessitait aucune action du client “en moins d’une semaine de travail”, ont déclaré les chercheurs. Il n’y a aucune preuve que les vulnérabilités ont été exploitées avant la publication du correctif, elles ont été ajoutées.

Cependant, un regard sur les détails techniques montre à quel point il est facile d’introduire des failles de sécurité dans les applications d’entreprise basées sur le cloud.

Défaut commun, codage unique

Alors que les failles d’injection SQL (SQLi) sont l’un des types de vulnérabilités les plus courants trouvés dans les applications Web, le problème de Zendesk était unique pour plusieurs raisons, a déclaré Michael Buckbee, ingénieur en sécurité chez Varonis, à Dark Reading.

“Ce qui a rendu cette attaque particulière inédite, c’est à la fois la façon dont l’application Zendesk construisait ses requêtes SQL – en tant qu’objets imbriqués dans un message GraphQL plus grand – et l’utilisation de la fonction constante de chaîne entre guillemets en dollars de Postgres DB pour contourner le filtre d’injection SQL existant de l’application.” dit Buckbee.

Zendesk utilise plusieurs API GraphQL dans ses produits, en particulier dans la console d’administration, ont expliqué les chercheurs dans l’article. GraphQL est un format d’API relativement nouveau, et après enquête sur son implémentation dans Zendesk, ils ont trouvé un type d’objet particulièrement intéressant dans Zendesk Explore, nommé QueryTemplate, qui indiquait un problème potentiel.

“Le champ querySchema s’est démarqué car il contient un document XML encodé en Base64 nommé Query à l’intérieur d’un objet JSON, et de nombreux attributs du XML étaient eux-mêmes des objets JSON encodés en Base64”, ont écrit les chercheurs.

Cela représentait un encodage à imbrication multiple, un scénario de code qui attire toujours l’attention des chercheurs sur les menaces, “parce qu’un grand nombre de wrappers autour des données signifie généralement que de nombreux services différents (qui ont très probablement été créés par des développeurs ou même des équipes distincts) sont utilisés .” pour traiter ces données”, ont-ils déclaré.

En bref, plus il y a de code dans une application, plus il y a d’emplacements potentiels pour que les vulnérabilités se cachent, ont déclaré les chercheurs.

Les chercheurs ont utilisé l’utilisateur administrateur du propre compte Zendesk de leur laboratoire pour explorer davantage l’application en visualisant un rapport dans Zendesk Explore, où ils ont trouvé une API appelée execute-query qui les a finalement amenés à découvrir les failles.

Déballer les problèmes

Certaines recherches supplémentaires ont conduit les chercheurs à un document XML dans lequel tous les attributs de nom se sont avérés vulnérables à une attaque par injection SQL, ont-ils déclaré. Les attributs de nom définissent les tables et les colonnes à interroger dans un document XML.

Une exploration plus approfondie de l’API d’exécution de requête a révélé qu’elle n’effectuait pas plusieurs vérifications logiques à la demande, ce qui représente une autre vulnérabilité dans l’application.

“L’intégrité des documents n’a pas été vérifiée, ce qui a permis à notre équipe de les modifier de manière à exposer le fonctionnement interne du système”, ont déclaré les chercheurs.

De plus, les identifiants “query”, “datasources” et “cubeModels” n’ont pas été évalués pour voir s’ils appartenaient à l’utilisateur actuel. Et enfin, et “le plus important”, le point de terminaison de l’API n’a pas vérifié que l’appelant avait l’autorisation de accéder à la base de données et exécuter des requêtes, ont noté les chercheurs

“Cela signifiait qu’un utilisateur final nouvellement créé pouvait invoquer cette API, modifier la requête et voler des données de n’importe quelle table dans le RDS du compte Zendesk cible, aucun SQLi requis”, ont-ils déclaré.

Atténuation des risques

Avec Zendesk corrigeant la faille rapidement avant qu’elle n’affecte les clients, les entreprises utilisant la solution CRM n’ont pas besoin de prendre d’autres mesures pour atténuer le problème, déclare Buckbee. Cependant, les problèmes SQLi étant un problème aussi courant, Zendesk et d’autres sociétés proposant des suites d’applications hébergées sur le Web devraient être plus proactives en prenant des mesures préventives pour surveiller leurs environnements afin d’éviter des scénarios similaires à l’avenir, dit-il.

La situation est réelle : les entreprises américaines font face à des pertes combinées de 12 à 23 milliards de dollars en 2022 en raison de compromis liés aux API Web, qui ont proliféré avec l’adoption accrue des services SaaS et cloud, et des méthodologies de développement de type DevOps, selon un récent analyse des données piratées.

“Les fournisseurs de SaaS d’entreprise doivent tester rigoureusement leurs points de terminaison API pour détecter de nouvelles attaques par injection SQL”, déclare Buckbee, “telles que celles impliquant des méthodes développées en interne pour générer des instructions SQL dynamiques, afin d’éviter d’exposer les clients à un risque similaire”.

Leave a Comment

Your email address will not be published. Required fields are marked *