Anti-phishing Protection Issue

[Minimalist 16]

10 hours ago, Marcos said:

Does pressing Ctrl+F5 to refresh the web page in Firefox make a difference?

No it doesn't make difference on my system. Page is displayed with no warning and an entry in log file is created.

[itman 1,659]

As far as I am concerned, there's an issue with Firefox's SecureDNS; i.e. DNS-over-HTTPS.

Remember I previously reset Firefox. Then Eset was detecting this web site OK. Today, I noticed that DNS-over-HTTPS was not enabled in Firefox, so I enabled it. When I subsequently accessed this phishing web site, Eset didn't alert. Then I disabled DNS-over-HTTPS and Eset alerted.

Also as far as Firefox's SecureDNS, weird things are going on. When I enable it and test on Cloudflare's test web site, https://www.cloudflare.com/ssl/encrypted-sni/ , strange things happen. First, it doesn't detect SecureDNS. Then on retest, it does detect it.

Edited September 6, 2021 by itman

[NewbyUser 73]

I've seen some Kaspersky users having strange issues with FF too in other forums. A solution suggested there is;

https://www.hellomails.com/blog/mozilla-firefox-pkix_error_key_pinning_failure-fix/

[itman 1,659]

2 minutes ago, NewbyUser said:

I've seen some Kaspersky users having strange issues with FF too in other forums. A solution suggested there is;

https://www.hellomails.com/blog/mozilla-firefox-pkix_error_key_pinning_failure-fix/

This is a certificate pinning error and is unrelated to this issue.

[NewbyUser 73]

52 minutes ago, itman said:

This is a certificate pinning error and is unrelated to this issue.

I'm aware of that. Your issue is it not properly scanning DNS over HTTPS, which involves certificates to be properly scanned. For what it's worth, most of them are realizing FF is the problem and just move to another browser.

[Minimalist 16]

2 hours ago, itman said:

As far as I am concerned, there's an issue with Firefox's SecureDNS; i.e. DNS-over-HTTPS.

Remember I previously reset Firefox. Then Eset was detecting this web site OK. Today, I noticed that DNS-over-HTTPS was not enabled in Firefox, so I enabled it. When I subsequently accessed this phishing web site, Eset didn't alert. Then I disabled DNS-over-HTTPS and Eset alerted.

Also as far as Firefox's SecureDNS, weird things are going on. When I enable it and test on Cloudflare's test web site, https://www.cloudflare.com/ssl/encrypted-sni/ , strange things happen. First, it doesn't detect SecureDNS. Then on retest, it does detect it.

Yes, I tested it and get same results here. If DOH is enabled I get no alert, when disabled alert returns (using Cloudflare or Quad9).

[itman 1,659]

Pondering a bit, I've pretty much figured out what the issue is with Firefox. Overall, Eset is not at fault here, but will have to address this situation. Also, this non-alerting phishing incident is turning out to be a "blessing in disguise." So let's get into the nitty gritty.

To begin, there is most definitely an IPv6 element involved. It will manifest if your ISP is using 4-to-6-to-4 tunneling; i.e. 464XLAT or one of its variants, to send IPv4 network traffic over its IPv6 network. This type of tunneling is dependent upon NAT64/DNS64 activity being performed on the router. Use of DNS64 is a known DNSSEC "buster" if not done properly. My own opinion is most ISP's are doing so intentionally since DNSSEC bypasses their DNS servers. The bottom line is if your afflicted by this, the only solution is to disable HTTPS-over-DNS option in Firefox.

One way to determine if your ISP is using 4-to-6-to-4 tunneling is to open a command prompt window and perform;

ipconfig /displaydns

Scroll through the resolved DNS entries for "ipv4only.arpa." If it exists, then your ISP is employing this type of tunneling activity.

Finally on my network and most prominent after a system restart, router to ISP initialization of 464XLAT components takes a while. This process is further aggravated by Win 10's Smart Multi-homed Name Resolution feature that:

Quote

The feature is designed to speed up DNS resolution on a device running Windows 8 or newer by sending DNS requests across all available network adapters. Microsoft refined the feature in Windows 10 as it selects the information that is returned the fastest automatically.

https://www.ghacks.net/2017/08/14/turn-off-smart-multi-homed-name-resolution-in-windows/

