Is there any way to prevent getaddrinfo from revealing the true IP address of a hostname?

Question

Let's say there is a program that opens up the HOSTS file to make sure that it isn't being rerouted somewhere. (It wants to connect to www.example.com but it makes sure you don't have an entry in the HOSTS file for that).

So instead, you decide to add a DNS entry, so that www.example.com really points to 123.123.1.123. So that works.

But then the program gets smarter and calls getaddrinfo to determine if it's being rerouted to 123.123.1.123. Is there any way to hide this information, or any alternate ways of changing the IP Address of a given hostname?

Is there any way to make the normal IP of www.example.com point to 123.123.1.123?

All I can think of is maybe detours, but I'm wondering if there's a better way. Perhaps there is a way to protect the Windows HOSTS file from being read?

Or is there a way to spoof packets so that it appears that they come from "www.example.com"? (Assume I have total control over the software sending / receiving the packets)

Answer 1

getaddrinfo() looks up for network names resolutions from different sources. Let's simplify and say that it just looks in the HOSTS file first and then in the DNS server then. These are some ways you can try trick your smart program into thinking that "www.example.com" is legitimately 123.123.1.123 (with increasing complexity):

1. Using the HOSTS file. As you've already pointed out, the program can easily check this file, so this doesn't look too promising. Protecting the HOSTS file from being read won't help either, because then you would not be able to use it to resolve the name.

2. Using a local DNS server. Depending on how smart your program may get, this could be not easily done - we are talking about DNS spoofing after all. In the simple case, you could just configure this server to be the authoritative DNS server for the "example.com" zone, but if you want to get really convincing (and we are getting out of the scope of getaddrinfo() here) you may also have to make some changes in the root servers configuration, just to avoid the program to double check with some root server or "com" TLD server (I know that all of this configuration can be done in bind, I don't know about other DNS servers). Even then, the program may argue that it will not trust a local DNS server. Even if you didn't use "127.0.0.1" but your network IP, it may detect that the DNS address is owned by the local machine. So let's get a little bit further.

3. Using a remote DNS server. Little to say here. Just the same you did before, only in an external computer. If the program is not willing to accept a DNS from your own network, or from any private network (e.g. 192.168.1.X), you may have to manage to put it on a public IP. At this point, the program would need to be extraordinarily scrupulous to find a hole in the deception. But suppose it is, and suppose it has hard-coded the IP addresses of the DNS root servers - it would find out that it was a plot all along! One more step, then.

4. Configure the routers in the network according to your trick. We're starting to get extreme here, but, assuming that you have full control of the network, this is the ultimate solution to make that program truly believe that it's in legitimate-land. Just setup the routes so the root DNS IPs are mapped to your DNS server. So that's it. We must be done now, right?

   Right?

   Well, unsurprisingly, some people though that all this was just too easy, so they came up with DNSSEC, which is basically an extension to the protocol that requires the DNS data to be signed with a cryptographic key. And so it boils down to the fact that, if this hellish program knows the public keys of the legitimate DNS servers and requires all the petitions to use DNSSEC, then it may render all your effort to nothing.

5. Steal the DNSSEC signing keys from the DNS root servers. Well, I'm afraid I can't really help you here, but please consider sharing your experiences if you get to this point.