Broken Cryptography

[Sammo 8]

This happens with all of my browsers at the Dashboard on badssl.com

How can I set Eset to block this kind if connection?

 

[itman 1,538]

This has nothing to do with Eset.

As the above posted description text clearly shows, it is a browser issue. Namely, the browser is allowing SHA1 connections. This can be corrected by removing the ciphers associated with SHA1-intermediate which involves a registry modification.

[Sammo 8]

Thanks for the reply. I have created a registry entry with the value of 0:

Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Hashes\SHA

This has made no difference. It must be related to the browser as when I use a vpn I don't get this insecure connecton.

[itman 1,538]

Correction - this is not a cipher issue but an Eset root certificate issue. Looks like it still accepts SHA1-intemediate certificates.

Can be verified by disabling SSL/TLS protocol scanning. Then the badssl.com SHA1-intemediate test passes.

[Sammo 8]

5 hours ago, itman said:

Correction - this is not a cipher issue but an Eset root certificate issue. Looks like it still accepts SHA1-intemediate certificates.

Can be verified by disabling SSL/TLS protocol scanning. Then the badssl.com SHA1-intemediate test passes.

Thanks! Will this be addressed in future updates to EIS?

[Posolsvetla 15]

We already tried to solve this issue. Unfortunately, there is no general solution which would work out-of-the-box.
Currently it's put on-hold and there is no progress being made on this.

[itman 1,538]

There might be an issue here in regards to non-Win 10 and Windows Server 2016/2019 Eset users. Or, anyone who hasn't applied this update patch.

Appears the stand-alone badssl.com SHA1-1024 Intermediate root certificate test creates an interesting Win Event log entry shown below. Microsoft patched this exploit in late Jan., 2020 for Win 10 and Windows Server 2016/2019 systems. Don't know if the same applies to Win 7 since it was end-of-life by then.

Possible detection of CVE: [CVE-2020-0601] cert validation

Additional Information: CA: <Microsoft ECC Product Root Certificate Authority 2018> sha1:

06F1AA330B927B753A40E68CDF22E34BCBEF3352 para: 06052B81040022 otherPara: 30820157020101303C06072A8648CE3D0101023100FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEFFFFFFFF0000000000000000FFFFFFFF307B0430FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEFFFFFFFF0000000000000000FFFFFFFC0430B3312FA7E23EE7E4988E056BE3F82D19181D9C6EFE8141120314088F5013875AC656398D8A2ED19D2A85C8EDD3EC2AEF031500A335926AA319A27A1D00896A6773A4827ACDAC73046104C711162A761D568EBEB96265D4C3CEB4F0C330EC8F6DD76E39BCC849ABABB8E34378D581065DEFC77D9FCED6B39075DE0CB090DE23BAC8D13E67E019A91B86311E5F342DEE17FD15FB7E278A32A1EAC98FC97E18CB2F3B2C487A7DA6F40107AC023100FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFC7634D81F4372DDF581A0DB248B0A77AECEC196ACCC52973020101

This Event is generated when an attempt to exploit a known vulnerability ([CVE-2020-0601] cert validation) is detected.
This Event is raised by a User mode process.

In regards to CVE-2020-0601:

Quote

Current Description

A spoofing vulnerability exists in the way Windows CryptoAPI (Crypt32.dll) validates Elliptic Curve Cryptography (ECC) certificates. An attacker could exploit the vulnerability by using a spoofed code-signing certificate to sign a malicious executable, making it appear the file was from a trusted, legitimate source, aka 'Windows CryptoAPI Spoofing Vulnerability'.

The NSA has also released a security advisory that includes mitigation information.

“NSA has discovered a critical vulnerability (CVE-2020-0601) affecting Microsoft Windows®1 cryptographic functionality. The certificate validation vulnerability allows an attacker to undermine how Windows verifies cryptographic trust and can enable remote code execution.” reads the NSA’s advisory.

“The consequences of not patching the vulnerability are severe and widespread. Remote exploitation tools will likely be made quickly and widely available”.

https://securityaffairs.co/wordpress/96414/security/microsoft-cve-2020-0601-flaw-nsa.html

 

 

Edited April 14, 2020 by itman

[Sammo 8]

I have Windows 10 and got the patch but I still get this test failure. 😒

[itman 1,538]

55 minutes ago, Sammo said:

I have Windows 10 and got the patch but I still get this test failure. 😒

As long as you have the patch, you can't be at least exploited by this SHA1 vulnerability.

[Sammo 8]

40 minutes ago, itman said:

As long as you have the patch, you can't be at least exploited by this SHA1 vulnerability.

Thanks, that's good to know.

Edited April 14, 2020 by Sammo

[Posolsvetla 15]

CVE-2020-0601 is related to ECC, not SHA1. Only Win10 were affected.
We have implemented the detection of the attack shortly after is was published, so our users are protected (to be precise, this applies only to the TLS connections scanned by Web access protection, not the complete protection of the whole OS) even if they don't have the Win patch installed.

Edited April 15, 2020 by Posolsvetla
details added

[itman 1,538]

5 hours ago, Posolsvetla said:

CVE-2020-0601 is related to ECC, not SHA1

Correct.

Badssl.com point is they used a hacked SHA1 cert. to attempt to exploit this vulnerability as an example of the seriousness of the issue. The fact that CVE-2020-0601 was employed overall is irrelevant to the main issue.

[itman 1,538]

Here's the issue in a nutshell.

All the major browsers; Edge, Chrome, and Firefox, will deny a HTTPS connection using a SHA1 certificate. So as far as browsers go, this Eset root certificate SHA1 problem is non-applicable. The problem is Eset is currently filtering all HTTPS communication. So Eset has two choices here. Fix the issue or stop filtering HTTPS communicating other than for the browser. Otherwise, Eset will again find itself highlighted in the next research publication on AV's performing insecure SSL/TLS protocol filtering.