Qlik Sense ODAG Security Flaw

Completely bypassing data connection security with Qlik Sense On-Demand App Generation (ODAG).

Important Disclaimer: This security flaw is being documented in the spirit of "white hat" security and in the hopes that Qlik fixes the vulnerability in short order. Infinity Insight does not condone anyone using the techniques described here to access any data in an unauthorized way. And, if you are tempted to do so, remember that unauthorized access may be revealed by a security audit.
It is very common for an enterprise self-service Qlik Sense environment to be shared among hundreds or even thousands of users. These users are usually from different teams and require different data sources to build their applications, resulting in dozens of distinct data connections on the server. Like everything else in Qlik Sense, access to each data connection is controlled by security rules. For example, you can say that Team A can use Data Connection X and Team B can use Data Connection Y.
Unfortunately, enabling ODAG on the server undermines the security of data connections pretty substantially.

Qlik Sense ODAG

ODAG is a powerful feature in Qlik Sense that is especially useful when querying big data sources that are not practical to load fully into memory. With ODAG, a user creates two applications: a "selection" app and a "template" app. The selection app is usually very small and just contains a distinct list of filters. The user makes the desired filter selections and the selection app passes those to the template app. The template app restructures the received filters into a SQL query, executes the query against a database (typically reducing a big data set into something manageable), uses the fetched data to build charts/tables and, finally, passes the charts/tables back to the selection app—where they are displayed to the user.
Inserted inconspicuously into the Qlik Sense documentation, however, we find the following:

The internal sa_api account has access to all data connections. Which means that ODAG will work even if the user does not have access to read from the relevant data connection. No doubt Qlik's intended use case was for a professional developer to create curated selection and template apps and ensure proper security by strictly controlling who has access to the selection app. But an entirely different use case is possible that neatly exploits the vulnerability that this architecture opened.

The Exploit

Once ODAG has been enabled on a server it is enabled for all users. That means that a user with app creation rights (which is pretty much everyone on a self-service server) just needs to know the exact name of a data connection to be able to successfully query it regardless of what security has been set in QMC. Here is a basic step-by-step guide assuming a database data connection, although with a few substitutions this technique is easily adaptable to virtually any kind of data connection:
  1. Create a new template app. In the template app load script, enter two simple lines of code. The first is a connection statement (this is where you will need to know the connection name). And the second is SQLCOLUMNS;

  3. Do not reload the template app. Instead, create a sheet. Create a table on that sheet with three dimensions: TABLE_OWNER, TABLE_NAME, COLUMN_NAME. These will all show up as red for now and that is expected. Add the table as a master item in the template app.
  4. Create a new selection app. Link it to the template app you created. You will see the table you added as a master item in the template app. Drag this into the selection app. The table will refresh (!) and display the structure of the database in the selection app.
  5. You can now go back to the template app, open the load script, remove the SQLCOLUMNS; statement and insert a SELECT to pull data from the table that you now know is there.
  6. Repeat the concept from step 2 to create a new table in the UI and add in fields from the database table, which you know exist because of step 2. Add this table as a master item, pull it down into your selection app...et voilà:

Is This Really a Big Deal?

Well no. And also yes. The one saving grace here is that a user would need to know the exact name, including proper capitalization, of the data connection. But the bad news is that he likely does. Why? Perhaps through seeing it written down in some documentation or old app script somewhere. But very likely because you, the admin, told him. Many organizations have a ticketing mechanism such as ServiceNow by which users can request access to resources throughout the company. This can include Qlik Sense streams, apps and, yes, data connections. So you might be presenting an orderly drop-down list of the exact data connection names in all your self-service environments, which is the only piece of the puzzle needed to exploit this vulnerability.
Now that I have thoroughly depressed admins, cybersecurity departments, and Qlik engineers, it's important to note that this problem only applies on those servers where ODAG is enabled which, by default, it is not. And to close with a bit of silver lining: the vast majority of users are ethical and would never exploit this vulnerability even if they knew about it. With all that said: Qlik, please fix this ASAP.
This entry was posted in Qlik Sense, Security. Bookmark the permalink.

Leave a Reply

Your email address will not be published. Required fields are marked *

Notify via email when new comments are added

Blog Home