Varonis Threat Labs découvre des vulnérabilités SQLi et des failles d’accès dans Zendesk

Varonis Threat Labs a découvert une vulnérabilité d’injection SQL et une faille d’accès logique dans Zendesk Explore, le service de reporting et d’analyse de la solution de service client populaire Zendesk.

Il n’existe aucune preuve que les comptes client Zendesk Explore ont été piratés, et Zendesk a commencé à travailler sur un correctif le jour même de son signalement. L’entreprise a corrigé plusieurs bogues en moins d’une semaine de travail sans nécessité d’une quelconque action de la part du client.

Avant d’être corrigée, la faille aurait permis aux acteurs malveillants d’accéder aux conversations, aux adresses e-mail, aux tickets, aux commentaires et autres informations des comptes Zendesk avec Explore activé.

Pour exploiter cette vulnérabilité, un pirate s’inscrirait d’abord au service de tickets du compte Zendesk de sa victime en tant que nouvel utilisateur externe. L’inscription est activée par défaut, car de nombreux clients Zendesk comptent sur les utilisateurs finaux qui envoient des tickets d’assistance directement via le Web. Zendesk Explore n’est pas activé par défaut, mais il est souvent présenté comme nécessaire pour accéder à la page « Analytic Insights ».

Execute, encodages imbriqués et XML, quel programme !

Zendesk utilise plusieurs API GraphQL dans ses produits, notamment dans la console d’administration. GraphQL étant un format d’API relativement nouveau, nous avons commencé nos recherches de ce côté. Nous avons trouvé un type d’objet particulièrement intéressant dans Zendesk Explore nommé QueryTemplate.

Le champ querySchema a retenu notre attention, car il contient un document XML codé en base 64 nommé Query à l’intérieur d’un objet JSON, et bon nombre des attributs du XML étaient eux-mêmes des objets JSON encodés en base 64. Qu’est-ce que ça veut dire ? Il s’agit d’un objet JSON codé en base 64, à l’intérieur d’un document XML codé en base 64, à l’intérieur d’un objet JSON. Ouf !

Les codages multiples imbriqués attirent toujours notre attention, car un grand nombre d’enveloppes 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 distinctes) sont utilisés pour traiter ces données. Plus de code signifie généralement plus d’emplacements potentiels pour les vulnérabilités.

C’est pour cette raison que nous avons approfondi nos recherches dans Zendesk Explore en tant qu’utilisateur de niveau administrateur de notre propre compte de laboratoire dans Zendesk. Lors de la visualisation d’un rapport dans Zendesk Explore, nous avons trouvé une API appelée execute-query. Cette méthode API accepte un objet JSON avec le code XML de requête, ainsi que plusieurs autres paramètres XML, dont certains sont codés en base 64.

Injection SQL

L’un des champs transmis à l’API est extra_param3_value, qui comprend un document XML en texte brut, DesignSchema, et non encodé en base 64. Ce dernier définit la relation entre une base de données relationnelle gérée (AWS RDS) et le document XML de requête précédemment mentionné.

Tous les attributs de nom dans ce document XML, qui définissent les tableaux et les colonnes à interroger, ont été considérés comme vulnérables à une attaque par injection SQL. Le défi pour notre équipe était d’exploiter la vulnérabilité SQLi pour exfiltrer les données.

Le moteur d’analyse XML sur le back-end était prêt à accepter des attributs à guillemets simples au lieu d’attributs à guillemets doubles par défaut, ce qui nous permet d’éviter ces derniers dans le nom du tableau.

Il nous fallait un moyen d’écrire des chaînes dans la requête sans utiliser de guillemets simples ou doubles. Heureusement, PostgreSQL, la base de données utilisée par Zendesk Explore, fournit une méthode pratique pour représenter les chaînes : les constantes de chaîne entre guillemets en dollars. Les caractères « $$ » peuvent être utilisés pour définir une chaîne au lieu du guillemet simple standard dans une instruction SQL.

Grâce à cette méthode de représentation de chaînes, nous avons pu extraire la liste des tableaux de l’instance RDS de Zendesk et continuer à exfiltrer toutes les informations stockées dans la base de données, notamment l’adresse électronique des utilisateurs, les prospects et les transactions du CRM, les conversations en direct des agents, les tickets, les articles du centre d’aide, etc.

Le défaut d’accès logique

Les injections SQL ont leurs avantages, mais la possibilité d’exfiltrer les données en tant qu’administrateur ne présente pas un grand intérêt. Nous recherchions un impact plus large, nous avons donc décidé d’étudier le fonctionnement de cette API execute-query.

La méthode de l’API execute-query accepte une charge utile JSON contenant un objet « content » avec des propriétés « query », « cubeModels » et « datasources ».

« query » contient un document XML de requête avec les colonnes, les lignes, les segments, les mesures et les explosions de la requête, ainsi que la configuration de visualisation au format JSON. Le document contient également une référence à la propriété « cubeModels ». Cette dernière contient un document XML nommé « OLAPSchema » qui définit les tableaux pouvant être interrogés dans la source de données sélectionnée.

L’API execute-query n’a pas effectué plusieurs contrôles logiques sur les demandes :

1. L’intégrité des documents n’a pas été vérifiée, ce qui a permis à notre équipe de les modifier de manière à dévoiler les opérations internes du système.
2. Les ID de « query », « datasources » et « cubeModels » n’ont pas été évaluées pour voir si elles appartenaient à l’utilisateur actuel.
3. Enfin, et surtout, le point de terminaison de l’API n’a pas vérifié que l’appelant avait l’autorisation d’accéder à la base de données et d’exécuter des demandes. Cela signifie qu’un utilisateur final nouvellement créé pouvait invoquer cette API, modifier la demande et voler des données de n’importe quel tableau dans le RDS du compte Zendesk cible, sans SQLi.

En résumé

Varonis Threat Labs a aidé Zendesk à résoudre une vulnérabilité SQLi et une faille de contrôle d’accès dans Zendesk Explore qui aurait permis à un acteur malveillant de divulguer les données des comptes clients Zendesk avec Explore activé. Zendesk a rapidement résolu le problème et cette faille dans Explore a été supprimée. Aucune action n’est nécessaire de la part des clients actuels.