Bypassing QlikView Section Access

Today we are going to learn one very simple technique for bypassing QlikView Section Access security.

It goes without saying that we do not in any way condone hacking or the unauthorized use of data that does not belong to you. However, there are times when it is essential to bypass security. For example, imagine you have legally acquired control of a QlikView application but it has been locked down by Section Access. Not only are you unable to access it, you don't even know who can! So, with nobody to turn to, should you just throw out what is potentially a huge amount of work and try to rebuild the application from scratch? Not necessarily. Or, at least, not always.
Most folks (especially those that read this blog regularly!) know that QlikView applications are essentially just encrypted XML files. Interestingly, they are not even fully encrypted. We have seen a taste of this in other posts, but for purposes of this workaround, we will be opening the QVW in a notepad window, rather than as a QlikView "table" source. I recommend using Notepad++ for this, as it has much lower overhead than the Notepad that comes pre-installed with Windows. Below is an application that has been locked with Section Access:
Download this QVW and open it in Notepad++. If you scroll down a bit (on line 1,071 in this particular QVW, although that will vary), you will see a section that begins with the XML tag <SectionAccessNames>:
This section, which will exist in every QVW that has NTNAME-style Section Access defined, provides us with a huge advantage over our previous predicament: even though we do not have access to the application, we at least know who does. If that person is still with our organization, we can walk over to his/her desk, ask him/her to open the QVW for us, and save the application in an unlocked state. In many cases, however, we are not so fortunate; either the person is not available, or does not have ADMIN rights within Section Access.
In those cases, we can simply spoof the username. When using NTNAME security, QlikView is operating in a password-agnostic mode. If you have authenticated as User X, then you are User X, period. The next part will most likely be the most cumbersome: finding a user with ADMIN access rights. Some applications may have thousands of users, but only a handful with ADMIN rights. We will eventually need to create the necessary user in either Active Directory or the local Windows directory. Before you do so, however, I recommend using a technique called "Web Ticketing" to quickly find the user. This technique, which is well-documented on QlikCommunity (and which we can set up for you, if you do not want to tackle the task yourself), allows you to authenticate to a QlikView AccessPoint as any user you want. Importantly, this user does not actually need to exist in any directory! You can input any username you like and simply enter the AccessPoint as that user.
Now, you can quickly generate tickets for each of the Section Access usernames, one by one, until you hit one that's an ADMIN. How will you know when that happens? Well, usually Section Access performs a reduction/selection for non-admin users. When you open the application in the AccessPoint and nothing is reduced/selected, you've most likely found an ADMIN. In addition, the XML usernames will be listed in the order in which they are loaded into the data model. In most cases, ADMINs are loaded separately from regular USERS, either first or last. Therefore, if you have a list of 1,000 usernames, it's a safe bet than you can exclude all but the first 100 and last 100. Another good technique is to search for a username that is clearly a service account (something like qliksvc). These accounts are usually added to Section Access so that Publisher tasks are able to run, and almost invariably have ADMIN rights. However you do it, once you find the magic user, you'll need to create this username in either Active Directory or the local Windows directory, so that you can login to Windows with that user account and open the application in QlikView Desktop. At which point, of course, mission accomplished.
Occasionally, you may run into a situation where Section Access Names are provided in domain\username format. This should not deter you. Using the web ticketing approach, a domain can be spoofed just as easily as a username. And when it comes time to open the application in QlikView Desktop, you can simply use a computer that is not joined to a domain and rename that computer to match the domain name. For instance, if you have a user that has been specified in Section Access as mycorpdomain\userx, you can simply rename your local computer "mycorpdomain" and create a local user "userx". Logging in with this user will result in QlikView authenticating you as mycorpdomain\userx, and allowing you access to the application.
I can hear many of your asking the obvious question: why don't we just add our own username to the XML section we found while we have it open in Notepad++? It doesn't work that way—that section is purely informational. Adding/modifying values will have no effect. It is also important to note that this technique is limited to NTNAME security and does not work with USERID (i.e. QlikView login) security, since neither usernames nor passwords will be listed in the XML in that scenario. If you have a USERID-style application that you are truly locked out of and absolutely have to recreate it from scratch, this meta-data discussion will make the task a bit easier. For the majority of enterprise applications, though, the Section Access "bypass" described here can save you from the monumental task of having to recreate an entire QlikView application, so should be a tool you have available in your toolbox for emergencies. Happy Qliking!
This entry was posted in Security, Tips & Tricks and tagged , , . Bookmark the permalink.

11 Responses to Bypassing QlikView Section Access

  1. Rob Wunderlich says:

    Thanks for an interesting post Vlad. I believe if someone were to use NTDOMAINSID in the Section Access table, it would be much harder to spoof, yes?

    • Yep. This technique, as I mentioned, is for NTNAME security only. With SID security, as with USERID security, the XML section won’t be populated. So it would be more secure, but IMO you could be asking for trouble down the line if you set up NTDOMAINSID security. What if you have to rebuild your AD? The MS migration tool lets you keep old SIDs if it’s a planned migration, but what about a DR rebuild? Everyone would get a new SID…at which point everyone would be locked out of the app.

  2. Tammy Gibson says:

    Hi Vlad-
    What do you think is the best defense against someone using this technique for illegal/unethical reasons?

    • Hi, Tammy. I was wondering that myself. I’m sure there’s a technical reason why Qlik decided to expose these values in plain text, but it does leave kind of a huge security hole. This is a boon both for those who have legitimate reasons for needing access, and for data thieves. A very good practice is to tightly control access to your physical QVWs; this technique requires a local copy of the QVW, so if someone doesn’t have that, they can’t do anything. I recently wrote another article detailing best practices in maintaining a secure development environment. I’d recommend starting by implementing the action items I described there. But I would definitely welcome more feedback on best practices, especially from experts like you and Rob!

  3. Francois says:

    You are requesting the web ticket from the QVWS (localhost). When implementing ticketing, you should not allow any user to request a ticket, only whitelisted IP’s or user accounts will be allowed to request a ticket.

    Section access and ticketing security is not based on obscurity. I can easily find out what the FD or MD’s windows userid is, it’s not a secret.
    There are security layers in place to prevent spoofing Section Access and Ticketing. NTDomainSID and whitelisted IP’s are some of those.

    • Francois says:

      If you implement ticketing and allow any person to request a ticket, then being able to extract the list of Section Access users isn’t the real problem.

      • Francois, I think there may be some confusion as to who “you” are in that sentence. I was suggesting that the person who wishes to unlock the application (presumably, the reader of this article) set up a throw-away QlikView Server installation and enable ticketing there.

        And yes, as I mentioned, this method only applies to NTNAME security. You can implement SID security, but that’s not always the best idea, as I wrote in response to Rob. And very few enterprises use USERID security. So I believe the method I described can be effectively used in the vast majority of enterprise apps.

  4. Haider Al-Seaidy says:

    Section access has always been a feature of the security. To secure the data, you must always protect the file itself.

  5. Would just like to point out that this article was written when 11.20 was the standard. 12.10, like the year 2017, has come and gone and we’re now into 12.20 SR1. The vulnerability still exists exactly as described above. Glad to see Qlik cares so much about their customers’ security…

Leave a Reply

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

Notify via email when new comments are added

Blog Home