Jump to content

CVE-2020-0601


itman

Recommended Posts

Just noticed this in my Win event log:

Eset_CVE.png.2f12e2368c62f0b796c4426effd1dec1.png

I assume Eset didn't detect source of this via IDS protection since Win 10 caught it?

Also and coincidental to this, I have been receiving a TLS based SChannel error at boot time originating from lsass.exe which started on 11/2. Only one error per day regardless of number of restarts done during the day. Perhaps related to ver. 14 SSL/TLS issues? In any case, I have previously set lsass.exe to a PPL processs. So need to know if Eset is trying to inject its amsi.dll into it. 

Edited by itman
Link to comment
Share on other sites

  • Administrators

Protection against CVE-2020-0601 has been in the Internet protection module since Feb 5, 2020. I assume that you installed the appropriate Windows update to patch the vulnerability around that time as well.  That said, I assume the event record it could be FP; it even reads "possible detection" and not "detection".

Link to comment
Share on other sites

2 hours ago, Marcos said:

I assume that you installed the appropriate Windows update to patch the vulnerability around that time as well.

Yes.

2 hours ago, Marcos said:

That said, I assume the event record it could be FP; it even reads "possible detection" and not "detection".

Doubt it. First, what is the exploit:

Quote

Proof of concept exploit for the Microsoft Windows CurveBall vulnerability where the signature of certificates using elliptic curve cryptography (ECC) is not correctly verified. ECC relies on different parameters. These parameters are standardized for many curves. However, Microsoft did not check all these parameters. The parameter G (the generator) was not checked, and the attacker can therefore supply his own generator, such that when Microsoft tries to validate the certificate against a trusted CA, it will only look for matching public keys, and then use then use the generator of the certificate.

https://packetstormsecurity.com/files/155961/CurveBall-Microsoft-Windows-CryptoAPI-Spoofing-Proof-Of-Concept.html

Note that the Microsoft Win root CA cert. is signed as sha384ECDSA. Next, the above posted screen shot clearly shows a SHA1 signing attempt with that cert..

The question is and outstanding is what attempted this? It is noted it was a user mode process.

Link to comment
Share on other sites

Maybe this is the reason Eset didn't detect this exploit activity. It was the source of the activity?

I find it way too coincidental that Eset was performing crypto activity at the exact second this exploit activity was detected. Time to totally roll back ver. 14 entirely or just get rid of SSL/TLS protocol scanning. I for one have about had it with this activity.

Eset_Cert.png.fbef196f9411b1e3fd768d956d1d8f21.png

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...