Nasty SQL Injection Bug in Zendesk Endangers Sensitive Customer Data

Multiple security vulnerabilities in Zendesk’s Web-based customer relationship management (CRM) platform could have allowed attackers to access sensitive information from potentially any customer account — a discovery that showcases application programming interface (API) endpoint weaknesses in enterprise software-as-a-solution (SaaS) applications.

Researchers from Varonis Threat Labs discovered the issues — specifically an SQL injection vulnerability and a logical access flaw — in Zendesk Explore, a component of Zendesk’s platform, they said in a blog post published Nov. 15.

More than 100,000 customers currently use Zendesk for their customer experience solution, according to the company’s website. Zendesk Explore is the aspect of the suite aimed at helping those customers analyze, understand, and share data about their respective businesses.

Researchers found they could use the flaws to extract data from Zendesk Explore, including the list of tables from Zendesk’s relational database service (RDS) instance as well as all the information stored in the database. That info included email addresses of users, sales leads, deals from the CRM, live agent conversations, tickets, help center articles, and more, they said.

For successful exploitation, a potential victim would have to have Zendesk Explore enabled, and an attacker would first have to register for the ticketing service of a victim’s Zendesk account as a new external user, the researchers explained.

However, “registration is enabled by default because many Zendesk customers rely on end users submitting support tickets directly via the web,” they wrote in the post. Zendesk Explore, on the other hand, is not enabled by default, but it is “heavily advertised as a requirement for the analytic insights page,” the researchers noted.

Varonis worked with Zendesk to fix the flaws, which the company managed to do quickly, pushing out a patch that required no customer action “in less than one work week,” the researchers said. There is no evidence that the vulnerabilities were exploited before the fix was issued, they added.

However, a look at the technical details brings up just how easy it is to introduce security flaws into cloud-based enterprise apps.

Common Flaw, Unique Coding

While SQL injection (SQLi) flaws are one of the most common types of vulnerabilities found in Web applications, the Zendesk issue was unique for a couple of reasons, Michael Buckbee, a security engineer at Varonis, tells Dark Reading.

“What made this particular attack novel was both how the Zendesk application was building its SQL queries — as nested objects within a larger GraphQL message — and the use of Postgres DB’s dollar-quoted string constant feature to bypass the application’s existing SQL injection filter,” Buckbee says.

Zendesk uses multiple GraphQL APIs in its products, especially in the administration console, the researchers explained in the post. GraphQL is a relatively new API format, and upon investigation of its implementation in Zendesk, they found a particularly interesting object type in Zendesk Explore, named QueryTemplate, that pointed to a potential issue.

“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,” the researchers wrote.

This represented a multiple-nested encoding, a code scenario that always catches the attention of threat researchers, “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,” they said.

In short, the more code there is in an application, the more potential locations there are for vulnerabilities to lurk, the researchers said.

Researchers leveraged the admin user of their lab’s own Zendesk account to explore the application further by visualizing a report in Zendesk Explore, where they found an API called execute-query that eventually led them to discover the flaws.

Unpacking the Issues

Some further digging led the researchers to an XML document in which all the name attributes were found to be vulnerable to a SQL injection attack, they said. Name attributes define the tables and columns to be queried in an XML document.

Further exploration of the execute-query API found that it did not perform several logical checks on request, representing another vulnerability in the application.

“The integrity of documents was not checked, allowing our team to modify them in ways that exposed the inner workings of the system,” the researchers said.

Moreover, the "query,” “datasources,” and “cubeModels” IDs were not evaluated to see if they belonged to the current user. And finally, and “most critically,” the API endpoint did not verify that the caller had permission to access the database and execute queries, the researchers noted

“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,” they said.

Mitigating Risk

With Zendesk patching the flaw quickly before it affected any customers, enterprises using the CRM solution don’t need to take further action to mitigate the issue, Buckbee says. However, with SQLi issues such a common problem, Zendesk and other companies offering Web-hosted application suites should be more proactive by taking preventative steps to monitor their environments to avoid similar scenarios in the future, he says.

The situation is real: US companies face a combined $12 billion to $23 billion in losses in 2022 from compromises linked to Web APIs, which have proliferated with the increased adoption of SaaS and cloud services, and DevOps-style development methodologies, according to a recent analysis of breach data.

“Enterprise SaaS vendors should rigorously test their API endpoints for novel SQL injection attacks,” Buckbee says, “such as those involving internally developed methods of generating dynamic SQL statements, to avoid exposing customers to similar risk.”