Vulnerability and weak encryption ciphers

On various Hardware and OS systems: pi / windows / routers / nas, etc

Moderator: leecollings

Post Reply
WujcioPafcio
Posts: 4
Joined: Thursday 03 September 2020 15:17
Target OS: Raspberry Pi / ODroid
Domoticz version: 2020.2
Contact:

Vulnerability and weak encryption ciphers

Post by WujcioPafcio »

Hi All!

I just started my adventure with Domoticz.
I configured it, secured it and published it into the world.
Now I scanned the server for SSL security and Qualys Cloud Platform.

SSL Test reported below weak ciphers.
Additionally I have a questions:
  • Can we disable it?
  • What webservice using Domoticz or where is SSL configuration?
Spoiler: show
TLS_RSA_WITH_AES_128_CBC_SHA (0x2f)   WEAK
TLS_DHE_RSA_WITH_AES_128_CBC_SHA (0x33)   DH 2048 bits   FS   WEAK
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013)   ECDH secp521r1 (eq. 15360 bits RSA)   FS   WEAK
TLS_RSA_WITH_AES_128_CBC_SHA256 (0x3c)   WEAK
TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 (0x67)   DH 2048 bits   FS   WEAK
TLS_RSA_WITH_AES_128_GCM_SHA256 (0x9c)   WEAK
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (0xc027)   ECDH secp521r1 (eq. 15360 bits RSA)   FS   WEAK
TLS_RSA_WITH_AES_128_CCM (0xc09c)   WEAK
TLS_RSA_WITH_AES_128_CCM_8 (0xc0a0)   WEAK
TLS_RSA_WITH_AES_256_CBC_SHA (0x35)   WEAK
TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x39)   DH 2048 bits   FS   WEAK
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014)   ECDH secp521r1 (eq. 15360 bits RSA)   FS   WEAK
TLS_RSA_WITH_AES_256_CBC_SHA256 (0x3d)   WEAK
TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 (0x6b)   DH 2048 bits   FS   WEAK
TLS_RSA_WITH_AES_256_GCM_SHA384 (0x9d)   WEAK
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (0xc028)   ECDH secp521r1 (eq. 15360 bits RSA)   FS   WEAK
TLS_RSA_WITH_AES_256_CCM (0xc09d)   WEAK
TLS_RSA_WITH_AES_256_CCM_8 (0xc0a1)   WEAK
SSL scan reporting also lack of support for Forward Secrecy ( INFO1 , INFO2 )

Second think are reported vulnerabilities in Qualys scanner.
Here is reported one on Medium level (score 2/5)
  • HTTP Security Header Not Detected
Spoiler: show
THREAT:
This QID reports the absence of the following HTTP headers according to CWE-693: Protection Mechanism Failure:
X-Frame-Options: This HTTP response header improves the protection of web applications against clickjacking attacks. Clickjacking, also known as a "UI redress attack", allows an attacker to use multiple transparent or opaque layers to trick a targeted user into clicking on a button or link on another page when they were intending to click on the the top level page.
X-XSS-Protection: This HTTP header enables the browser built-in Cross-Site Scripting (XSS) filter to prevent cross-site scripting attacks. X-XSS-Protection: 0; disables this functionality.
X-Content-Type-Options: This HTTP header prevents attacks based on MIME-type mismatch. The only possible value is nosniff. If your server returns X-Content-Type-Options: nosniff in the response, the browser will refuse to load the styles and scripts in case they have an incorrect MIME-type.
Strict-Transport-Security: The HTTP Strict-Transport-Security response header (HSTS) is a security feature that lets a web site tell browsers that it should only be communicated with using HTTPS, instead of using HTTP.
QID Detection Logic:
This unauthenticated QID looks for the presence of the following HTTP responses:
Valid directives for X-Frame-Options are:
X-Frame-Options: DENY - The page cannot be displayed in a frame, regardless of the site attempting to do so.
X-Frame-Options: SAMEORIGIN - The page can only be displayed in a frame on the same origin as the page itself.
X-Frame-Options: ALLOW-FROM RESOURCE-URL - The page can only be displayed in a frame on the specified origin.

