Q&A [Updated 29/12/2018] Browser extension comparison: Malwares and Phishings

[legendcampos]

I guess EBS does block something, since I have got this, until I have disabled it.

Usually malicious scripts they see on those sites where the pages open alone, if not detected may have gone unnoticed, scan with malwarebytes to see if it detects something.

 

[Windows_Security]

They are not really meant for that, they are for blocking URLs, ADs are embedded within webpages, they need a different filtering, like uBlock.
It is preferable to block ADs within the system before they reach the browser, like ESET, K9 or via DNS: adguard, alternate, cleanbrowsing.

Why do people complain about AntiVirus companies going through hoops and loops to decrypt HTTPS traffic before it reaches your browser and advice positively on ad-blockers doing seemingly the same thing to block HTTPS encrypted malvertising URL's and redirects?

Can somebody explain this to me why the AV-approach is wrong and Anti-Ad approach (of Adguard, K9 etc) is okay?

 

[Arequire]

Can somebody explain this to me why the AV-approach is wrong

There's a myriad of issues that can be caused by intercepting HTTPS. Things like breaking or not using certificate validation, using broken or outdated ciphers, degrading TLS connections and using outdated TLS versions, opening up connections to TLS attacks (Beast, Freak, Logjam, Crime, etc.)

and Anti-Ad approach (of Adguard, K9 etc) is okay?

