6 ms·

> 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 wh

by 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 ago
And don't you similarly also need name resolution or a hard-coded IP address in order to reach a malicious DoH server?
- zrm 6y ago
  It'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 ago
    That'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 ago
      The 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 ago
        I 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 ago
        The 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.
        shawnz 6y ago
        Yes, and I am saying the default should be to use a guaranteed source of truth and not something set by the network operator's policy. Same as how your trusted root CA certificates don't come from a network policy for example. I don't think we should be making a convention of inspecting users' private traffic, regardless of whether it is by default or by opt-in, under the guise of protecting them from malware. DNS has historically been set by network policy so that it's easy for network operators to map hostnames to their local network resources. The point of the design wasn't to enable traffic monitoring or content blocking by altering the results for hosts that aren't under your control.
        zrm 6y ago
        The problem is "guaranteed source of truth" doesn't exist. When the network operator is you, or your family/company, you may trust the local DNS to respect your privacy more than you do Cloudflare. Not all names are intended to resolve the same everywhere -- sometimes the local DNS will give the RFC1918 address for a local server instead of the public one, or have a set of local names that are only accessible on the local network. How do you propose to globally resolve the reverse lookup zones for 10.0.0.0/8 et al?
        6y ago
      - josephcsible 6y ago
        That's not an issue with overriding the system DNS. It's the point of overriding the system DNS. Content blocking by anyone but the user is a bad thing, and if you the user want it, then install uBlock Origin or something.
akerl_ 6y ago
GitHub, PyPi, NPM, etc are all great options for hosting dynamic content from a fixed location which looks benign to scanning. For non-tech companies, replace with any relatively popular wiki. The goal is “make a connection over HTTPS or other normal-looking protocol, to a destination that is both justifiability relevant for normal user traffic and allows the attacker to seed the next-step”. And it turns out there are lots of sites that fit that bill.
- lmm 6y ago
  > GitHub, PyPi, NPM, etc are all great options for hosting dynamic content from a fixed location which looks benign to scanning. They're not going to leave malware payloads sitting there. Pastebins etc. get abused as malware command-and-control systems all the time, and of course some gets through, but countermeasures happen. Whereas for a DoH server it would be operating as designed.
  - shawnz 6y ago
    Domains can be seized too, nothing is foolproof.
  - bilkow 6y ago
    > They're not going to leave malware payloads sitting there. They do though, I usually check where spam emails lead me to as a curiosity, and the payload is sometimes hosted on github. A simple GET request to https://github.com/adkafdjsh20/cool_repo/blob/master/dns.txt https://github.com/adkafdjsh20/cool_repo/blob/master/dns.txt would work for DNS purposes. Also, there are countermeasures for malware domains themselves, as you can report them to registrars.
  - akerl_ 6y ago
    As a parallel reply noted, the goal isn’t to host a payload on GitHub or a pastebin. The issue is “how do I tell my bootstrapper where to get a payload from in an inconspicuous way”. To solve that, you find a benign site with existing business purpose (like GitHub or a wiki or a pastebin), and you insert your desired IP address. So maybe you add it as new file in a repo under your cool new fake GitHub account, and the file just says “1.2.3.4”. Now you can tell your bootstrapper to make an HTTPS request for that file, which looks boring to any introspection because outbound requests to GitHub are normal, and to use the resulting IP to request the payload. Your compromised payload host gets shut down? Spin up a new one, and update the file on GitHub with the new IP.

by zrm 6y ago

shawnz 6y ago

And don't you similarly also need name resolution or a hard-coded IP address in order to reach a malicious DoH server?

zrm 6y ago
It'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 ago
  That'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 ago
    The 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 ago
      I 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 ago
        The 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.
        shawnz 6y ago
        Yes, and I am saying the default should be to use a guaranteed source of truth and not something set by the network operator's policy. Same as how your trusted root CA certificates don't come from a network policy for example. I don't think we should be making a convention of inspecting users' private traffic, regardless of whether it is by default or by opt-in, under the guise of protecting them from malware. DNS has historically been set by network policy so that it's easy for network operators to map hostnames to their local network resources. The point of the design wasn't to enable traffic monitoring or content blocking by altering the results for hosts that aren't under your control.
        zrm 6y ago
        The problem is "guaranteed source of truth" doesn't exist. When the network operator is you, or your family/company, you may trust the local DNS to respect your privacy more than you do Cloudflare. Not all names are intended to resolve the same everywhere -- sometimes the local DNS will give the RFC1918 address for a local server instead of the public one, or have a set of local names that are only accessible on the local network. How do you propose to globally resolve the reverse lookup zones for 10.0.0.0/8 et al?
        6y ago
    - josephcsible 6y ago
      That's not an issue with overriding the system DNS. It's the point of overriding the system DNS. Content blocking by anyone but the user is a bad thing, and if you the user want it, then install uBlock Origin or something.

akerl_ 6y ago

GitHub, PyPi, NPM, etc are all great options for hosting dynamic content from a fixed location which looks benign to scanning. For non-tech companies, replace with any relatively popular wiki. The goal is “make a connection over HTTPS or other normal-looking protocol, to a destination that is both justifiability relevant for normal user traffic and allows the attacker to seed the next-step”. And it turns out there are lots of sites that fit that bill.

lmm 6y ago
> GitHub, PyPi, NPM, etc are all great options for hosting dynamic content from a fixed location which looks benign to scanning. They're not going to leave malware payloads sitting there. Pastebins etc. get abused as malware command-and-control systems all the time, and of course some gets through, but countermeasures happen. Whereas for a DoH server it would be operating as designed.
- shawnz 6y ago
  Domains can be seized too, nothing is foolproof.
- bilkow 6y ago
  > They're not going to leave malware payloads sitting there. They do though, I usually check where spam emails lead me to as a curiosity, and the payload is sometimes hosted on github. A simple GET request to https://github.com/adkafdjsh20/cool_repo/blob/master/dns.txt https://github.com/adkafdjsh20/cool_repo/blob/master/dns.txt would work for DNS purposes. Also, there are countermeasures for malware domains themselves, as you can report them to registrars.
- akerl_ 6y ago
  As a parallel reply noted, the goal isn’t to host a payload on GitHub or a pastebin. The issue is “how do I tell my bootstrapper where to get a payload from in an inconspicuous way”. To solve that, you find a benign site with existing business purpose (like GitHub or a wiki or a pastebin), and you insert your desired IP address. So maybe you add it as new file in a repo under your cool new fake GitHub account, and the file just says “1.2.3.4”. Now you can tell your bootstrapper to make an HTTPS request for that file, which looks boring to any introspection because outbound requests to GitHub are normal, and to use the resulting IP to request the payload. Your compromised payload host gets shut down? Spin up a new one, and update the file on GitHub with the new IP.