5 ms·
> At its most basic, they could hardcode lists of IPs into their malicious code. Which makes the malware more fragile, because the hosts are often compromised
by zrm 6y ago
> At its most basic, they could hardcode lists of IPs into their malicious code.
Which makes the malware more fragile, because the hosts are often compromised machines themselves, or are the targets of takedowns. If they include only one IP at a time (as they can do with DNS) then when that machine gets cleaned by the owners, they have no way to switch to another one. If they list several machines then anyone analyzing the malware has a list of multiple compromised machines to go have them all cleaned at once. Also, then you can add the IP address to a block list and they can't update it like they can with DNS.
> At its most complex, the same building blocks that DoH/DoT use were available to them: they could build similar tools that tunnel over HTTPS/SSH/etc, whichever protocol they felt was least conspicuous on their target system.
Malicious javascript in a browser doesn't have access to SSH or similar. And that's assuming their code can even reach your machine if your Pi-hole is blocking the DNS name of the server hosting it.
> DoH in Firefox simply makes the above issue harder to ignore.
It makes it harder to prevent. Someone sends the user an email link to a URL containing an unpatched browser exploit or a link to a malicious binary. If the Pi-hole blocks the domain and/or the IP address in the email, the attack is prevented. If the browser bypasses the Pi-hole, you have malicious code actually running on the user's machine, and that's a much bigger problem.
- shawnz 6y agoHardcoding the IP certainly has limitations but that is only the easiest example of bypassing DNS-based content blocking. A slightly less trivial solution where you grab the IP out of a file over HTTP instead could be easily implemented by any junior developer. > Also, if they use an IP address then they can't be using SNI to host it on the same IP address as several other domains Sure they can, just hardcode the "Host" header value as well > Malicious javascript in a browser doesn't have access to SSH or similar. They can access HTTP though, which is more than enough.
- zrm 6y ago> A slightly less trivial solution where you grab the IP out of a file over HTTP instead could be easily implemented by any junior developer. Over HTTP from what? You would need name resolution or a hard-coded IP address to make an HTTP request. And the thing this is preventing isn't just what the malware does after you're already infected, it's the path to receiving malware to begin with.
- shawnz 6y agoAnd don't you similarly also need name resolution or a hard-coded IP address in order to reach a malicious DoH server?
- zrm 6y agoIt's not a malicious DoH server. It's just any DoH server which is bypassing your Pi-hole and therefore resolves the malicious name instead of blocking it.
- shawnz 6y agoThat's not the point. Don't you need to hardcode some kind of identifier in order to use your malware's preferred DoH server instead of the user's preferred one (which could have content blocking applied)?
- zrm 6y agoThe issue is with Firefox overriding the system DNS with its own by default, when the system DNS may have content blocking applied and the Firefox default may not.
- shawnz 6y agoI think if the user wants that, they should choose to apply it. Not the network operator. Same as how I wouldn't want my network operator inspecting my HTTPS traffic for malware.
- zrm 6y agoThe user can do whatever they want. It's their machine. But you know perfectly well that almost everybody is going to take the default because they don't even know what the setting does, and end up disabling content blocking when they didn't intend to. And in many cases the user is the network operator. What the browser is doing is taking away the mechanism to set local policy. Ordinarily you hand out the DNS you want your devices to use via DHCP, and they use it. If you move that from the OS to the application and the application ignores the DHCP setting by default, now you've lost the ability to set a uniform policy for all your devices and applications. It becomes an arduous manual process to change the setting in every application on every device, and then you probably miss half of them.