I wouldn't say it's okay (I refuse to use AdGuard for this exact reason and its one of the reasons I don't use a traditional AV) but AdGuard themselves acknowledge the issues that HTTPS interception causes and actively try to avoid them as best they can. AV vendors just seem to be either negligent or indifferent when it comes to this stuff.

Here's a research paper about it if you want to get into the nitty gritty details:
https://jhalderm.com/pub/papers/interception-ndss17.pdf
And the conclusion they came up with:

Antivirus vendors should reconsider intercepting HTTPS. Antivirus software operates locally and already has access to the local filesystem, browser memory, and any content loaded over HTTPS. Given their history of both TLS misconfigurations and RCE vulnerabilities, we strongly encourage antivirus providers to reconsider whether intercepting HTTPS is responsible.

 

[Andy Ful]

Usually malicious scripts they see on those sites where the pages open alone, if not detected may have gone unnoticed, scan with malwarebytes to see if it detects something.

I am not sure if your example with Eset can be accepted as a test for all web filtering protection methods.

1. Most web filtering applications block the access to the content of the whole webpage (like Eset).
2. Other solutions block often only the malicious links to files which are actually loaded by the web page.

In the first case the webpage will be blocked. In the second case it will be allowed, but the script will be blocked anyway, after clicking the malicious link.

So, another testing method should be applied for the solutions from the point 2. (like WD Network Protection).

 

[legendcampos]

I am not sure if your example with Eset can be accepted as a test for all web filtering protection methods.

1. Most web filtering applications block the access to the content of the whole webpage (like Eset).
2. Other solutions block often only the malicious links to files which are actually loaded by the web page.

In the first case the webpage will be blocked. In the second case it will be allowed, but the script will be blocked anyway, if you will click the malicious advertisement.

So, another testing method should be applied for the solutions from the point 2. (like WD Network Protection).

1- It is correct, so I disabled adguard and then disabled ESET I left only the extensions of Emsisoft and Windows Defender and the coinminer went unnoticed, you can even test, the link of the site that I did the simple test is in the comment itself just click on some Movie with adblocker disabled and you'll see malicious windows opening by themselves.

2- It does not always block, many still see how phishing I believe this is a past method, are currently always innovating most attacks to exploit vulnerabilities and attacks Js. Scripts, Coinminer.... and others are more difficult to detect if not Have a good set or configuration, common user will not know.

 

[Andy Ful]

1- It is correct, so I disabled adguard and then disabled ESET I left only the extensions of Emsisoft and Windows Defender ...

WD Network Protection is not the web browser extension - it is different from WD Browser Protection for Google Chrome.

 

[legendcampos]

WD Network Protection is not the web browser extension - it is different from WD Browser Protection for Google Chrome.

You are correct are different, I tested as a common user with basic protection and some extension in the case WD browser protection and yet Emsisoft browser is as previously said ordinary user will not know advanced options and even secure extensions I believe That 99% of users find that only the default WD after Windows installation are already secure.

 

[TairikuOkami]

Here's a research paper about it if you want to get into the nitty gritty details:
https://jhalderm.com/pub/papers/interception-ndss17.pdf
And the conclusion they came up with:

Exactly, replacing certificates breaks the working system (SSL handshake) and makes the browser more vulnerable to MitM attacks. AV companies claim, that they have already handled it, but hardly considering, that even Kaspersky 2019 suffers from it. Web SSL filtering is the first I disable.

 

[Andy Ful]

Generally, testing the web protection applications/extensions is not easy. There are many false positives, so most tests do not test the real effectiveness of those solutions, but rather their aggressiveness on blocking unsafe (but not necessarily malicious) content.
The fact of blocking something by AdGuard or Eset, and not blocking it by another solution, does not automatically prove that the blocked content was malicious.
The test of WD Network Protection can be found here (see the result for WDEG NP 19):
Q&A - [Updated 29/12/2018] Browser extension comparison: Malwares and Phishings

 

[Windows_Security]

And the conclusion they came up with:Antivirus vendors should reconsider intercepting HTTPS. Antivirus software operates locally and already has access to the local filesystem, browser memory, and any content loaded over HTTPS. Given their history of both TLS misconfigurations and RCE vulnerabilities, we strongly encourage antivirus providers to reconsider whether intercepting HTTPS is responsible.

Thanks for the link and your answer.

So my assumption is confirmed by your response: when AV-companies should not intercept (decrypt) HTTPS traffic, other software should not touch it either (e.g. like parental control or ad & tracking blockers).

 

[TairikuOkami]

other software should not touch it either (e.g. like parental control or ad & tracking blockers).

They work differently, they block accessing IPs/domains before they get loaded into the browser, acting like a firewall/HOSTS.

 

[Andy Ful]

...
I wouldn't say it's okay (I refuse to use AdGuard for this exact reason and its one of the reasons I don't use a traditional AV) but AdGuard themselves acknowledge the issues that HTTPS interception causes and actively try to avoid them as best they can. AV vendors just seem to be either negligent or indifferent when it comes to this stuff.
...

Is there any difference for AdGuard DNS?

 

[SHvFl]

Is there any difference for AdGuard DNS?

The issue happens only when you have to inject your certificate to browsers and then intercept traffic. Adguard does decent and they usually try to use the latest protocols available but the chance that an issue appears it is still there.
Adguard dns filters on the network level when requests are made so no issue with https filtering or anything. Dns filtering has many more other issues thoughthat will probably annoy the average user more than https filtering with the adguard desktop application.

 

[Windows_Security]

They work differently, they block accessing IPs/domains before they get loaded into the browser, acting like a firewall/HOSTS.

Assumption.
When Adguard does not decrypt HTTPS traffic, they can only see the TCP/IP data (IP address + domain name).

Observation
The Adguard desktop can do more advanced filterng (according to AdGuard's website) than the browser extension.

Question
When AdGuard extension is able filter HTML and Javascript (calls and scriptlests) and even CSS? How does AdGuard do its trick to read the encrypted HTTPS traffic when they can only see the underlaying TCP/IP data (which is limited to IP and domain name, see Wiki explanation below)?

Because HTTPS piggybacks HTTP entirely on top of TLS, the entirety of the underlying HTTP protocol can be encrypted. This includes the request URL (which particular web page was requested), query parameters, headers, and cookies.

However, because host (website) addresses and port numbers are necessarily part of the underlying TCP/IP protocols, HTTPS cannot protect their disclosure. In practice this means that even on a correctly configured web server, eavesdroppers can infer the IP address and port number of the web server (sometimes even the domain name, but not the rest of the URL) that one is communicating.

I still don understand it. It also does makes no sense to me that AV companies are so stupid to use unsafe ways to read encrypted data and AdBlocking can do the same by just using API's? Why would not AV companies use those API's,? When those API's were sufficient, why would EMSISOFT develop an extension, just for the purpose to get more information from INSIDE the browser?

 

[Andy Ful]

The issue happens only when you have to inject your certificate to browsers and then intercept traffic. Adguard does decent and they usually try to use the latest protocols available but the chance that an issue appears it is still there.
Adguard dns filters on the network level when requests are made so no issue with https filtering or anything. Dns filtering has many more other issues thoughthat will probably annoy the average user more than https filtering with the adguard desktop application.

Are those issues related to the users' security?

 

[Arequire]

For anyone interested in a counterargument, here's the editor of Virus Bulletin commenting on the matter of HTTPS interception:
Virus Bulletin :: Security products and HTTPS: let's do it better

 

[SHvFl]

Are those issues related to the users' security?

I said annoy and average user so nope. Issues are for the ability to filter at the same degree and quality plus keep pages looking the same.
Dns filtering in general doesn't suffer from any security issues a normal dns would not suffer. Adguard especially offers doh which increases privacy/security in a combination with the correct setup(atm firefox and something to do the dns resolving as windows suck. possibly dnscrypt etc).

 

[Windows_Security]

For anyone interested in a counterargument, here's the editor of Virus Bulletin commenting on the matter of HTTPS interception:
Virus Bulletin :: Security products and HTTPS: let's do it better

Thanks, or the link.

First, those who are against the practice point out that it breaks the end-to-end principle of HTTPS. This is obviously true, but misses an important point: a compromise in one area of security could (sometimes) lead to improved security elsewhere, and thus a net win.

Feel free to believe the blog of the VB-editor, but it is [a seven character word which will be moderated and starts with a B and ends with a T]. To conclude with the author of the VB-blog: yes breaking security integrity for security sake COULD (in theory) improve security, that is true. It is just not likely that only goodware uses this compromise and the chance of running into a risky web interaction of the security unaware users even decreases the likely hood of this comprise paying out well.

The editor uses the same arguments HIPS/Security Vendors used when Microsoft stopped allowing kernel patching in 64-bits systems. It is a known and never ending discussion in security forums, simular to kernel patching and Sandboxie breaking the integrity of the Chrome sandbox on Windows. My take is clear on this. When AV-vendors should not compromise HTTPS, neither Ad & Tracking blockers and Parental Control programs should not do this either.

 

[Windows_Security]

I said annoy and average user so nope. Issues are for the ability to filter at the same degree and quality plus keep pages looking the same.
Dns filtering in general doesn't suffer from any security issues a normal dns would not suffer. Adguard especially offers doh which increases privacy/security in a combination with the correct setup(atm firefox and something to do the dns resolving as windows suck. possibly dnscrypt etc).

YEP but as far as I know DNS filtering only can see TCP data (IP and domain, see WIKI), so how do they achieve HTML, script and CSS filtering?

 

[SHvFl]

YEP but as far as I know DNS filtering only can see TCP data (IP and domain, see WIKI), so how do they achieve HTML, script and CSS filtering?

They don't hence why i said it doesn't have the ability to filter at the same degree and quality as normal extension or whatever filtering.