Zendesk Explore flaws opened the door to account pillage

Patched SQLi and logical access vulnerabilities posed serious risk

Security researchers from Varonis have published details of SQL injection and logical access vulnerabilities in Zendesk Explore that posed a severe threat for users of the popular customer service platform.

Zendesk acted promptly in response to vulnerability reports by creating patches that required no customer action, according to Varonis.

This is just as well because the vulnerability would have allowed potential miscreants to access conversations, tickets, comments, email addresses, and other information held in Zendesk accounts in instances where Explore was enabled.

Catch up on the latest cybersecurity research news

Potential exploitation would have involved an attacker first registering for the ticketing service as an external user of a targeted Zendesk account, a commonly enabled feature. The vulnerable Zendesk Explore facility is not enabled by default but still widely used because it powers the analytic insights page of the CRM platform.

Zendesk uses multiple GraphQL APIs in its products, especially in the administration console. Because GraphQL is a relatively new API format, this prompted security researchers from Varonis Threat Labs to explore Zendesk’s implementation, in what turned out to be a fruitful search.

API hunting ground

Zendesk uses multiple APIs in its products. Varonis Threat Labs found a query field called execute-query. This field stood out because it contains a Base64-encoded JSON object, inside a Base64-encoded XML document, inside a JSON object. Multiple nested encodings like this one usually mean that many different services (likely created by separate developers or even teams) are used to process this data.

“This API method accepts a JSON object with the Query XML, along with multiple other XML parameters, some of which are encoded in Base64,” the researchers explain in a technical blog post.

“One of the fields passed to the API is extra_param3_value which includes a plain-text XML document, DesignSchema, not encoded in Base64.”

DesignSchema defines the relationship between an AWS RDS (managed relational database) and the Query XML document.

Old school SQL injection

Varonis discovered that the name attributes in this XML document were vulnerable to a SQL injection attack. The security researchers found a way to exploit this vulnerability to exfiltrate data.

In response to questions from The Daily Swig, Michael Buckbee, a security engineer at Varonis, explained that although the issue is complicated on multiple levels by encoding, “at its heart” it’s a classic SQL injection problem.

“The root cause was fields that were not properly filtered in the application,” Buckbee explained.

The researcher added: “While the method that the SQL command is passed from the client back to Zendesk is complicated with multiple levels of Base64-encoded JSON and XML as part of a GraphQL action, the root cause of the SQL Injection isn’t the multiple levels of encoding, but insufficient validation happening on the application server parsing the response.”

The researchers went on to discover that the execute-query API failed to carry out several logical checks on requests.

“Most critically, the API endpoint did not verify that the caller had permission to access the database and execute queries,” Varonis reports. “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.”

Zen garden

Zendesk quickly resolved the issues in Explore with Varonis Threat Labs’ help, without requiring customers to take any action.

The Daily Swig invited Zendesk to comment on the vulnerabilities, Varonis’ research, and its remediation action. We haven’t heard back, as yet, but we’ll update this story as and when more news comes to hand.

YOU MAY ALSO LIKE CSRF in Plesk API enabled server takeover