topic Re: GOLDENDOODLE vulnerability found in Qlik Sense June 2019 in Management & Governance

GOLDENDOODLE vulnerability found in Qlik Sense June 2019

thomsweet — Thu, 28 Nov 2019 14:36:37 GMT

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)

Re: GOLDENDOODLE vulnerability found in Qlik Sense June 2019

Stoyan_Terziev — Thu, 28 Nov 2019 15:51:29 GMT

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.

Re: GOLDENDOODLE vulnerability found in Qlik Sense June 2019

thomsweet — Fri, 29 Nov 2019 01:31:41 GMT

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)

Re: GOLDENDOODLE vulnerability found in Qlik Sense June 2019

Levi_Turner — Wed, 04 Dec 2019 11:04:37 GMT

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.

Re: GOLDENDOODLE vulnerability found in Qlik Sense June 2019

CryptoGuru — Sun, 19 Jan 2020 14:08:30 GMT

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

Re: GOLDENDOODLE vulnerability found in Qlik Sense June 2019

HendrikJ — Tue, 28 Jul 2020 07:39:14 GMT

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

Re: GOLDENDOODLE vulnerability found in Qlik Sense June 2019

Levi_Turner — Tue, 28 Jul 2020 09:34:40 GMT

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

Re: GOLDENDOODLE vulnerability found in Qlik Sense June 2019

HendrikJ — Mon, 03 Aug 2020 07:11:37 GMT

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

Re: GOLDENDOODLE vulnerability found in Qlik Sense June 2019

Levi_Turner — Mon, 03 Aug 2020 10:08:34 GMT

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.

Re: GOLDENDOODLE vulnerability found in Qlik Sense June 2019

HendrikJ — Mon, 03 Aug 2020 10:19:42 GMT

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.

Re: GOLDENDOODLE vulnerability found in Qlik Sense June 2019

Levi_Turner — Mon, 03 Aug 2020 14:42:29 GMT

I am not sure what other web apps that you're referring to. Personally I interact with Qlik Sense Enterprise, Apache, and Nginx most often. With the latter two using OpenSSL as their crypto provider and thus having application specific configs for configuring TLS and Cipher Suites.

As for the general problem, I am by no means a crypto expert, but as I understand it (i.e. https://blog.qualys.com/technology/2019/04/22/zombie-poodle-and-goldendoodle-vulnerabilities / https://www.tripwire.com/state-of-security/vert/goldendoodle-attack/ being good references), the *DOODLE suite of vulnerabilities come down to the use of the CBC ciphers on any TLS protocol lower than 1.3. So the fix for this are:

Use TLS 1.3 (exclusively)
Disable the CBC ciphers

TLS 1.3 support on Windows is fairly new (https://devblogs.microsoft.com/premier-developer/microsoft-tls-1-3-support-reference/) so the strongest option at this juncture is to go the (2) route. Even when (1) is viable from a technical perspective, it seems extraordinarily risky to my eyes to require this for a web app unless you have pretty rigorous control over the configuration of the clients who are attempting to connect to the web app. i.e. they run very up-to-date Client OSs, use modern browsers, etc.

Just my 2 cents on the matter.

Re: GOLDENDOODLE vulnerability found in Qlik Sense June 2019

HendrikJ — Tue, 04 Aug 2020 04:17:43 GMT

I am no crypto expert either, bt in the scenario you described, I agree that option number 2 is the most viable solution for now. Thanks for the help!

Re: GOLDENDOODLE vulnerability found in Qlik Sense June 2019

veera_a — Mon, 28 Oct 2024 23:04:15 GMT

@HendrikJ -Do you still has this issue in your environment ?
Thanks
Veer