Again, the bottom line is Eset appears not to recognize that an IPv6 connection exists until initialization of 464XLAT completes. And this is a "hit-or-miss" scernerio.

Edited September 6, 2021 by itman

[NewbyUser 73]

Lots to digest there. Do you use any other browsers and see similar issues? dispalydns here reveals a smattering of both IPV4 and 6 addresses and no "ipv4only.arpa" so maybe your ISP is contributing to the problem.

[itman 1,659]

1 hour ago, NewbyUser said:

Do you use any other browsers and see similar issues?

As I previously posted, I tried Edge and it properly alerted on this phishing web site. See the below screen shot for the reason why:

First note that the later versions of Edge will try to activate HTTPS-over-DNS by default. As the screen shot shows, not only did Edge not activate HTTPS-over-DNS but it locked access to the setting preventing it to be forced enabled.

It also should be noted that upon my reset of Firefox, HTTPS-over-DNS was not enabled. Again, current versions of Firefox will enable HTTPS-over-DNS by default if possible. The difference here is Firefox will allow you to manually enable HTTPS-over-DNS. What Mozilla doesn't warn is you do so at your own peril. My best guess is why it was not auto disabled in existing Firefox version updates when DNS resolution problems exist is some issue with older profile settings overriding new default/auto created profile settings.

Edited September 6, 2021 by itman

[NewbyUser 73]

Is all this going down a road of whether it's worth decrypting things to scan if they're safe? Similar to the debates when scanning https first became common? When is it wise to scan encrypted traffic and when isn't it? 
 

