The principle and implementation of DNS ID spoofing under Windows

Domain Name System (DNS) is a distributed database for TCP/IP applications that provides conversion information between host names and IP addresses. Typically, network users communicate through the UDP protocol and the DNS server, while the server listens on a specific 53 port and returns the relevant information required by the user.

A Related data structure of DNS protocol

DNS datagram:

typedef struct dns
{
　 unsigned short id；
　 //标识，通过它客户端可以将DNS的请求与应答相匹配；
　 unsigned short flags；
　 //标志：[QR | opcode | AA| TC| RD| RA | zero | rcode ]
　 unsigned short quests；
　 //问题数目；
　 unsigned short answers；
　 //资源记录数目；
　 unsigned short author；
　 //授权资源记录数目；
　 unsigned short addition；
　 //额外资源记录数目；
}DNS,*PDNS；

In the 16-bit logo: QR bit is the query/response message, opcode difference query type, AA judge whether the answer to the authorization, TC judge whether can be truncated, RD judge whether the expected recursive query, RA judge whether is available recursion, zero must be 0,rcode for return code field.

DNS Query datagram:

typedef struct query
{
　 unsinged char　*name；
　 //查询的域名,这是一个大小在0到63之间的字符串；
　 unsigned short type；
　 //查询类型，大约有20个不同的类型
　 unsigned short classes；
　 //查询类,通常是A类既查询IP地址。
}QUERY,*PQUERY；

DNS Response Datagram:
typedef struct response
{
　 unsigned short name；
　 //查询的域名
　 unsigned short type；
　 //查询类型
　 unsigned short classes；
　 //类型码
　 unsigned int　 ttl；
　 //生存时间
　 unsigned short length；
　 //资源数据长度
　 unsigned int　 addr；
　 //资源数据
}RESPONSE,*PRESPONSE；

Two The principle of DNS ID spoofing under Windows

We can see that the IDs (identities) in the DNS data header are used to match the response and request datagrams. Now, let's take a look at the entire process of domain name resolution. The client first sends a domain name Query datagram to the DNS server with a specific identity and sends a domain name response datagram to the client after the DNS server query with the same ID number. The client then compares the ID of the received DNS response datagram with the query datagram ID it sends, and if the match indicates that it is the one that was waiting for it, it is discarded if it does not match.

If we can disguise the DNS server in advance to send a response datagram to the client, then the client's DNS cache in the domain name corresponding to the IP is our custom IP, and the client is also taken to the site we want. There's only one condition, and that's the ID that we send the DSN response datagram arrives at the client before the response datagram sent by the DNS server. The following figure clearly shows the process of DNS ID spoofing:

Client ＜--response--| . . . . . .. . . . . . . . . . DNS Server
　　　　　　　　　　 |＜--[a.b.c == 112.112.112.112]-- Your Computer

Here, I think we all know the nature of DNS ID spoofing, then how to achieve it? There are two kinds of situations:

1. The local host and the DNS server, the local host and the client host are not in the same LAN, there are several methods: send a large number of DNS response datagrams randomly to the client host, the hit rate is very low; a denial of service attack to the DNS server is too rude; bind vulnerability, narrow use scope.

2. The local host is at least in the same LAN as the DNS server or one of the client hosts: We can use ARP spoofing to achieve reliable and stable DNS ID spoofing, which we will discuss in detail below.
First of all, the basis of our DNS ID spoofing is ARP spoofing, which is to spoof both the gateway and the client host in the local area network (it can also be spoofed gateways and DNS servers, or spoofing DNS servers and client hosts). We send the ARP response datagram to the gateway in the name of the client, but the source MAC address is changed to the MAC address of our own host, and the ARP response datagram is sent to the client host in the name of the gateway, and the MAC address of our own host is changed to the source MAC address. In this way, the gateway appears that the client's MAC address is our host's MAC address, the client also thinks the Gateway MAC address is our host's MAC address. Since the transmission of datagrams in the LAN is based on the MAC address, the data flow between the gateway and the client must first pass through the local host.

In monitoring the data between the gateway and the client host, if a DNS query datagram sent by the client is found (the destination port is 53), we can send our own constructed DNS response datagram to the client in advance. Note that we must extract the ID information of the DNS query datagram sent by the client because it is used by the client to match the authentication, which is a DNS vulnerability we can exploit. This way the client will receive our DNS response datagram and visit our customized website, although the client will receive the response message from the DNS server, but it is too late, haha.