Memory Usage

[itman 1,659]

4 hours ago, MMx said:

Unfortunately you're wrong here. If someone performs a Man-in-the-Middle attack on your connection to imgur.com it's very likely they will try transferring malware or other content of security interest to the user. In that case we very much want to scan that connection. And the only way to detect that attack is to verify the certificate. We don't want to whitelist anything that's called imgur.com, we only want to whitelist the actual imgur server.

 

Quote

Stop Certificate Pinning

The biggest problem with pinning is that you lose the ability to respond to certificate issues. If you need to change keys, certificates, issuers, or your CA vendor, for any reason, you must fix your client, browser, code, IoT device, etc. - sometimes on a short schedule. If you are committed to supporting an application version for years and it contains a pinned certificate, how can you be sure the certificate will remain valid for the entire lifetime of your application? Pinning is especially problematic with publicly trusted TLS certificates because they must adhere to ever-evolving rules, decreasing maximum lifetimes and other surprises.

Luckily, HPKP is a thing of the past, and DigiCert has not been a big proponent of other types of public key pinning. DigiCert recommends you do not use pinning; the complexities and consequences outweigh the benefits.

https://www.digicert.com/blog/certificate-pinning-what-is-certificate-pinning

Again, just one more example where the critics of AV's performing SSL/TLS protocol scanning are most justified in their criticisms.

Edited February 21, 2022 by itman

[MMx 28]

I see no AV criticism in the linked article or in your post. Also we're not using HTTP Public Key Pinning nor certificate pinning. Can you explain the relevance to the topic here?

[Mr_Frog 14]

42 minutes ago, MMx said:

I see no AV criticism in the linked article or in your post. Also we're not using HTTP Public Key Pinning nor certificate pinning. Can you explain the relevance to the topic here?

So do you have any explanation so far what is causing the large memory consumption of the eset kernel when opening the browser??? I am really surprised how defensive you are and I think you also have bad communication in public area. I said public area because this forum is open to the public, everyone does not need to register to view information on this forum. I personally don't like the way you defend your product either. I like eset products, I have been using since 2015 and so far I have never had a big problem with this product, but seeing the eset staff act like this makes me frown, again from my point of view your way is just degrading the product. Highly recommended in the future if you want to reply to a specific topic it's better to be represented by an eset moderator who I believe understands better how to communicate well in public area. let's see if you will attack me too haha.

[Marcos 5,070]

2 minutes ago, Mr_Frog said:

So do you have any explanation so far what is causing the large memory consumption of the eset kernel when opening the browser??? I am really surprised how defensive you are and I think you also have bad communication in public area. I said public area because this forum is open to the public, everyone does not need to register to view information on this forum. I personally don't like the way you defend your product either. I like eset products, I have been using since 2015 and so far I have never had a big problem with this product, but seeing the eset staff act like this makes me frown, again from my point of view your way is just degrading the product. Highly recommended in the future if you want to reply to a specific topic it's better to be represented by an eset moderator who I believe understands better how to communicate well in public area. let's see if you will attack me too haha.

Since it's gone into very technical details, we've asked developers to reply here directly regarding technical matters. Only developers know all the ins and outs of how the SSL filtering works in detail so they are the right staff to give you technical response on queries.

[MMx 28]

8 minutes ago, Mr_Frog said:

So do you have any explanation so far what is causing the large memory consumption of the eset kernel when opening the browser???

Yes, I've written a detailed analysis here: https://forum.eset.com/topic/31282-memory-usage/page/4/#comment-147108

In a nutshell, this memory is occupied by Windows Crypto API cache that we don't have direct control over. I'm currently trying to figure out if it can be configured beforehand.

[itman 1,659]

I am going to make another posting and it's in regards to Eset's SSL/TLS protocol scanning of browser network traffic.

I previously posted that I felt my existing browser only based protections were adequate to protect me against web site based malware:

Quote

As far as Eset scanning for malware on HTTPS sites, Google Safe Browsing also does this along with PUA detection. I also use uBLock Origin with multiple malware and adblock filter lists selected. 

I set about to test my this assumption. For this test and again with Eset SSL/TLS protocol scanning disabled for Firefox, I tested at web site that Eset had previously detected a malicious script. Although the original Eset detection was two months ago, my hunch, which proved correct, was this web site was still infected implying it was most likely done intentionally by the web site developer.

Below is the Eset original detection with SSL/TLS protocol scanning enabled:

