Researchers disclosed technical details of critical SQLi and access vulnerabilities in the Zendesk Explore Service.
Cybersecurity researchers at Varonis disclosed technical details of critical SQLi and access vulnerabilities impacting the Zendesk Explore service. Zendesk Explore allows organizations to view and analyze key information about their customers, and their support resources.
Threat actors would have allowed threat actors to access conversations, email addresses, tickets, comments, and other information from Zendesk accounts having the Explore service enabled. The experts are not aware of attacks in the wild.
“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.” reads the advisory published by Varonis. “Zendesk Explore is not enabled by default but is heavily advertised as a requirement for the analytic insights page.”
Varonis reported the flaws to Zendesk which started working on a fix the same day they were reported. The company addressed multiple vulnerabilities in less than one workweek.
In order to exploit these flaws, an attacker has to register for the ticketing service of the target’s Zendesk account as a new external user. The experts highlighted that this is a feature that’s likely enabled by default to allow end-users to submit support tickets.
The SQL injection vulnerability resides in the GraphQL API execute-query, an attacker can abuse it to exfiltrate all information (email addresses of users, leads, and deals from the CRM, live agent conversations, tickets, help center articles, and more) stored in the database as an admin user.
The second critical issue is a logic access flaw associated with a query execution API. The researchers pointed out that the execute-query API did not perform the following logical checks:
- The integrity of documents was not checked, allowing our team to modify them in ways that exposed the inner workings of the system.
- “query,” “datasources,” and “cubeModels” IDs were not evaluated to see if they belonged to the current user.
- 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.
Varonis reported the issues to Zendesk on August 30 and the company addressed it on September 8, 2022.
Follow me on Twitter: @securityaffairs and Facebook and Mastodon
(SecurityAffairs – hacking, Zendesk Explore)
Share On
