DNS (Domain Name Server) spoofing technology

Overview: What is DNS spoofing?
DNS Spoofing is the art of changing the original IP address of DNS. For better understanding, let's look at an example. If you want to use a browser to search for some information on Google, you can enter the information in the address bar without a doubt.

Www.google.com

And press Enter.
So what is going on behind this? In general, your browser will send a request to the DNS server to request

Www.google.com

If the IP address matches, the DNS server will tell your browser the IP address of Google, and then your browser will connect and display the homepage content. Oh, wait a moment. The webpage you opened says that Google has no money to pay for the website and transferred it

Csite

. You may be surprised and call to tell your friends. Of course, your friends will laugh at you crazy, because your friends can log on to Google and search for it. Are you sure the IP address you are communicating with is friendly? Maybe you have become a sheep in the circle. When you enter http: // 66.249.89.99 in the browser address and press enter, you will find that, in fact

Www.google.com

Still healthy.
In fact, this is what witnesses may see during DNS hijacking.
Quote:
Imagine how bad it would be if the page to jump to is hang silently
Are you eager to know about the xuanjicang? Does the DNS server give us an incorrect IP address? Maybe so. At least, this is the most logical answer in our minds.
Click here to open an image in a new window

In fact, there are two ways to achieve DNS hijacking. Let's take a look at the first "dns id spoofing" technology.
A) DNS high-speed buffer memory Paralysis)
As you can imagine, the DNS server cannot store all existing domain names or IP addresses in its own buckets. This is why the DNS server has a cache, which allows the server to store DNS records for a period of time.
In fact, a DNS server only records authorized hosts in its own domain. if it wants to know other information about hosts outside its own domain, you must send a request to the registrant (another DNS server). In addition, the DNS server records the information returned by the other DNS server in order not to send the request every time.
Now let's take a look at how DNS caches are paralyzed.
Attackers have their own domain (attacker.net) and an attacked DNS server (ns.attacker.net ). Note! I am talking about the attacked DNS server, because the attacker has customized the records of his own DNS server. For example, the record can be

Www.google.com = 81.81.81.81

1) attackers send request queries to your DNS server.

Www.attacker.net
2) your DNS server does not know the IP address of this host. Because it does not belong to its own domain, all your DNS servers will ask the DNS server in the domain of this host.
3) The hacked DNS server will reply to your DNS server, and it will also give all its records (including connections)

Www.google.com

)
Note that this process is called zone transfer.

Click here to open an image in a new window

4) This is because your DNS server has not been paralyzed. The attacker gets his own IP address, but his goal is not to get the address of his network server, but to force the zone transfer to paralyze your DNS server until its cache is not clear or updated.

Click here to open an image in a new window

5) Now, if you ask your DNS server about

Www.google.com

It will tell you 172.50.50.50, which is where the attacker's server is! Now attackers can do whatever they want, such as hanging horses or something ...... Of course, this also caused considerable losses to Google!
B) DNS ID spoofing (DNS ID spoofing)
We can see that when Host X wants to contact host y, it requires a recent IP address. However, in most cases, X only has the y name. In this way, the DNS protocol solves the problem of name-to-IP address.
Therefore, X will ask the DNS server of its domain for the IP address of Y. In the meantime, Host X allocates a random number, which will also appear in the information returned from the DNS server. When x receives a response, X compares the two numbers. If the two numbers are the same, the received information is regarded as valid.
Is such a model safe? Not very secure. Anyone can organize an attack to obtain this ID. For example, if you use LAN, someone else can use the sniffer to capture your request ID, and then forge a reply according to this ID ...... However, the information contains the IP address selected by the attacker. If not identified, X considers the IP address provided by the attacker as Y.
By the way, DNS requests depend on UDP (TCP is used only when zone transfer is used), which means sending a forged packet is extremely simple, because there is no SYN/ack number (unlike TCP, UDP does not provide protection against small IP Spoofing)

Click here to open an image in a new window

Click here to open an image in a new window

However, such attacks are limited. In my above example, an attacker blocks an ID with a sniffer and replies a constructed packet to the victim host.
In other words, even if the attacker intercepts the request, the packets will still be transmitted to the DNS server, the DNS server will also reply (unless the attacker intercepts and blocks requests to the gateway or implements ARP cache paralysis, it will be possible to attack in the conversion network ).
This means that the attacker must reply before the real DNS server, that is, to successfully attack, the attacker must be on the same LAN as the attacker, only in this way can he get a fast ping and capture the packets of the other party.
Example (for test purpose only)
How to hijack our local network connection:
1. paralyze the attacker's ARP cache (the specific tools and instructions can be found in

Http://www.arp-sk.org

On)
2. At this time, the export data packet of the target host will be redirected to your host, but it must be forwarded to the real gateway. We can use a tool similar to WinRoute pro.
3. To implement dns id spoofing, we use the tool developed by valgasu.

Windnsspoof

(Install Winpcap before using this tool. See

Http://winpcap.polito.it

)
Enter a similar command in the command line:
WDS-n

Www.google.com

-I 123.123.123.123-G 00-c0-26-dd-59-cf-V
This command causes

Www.google.com

Point to 123.123.123.123.
Among them, 00-c0-26-dd-59-cf is the MAC address of the gateway or DNS server.
TIPS: in Windows NT kernel, you can use the nbtstat-a xxx. XXX command in cmd to query the MAC address of a remote IP address.
Warning: Remember! Using these methods without authorization is forbidden!
C) Precise attacks based on the birthday paradox
What is the "birthday paradox "?
The "birthday paradox" is named after a mathematical model that produces strange phenomena. If there are 23 people together, it is very likely that two of them have the same birthday. It is not that difficult to understand.
If you ask someone about his birthday at a party, the probability of his birthday being different from yours is 364/365 = 0.997, and the same probability is 1-364/365 = 0.003.
Now, if you ask another person again, his birthday is different from the previous one, and his probability is (364/365) * (363/365) = 0.992, so we can at least push that the probability of two people having the same birthday is 1-0.992 = 0.008.
If we continue with this calculation, we will soon be able to calculate that two of the 23 people have the same probability of birthday as 50%. We can see from the following C code how the probability approaches 1.