Time;Scanner;Object type;Object;Detection;Action;User;Information;Hash;First seen here
12/28/2021 2:46:00 PM;HTTP filter;file;https://baysuit.org/wp-content/themes/obour/js/swiper.min.js?ver=5.8.2;JS/Agent.PIV trojan;connection terminated;XXXX\XXX;Event occurred during an attempt to access the web by the application: C:\Program Files\Mozilla Firefox\firefox.exe (E36F9A16D60EFAAF370C07A99559B78476BD8AAA).;81FC52AD86F1CFF308D71444EB305697B81D49B2;

The detail to note at this point is Eset detected using its HTTP filter indicating Eset was examining SSL/TLS protocol scanned decrypted code.

Here is the result of accessing the same web site yesterday with SSL/TLS protocol scanning disabled:

Time;Scanner;Object type;Object;Detection;Action;User;Information;Hash;First seen here
2/20/2022 4:05:08 PM;JavaScript scanner;file;https://baysuit.org/wp-content/themes/obour/js/comments.js?ver=495eca89ae6a299dbcae062d611592bc;JS/Agent.PIV trojan;blocked;XXX\XXX;Event occurred during an attempt to access the web by the application: C:\Program Files\Mozilla Firefox\firefox.exe (DDA2DF4674CFAC53C721366914D7CD6F8A4A84DA).;01F58FB0AAFF6CBBB313B0017A69CE650F82391C;

Of note with this recent detection is although the hashes for the two detection's differ, Eset's malware identification is the same. This would be indicative of the creator of the malicious script creating a new variant in hopes of evading AV signature detection. Also assumed is the script was moved to a new WordPress plug-in to further obfuscate AV detection.

Most important with the recent Eset detection is it was made via Advanced Script Scanner. Err ....... how is that possible with SSL/TLS protocol scanning disabled?

Finally, browser based protections alone are not enough to detect browser based malicious scripts. Your only alternative is to use a browser extension such as NoScript which blocks all script execution. Then whitelist web sites you frequent that are known to be safe. Obviously, few will tolerate doing so.

In any case, Eset SSL/TLS protocol scanning on my device will remain permanently disabled for Firefox.

Edited February 21, 2022 by itman

[Marcos 5,070]

The JavaScript detection was using the advanced scanning of browser scripts feature which is provided by injecting eplgfirefox.dll into Firefox. It's unrelated to AMSI.

[itman 1,659]

6 minutes ago, Marcos said:

The JavaScript detection was using the advanced scanning of browser scripts feature which is provided by injecting eplgfirefox.dll into Firefox.

Yes, I realize that. But since the code is still encrypted, this .dll can't scan it.

Are you stating that Eset in violation of the user's explicit instruction not to scan browser encrypted code is still doing so?

Edited February 21, 2022 by itman

[Marcos 5,070]

5 minutes ago, itman said:

Are you stating that Eset in violation of the user's explicit instruction not to scan browser encrypted code is still doing so?

If a user explicitly disables advanced scanning of browser scripts + AMSI scanner, then the script should not be detected.

Update: the file would be also detected by real-time protection:

72b7543b080d78da6ff89f6a7eed9bbc465f4e61526ac73c9ad7320b56a861eb.htm - JS/Agent.PIV trojan

[itman 1,659]

Just now, Marcos said:

If a user explicitly disables advanced scanning of browser scripts + AMSI scanner, then the script should not be detected.

Then, AMSI scanner is indeed employed.

[Marcos 5,070]

2 minutes ago, itman said:

Then, AMSI scanner is indeed employed.

Not if "JavaScript scanner" is listed in logs.

[itman 1,659]

1 minute ago, Marcos said:

Not if "JavaScript scanner" is listed in logs.

Please explain how Eset's JavaScript scanner can scan encrypted code.

[Marcos 5,070]

1 minute ago, itman said:

Please explain how Eset's JavaScript scanner can scan encrypted code.

We have a dll injected in the browser process, hence we can scan the content of websites. Even if you saved the page content to the disk, it would be detected by real-time protection in this case.

[itman 1,659]

Just now, Marcos said:

We have a dll injected in the browser process, hence we can scan the content of websites. Even if you saved the page content to the disk, it would be detected by real-time protection in this case.

OK. I got it.

Eset is actually inspecting the script code after it has been decrypted by the browser. In other words, the "proper" way AV's should be examining web site code.

As such, what other reasons are there for employing SSL/TLS protocol scanning? The vast majority of web site malicious code is script based.

[MMx 28]

