Unlock a world of possibilities! Login now and discover the exclusive benefits awaiting you.
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
Ditto also
I've gotten a question from one of our customers on this matter as well.
Dear supporters,
is there anyone who can answer me, I mean the development department?
Thank you Pavel
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.
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:
Dear supporters,
is there anyone who can answer me, I mean the development department?
Thank you Pavel
Dear all,
how can I contact a competent person for solution these issues?
Thank you Pavel
We are having the same issue. We have the August 2023 issue of QSEoW running on Windows Server 2022.
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