Qlik Community

Qlik Sense Deployment & Management

Discussion board where members learn more about Qlik Sense Installation, Deployment and Management.

Announcements
BI & Data Trends 2021. Discover the top 10 trends emerging in today. Join us on Dec. 8th REGISTER
cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
Contributor
Contributor

GOLDENDOODLE vulnerability found in Qlik Sense June 2019

Hello,

We got report about GOLDENDOODLE vulnerablity,

Here is report

Severity:

Medium

Vulnerability ID:

q038764

Source Type:

SERVER

Details:

Port: 443/tcp
GOLDENDOODLE vulnerability found with ECDHE-RSA-AES256-SHA384 on TLSv1.2
The server returns valid data in response to valid padding with an invalid MAC
---------- ---------- ----------
VURIOUS preprocessing log for debugging and troubleshooting:

Port:

443/tcp

Layer:

Middleware

References:

Qualys Knowledgebase: 
https://blog.qualys.com/technology/2019/04/22/zombie-poodle-and-goldendoodle-vulnerabilities 

Bugtraq List: 
107174, http://www.securityfocus.com/bid/107174

Generic Remediation Instructions:

Please refer to official github page TLS Padding Oracles for affected products and patch links.

Patch:

Following are links for downloading patches to fix the vulnerabilities:

OpenSSL Security Advisory: OpenSSL

Generic Vulnerability Description:

A TLS padding oracle vulnerability is detected.


If an application encounters a fatal protocol error and then calls SSL_shutdown() twice (once to send a close_notify, and once to receive one) then OpenSSL can respond differently to the calling application if a 0 byte record is received with invalid padding compared to if a 0 byte record is received with an invalid MAC. If the application then behaves differently based on that in a way
that is detectable to the remote peer, then this amounts to a padding oracle that could be used to decrypt data.


QID Detection Logic:

This QID sends the multiple tls padding payloads to determine the vulnerability.


Note: Qualys scanner version 11.1.24-1 or later is required to use this QID. 

Consequences: 
An attacker who can take a man-in-the-middle (MitM) position can exploit this vulnerability and gain access to encrypted communication between a client and server.

 

We're new to Qlik sense, how could we fix this issue?

Many thanks in advance.

--

Thom (FW)

11 Replies
Highlighted
Partner
Partner

Hi Thom,

 

There could be several reasons to encounter this issue. The first that comes to my mind is you may have opened the connection to the WWW. In that case, you need to have a SSL certificate installed.

Best practice is to have a form of tunneling (VPN would be best) and keep your QS environment within unless there is a mandatory reason to have it exposed.

 

I hope that helps!

 

Regards,

S.T.

Highlighted
Contributor
Contributor

Hello Stoyan,

Thanks for your feedback. We already had signed SSL certificate installed, but I think the encrypt library (maybe OpenSSL) has leak.

VPN is good idea, we can consider it as long term solution, it needs time to implement, but I still need to fix this issue.

BR.

Thom (FW)

Highlighted
Employee
Employee

Since Qlik Sense Enterprise inherits the SCHANNEL protocols and cipher suites from the Windows OS' settings, then disable ECDHE-RSA-AES256-SHA384 on Windows. 

I'd encourage consulting with your organization to see if there are gold standard scripts to handle things, but if you're on your own you can leverage a tool like IISCrypto to set things appropriately in the Windows registry.

Highlighted
Contributor
Contributor

Although I understand the weakness and vulnerability of CBC (Mode of Operation) I believe there are some OpenSSL libraries within Qlik that enables the findings. Currently the vulnerability number 38764 and is described as follow:

"Testing multiple connections and  If an application encounters a fatal protocol error and then calls SSL_shutdown() twice (once to send a close_notify, and once to receive one) then OpenSSL can respond differently to the calling application if a 0 byte record is received with invalid padding compared to if a 0 byte record is received with an invalid MAC. If the application then behaves differently based on that in a way
that is detectable to the remote peer, then this amounts to a padding oracle that could be used to decrypt data."

This to me is significant and should be revisited by Qlik for remediation of the OpenSSL libraries in use.

On another note, there are other applications listening on a Windows server that are not "Flagged" by the scanner.  For example RDP.  Which is using the same set of ciphers set by a GPO.

So, Qlik is vulnerable but not RDP on the same server.

When can we expect a patch or upgrade that would remediate the vulnerability?

Thank you

Highlighted
Contributor II
Contributor II

@Levi_Turner 

I can confirm the findings of other users here, no other service except Qlik is affected by this vulnerability (TLS Padding Zombie POODLE and GOLDENDOODLE). This strongly hints at the use of old SSL libraries by Qlik.

We need to fix this ASAP, otherwise our Qlik Sense server might get shut down by the security team. Please anyone from Qlik respond how to solve this.

Highlighted
Employee
Employee

I personally use Tripwire's padcheck for validation:

Before:

levi@usral-ltu2:~$ ./padcheck {IPAddress}
{IPAddress} ({IPAddress}:443) is being tested for oracles with cipher 0xc027 using TLS 0x0303
{IPAddress} ({IPAddress}:443) is being tested for oracles with cipher 0xc027 using TLS 0x0303
{IPAddress} ({IPAddress}:443) is being tested for oracles with cipher 0xc027 using TLS 0x0303
{IPAddress} ({IPAddress}:443) is VULNERABLE with a Observable Padding Validity (GOLDENDOODLE) oracle when using cipher 0xc027 with TLS 0x0303. The fingerprint is 6be7b5

After applying IIS Crypto's best practices + manually de-selecting the CBC ciphers:

levi@usral-ltu2:~$ ./padcheck {IPAddress}
{IPAddress} ({IPAddress}:443) had an unexpected connection failure: EOF

 

1.png

2.png

 

Highlighted
Contributor II
Contributor II

Just wanted to say that this does indeed work, but I consider this to be only a workaround.

This is specific to Qlik, other services on our machines don't exhibit this vulnerability in connection with CBC ciphers. Ist there any plan to update the SSL libraries that come packaged with Qlik to solve this (I'm assuming that an up-to-date SSL library would fix the issue).

Highlighted
Employee
Employee

Agree to disagree. Adjusting the OS level availability of protocols and cipher suites is exactly how I would vote to design a web app. Otherwise you have an application which is rolling its own cryptography which is generally poor form outside of applications which provide cryptography.

Highlighted
Contributor II
Contributor II

You are correct that applications should ideally take cryptography setting from the OS. I'm wondering why this vulnerability is only detected in our Qlik installations though, not other applications.

I was assuming that this might be fixed by changing the way Qlik handles things, since other applications don't seem to be affected. That's why I was asking if there are any plans by Qlik to address this issue.

If there is nothing that Qlik can actually do about this because ALL CBC algorithms are vulnerable no matter the SSL libraries being used, then I can see why disabling all CBC ciphers is the way to go here.