Unlock a world of possibilities! Login now and discover the exclusive benefits awaiting you.
Okay, there are a few restrictions on this exploit, but nevertheless exploitable in a situation where:
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.
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.
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
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. 🙂
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.
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
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.
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.
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.
Hi,
just our of curiosity: Does anyone know if / how this has been fixed?
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! 🙂