Skip to main content
Announcements
Have questions about Qlik Connect? Join us live on April 10th, at 11 AM ET: SIGN UP NOW
cancel
Showing results for 
Search instead for 
Did you mean: 
vegard_bakke
Partner - Creator III
Partner - Creator III

Security rules on data connections can easily be circumvented

Okay, there are a few restrictions on this exploit, but nevertheless exploitable in a situation where:

  • Access to data connections have been restricted by security rules
  • The exploiter can publish an app that has an existing reload task running

How?  Well, the reload task is not running as the owner of the app, or the task, but as INTERNAL\sa_scheduler.

All you need to do is:

LOAD *
FROM [lib://HiddenDataConnection/file.qvd] (options);

And wait for the task to run, then duplicate the app to you work folder.

 

Counterargument

One may argue that the name of the data connection is hidden, and so is the data structure inside the data connection (especially if it is a folder).

However, that is not security.  And folder structure and name of data connections is not really secret information.

 

 

In may real-life case, we had developers in separate bank branches, that were not allowed to see each others data.  But, of course they had the same data structure.  Also, the plan was to name the data connections as 'Bank_A', 'Bank_B', etc.  So guessing the name of another data connection was trivial.

 

 

If you have a similar setting, you may need to take extra precautions, until Qlik acknowledges this as s security vulnerability. 

 

Not sure what the best fix would be.  One suggestion is to let the task run as the owner of the task, of course, and not with system wide privileges.

Labels (4)
1 Solution

Accepted Solutions
analienx
Contributor III
Contributor III

Hi,

this is a known bug when a user can reload with privileges to connection he has no rights to (if he knows the name of the connection and the app gets reloaded from qmc).

There should be a fix since April 20 release.

 

View solution in original post

9 Replies
frank_billes_de
Partner - Contributor II
Partner - Contributor II

Hi @vegard_bakke ,

this is a known behavior and there is currently no technical way to circumvent that. 

I passed a pen-test in a bank in the past with that "bug" by doing this:

- perform a manual go-live check for every app, ensure that it only uses allowed connections
   (simple search in the script, your naming convention for data connections should make that easy)
- only after that promote to the separated PROD-environment

For DEV in banking environments you and the developers anyway only have fake data. At least for me that was the case.

greets Frank

vegard_bakke
Partner - Creator III
Partner - Creator III
Author

Thank you for your input, Frank. 

 

In my case we were not dealing with developers, but bank analysts.  And they cannot use fake data, unfortunately. 

 

One of our counter measures was to actively monitor the log files. 

We cannot stop then from getting hold of a restricted data connection.
But we stop them from getting hold of a restricted data connection, unnoticed.  

When you try accessing a data connection that has been restricted from you, you will get an error when running the LOAD script, as it then, is running with your user privileges.  So it has to be a deliberate act trying to circumvent a restriction put in place. Bringing on consequences for a full time permanent employee.

 

So in my case, with the type of data in question, the group of people, and other circumstances, we found an acceptable solution.  But far from ideal.

 

My intention by publishing this, is to warn other people in the same situation.  And hoping that someone other than my Qlik Support representative and his/her contact with R&D find this unacceptable, and prioritizing a proper solution.

 

But I don't think we'll see a fix for this in April 2020.  🙂

frank_billes_de
Partner - Contributor II
Partner - Contributor II

Hi again,
I think the main question is how you setup your roles and permissions in the organization.

Analysts in your case obviously have permissions to create apps and reload them. That works fine and secure with only the data connections they have access to since these are run with the respecitve user permissions.

The issue only surfaces when they also have access to the QMC and are allowed to setup reloads there. These are run with the sa_scheduler.

Basically you need to separate QMC access, so only Ops people are allowed to setup scheduled reloads. Then you don't have to scare people with consequences.

vegard_bakke
Partner - Creator III
Partner - Creator III
Author

I believe the main question is that tasks run with system wide privileges. 

Professional users can publish app through the hub. Without accessing the QMC.

 

It's a bit like setting up a scheduled task on a machine to runs as administrator, but leaves the script file open for anyone to edit. 

 

I'd be happy to discuss potential solutions to my case, which was included as an example.  But let's do that in a separate thread.  : )

 

 

Cheers,
Vegard 

analienx
Contributor III
Contributor III

Hi,

this is a known bug when a user can reload with privileges to connection he has no rights to (if he knows the name of the connection and the app gets reloaded from qmc).

There should be a fix since April 20 release.

 

vegard_bakke
Partner - Creator III
Partner - Creator III
Author

That's good news. I hope you are right. : )

 

I was told "this has been designed to ease the work of administrators and partners" by Qlik Support.  So I did not expect that Qlik was prioritizing this. Let's hope I was wrong. 

 

analienx
Contributor III
Contributor III

Its a security flaw, a big one. Qlik Sense is mainly designed as Self-Service platform yet that should not mean there would be no way to isolate individual projects objects (unless you had completely isolated environments), limiting users privileges (i.e. not being able to refresh data  ) would not help either. What we have been told is that there are to be two modes - the existing one and the one that enforces better security which is always the option when confidential/sensitive data are being used. The switch is to be available in QMC and might not be available in previous releases since it would require DB changes.

Oliver_F
Partner - Creator III
Partner - Creator III

Hi,

just our of curiosity: Does anyone know if / how this has been fixed?

vegard_bakke
Partner - Creator III
Partner - Creator III
Author

In QMC under Service cluster, you can now tick off the box:

Impersonation - Reload tasks:

'Selecting this option will make all task-triggered app reloads run with app owner privileges.'

 

I haven't tested it thoroughly  myself, yet.  But it sounds promising.  

Please report back, if you try it out! 🙂