Just a quick heads-up, we've been made aware of a malware campaign that hosts malicious payloads as images in imgur.com, so we're removing it from the list of domains for which TLS filtering is skipped. That means it won't behave as described in previous posts anymore.

[MMx 28]

1 minute ago, itman said:

As such, what other reasons are there for employing SSL/TLS protocol scanning?

It's the only way to catch exploits targeting browsers before they have a chance to run.

[itman 1,659]

4 hours ago, MMx said:

It's the only way to catch exploits targeting browsers before they have a chance to run.

Not a good enough reason for me. Why? Because it implies Eset has the ability to detect 0-day exploits which is certainly not the case.

-EDIT- This also brings up an issue that I am increasingly having an issue with using Eset.  The issue is Eset is a "one solution fits all product." Eset consumer products are for the most part, a "port" of their Endpoint version.

In commercial IT environments, it is a common but, abet insecure practice, to delay software patching. This practice would hold true for browsers. As such, protection for known browser exploits would make sense.

Most home users on the other hand would be running their browser at default settings. One of these default settings is to have the browser auto update. This in turn ensures the latest vulnerabilities are patched resulting in known exploits being a moot point.

Edited February 21, 2022 by itman

[New_Style_xd 69]

3 minutes ago, MMx said:

Just a quick heads-up, we've been made aware of a malware campaign that hosts malicious payloads as images in imgur.com, so we're removing it from the list of domains for which TLS filtering is skipped. That means it won't behave as described in previous posts anymore.

I liked this warning, it should have a fixed topic of information like this. would be a good suggestion.

[itman 1,659]

In regards to SSL/TLS protocol scanning being justified as to exploitation of browser vulnerabilities, a few additional comments.

What is relevant here is known exploitation of browser vulnerabilities and there is an organization that tracks those: https://www.cisa.gov/known-exploited-vulnerabilities-catalog . In the case of Firefox, three are listed. In the case of Chrome, a whopping 22 are listed.

-EDIT- All the above have been patched by their respective vendor.

In regards to browser vulnerabilities overall, 33 Intermediate level ones were recorded for Chrome in the last week: https://www.cisa.gov/uscert/ncas/bulletins/sb22-052

So if you're a Chrome user, it appears keeping SSL/TLS protocol scanning enabled for it makes sense. You also have no choice here due to the previously noted OCSP stapling issue in Chrome.

Also folks, this issue among many others is why I refuse to use Chrome.

Edited February 22, 2022 by itman

[New_Style_xd 69]

23 minutes ago, itman said:

In regards to SSL/TLS protocol scanning being justified as to exploitation of browser vulnerabilities, a few additional comments.

What is relevant here is known exploitation of browser vulnerabilities and there is an organization that tracks those: https://www.cisa.gov/known-exploited-vulnerabilities-catalog . In the case of Firefox, three are listed. In the case of Chrome, a whopping 22 are listed.

So if you're a Chrome user, it appears keeping SSL/TLS protocol scanning enabled for it makes sense. You also have no choice here due to the previously noted OCSP stapling issue in Chrome.

Also folks, this issue among many others is why I refuse to use Chrome.

I think chrome has more problems because there are far more services than Firefox.

[itman 1,659]

One last comment here and it's an important one.

Skirting the SSL/TLS protocol scanning use "debate," Eset needs to immediately stop certificate validation processing in regards to Firefox. It is the only browser past or present that performed certificate validation processing properly.

As it currently stands, the only way to remove Eset's certificate validation processing in regards to Firefox is to disable SSL/TLS protocol scanning.

[Posolsvetla 15]

19 hours ago, itman said:

immediately stop certificate validation processing in regards to Firefox. It is the only browser past or present that performed certificate validation processing properly.

We cannot stop validating certificates.

We don't do it because some browser might do certificate validation incorrectly. We do it because if TLS scanning is active for a particular web site, a browser cannot validate the original certificate of that site. (Note: As already discussed previously, we validate certificates also in several cases when TLS scanning is not active for a web page in question.)

What would happen if we stopped validating certificates can be simulated like this:
As per https://help.eset.com/eis/15/en-US/?idh_config_epfw_ssl_known.html add the certificate for https://untrusted-root.badssl.com/ and set the Access action to Allow. This way, the server's certificate will be considered valid by our product with the same effect as if we didn't validate it. (Note: As already mentioned, the revoked certificates won't be considered valid even if configured so.) Then try to open that web site. It will succeed.