Valid directives for X-XSS-Protections are:
X-XSS-Protection: 1 - Enables XSS filtering (usually default in browsers). If a cross-site scripting attack is detected, the browser will sanitize the page (remove the unsafe parts).
X-XSS-Protection: 1; mode=block - Enables XSS filtering. Rather than sanitizing the page, the browser will prevent rendering of the page if an attack is detected.
X-XSS-Protection: 1; report=URI - Enables XSS filtering. If a cross-site scripting attack is detected, the browser will sanitize the page and report the violation. This uses the functionality of the CSP report-uri directive to send a report.
X-XSS-Protection: 0 disables this directive and hence is also treated as not detected.

A valid directive for X-Content-Type-Options: nosniff

A valid HSTS directive Strict-Transport-Security: max-age=<expire-time>; [; includeSubDomains][; preload]

NOTE: All report-only directives (where applicable) are considered invalid.

IMPACT:
Depending on the vulnerability being exploited, an unauthenticated remote attacker could conduct cross-site scripting, clickjacking or MIME-type sniffing attacks.
SOLUTION:
Note: To better debug the results of this QID, it is requested that customers execute commands to simulate the following functionality: curl -lkL --verbose.
CWE-693: Protection Mechanism Failure mentions the following - The product does not use or incorrectly uses a protection mechanism that provides sufficient defense against directed attacks against the product. A "missing" protection mechanism occurs when the application does not define any mechanism against a certain class of attack. An "insufficient" protection mechanism might provide some defenses - for example, against the most common attacks - but it does not protect against everything that is intended. Finally, an "ignored" mechanism occurs when a mechanism is available and in active use within the product, but the developer has not applied it in some code path.

Customers are advised to set proper X-Frame-Options, X-XSS-Protection, X-Content-Type-Options and Strict-Transport-Security HTTP response headers.

Depending on their server software, customers can set directives in their site configuration or Web.config files. Few examples are:

X-Frame-Options:
Apache: Header always append X-Frame-Options SAMEORIGIN
nginx: add_header X-Frame-Options SAMEORIGIN;
HAProxy: rspadd X-Frame-Options:\ SAMEORIGIN
IIS: <HTTPPROTOCOL><CUSTOMHEADERS><ADD NAME="X-Frame-Options" VALUE="SAMEORIGIN"></ADD></CUSTOMHEADERS></HTTPPROTOCOL>

X-XSS-Protection:
Apache: Header always set X-XSS-Protection "1; mode=block"
PHP: header("X-XSS-Protection: 1; mode=block");

X-Content-Type-Options:
Apache: Header always set X-Content-Type-Options: nosniff

HTTP Strict-Transport-Security:
Apache: Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"
Nginx: add_header Strict-Transport-Security max-age=31536000;

Note: Network devices that include a HTTP/HTTPS console for administrative/management purposes often do not include all/some of the security headers. This is a known issue and it is recommend to contact the vendor for a solution.

COMPLIANCE:
Not Applicable
EXPLOITABILITY:
There is no exploitability information for this vulnerability.
ASSOCIATED MALWARE:
There is no malware information for this vulnerability.
RESULTS:
X-Frame-Options or Content-Security-Policy: frame-ancestors HTTP Headers missing on port 443.

GET / HTTP/1.1
Host: ip-236.212-91-26-0.dynamic.chello.pl
Connection: Keep-Alive



HTTP/1.1 200 OK
Last-Modified: Tue, 25 Aug 2020 21:27:44 GMT
Content-Length: 74155
Content-Type: text/html;charset=UTF-8
Access-Control-Allow-Origin: *
X-Content-Type-Options: nosniff
X-XSS-Protection: 1; mode=block
Connection: Keep-Alive
Keep-Alive: max=20, timeout=20

Strict-Transport-Security HTTP Header missing on port 443.
And two Potential Vulnerabilities on Serious level (score 3/5)
  • jQuery Prior to 3.5.0 Cross-Site Scripting Vulnerability
Spoiler: show
QID: 13770
Category: CGI
CVE ID: CVE-2020-11022
Vendor Reference Jquery
Bugtraq ID: -
Service Modified: 05/26/2020
User Modified: -
Edited: No
PCI Vuln: Yes

THREAT:
JQuery is prone to a cross-site-scripting vulnerability because it fails to sufficiently sanitize user-supplied input.
Affected Versions:
jQuery versions greater than or equal to 1.2 and before 3.5.0.

