Varonis announces strategic partnership with Microsoft to accelerate the secure adoption of Copilot.

Learn more

Varonis Threat Labs Discovers SQLi and Access Flaws in Zendesk

Varonis Threat Labs found a SQL injection vulnerability and a logical access flaw in Zendesk Explore, the reporting and analytics service in the popular customer service solution, Zendesk.
Tal Peleg
3 min read
Last updated November 15, 2022

Varonis Threat Labs found a SQL injection vulnerability and a logical access flaw in Zendesk Explore, the reporting and analytics service in the popular customer service solution, Zendesk.

There is no evidence that any Zendesk Explore customer accounts were exploited, and Zendesk started working on a fix the same day it was reported. The company fixed multiple bugs in less than one workweek with zero customer action required.

Before it was patched, the flaw would have allowed threat actors to access conversations, email addresses, tickets, comments, and other information from Zendesk accounts with Explore enabled.

To exploit the vulnerability, an attacker would first register for the ticketing service of its victim's Zendesk account as a new external user. Registration is enabled by default because many Zendesk customers rely on end-users submitting support tickets directly via the web. Zendesk Explore is not enabled by default but is heavily advertised as a requirement for the analytic insights page.

Execute, nested encodings, and XMLs, oh my!

Zendesk uses multiple GraphQL APIs in its products, especially in the administration console. Because GraphQL is a relatively new API format, we started our research there. We found one particularly interesting object type in Zendesk Explore named QueryTemplate.

The querySchema field stood out because it contains a Base64-encoded XML document named Query inside of a JSON object, and many of the attributes in the XML were Base64-encoded JSON objects themselves. Translation? That's a Base64-encoded JSON object, inside a Base64-encoded XML document, inside a JSON object. Phew!


Multiple nested encodings always catch our attention because a large number of wrappers around data usually means that many different services (which were most likely created by separate developers or even teams) are used to process this data. More code usually means more potential locations for vulnerabilities.

For this reason, we dug deeper into Zendesk Explore using the admin user of our own lab account in Zendesk. When visualizing a report in Zendesk Explore, we found an API called execute-query. This API method accepts a JSON object with the Query XML, along with multiple other XML parameters, some of which are encoded in Base64.

SQL injection

One of the fields passed to the API is extra_param3_value which includes a plain-text XML document, DesignSchema, not encoded in Base64. This document defines the relationship between an AWS RDS (managed relational database) and the aforementioned Query XML document.

All the name attributes in this XML document, which define the tables and columns to be queried, were found to be vulnerable to a SQL injection attack. The challenge for our team was how to exploit the SQLi vulnerability to exfiltrate data.


The XML parsing engine on the back end was willing to accept single-quoted attributes instead of the default double-quoted attributes, allowing us to escape the double-quotes in the table name.

Now we needed a way to write strings in the query without using single quotes or double quotes. Fortunately, PostgreSQL, the database used by Zendesk Explore, provides a convenient method for representing strings: dollar-quoted string constants. The characters “$$” can be used to define a string in lieu of the standard single quote character in an SQL statement.

Using this string representation method, we were able to extract the list of tables from Zendesk's RDS instance and continue to exfiltrate all the information stored in the database, including email addresses of users, leads, and deals from the CRM, live agent conversations, tickets, help center articles, and more.


The logical access flaw

SQL injections are always interesting but being able to exfiltrate data as an admin is not very exciting. We were looking for a broader impact, so we decided to study how this execute-query API really worked.

The execute-query API method accepts a JSON payload containing a “content” object with “query,” “cubeModels,” and “datasources” properties.


“query” contains a Query XML document with the columns, rows, slicers, measures, and explosions of the query, as well as the visualization configuration in JSON format. The document also contains a reference to the “cubeModels” property. “cubeModels” contains an XML document named “OLAPSchema” that defines the tables that can be queried in the selected data source.

The execute-query API did not perform several logical checks on requests:

  1. The integrity of documents was not checked, allowing our team to modify them in ways that exposed the inner workings of the system.
  2. “query,” “datasources,” and “cubeModels” IDs were not evaluated to see if they belonged to the current user.
  3. Finally, and most critically, the API endpoint did not verify that the caller had permission to access the database and execute queries. This meant that a newly created end-user could invoke this API, change the query, and steal data from any table in the target Zendesk account's RDS, no SQLi required.

Summing it up

Varonis Threat Labs helped Zendesk solve a SQLi vulnerability and an access control flaw in Zendesk Explore that would have allowed a threat actor to leak data from Zendesk customer accounts with Explore enabled. Zendesk quickly resolved the issue and there is no longer this flaw in Explore. No action is needed from current customers.

What you should do now

Below are three ways we can help you begin your journey to reducing data risk at your company:

  1. Schedule a demo session with us, where we can show you around, answer your questions, and help you see if Varonis is right for you.
  2. Download our free report and learn the risks associated with SaaS data exposure.
  3. Share this blog post with someone you know who'd enjoy reading it. Share it with them via email, LinkedIn, Reddit, or Facebook.

Try Varonis free.

Get a detailed data risk report based on your company’s data.
Deploys in minutes.

Keep reading

Varonis tackles hundreds of use cases, making it the ultimate platform to stop data breaches and ensure compliance.

SecurityRWD - Introduction to AWS Services
Kilian Englert and Ryan O'Boyle from the Varonis Cloud Architecture team kick off a new series diving into the various services found under the AWS umbrella. In this video, they introduce and provide an overview of some of the core services including IAM, S3, and EC2.
SecurityRWD - Introduction to AWS Lambda
Join Kilian Englert and Ryan O'Boyle from the Varonis Cloud Architecture team as they discuss AWS's serverless computing platform, Lambda. Find out what the Lambda functions allow for, see an everyday example of how it all comes together, and learn why it's so important for organizations to monitor Lambda's behavior within the entire Amazon Web Service ecosystem.
SecurityRWD - Introduction to AWS Simple Storage Service (S3)
Kilian Englert and Ryan O'Boyle from the Varonis Cloud Architecture team compare and contrast Amazon Web Services S3 to traditional on-prem storage systems. Listen in as the team discusses how AWS S3 goes beyond basic data storage, and enables programmatic access to apps and services inside and outside the AWS environment.
How to Set Up AWS IAM: Elements, Features, & Components
Amazon Web Services (AWS) Identity and Access Management (IAM) is a web service that helps you securely control access to AWS. In this article, we will learn to plan, setup IAM to control who is authenticated (signed in) and authorized (has permissions) to use these resources.