Or maybe, are we encrypting stuff (and then having to decrypt it to ensure it's safe), that shouldn’t be encrypted in the first place?

Edited September 6, 2021 by NewbyUser

[itman 1,659]

29 minutes ago, NewbyUser said:

Is all this going down a road of whether it's worth decrypting things to scan if they're safe? Similar to the debates when scanning https first became common? When is it wise to scan encrypted traffic and when isn't it? 

All the "hullabaloo" about DoH in recent times has been generated by the browser manufacturers and the primary reason why is summed up nicely in this article: https://www.dnsfilter.com/blog/dns-over-tls .

The bottom line of the article is in many cases, DNS-over-TLS is actually more secure than DNS-over-HTTPS. DoH is about privacy; namely the ability to bypass your ISP's DNS servers. And that claim has been disputed in that using DoH still involves transit through the ISP server network. Then there is the debate about how secure for example, Cloudflare DNS servers are.

[NewbyUser 73]

Just seems to me to be a waste of time and resources encrypting something that there are multiple other ways discover users DNS traffic. Even HTTPS seems a waste when you really think about it. We created it to be "more" secure, then had antimalware "break" that encryption to "ensure we're safe" even though they're technically hacking into that encryption in the first place in the name of "Security". Makes it all seem rather pointless.

https://www.zdnet.com/article/dns-over-https-causes-more-problems-than-it-solves-experts-say/ 

Edited September 6, 2021 by NewbyUser

[NewbyUser 73]

On 9/6/2021 at 2:24 PM, itman said:

Pondering a bit, I've pretty much figured out what the issue is with Firefox. Overall, Eset is not at fault here, but will have to address this situation. Also, this non-alerting phishing incident is turning out to be a "blessing in disguise." So let's get into the nitty gritty.

To begin, there is most definitely an IPv6 element involved. It will manifest if your ISP is using 4-to-6-to-4 tunneling; i.e. 464XLAT or one of its variants, to send IPv4 network traffic over its IPv6 network. This type of tunneling is dependent upon NAT64/DNS64 activity being performed on the router. Use of DNS64 is a known DNSSEC "buster" if not done properly. My own opinion is most ISP's are doing so intentionally since DNSSEC bypasses their DNS servers. The bottom line is if your afflicted by this, the only solution is to disable HTTPS-over-DNS option in Firefox.

One way to determine if your ISP is using 4-to-6-to-4 tunneling is to open a command prompt window and perform;

ipconfig /displaydns

Scroll through the resolved DNS entries for "ipv4only.arpa." If it exists, then your ISP is employing this type of tunneling activity.

Finally on my network and most prominent after a system restart, router to ISP initialization of 464XLAT components takes a while. This process is further aggravated by Win 10's Smart Multi-homed Name Resolution feature that:

https://www.ghacks.net/2017/08/14/turn-off-smart-multi-homed-name-resolution-in-windows/

Again, the bottom line is Eset appears not to recognize that an IPv6 connection exists until initialization of 464XLAT completes. And this is a "hit-or-miss" scernerio.

More on IPv6 issues

https://isc.sans.edu/forums/diary/Why+I+Gave+Up+on+IPv6+And+no+it+is+not+because+of+security+issues/27814/

[itman 1,659]

1 hour ago, NewbyUser said:

More on IPv6 issues

https://isc.sans.edu/forums/diary/Why+I+Gave+Up+on+IPv6+And+no+it+is+not+because+of+security+issues/27814/

The below comment sums it up nicely:

Quote

Even if you "disable" IPv6 in the clients network configuration, the router advertisement may disturb your normal operations, i.e. DNS. A lot of internal processes in modern OS's depend on IPv6, so a complete termination is most likely not an option. To Disable it on the gateway's internal interface, so far the best.

In other words, you shouldn't disable it. If you do so, it needs to be done on the router.

[itman 1,659]

I must say, this incident "keeps on giving" and I mean so in a positive way. To begin, the issue not only applies to DoH but also to use of third party IPv6 DNS servers overall if the following situation applies.

Many older ISP issued routers are hybrid IPv6 versions. These routers are original IPv4 only supported networking devices where the ISP has modified the firmware to support IPv6. The problem with this is the required internal circuitry to support IPv6 DNS doesn't exist. The ISP's accommodate this by programming the router to connect to a reserved IPv6 DNS server on their network. Next the router establishes connectivity from this served up ISP IPv6 DNS server to a reserved IPv6 local subnet cache allocated address. This "hand shaking" processing is all done via ICMPv6 communication from the router to connected local devices. The bottom line here is if you have such a router, you must use your ISP's IPv6 DNS servers at all times or your IPv6 DNS communication will be borked in some way.

My ongoing battle with Eset use is existing Eset ICMPv6 rules do not support the above described hand shaking processing. For example, one ICMPv6 communication being blocked is inbound echo request from the router to IPv6 gateway and reserved IPv6 local subnet cache allocated addresses which occur at 30 sec. intervals. Other necessary ICMPv6 inbound communication at system initialization from the gateway to local subnet addresses may also be blocked. The only viable solution is to use the Network Wizard to create insecure inbound ICMPv6 communication rules from the router to the gateway and subnet cache addresses.

Edited September 8, 2021 by itman

[NewbyUser 73]

And then when something happens they will blame you for creating the insecure rules. It’s certainly been an enlightening experience today. 

[itman 1,659]

Another concerning observation.

A Firefox reset has no effect whatsoever on the profile being used by Eset B&PP. If you have disabled DoH in your main Firefox settings, you need to do likewise in Eset B&PP browser session assuming Firefox is your Windows default browser.

[itman 1,659]

It should also be mentioned that with Win10 20H2: https://www.bleepingcomputer.com/news/microsoft/how-to-enable-dns-over-https-doh-in-windows-10/ and also Win 11: https://appuals.com/configure-doh-windows-11/  , one will be able to global enable DoH. This will end the need to do so at the browser level.

What's neat about the Windows global implementation of DoH is it will be implemented at the IP level. So in my case, I could set in on for IPv4 and leave it disabled for IPv6.

[shocked 60]

the other day when i disabled DNS-over-HTTPS it didn't change anything, now it (somewhat) successfully detects the phishing website, mostly on the second try by refreshing the page.

 

[itman 1,659]

13 hours ago, shocked said:

the other day when i disabled DNS-over-HTTPS it didn't change anything, now it (somewhat) successfully detects the phishing website, mostly on the second try by refreshing the page.

 

Did you close the browser after disabling DoH? Then re-open the browser and determine if Eset alerts?

Note: some browser setting changes are not effective in the current browser session.

[itman 1,659]

One last comment here.

I strongly recommend one test the security of whatever DNS provider they are using. An excellent test is this one by Gibson Research: https://www.grc.com/dns/dns.htm . When I tested using my ISP, AT&T, DNS servers, they received an excellent rating in all categories. Such was not the case when using Cloudflare DNS servers.

Edited September 9, 2021 by itman

[shocked 60]

4 hours ago, itman said:

Did you close the browser after disabling DoH

i was testing it for a few minutes, i did close the browser between the on/off of the setting