itman 1,543 Posted November 6, 2020 Share Posted November 6, 2020 (edited) Just noticed this in my Win event log: 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 November 6, 2020 by itman Link to comment Share on other sites More sharing options...
Administrators Marcos 4,718 Posted November 6, 2020 Administrators Share Posted November 6, 2020 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 More sharing options...
itman 1,543 Posted November 6, 2020 Author Share Posted November 6, 2020 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 More sharing options...
itman 1,543 Posted November 6, 2020 Author Share Posted November 6, 2020 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. Link to comment Share on other sites More sharing options...
Recommended Posts