Skip to main content
Woohoo! Qlik Community has won “Best in Class Community” in the 2024 Khoros Kudos awards!
Announcements
Nov. 20th, Qlik Insider - Lakehouses: Driving the Future of Data & AI - PICK A SESSION
cancel
Showing results for 
Search instead for 
Did you mean: 
Pajik3909
Contributor III
Contributor III

SSL/TLS: Renegotiation DoS Vulnerability - next part

Hello everybody,

we performed the patching of the Qlik Sense Enterprise on Windows from version May 2021 to version November 2023 Patch 1 on our server according your recommendation.

But problem persist. 

I received information about the problem with renegotiation DoS Vulnerability from our IT department. See message below:

Hostname: qlik.xxx.ch,
Host Ip: 
Taskname: 
Severity: Low,
Description: SSL/TLS: Renegotiation DoS Vulnerability (CVE-2011-1473, CVE-2011-5094)
Summary: The remote SSL/TLS service is prone to a denial of service (DoS) vulnerability.
Insight: The flaw exists because the remote SSL/TLS service does not properly restrict client-initiated renegotiation within the SSL and TLS protocols. Note: The referenced CVEs are affecting OpenSSL and Mozilla Network Security Services (NSS) but both are in a DISPUTED state with the following rationale: > It can also be argued that it is the responsibility of server deployments, not a security library, to prevent or limit renegotiation when it is inappropriate within a specific environment. Both CVEs are still kept in this VT as a reference to the origin of this flaw.
Solution: Users should contact their vendors for specific patch information. A general solution is to remove/disable renegotiation capabilities altogether from/in the affected SSL/TLS service.
Nvt: 1.3.6.1.4.1.25623.1.0.117761
CVE: CVE-2011-1473, CVE-2011-5094>
Affected: Every SSL/TLS service which does not properly restrict client-initiated renegotiation.
Detection: Checks if the remote service allows to re-do the same SSL/TLS handshake (Renegotiation) over an existing / already established SSL/TLS connection.
Descriptions: The following indicates that the remote SSL/TLS service is affected:Protocol Version | Successful re-done SSL/TLS handshakes (Renegotiation) over an existing / already established SSL/TLS connection----------------------------------------------------------------------------------------------------------------------------------TLSv1.2 | 10
Soulution Type: VendorFix,
Reference: CVE-2011-1473; CVE-2011-5094; https://mailarchive.ietf.org/arch/msg/tls/wdg46VE_jkYBbgJ5yE4P9nQ-8IU/; https://orchilles.com/ssl-renegotiation-dos/; https://vincent.bernat.ch/en/blog/2011-ssl-dos-mitigation; https://www.openwall.com/lists/oss-security/2011/07/08/2

Hostname: qlik.xxx.ch,
Host Ip: 
Taskname: 
Severity: High,
Description: MacOS X Finder .FBCIndex Information Disclosure
Summary: MacOS X creates a hidden file, '.FBCIndex' in each directory that has been viewed with the Finder. This file contains the content of the files present in the directory, giving an attacker information on the HTML tags, JavaScript, passwords, or any other sensitive word used inside those files.
Insight:
Solution: Block access to hidden files (starting with a dot) within your webservers configuration
Nvt: 1.3.6.1.4.1.25623.1.0.10773
CVE: CVE-2001-1446>
Affected:
Detection:
Descriptions: The following files were identified:https://qlik.xxx.ch:4244/internal_forms_authentication/.FBCIndex
Soulution Type: Workaround,
Reference: CVE-2001-1446; http://www.securityfocus.com/bid/3325; https://www.kb.cert.org/vuls/id/177243

Does exist any solution for solving this problem?

Thank you,

Pavel

 

Labels (3)
9 Replies
kbrooks78
Contributor
Contributor

Ditto also

Skage
Partner - Creator
Partner - Creator

I've gotten a question from one of our customers on this matter as well.

Pajik3909
Contributor III
Contributor III
Author

Dear supporters,

is there anyone who can answer me, I mean the development department?

Thank you Pavel

Skage
Partner - Creator
Partner - Creator

The .FBCIndex issue seems to be questionable testing.

Regardless what comes after /internal_form_authentication will not make a difference in the response so it will be a http-200. The vuln-testing-software is probably testing different paths and if a 200-response is given for something like .FBCIndex it will classify it as a problem.

One can always debate if a 200-response is correct response when requesting an named assed that doesn't exist.

marcocecchi
Contributor
Contributor

Hello,

my hosting vendor find this as potential vulnerability scanning our Windows 2019 Qlik server.

Sorry but I have only scanned PDF, not digital version, if it could be helpful to find a solution in new Qlik Server releases:

marcocecchi_0-1713962170350.png

marcocecchi_1-1713962336263.pngmarcocecchi_2-1713962462211.png

 

 

Pajik3909
Contributor III
Contributor III
Author

Dear supporters,

is there anyone who can answer me, I mean the development department?

Thank you Pavel

Pajik3909
Contributor III
Contributor III
Author

Dear all,

how can I contact a competent person for solution these issues?

Thank you Pavel

paulselousyoriz
Partner - Contributor III
Partner - Contributor III

We are having the same issue. We have the August 2023 issue of QSEoW running on Windows Server 2022.

Sebastian_Linser

As @Skage pointed out it is a false positive because everything you add behind the forms authentication link will return a 200 OK.

We have raised QB-28211 to get either a 404 or 400 returned in the future.

 

best regards

Sebastian

Help users find answers! Don't forget to mark a solution that worked for you! 🙂