Copy code

# Define possibilities 365.0
Void main (void)
{
Float chances;
Int I, J;
For (I = 1; I
If you cannot compile the file, you can view the following results:
People
2
9
16
23
30
37
44
65
79
Chances
0.0027
0.0946
0.2836
0.5073
0.7063
0.8487
0.9329
0.9977
0.9999
If you cannot compile the file, you can view the following results:

Birthday paradox is widely used in hash function Detection: the number of collision tests in a hash table with N-bit length is not 2n, but 2n/2. This conclusion is applied to the birthday attack of cracking cryptographic hash functions.
The theory hidden in the birthday question has been applied in the statistical experiment [Schnabel 1938] named capture-recapture to estimate the number of fishes in the lake.
Okay. Now let's go back to my attack test. In the most common DNS spoofing attacks mentioned above, we are listening to (SNIFFING) the network to get the ID number from X, then, the system replies with the same ID containing only the IP address provided by the attacker.
As I said before, such attacks require sniffing the DNS data generated by X in the network. Does this mean that attackers cannot use sniffer to launch attacks?
How about "Guess" id?
Why not? But the ID number is composed of two bytes, which means there are 65535 possible values! That is to say, if an attacker wants to launch a successful attack, he needs to construct 65535 forged replies with different IDCs. In this way, at least one package is available.
For such attacks, we need a good bandwidth, and most importantly, we do not know when to send forged replies. He must first know that the other party has a request, and then send a reply immediately (before the reply from the DNS server is true.
Let's look at the problem from another perspective. We know that it is possible to directly paralyze the DNS server. Recall that the attacker wanted DNS server to ask for resolution

Www.attacker.net

Thanks to the malicious zone transfer record from ns.attacker.net, attackers can paralyze the DNS server's high-speed cache. It is worth mentioning that the limitation of such attacks is that attackers must run their own DNS servers with malicious records.
In this analysis, If attackers cannot sniff your network data or have no servers, do they mean you are away from DNS hijacking technology?
The answer is, none of them.
As I mentioned earlier, the DNS protocol uses UDP to reply. UDP is not a connection protocol, and there is no process like TCP three-way handshake. Therefore, this makes it very easy to use any IP address you choose to send a UDP packet. So why is it hard for attackers to set up their own DNS servers when they can send fake packets from any DNS server? He can directly ask the victim's DNS server for resolution.

Www.google.com

And then immediately send the packet containing the forged IP address

Www.google.com

.
Well, this is the right time. This is feasible, so the problem is that the victim's DNS server will send a request to ns.google.com to get

Www.google.com

And a request ID. Once again, attackers must send 65535 fake packets containing ns.google.com as the source address of the victim's Domain Name Server. At least one package is consistent. So it may be successful.
The following is the most interesting part ...... If the attacker sends 100 requests to the victim's DNS server for resolution

Www.google.com

What will happen? Then ns.victim.com will send 100 requests to ns.google.com. What if we send 100 forged replies from ns.google.com to ns.victim.com? If you have understood the principles of the birthday paradox just mentioned, you should understand that the probability of collision (guess) has been significantly improved.

Click here to open an image in a new window

Click here to open an image in a new window

In addition, there is a small detail-the source port!
Imagine that ns.victim.com will send a request to ns.google.com, And the UDP header should be like this:

Copy code

Source Address: ns.victim.com
Destination Address: ns.google.com
Source Port: 1256 (choosed randomly and> 1024)
Destination Port: 53 (DNS port)
Data: What is the IP of www.google.com?
Obviously, attackers must use the source port of ns.victim.com as the target port to send forged DNS replies. The package content is like:

Copy code

Source Address: ns.google.com
Destination Address: ns.victim.com
Source Port: 53
Destination Port: 1256
Data: the IP of www.google.com is 81.81.81.81
So how can we guess the source port without sniffing? Unfortunately, for most DNS servers, the source port does not change for each client. Therefore, attackers can simply view the current source port of ns.victim.com. For example, if he has a Domain Name Server, he only needs to request the DNS to find a website name for his domain, the returned query package contains the source port used by ns.victim.com to send DNS requests.
Now that I know how to get the source port, you may be curious about the attack success rate. This is what I want to talk about. Our C Code has also been changed:

Copy code

# Define possibilities 65535.0
Void main (void)
{
Float chances;
Int I, J;
For (I = 0; I
The result is as follows:
Queries
50
100
150
200
250
300
350
400
500
550
650
750
Chances
0.0185
0.0728
0.1569
0.2621
0.3785
0.4961
0.6069
0.7048
0.8517
0.9008
0.9604
0.9865
We can see that the probability of 650 constructed replies is 0.960411 successful, almost 100%!
For more information, read the following articles:

Http://www.kb.cert.org/vuls/id/457875

Http://www.securityfocus.com/guest/17905

D) Summary
In this article, I used

Www.google.com

This is not because I am really interested in the redirection attack. This issue is especially important when you access your bank account, online book purchasing websites, or even webpage emails.
For website administrators, feasible preventive measures include:
Restrict the cache so that no additional records are retained.
Do not use or rely on DNS to build a security system.
Using encryption technologies such as SSL makes it more difficult to be attacked (see man in the middle article)