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!

image1-1

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.

image2

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.

image3-1

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.

image4-1

“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 should I do now?

Below are three ways you can continue your journey to reduce data risk at your company:

1

Schedule a demo with us to see Varonis in action. We'll personalize the session to your org's data security needs and answer any questions.

2

See a sample of our Data Risk Assessment and learn the risks that could be lingering in your environment. Varonis' DRA is completely free and offers a clear path to automated remediation.

3

Follow us on LinkedIn, YouTube, and X (Twitter) for bite-sized insights on all things data security, including DSPM, threat detection, AI security, and more.

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.

the-2021-financial-data-risk-report-reveals-every-employee-can-access-nearly-11-million-files
The 2021 Financial Data Risk Report Reveals Every Employee Can Access Nearly 11 Million Files
Financial services organizations must safeguard tons of highly sensitive information, but data is often left exposed to far too many people. If just one employee clicks on a phishing email,...
saas-risk-report-reveals-exposed-cloud-data-is-a-$28m-risk-for-typical-company
SaaS Risk Report Reveals Exposed Cloud Data is a $28M Risk for Typical Company
The Great SaaS Data Exposure examines the challenge CISOs face in protecting data across a growing portfolio of SaaS apps and services such as Microsoft 365.
the-2021-manufacturing-data-risk-report-reveals-1-in-5-files-is-open-to-all-employees
The 2021 Manufacturing Data Risk Report Reveals 1 in 5 Files is Open to All Employees
Threats against the manufacturing sector continue — from big game ransomware groups that steal victim’s data before encrypting it, to nation-state attackers seeking technology secrets, to company insiders looking for…
2019-data-risk-report-stats-and-tips-you-won’t-want-to-miss
2019 Data Risk Report Stats and Tips You Won’t Want to Miss
Our data risk report analyzed over 54 billion files across 30+ industries for the latest insights, stats and tips to improve your data security practices