3

I am working on creating a fake DNS response for my homework.

I am able to successfully send the spoofed response before the actual response of the DNS server (verified by packet capture)

Packet capture of DNS responses:

=======================================================================
MY FAKE DNS RESPONSE
--------------------
Wed Apr 20 22:04:25 2016    Ether-type: IP (0x0800) 
Source MAC Address:  00:0c:29:b6:95:c8  Destination MAC Address: 00:0c:29:0f:e9:96
Source IP Address: 192.168.88.132   Destination IP Address: 192.168.88.131 
UDP packet  Source Port: 53     Destn Port: 37837   UDP Length = 46
============
UDP PAYLOAD:
============
2d  97  81  80  00  01  00  01  00  00  00  00  02  69  6e      -............in
05  79  61  68  6f  6f  03  63  6f  6d  00  00  01  00  01      .yahoo.com.....
c0  0c  00  01  00  01  00  00  02  58  00  04  9b  21  11      .........X...!.
44      D........X...!.


=======================================================================
ACTUAL DNS RESPONSE
-------------------
Wed Apr 20 22:04:25 2016    Ether-type: IP (0x0800) 
Source MAC Address:  00:50:56:e9:cd:36  Destination MAC Address:  00:0c:29:0f:e9:96
Source IP Address: 192.168.88.2     Destination IP Address: 192.168.88.131 
UDP packet  Source Port: 53     Destn Port: 37837   UDP Length = 89
============
UDP PAYLOAD:
============
2d  97  81  80  00  01  00  03  00  00  00  00  02  69  6e      -............in
05  79  61  68  6f  6f  03  63  6f  6d  00  00  01  00  01      .yahoo.com.....
c0  0c  00  05  00  01  00  00  00  05  00  0f  06  66  64      .............fd
2d  66  70  32  03  77  67  31  01  62  c0  0f  c0  2a  00      -fp2.wg1.b...*.
01  00  01  00  00  00  05  00  04  62  8b  b7  18  c0  2a      .........b....*
00  01  00  01  00  00  00  05  00  04  62  8b  b4  95      ..........b...*


=======================================================================

As you can see my fake response is arriving before the actual DNS response. But for some reason, the DNS client always accepts the later (genuine) response.

Questions:

  1. Why is my DNS response not accepted by DNS client even when it arrives before the actual one ?
  2. Is it because of erroneous DNS response packet format ?
  3. Is it because the IP address of fake response is different from actual one ?
  4. Are there any DNS client debugs/logs which can help me find out why my response is not accepted by DNS client ?
  5. Any other reason ?

The debug output is from Ubuntu 14.04

I am really stuck with this problem for 3 days and I am not able to figure out the reason. Any help is appreciated :)

Neeraj Dixit
  • 61
  • 1
  • 4
  • Could it be using the real response because that's the one it receives _last_? The client could be working with the latest info. Any chance you could disconnect from the internet or otherwise block the genuine DNS packet and see what happens? And it doesn't sound like there are any DNS caches local to your machine: http://stackoverflow.com/questions/11020027/dns-caching-in-linux – yano Apr 22 '16 at 21:46
  • Thanks yano, but I think that is not possible according to this article: http://serverfault.com/questions/102879/how-do-dns-clients-choose-an-ip-address-when-they-get-multiple-answers – Neeraj Dixit Apr 22 '16 at 22:02

2 Answers2

2

In order for your fake DNS response to work properly, first: the UDP destination port, the DNS transaction ID, and the domain name being requested, must match the client request. I assume you already did this properly.

However, as mentioned by Stian, the DNS response source IP address must match the legitimate DNS server IP address; if not, it is dropped by the client. (AFAIK, the source MAC address does not need to match though.)

In order to set the source IP address by yourself, you need to create a RAW IP socket instead of a UDP socket, and forge a full UDP packet (fake DNS response) using a RAW IP packet. You can find here code snippets to create such a RAW IP socket and forge a UDP packet from RAW (including UDP checksum).

shrike
  • 4,449
  • 2
  • 22
  • 38
0

All socket connections has 4 parameters which identifies them. Source IP, Source Port, Dest IP and Dest Port.

In your example above, the Source IP for fake DNS UDP response is not correct, so the packet will never reach the socket. And if the source IP was correct, the non-matching MAC address might be blocked aswell, since it does not match with the ARP table (rpfilter).

Stian Skjelstad
  • 2,277
  • 1
  • 9
  • 19
  • okkk, so how can I disable this MAC learning and make the fake packet be forwarded to DNS client ? OR will the program work if I spoof the source MAC address as well ? – Neeraj Dixit Apr 22 '16 at 22:02
  • For the MAC filtering, you can find some information here http://www.slashroot.in/linux-kernel-rpfilter-settings-reverse-path-filtering . It can be disabled via the /proc file-system. Please beware that when you perform MAC spoofing aswell, your network switch will get confused, and start to forward the gateway traffic to you, since it sees that the source MAC address has moved to a new port. – Stian Skjelstad Apr 22 '16 at 22:21
  • I assume you want to manipulate the DNS for a program. There are probably some easier approaches. You can simply insert the entries you want to override into your /etc/hosts file, or you can configure /etc/resolv.conf to send all DNS requests to a dns-proxy application you write yourself – Stian Skjelstad Apr 22 '16 at 22:27
  • I just used tcpdump to find out that the spoofed response is not getting UDP checksum... I think that the UDP checksum is optional in the UDP header. Would the UDP header be dropped if there is no checksum ? – Neeraj Dixit Apr 23 '16 at 01:19
  • Save the tcpdump into a pcap file, and load it into wireshark. Wireshark is a great tool to detect faults in packets – Stian Skjelstad Apr 23 '16 at 05:32
  • I captured the trace with tcpdump & checked in wireshark and no checksum errors were seen! 18:00:09.859318 IP (tos 0x0, ttl 64, id 34633, offset 0, flags [DF], proto UDP (17), length 77) 192.168.88.133.domain > 192.168.88.131.16279: [no cksum] 24347 q: A? foo.example.com. 1/0/0 foo.example.com. A 172.24.20.30 (49) This is my spoofed response in tcpdump with no checksum. At the end of trace in tcpdump, I could see 0 packets dropped which means that the packet was not dropped by kernel Is it possible that kernel favours packets with checksum more than ones without checksum ? – Neeraj Dixit Apr 23 '16 at 06:26
  • Are you spoofing the mac aswell, and/or disabled rpfilter? – Stian Skjelstad Apr 23 '16 at 12:32