I managed to find a few links which might be helpful for anybody reading this forum:
https://medium.com/@ethicalevil/how-http-proxies-read-tls-traffic-from-browsers-f15364e91226
https://security.stackexchange.com/questions/133254/how-does-ssl-proxy-server-in-company-work
https://docs.mitmproxy.org/stable/concepts-howmitmproxyworks/#transparent-https
https://en.wikipedia.org/wiki/TLS_termination_proxy
According to Wikipedia, we use "TLS termination proxy" of "TLS Bridging" type in order to be able to do TLS scanning.

Edited February 24, 2022 by Posolsvetla
better clarification

[itman 1,659]

As far as Eset's conducting monster-in the-middle (MITM) activities in regards to SSL/TLS protocol scanning, it might want to look into what Avast is doing: https://textslashplain.com/2019/08/11/spying-on-https/ .

Additional ref.: monster-in-the-browser attack (MITB)

-EDIT- For those interested, here's a formal scientific paper, 'The Security Impact of HTTPS Interception', published a few years back: https://zakird.com/papers/https_interception.pdf . This publication can be summed up in the following paragraph:

Quote

The study shows that 62% of traffic that traverses a network middlebox has reduced security and 58% of middlebox connections have severe vulnerabilities. They also investigated popular antivirus and corporate proxies, finding that nearly all of them reduce connection security and that many introduce vulnerabilities.

https://www.thesslstore.com/blog/ssl-inspection/

Edited February 26, 2022 by itman

[MMx 28]

On 2/25/2022 at 10:37 PM, itman said:

https://textslashplain.com/2019/08/11/spying-on-https/

This method doesn't allow to inject data into the connection. This has several disadvantages:

• No blocking pages (it's much easier to figure out which tab a message is related to if its displayed directly in the tab than in a separate dialog), no redirects for Banking & Payment protection.
• There's no way to implement HTTP2 flow control properly since we would be unable to send any messages: "Flow control is specific to a connection. Both types of flow control are between the endpoints of a single hop and not over the entire end-to-end path." (https://datatracker.ietf.org/doc/html/rfc7540#section-5.2.1) This could have unforeseen consequences.
• There's also no way to send HTTP2 RST message to inform the browser that it shouldn't use any data it has received so far.
• If an HTTP2 response is completely tranfserred but we haven't finished scanning it yet, we are only able to delay the entire connection, blocking access to other resources which the browser could be parsing in the meantime. This would result in degraded performance. This might be one of the reasons why Avast slows down your browsing more than ESET (see Slowing-down when launching popular websites):
  https://www.av-test.org/en/antivirus/home-windows/windows-10/december-2021/eset-internet-security-15.0-211609/
  https://www.av-test.org/en/antivirus/home-windows/windows-10/december-2021/avast-free-antivirus-21.9-211603/

On 2/25/2022 at 10:37 PM, itman said:

https://zakird.com/papers/https_interception.pdf

As already mentioned this research is couple of years old. Most of the findings there related to ESET were fixed before the paper was published (we were contacted by the author beforehand), all of them are fixed by now, some were never correct in the first place. Unfortunately the author didn't respond to our request for corrections or updates.

[MMx 28]

Back to the original topic.

We've had a discussion with Microsoft regarding this. They believe that the memory and CPU usage reported here is adequate to the size of the revocation list that is being processed. There are no plans to implement any changes in this part of Windows unless they are required for security. In their words it's not possible to avoid this behavior except disabling the cache which is not recommended.

I've identified some circumstances that were contributed to this problem. This will be solved in protoscan 1439. Unfortunately the problem might come back anyway since it's considered a normal behavior of Windows, although now it will be less likely.

It's possible to apply this workaround manually. To do that create a DWORD registry value called CryptnetCachedOcspSwitchToCrlCount under HKLM\SOFTWARE\Policies\Microsoft\SystemCertificates\ChainEngine\Config (you may need to create several missing path components) and set it to 1047 (the special meaning of this value is that it will be reverted to default when the product is uninstalled). Then run the following commands elevated and reboot:
certutil.exe -urlcache http://crl3.digicert.com/ssca-sha2-g6.crl delete
certutil.exe -urlcache http://crl4.digicert.com/ssca-sha2-g6.crl delete
This needs to be done for each user separately.

It is also possible to completely disable the cache that is causing these problems. Doing it means that verifying certificates after reboot will be as slow as it is the first time they are encountered ever. This is not a recommended solution:
certutil -setreg chain\ChainCacheResyncFiletime @now+10000:0
To revert this use
certutil -delreg chain\ChainCacheResyncFiletime

Edited March 3, 2022 by MMx