GOLDENDOODLE vulnerability found in Qlik Sense June 2019

[thomsweet]

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)

[Stoyan_Terziev]

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.

[thomsweet]

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)

[Levi_Turner]

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.

[Levi_Turner]

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.

[CryptoGuru]

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

[HendrikJ]

@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.

[Levi_Turner]

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

[HendrikJ]

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).

[Levi_Turner]

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.

[HendrikJ]

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.