QID Detection Logic(Unauthenticated):
It checks for vulnerable versions of jQuery from default web page.

IMPACT:
An attacker may leverage this issue to execute arbitrary script code in the browser of an unsuspecting user in the context of the affected site.
SOLUTION:
Vendor has advised to Upgrade jquery to version 3.5.0
Patch:
Following are links for downloading patches to fix the vulnerabilities:
jQuery

COMPLIANCE:
Not Applicable
EXPLOITABILITY:
There is no exploitability information for this vulnerability.
ASSOCIATED MALWARE:
There is no malware information for this vulnerability.
RESULTS:
jQuery Version Prior to 3.5.0 Detected.jquery-ui.min.css" />
<
  • jQuery Cross-Site Scripting Vulnerability
Spoiler: show
QID: 13772
Category: CGI
CVE ID: CVE-2020-11023
Vendor Reference Jquery
Bugtraq ID: -
Service Modified: 05/26/2020
User Modified: -
Edited: No
PCI Vuln: Yes
THREAT:
JQuery is prone to a cross-site-scripting vulnerability because it fails to sufficiently sanitize user-supplied input.
Affected Versions:
jQuery versions greater than or equal to 1.0.3 and before 3.5.0.

QID Detection Logic(Unauthenticated):
It checks for vulnerable versions of jQuery from default web page.

IMPACT:
An attacker may leverage this issue to execute arbitrary script code in the browser of an unsuspecting user in the context of the affected site.
SOLUTION:
Vendor has advised to Upgrade jquery to version 3.5.0
Patch:
Following are links for downloading patches to fix the vulnerabilities:
jQuery

COMPLIANCE:
Not Applicable
EXPLOITABILITY:
There is no exploitability information for this vulnerability.
ASSOCIATED MALWARE:
There is no malware information for this vulnerability.
RESULTS:
jQuery Version Prior to 3.5.0 Detected.jquery-ui.min.css" />
<
Is jQuery going to be upgraded in next version of Domoticz?
Or I can upgrade it on my own without breaking anything?
ben53252642
Posts: 543
Joined: Saturday 02 July 2016 5:17
Target OS: Linux
Domoticz version: Beta
Contact:

Re: Vulnerability and weak encryption ciphers

Post by ben53252642 »

Personally I access Domoticz via a VPN into my home network.

My setup is not security focused, I have Domoticz running as the root user so I would never consider making it directly accessible via the internet.

Even if it wasn't running as the root user, I still would not make it directly accessible via the internet.
Unless otherwise stated, all my code is released under GPL 3 license: https://www.gnu.org/licenses/gpl-3.0.en.html
WujcioPafcio
Posts: 4
Joined: Thursday 03 September 2020 15:17
Target OS: Raspberry Pi / ODroid
Domoticz version: 2020.2
Contact:

Re: Vulnerability and weak encryption ciphers

Post by WujcioPafcio »

I prepared my Domoticz for Google Home Assistant and voice control.
Unfortunately, this functionality requires Internet access.
EddyG
Posts: 1042
Joined: Monday 02 November 2015 5:54
Target OS: -
Domoticz version:

Re: Vulnerability and weak encryption ciphers

Post by EddyG »

If you want to expose your Domoticz to the outside world then use
1. Letsencrypt (free).
2. A totally random portnumber.
3. A random username.
4. A strong password for that user.

Then I think you are save.
freijn
Posts: 536
Joined: Friday 23 December 2016 16:40
Target OS: Raspberry Pi / ODroid
Domoticz version: Stable
Location: Netherlands Purmerend
Contact:

Re: Vulnerability and weak encryption ciphers

Post by freijn »

WujcioPafcio wrote: Friday 04 September 2020 8:12 I prepared my Domoticz for Google Home Assistant and voice control.
Unfortunately, this functionality requires Internet access.
only allow Google servers to acces your domoticz, block any other ipaddress.
WujcioPafcio
Posts: 4
Joined: Thursday 03 September 2020 15:17
Target OS: Raspberry Pi / ODroid
Domoticz version: 2020.2
Contact:

Re: Vulnerability and weak encryption ciphers

Post by WujcioPafcio »

