Security researchers at Varonis Threat Labs discovered an SQL injection vulnerability and a logical flaw in Zendesk Explore, the reporting and analytics service within Zendesk. These two flaws would allow a threat actor to access conversations, email addresses, tickets, comments, and other information from Zendesk accounts that had this feature enabled. While it is not enabled by default, it is typically advertised as a require feature for the analytic insights page. These vulnerabilities were patched by Zendesk within a week of reporting and there is no evidence that the vulnerability was exploited in the wild. This patch requires zero customer interaction.
To exploit this vulnerability, a threat actor would first have to register for the ticketing system of the victim’s Zendesk account as an external user. This feature is enabled by default due to many of Zendek’s clients relying on end-users submitting support tickets directly via the web. The Varonis team first examined GraphQL APIs within Zendesk Explore, which lead them to an interesting object type named “QueryTemplate” that had a “querySchema” field that contained a base64-encoded XML document named “Query” inside of a JSON document. This XML document also contained many base-64 JSON objects itself. This caused the team to further look into the Zendesk Explore feature, as multiple nested encodings are indicative of multiple teams working on a single service, which typically leaves more room for vulnerabilities.
Using the administrator of their own lab environment, the Varonis team found and API called “execute-query” that accepts a JSON object with the “Query” XML, along with multiple other XML parameters, some of which are also encoded. One of the fields passed to the API is extra_param3_value which includes a plain-text XML document, DesignSchema, not encoded in Base64. 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 researchers were able to use single quotes to escape the double quotes of the database and then use the characters “$$” to define a string, a feature provided by PostgreSQL, the database that Zendesk Explore uses. Although requiring administrator rights, their team was able to exfiltrate all information stored in the database.
As the SQL injection requires administrator rights, their team looked further into the “execute-query” API to determine if there were any additional ways to exploit this API. They found that it accepts a JSON payload containing a “content” object with the properties “query”, “cubeModels”, and “datasources” as well as not performing several logical checks on requests. First, the integrity of documents was not checked, allowing the Varonis team to modify them in ways that exposed the inner workings of the system. Next, the three aforementioned properties were not evaluated to see if they belonged to the current user. Finally, the API endpoint did not verify that the caller had permission to access the database and execute queries. This meant that a newly register end-user could invoke this API, change the query, and steal data from any table without the use for administrator rights or SQL Injection, a logical access flaw in the ZenDesk explore feature.
Analyst Notes
The Zendesk team did an exceptional job at patching this vulnerability in a timely manner. If this vulnerability was discovered by threat actors before the Varonis team, or if this vulnerability was left unpatched, the flaw would have been considered a critical vulnerability in the Zendesk application; attackers would have the capabiilty to steal any information from the database that they wanted. Since many organizations have external user registration enabled by default and any user could invoke this API, this would have been a difficult exploit to monitor for in terms of detection rules. The actual activity itself would likely not have logged anything that a reliable detection could be built around. In terms of these specific vulnerabilities, the best course of detection would be to create rules around data exfiltration. The scenario highlights the need for a defense-in-depth strategy to cover all stages of the cyber kill chain.
https://www.varonis.com/blog/zendesk-sql-injection-and-access-flaws
