SeriousHoax 83 Posted March 9 Share Posted March 9 (edited) When Firefox is set to use maximum or increased protection in DNS over HTTPS settings then ESET does not block blacklisted websites. For example, here's a VT link of a fake crack program website already in ESET's blacklist: https://www.virustotal.com/gui/url/5583ee6d3fa820c9c851f37746d9b5a896da37bc7ce93329d6dcc02e4b7d9daa/detection But with above DNS settings, it is not blocked: When I set Firefox's DNS over HTTPS settings to Off, ESET blocks it. There is no such issue on Chromium browsers: Edit: In case it has some sort of connection, ESET's web protection also doesn't work when used with AdGuard for Windows. Changing any network driver or other related settings has no impact. To be clear, in the explained scenario in my main post I'm not using AdGuard for Windows. Edited March 9 by SeriousHoax Quote Link to comment Share on other sites More sharing options...
itman 1,659 Posted March 9 Share Posted March 9 (edited) 4 hours ago, SeriousHoax said: For example, here's a VT link of a fake crack program website already in ESET's blacklist: https://www.virustotal.com/gui/url/5583ee6d3fa820c9c851f37746d9b5a896da37bc7ce93329d6dcc02e4b7d9daa/detection But with above DNS settings, it is not blocked: I have Firefox DNS over HTTPS set to Default level w/CloudFlare as DNS provider. I am also using CloudFlare as my Win 10 DNS provider. When I try to access the malicious URL in question, I can access the web site and even download the malicious crack. Quote When I set Firefox's DNS over HTTPS settings to Off, ESET blocks it. Same here. I am wondering if this is a FireFox problem since Eset blocks the URL on Chrome? -EDIT- I set Firefox DNS over HTTPS to Increased Protection using CloudFlare as DNS provider, Eset alert now displayed on attempted web page access. However, w/ DNS over HTTPS set to Maximum protection, no web site blocking occurs. Also when setting back to Increased Protection, no Eset alert. Clearing all browser cache settings, restarting Firefox, setting to Default protection, Eset now alerts. Repeat test at Default protection, Eset still alerts. I would say this is indeed a Firefox bug. Edited March 9 by itman Quote Link to comment Share on other sites More sharing options...
SeriousHoax 83 Posted March 9 Author Share Posted March 9 48 minutes ago, itman said: I have Firefox DNS over HTTPS set to Default level w/CloudFlare as DNS provider. I am also using CloudFlare as my Win 10 DNS provider. When I try to access the malicious URL in question, I can access the web site and even download the malicious crack. Same here. I am wondering if this is a FireFox problem since Eset blocks the URL on Chrome? -EDIT- I set Firefox DNS over HTTPS to Increased Protection level using CloudFlare as DNS provider. Eset alert now displayed on attempted web page access. However, w/ DNS over HTTPS set to Maximum protection, no web site blocking occurs. I would say this is indeed a Firefox bug. I don't know whose bug it is but for me the example site is not blocked even in Increased protection mode. I tested two other security products, but they don't have this issue on Firefox. Quote Link to comment Share on other sites More sharing options...
itman 1,659 Posted March 9 Share Posted March 9 (edited) Found the problem, I believe. Eset Filtered Web Site log shows it blocked access; Time;URL;Status;Detection;Application;User;IP address;Hash 3/9/2024 11:43:27 AM;https://crackingpatching.com;Blocked;Internal blacklist;C:\Program Files\Mozilla Firefox\firefox.exe;xxxxx;104.21.43.46;F736FE1F2C3ACB8E53F9E22EFE632D18B65DECCB Time;URL;Status;Detection;Application;User;IP address;Hash 3/9/2024 11:43:28 AM;https://accounts.google.com/o/oauth2/postmessageRelay?parent=https://crackingpatching.com&jsh=m;/_/scs/abc-static/_/js/k=gapi.lb.en.8uXxGUoumbY.O/d=1/rs=AHpOoo96qx3mL4tzGUOa-0q0udyPRqEAoA/m=__features__;Blocked;Internal blacklist;C:\Program Files\Mozilla Firefox\firefox.exe;xxxxx;2607:f8b0:4023:140d::54;F736FE1F2C3ACB8E53F9E22EFE632D18B65DECCB But web site access is not blocked. Notice the redirect to Google. Looks like someone has figured out how to bypass Eset Web Filtering on Firefox. Edited March 9 by itman Quote Link to comment Share on other sites More sharing options...
SeriousHoax 83 Posted March 9 Author Share Posted March 9 2 hours ago, itman said: Found the problem, I believe. Eset Filtered Web Site log shows it blocked access; Time;URL;Status;Detection;Application;User;IP address;Hash 3/9/2024 11:43:27 AM;https://crackingpatching.com;Blocked;Internal blacklist;C:\Program Files\Mozilla Firefox\firefox.exe;xxxxx;104.21.43.46;F736FE1F2C3ACB8E53F9E22EFE632D18B65DECCB Time;URL;Status;Detection;Application;User;IP address;Hash 3/9/2024 11:43:28 AM;https://accounts.google.com/o/oauth2/postmessageRelay?parent=https://crackingpatching.com&jsh=m;/_/scs/abc-static/_/js/k=gapi.lb.en.8uXxGUoumbY.O/d=1/rs=AHpOoo96qx3mL4tzGUOa-0q0udyPRqEAoA/m=__features__;Blocked;Internal blacklist;C:\Program Files\Mozilla Firefox\firefox.exe;xxxxx;2607:f8b0:4023:140d::54;F736FE1F2C3ACB8E53F9E22EFE632D18B65DECCB But web site access is not blocked. Notice the redirect to Google. Looks like someone has figured out how to bypass Eset Web Filtering on Firefox. Very interesting🤔 I have two blocks. But mine is a twitter redirect not google. Quote Time;URL;Status;Detection;Application;User;IP address;Hash 10-Mar-24 12:51:58 AM;https://platform.twitter.com/widgets/widget_iframe.2f70fb173b9000da126c79afe2098f02.html?origin=https://crackingpatching.com;Blocked;Internal blacklist;C:\Program Files\Mozilla Firefox\firefox.exe;****;F736FE1F2C3ACB8E53F9E22EFE632D18B65DECCB Time;URL;Status;Detection;Application;User;IP address;Hash 10-Mar-24 12:51:56 AM;https://crackingpatching.com;Blocked;Internal blacklist;C:\Program Files\Mozilla Firefox\firefox.exe;****;F736FE1F2C3ACB8E53F9E22EFE632D18B65DECCB Quote Link to comment Share on other sites More sharing options...
itman 1,659 Posted March 9 Share Posted March 9 (edited) Did more testing with the TLD https://crackingpatching.com/ The problem is with DoH enabled in Firefox. With DoH disabled, Eset will alert and block access every time. When any of the DoH settings are enabled, Eset might block it once after setting change but not thereafter. Doesn't matter what DoH option is selected or DoH provider selected. I am keeping DoH disabled until this is resolved. Glad you found this problem. Edited March 9 by itman Quote Link to comment Share on other sites More sharing options...
SeriousHoax 83 Posted March 10 Author Share Posted March 10 12 hours ago, itman said: Did more testing with the TLD https://crackingpatching.com/ The problem is with DoH enabled in Firefox. With DoH disabled, Eset will alert and block access every time. When any of the DoH settings are enabled, Eset might block it once after setting change but not thereafter. Doesn't matter what DoH option is selected or DoH provider selected. I am keeping DoH disabled until this is resolved. Glad you found this problem. Well, now it's not even working for me in Chromium browsers. In Edge, the first time it blocks and then if I reload the page, it isn't blocked. On my testing Chrome Portable browser in another drive, web protection is not working most of the time even in default settings without DoH. Something is not right. It needs to be looked at fixed soon. Quote Link to comment Share on other sites More sharing options...
itman 1,659 Posted March 10 Share Posted March 10 Another observation. With DoH disabled in Firefox, attempted access to https://crackingpatching.com/2017/03/avast-pro-antivirus-internet-security-premier-17-2-3419-0-keys.html results in blocking at the TLD as should be; Time;URL;Status;Detection;Application;User;IP address;Hash 3/10/2024 10:09:53 AM;https://crackingpatching.com;Blocked;Internal blacklist;C:\Program Files\Mozilla Firefox\firefox.exe;xxxxxxxx;2606:4700:3034::6815:2b2e;F736FE1F2C3ACB8E53F9E22EFE632D18B65DECCB Quote Link to comment Share on other sites More sharing options...
SeriousHoax 83 Posted March 10 Author Share Posted March 10 (edited) 39 minutes ago, itman said: Another observation. With DoH disabled in Firefox, attempted access to https://crackingpatching.com/2017/03/avast-pro-antivirus-internet-security-premier-17-2-3419-0-keys.html results in blocking at the TLD as should be; Time;URL;Status;Detection;Application;User;IP address;Hash 3/10/2024 10:09:53 AM;https://crackingpatching.com;Blocked;Internal blacklist;C:\Program Files\Mozilla Firefox\firefox.exe;xxxxxxxx;2606:4700:3034::6815:2b2e;F736FE1F2C3ACB8E53F9E22EFE632D18B65DECCB Compatibility issue with DoH. Have a look at this weird behavior on Edge: https://ibb.co/1TXPwMs Edited March 10 by SeriousHoax Quote Link to comment Share on other sites More sharing options...
itman 1,659 Posted March 10 Share Posted March 10 1 hour ago, SeriousHoax said: Have a look at this weird behavior on Edge: https://ibb.co/1TXPwMs I would say DoH should be disabled on all browsers till Eset fixes the problem. Quote Link to comment Share on other sites More sharing options...
SeriousHoax 83 Posted March 10 Author Share Posted March 10 1 hour ago, itman said: I would say DoH should be disabled on all browsers till Eset fixes the problem. The above issue I showed in the GIF above is happening even when DoH is disabled in Edge. So, the problem is probably worse than we thought. Quote Link to comment Share on other sites More sharing options...
itman 1,659 Posted March 10 Share Posted March 10 25 minutes ago, SeriousHoax said: The above issue I showed in the GIF above is happening even when DoH is disabled in Edge. So, the problem is probably worse than we thought. No problem in Firefox on this regard w/DoH disabled. When I select reload icon, the site is blocked again. Quote Link to comment Share on other sites More sharing options...
SeriousHoax 83 Posted March 10 Author Share Posted March 10 56 minutes ago, itman said: No problem in Firefox on this regard w/DoH disabled. When I select reload icon, the site is blocked again. Same here. But on Chrome and Edge it's not behaving correctly even in default settings. So, it's a far more serious issue as more people use Chrome and Edge. Quote Link to comment Share on other sites More sharing options...
itman 1,659 Posted March 10 Share Posted March 10 3 hours ago, SeriousHoax said: Same here. But on Chrome and Edge it's not behaving correctly even in default settings. So, it's a far more serious issue as more people use Chrome and Edge. My guess is Chrome and Edge are reloading the web page from their cache versus from its source as Firefox does. Quote Link to comment Share on other sites More sharing options...
itman 1,659 Posted March 11 Share Posted March 11 (edited) I am also wondering if we are looking at exploitation of a new IPv6 DoH DNS rebind vulnerability similar to the IPv4 one noted here; Quote Vulnerability Details : CVE-2020-26961 When DNS over HTTPS is in use, it intentionally filters RFC1918 and related IP ranges from the responses as these do not make sense coming from a DoH resolver. However when an IPv4 address was mapped through IPv6, these addresses were erroneously let through, leading to a potential DNS Rebinding attack. This vulnerability affects Firefox < 83, Firefox ESR < 78.5, and Thunderbird < 78.5. Now my ISP uses 6rd tunneling on its network. This is the reverse of the above in that all IPv6 traffic is tunneled through an IPv4 connection via use of a tunnel broker ISP. Let's again review what happens when a connection is made to https://crackingpatching.com/2017/03/avast-pro-antivirus-internet-security-premier-17-2-3419-0-keys.html with DoH enabled in Firefox; Eset Filtered Web Site log shows it blocked access; Time;URL;Status;Detection;Application;User;IP address;Hash 3/9/2024 11:43:27 AM;https://crackingpatching.com;Blocked;Internal blacklist;C:\Program Files\Mozilla Firefox\firefox.exe;xxxxx;104.21.43.46;F736FE1F2C3ACB8E53F9E22EFE632D18B65DECCB Time;URL;Status;Detection;Application;User;IP address;Hash 3/9/2024 11:43:28 AM;https://accounts.google.com/o/oauth2/postmessageRelay?parent=https://crackingpatching.com&jsh=m;/_/scs/abc-static/_/js/k=gapi.lb.en.8uXxGUoumbY.O/d=1/rs=AHpOoo96qx3mL4tzGUOa-0q0udyPRqEAoA/m=__features__;Blocked;Internal blacklist;C:\Program Files\Mozilla Firefox\firefox.exe;xxxxx;2607:f8b0:4023:140d::54;F736FE1F2C3ACB8E53F9E22EFE632D18B65DECCB Notice first two connections are made with the first connection in IPv4 to the TLD. Eset doesn't alert or block the connection in this instance. However with DoH disabled in Firefox, only one connection is being made/logged. It is to the TLD. Most important it is via IPv6. Eset alerts and blocks this connection; Time;URL;Status;Detection;Application;User;IP address;Hash 3/11/2024 11:25:41 AM;https://crackingpatching.com;Blocked;Internal blacklist;C:\Program Files\Mozilla Firefox\firefox.exe;xxxxxxxx;2606:4700:3034::6815:2b2e;F736FE1F2C3ACB8E53F9E22EFE632D18B65DECCB Also significant is that the URL shown on the Eset block alert is the sub-domain; https://crackingpatching.com/2017/03/avast-pro-antivirus-internet-security-premier-17-2-3419-0-keys.html I have seen enough that I am keeping DoH permanently disabled. Edited March 11 by itman Quote Link to comment Share on other sites More sharing options...
itman 1,659 Posted March 11 Share Posted March 11 It gets better ....... This domain is using Cloudflare DNS servers; Quote Link to comment Share on other sites More sharing options...
itman 1,659 Posted March 11 Share Posted March 11 Confirmed. DoH does not prevent a DNS rebind attack; Quote Using our DNS rebinding framework, Singularity of Origin, we tested several DoH services to determine whether DoH prevents or adversely impacts DNS rebinding attacks. Our results show that DoH does not prevent DNS rebinding attacks and all rebinding strategies and techniques implemented in Singularity still work, including the fast multiple answers strategy and DNS cache flooding technique that allow rebinding in just a few seconds. https://research.nccgroup.com/2020/03/30/impact-of-dns-over-https-doh-on-dns-rebinding-attacks/ Quote Link to comment Share on other sites More sharing options...
SeriousHoax 83 Posted March 12 Author Share Posted March 12 ESET officials need to have a look at this matter and find the solution ASAP. Quote Link to comment Share on other sites More sharing options...
itman 1,659 Posted March 13 Share Posted March 13 Another interesting observation. Excluding the browser DoH factor, the TLD is not detected by Eset blacklist used by Sucuri: https://sitecheck.sucuri.net/results/crackingpatching.com . Could it be that since the site is using a trusted cert., scanning of it is being ignored? Quote Link to comment Share on other sites More sharing options...
SeriousHoax 83 Posted March 13 Author Share Posted March 13 41 minutes ago, itman said: Another interesting observation. Excluding the browser DoH factor, the TLD is not detected by Eset blacklist used by Sucuri: https://sitecheck.sucuri.net/results/crackingpatching.com . Could it be that since the site is using a trusted cert., scanning of it is being ignored? Only decryption of TLS is ignored for sites using trusted certificate, but blacklisted hosts are/should still be blocked by TLD. Quote Link to comment Share on other sites More sharing options...
itman 1,659 Posted March 13 Share Posted March 13 As far if DoH should be used at all, this article is worth a read: https://flashstart.com/dns-over-https/ . I again reiterate, both Win and browser based DoH are now removed from my PC. Quote Link to comment Share on other sites More sharing options...
itman 1,659 Posted March 14 Share Posted March 14 (edited) Scholarly article on why you don't want to use DoH; Quote To circumvent the protection offered by DoH, an active adversary might try to downgrade DoH to DNS and carry out the known DNS attacks. In fact, this is feasible as the usage profile RFC [35] specifies that a stub resolver can choose Opportunistic Privacy profile, which allows DNS encryption to fall back to plaintext when the encrypted channel cannot be constructed. https://www.usenix.org/system/files/foci20-paper-huang.pdf Edited March 14 by itman Quote Link to comment Share on other sites More sharing options...
COStark26 10 Posted March 14 Share Posted March 14 (edited) PDF Link @itman just provided .... Interesting 5 Browser Vendors Plan NO Changes .... @ itman, Surely you saw this SO, per Below .... Still No DoH in Browsers Or Windows? Low-tech'ers wouldn't likely conclude that - so the clarification helps.... We reported our observations via the vulnerability disclosure systems to the 6 browser vendors, together with our sugges- tions to better manage the threat of downgrade attacks. We have received responses from all of them except Microsoft Edge........ Among the ones replied, none consider a fix is neces- sary in order to prevent DoH from being attacked. According to the reply from Firefox, that DoH is vulnerable under down- grade attacks is an expected feature of Opportunistic Privacy profile. Firefox believes this setting still protects the users against passive adversaries most of the time. Chrome claims that the issue is the “intended, designed, and documented be- havior” of current Chrome DoH. In fact, Chrome uses plain- text DNS until a DoH resolver can be reliably connected and then upgrade all DNS communications to DoH in opportunis- tic mode. The communication falls back to plaintext DNS if any connection issue happens. For other browsers whose DoH implementation is provided entirely by the Chromium browser engine, the responses are similar or expected to be. While given all browsers follow RFC 8310 [35], which has mentioned the possibility of attacks, it is unsurprising that none of the browsers will make a step to address our attacks. However, we are concerned that the user notification is deliberately ignored and none of the browser vendors plan to adopt it even though the integration into browser UI should incur moderate effort and overhead (e.g., using Notification API [28,31]). We believe users should be put into the decision loop, so they can choose to avoid sensitive communications (e.g., visiting a controversial website) in a hostile environment when necessary. Edited March 14 by COStark26 Quote Link to comment Share on other sites More sharing options...
itman 1,659 Posted March 14 Share Posted March 14 The point to note here is if a downgrade from DoH to DNS is occurring, it is being done on the browser server. As such, it is physically impossible for Eset to inspect that DNS traffic. Quote Link to comment Share on other sites More sharing options...
itman 1,659 Posted March 17 Share Posted March 17 (edited) I did more research on this issue yesterday with a number of interesting results. The first find is that Firefox is unique in how it handles DNS over HTTPS; Quote This may be due to Mozilla Firefox's enablement of DNS over HTTPS. This feature is designed to bypass enterprise DNS and security and should not be used in an Enterprise environment. Our Web Protection interception interferes with this lookup. Note: Only Mozilla Firefox is affected by this. Other browsers that may use DNS over HTTPS such as Google Chrome, use the Operating System information for DNS, which we also do. Firefox is the only browser that uses its own DNS configuration. DNS-over-HTTPS at an application level attempts to bypass many security features. As such, we do not recommend having this setting enabled when using Sophos Web Protection. https://support.sophos.com/support/s/article/KB-000043686?language=en_US The next find is how this web site: https://crackingpatching.com/ is bypassing Eset blacklist detection. It yielded how the bypass occurs but not how it is being done w/DoH enabled. Firefox has developer network tools that can be accesses via about:networking. One of these tools is DNS which will log all DNS name servers used by a web site. Access to https://crackingpatching.com/ yielded the same results as shown by Sucuri: https://forum.eset.com/topic/40209-eset-web-protection-doesnt-block-websites-on-firefox/?do=findComment&comment=181351 . Of note is this name server IP address,172.67.219.95. This IP address is also listed as the IP address in the VirusTotal detection: https://www.virustotal.com/gui/url/5583ee6d3fa820c9c851f37746d9b5a896da37bc7ce93329d6dcc02e4b7d9daa/detection . This IP address is not shown as a DNS name server associated with this web site: https://forum.eset.com/topic/40209-eset-web-protection-doesnt-block-websites-on-firefox/?do=findComment&comment=181211 . Finally, a lookup of this IP address shows it is no way associated with https://crackingpatching.com/ ; per Robtex lookup; https://www.robtex.com/ip-lookup/172.67.219.95 -EDIT- I almost missed this. Notice the IP addresses highlighted; Those are the DNS name servers associated with https://crackingpatching.com/ . It really appears that someone has figured out a way to manipulate Cloudflare DNS server connection when DNS over HTTPS is being used. Edited March 17 by itman Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.