Maybe two simple questions?
  • is there any options to change manually in some config files of webservice SSH encryption methods?
  • Is jQuery going to be upgraded in next version of Domoticz or I can upgrade it on my own without breaking anything?
lost
Posts: 617
Joined: Thursday 10 November 2016 9:30
Target OS: Raspberry Pi / ODroid
Domoticz version:
Contact:

Re: Vulnerability and weak encryption ciphers

Post by lost »

WujcioPafcio wrote: Friday 04 September 2020 8:12 I prepared my Domoticz for Google Home Assistant and voice control.
Unfortunately, this functionality requires Internet access.
So you seems concerned by security... and you widely open your system to google and accept an always on microphone inside your home???! :lol:
lost
Posts: 617
Joined: Thursday 10 November 2016 9:30
Target OS: Raspberry Pi / ODroid
Domoticz version:
Contact:

Re: Vulnerability and weak encryption ciphers

Post by lost »

freijn wrote: Friday 04 September 2020 9:31 only allow Google servers to acces your domoticz, block any other ipaddress.
No way IMO: They must be doing heavy load balancing between servers with many & always moving IP ranges that'll be difficult to know in advance.
WujcioPafcio
Posts: 4
Joined: Thursday 03 September 2020 15:17
Target OS: Raspberry Pi / ODroid
Domoticz version: 2020.2
Contact:

Re: Vulnerability and weak encryption ciphers

Post by WujcioPafcio »

lost wrote: Friday 04 September 2020 13:49
So you seems concerned by security... and you widely open your system to google and accept an always on microphone inside your home???! :lol:
Google is following us anyway, whether we want it or not. Android devices, Chrome browser...
Better Google than unknown Russians, so please be smart somewhere else ;)
Number8
Posts: 374
Joined: Friday 23 May 2014 7:55
Target OS: Linux
Domoticz version: 2022.1
Location: Saint Pierre de Jards
Contact:

Re: Vulnerability and weak encryption ciphers

Post by Number8 »

ben53252642 wrote: Friday 04 September 2020 5:35 Personally I access Domoticz via a VPN into my home network.

My setup is not security focused, I have Domoticz running as the root user so I would never consider making it directly accessible via the internet.

Even if it wasn't running as the root user, I still would not make it directly accessible via the internet.
I have the same approach.
Debian buster on NUC and three RPi with buster.
EddyG
Posts: 1042
Joined: Monday 02 November 2015 5:54
Target OS: -
Domoticz version:

Re: Vulnerability and weak encryption ciphers

Post by EddyG »

WujcioPafcio wrote: Friday 04 September 2020 14:54
lost wrote: Friday 04 September 2020 13:49
So you seems concerned by security... and you widely open your system to google and accept an always on microphone inside your home???! :lol:
Google is following us anyway, whether we want it or not. Android devices, Chrome browser...
Better Google than unknown Russians, so please be smart somewhere else ;)
Just to be smart anyway.
Use an old Nokia 3210 and DuckDuckGo with a VPN then you no longer supplying Google with info.
I have my system totally open, as described, and never had any problems and keep my fingers crossed.

B.T.W. The links you mentioned won't scan my site because I do not use port 443. Go figure!
And believe me Google has interest in you, the Russians don't, and the Chinese might.
lost
Posts: 617
Joined: Thursday 10 November 2016 9:30
Target OS: Raspberry Pi / ODroid
Domoticz version:
Contact:

Re: Vulnerability and weak encryption ciphers

Post by lost »

WujcioPafcio wrote: Friday 04 September 2020 14:54 so please be smart somewhere else ;)
This is not really being "smart" to be able to make a difference between been followed by google trackers (with some mitigations still possible, even if not always easy/fully possible) and setting their (by nature) always on (and high sensitivity) microphone in your home!
On top of this, voice is considered bio-metric data as this can be used to identify single individuals. Your keyboard don't send your fingerprints to the browser at each key pressed...
Last edited by lost on Tuesday 08 September 2020 8:02, edited 1 time in total.
EddyG
Posts: 1042
Joined: Monday 02 November 2015 5:54
Target OS: -
Domoticz version:

Re: Vulnerability and weak encryption ciphers

Post by EddyG »

Post Reply

Who is online

Users browsing this forum: Google [Bot] and 1 guest