Wifi interface ask the gateway about an address located on a totally different (and private) network

Question

Initially fighting against DNS Leak, for both knowledge and privacy, I end with a computer that asks the FAI box for a local address located outside of its scope (another network)... I've spend hours trying to understand the reasons for that.

What I want is wlan1 to check if IP is in its scope, or (if a hostname is provided) with dnsmasq if hostname exists and, in this case, resolv and tell me it can't proceed. Instead, wlan1 continue the check and ask the FAI box...

Parts of the network:

1. a main computer
2. a eeePC, running my Web developments

3. a FreeBox that gives me access to internet

   • The EEPC is not connected to the FreeBox
   • The main computer is connected to the FreeBox (wlan1)
   • The main computer is connected to the EEPC (eth1)
   • The main computer runs DnsMasq on :53

First I set eth1 to be static auto eth1

iface eth1 inet static
        address 192.168.1.42
        netmask 255.255.255.0
        network 192.168.1.0

Second I removeed, --purged and finally removed manually (because it was not well done) everything that was related to resolvconf package.

Third I've chattr +i /etc/resolv.conf. The file contains :

nameserver localhost
nameserver 84.200.69.80 84.200.70.40

And I've added the strict-order directive to /etc/dnsmasq.conf

Finally I connected to the wifi which is WEP secured :

wlan1     IEEE 802.11bgn  ESSID:"***************"  
          Mode:Managed  Frequency:2.417 GHz  Access Point:   ******   
          Bit Rate=9 Mb/s   Tx-Power=16 dBm   
          Retry short limit:7   RTS thr:off   Fragment thr:off
          Encryption key:**********
          Power Management:off
          Link Quality=40/70  Signal level=-70 dBm  
          Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
          Tx excessive retries:0  Invalid misc:132   Missed beacon:0

Ip of wlan1 is 192.168.0.26 (DhCP obtained);

eeePC has static ip : 192.168.1.2

The main computer see the eePC on the correct interface :

ping -I eth1 eeepc
PING eeepc.dev (192.168.1.2) from 192.168.1.42 eth1: 56(84) bytes of data.
64 bytes from eeepc.dev (192.168.1.2): icmp_seq=1 ttl=64 time=0.554 ms
64 bytes from eeepc.dev (192.168.1.2): icmp_seq=2 ttl=64 time=0.178 ms
64 bytes from eeepc.dev (192.168.1.2): icmp_seq=3 ttl=64 time=0.171 ms
64 bytes from eeepc.dev (192.168.1.2): icmp_seq=4 ttl=64 time=0.158 ms
^C
--- eeepc.dev ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 2997ms

But here is the crazy thing :

ping -I wlan1 192.168.1.2
PING 192.168.1.2 (192.168.1.2) from 192.168.0.26 wlan1: 56(84) bytes of data.
From 192.168.0.254 icmp_seq=1 Destination Host Unreachable
From 192.168.0.254 icmp_seq=2 Destination Host Unreachable
From 192.168.0.254 icmp_seq=3 Destination Host Unreachable
From 192.168.0.254 icmp_seq=4 Destination Host Unreachable
^C
--- 192.168.1.2 ping statistics ---
4 packets transmitted, 0 received, +4 errors, 100% packet loss, time 3002ms

Worst :

ping -I wlan1 eeepc
PING eeepc.dev (192.168.1.2) from 192.168.0.26 wlan1: 56(84) bytes of data.
From Freebox-Server.local (192.168.0.254) icmp_seq=1 Destination Host Unreachable
From Freebox-Server.local (192.168.0.254) icmp_seq=2 Destination Host Unreachable
From Freebox-Server.local (192.168.0.254) icmp_seq=3 Destination Host Unreachable
From Freebox-Server.local (192.168.0.254) icmp_seq=4 Destination Host Unreachable
^C
--- eeepc.dev ping statistics ---
4 packets transmitted, 0 received, +4 errors, 100% packet loss, time 3002ms

The main computer ends to ask the FreeBox to resolv the eeePC. I'm afraid it is a DNS leak. But above all, I feel like there is something I miss completely...

Answer 1

well, I don't agree that your ping output represents a dns leakage, because it is unlikely that ping actually tried to resolve the private IP with your public servers. First note that the .local and .dev addresses were resolved with local resources (hosts file, or a zeroconf lookup interface). There is no evidence that any of your addresses were sent to the public servers. They would never respond with .dev or .local responses.

Beyond that, pinging out the wrong interface isn't something an attacker could actually do to you, because even if they were monitoring the dns server for requests from your network that might provide info on it, they will only get back what they put in, so nothing is discovered. If you don't do ping on the wrong network, then there is no likelihood that ping is exposing information about your LAN to the dns servers.

Last, the issue if there is one, is with ping itself, and there is no way to change its desire to lookup, except to use -n when running it. DNS leaks occur in applications, and if the application can't be configured with network configuration, it can't be easily fixed. In your case, your network layout is designed to prevent this kind of issue by forcing the eeepc to use the main PCs dnsmasq, so anything from the eeepc is hidden, but if you misuse the main pc as you have in this example, you circumvent those protections.

In sum, you have discovered a way to bypass the protections you set up, I don't believe that you actually exposed any info publically in this test, and more than that, aside from the specific scenario you are testing, I don't believe that an attacker could use this method to bypass any protections, unless they already had strong control over the main PC.