DNS spoofing technology principle and Security Protection 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 your browser to search for some information on google, you can enter www.google.com in the address bar and press Enter.
 
So what is going on behind this? Generally, your browser will send a request to the DNS server to obtain an IP address that matches www.google.com. the DNS server will tell your browser the IP address of google, then, your browser will connect to and display the homepage content. Oh, wait a moment. The webpage you opened says that google has transferred the message to CSite because it has no money to pay the website fee. 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 www.google.com is still alive.
 
In fact, this is what witnesses may see during DNS hijacking.
 
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.
 
In fact, there are two ways to enable DNS hijacking in a new window. 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) the attacker sends a request to your DNS server to query 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 records connected to www.google.com)
 
Note that this process is called zone transfer.
 
 
 
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.
 
 
 
5) if you ask your DNS server about the IP address of 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)
 
 
 
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. paralyzing the attacker's ARP cache (specific tools and instructions can be found on the http://www.arp-sk.org)
 
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 WinDNSSpoof tool developed by valgasu.
 
(Install Winpcap first before using this tool, see http://winpcap.polito.it)
 
Enter a similar command in the command line:
 
The wds-n www.google.com-I 123.123.123.123-g 00-C0-26-DD-59-CF-v command directs www.google.com of the target host 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.
 
 
 
# 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
 
 
 
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 has been applied to the statistical experiment named capture-recapture in [Schnabel 1938] to crack the birthday attack of cryptographic hash functions, 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 the DNS server to ask for resolution of www.attacker.net. Thanks to the malicious zone transfer record from ns.attacker.net, the attacker could 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 to resolve www.google.com, and then immediately send a packet containing a forged IP address to the Domain Name Server 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 the IP address of www.google.com, and there is a request ID number. 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 ...... What happens if an attacker sends 100 requests to the victim's DNS server to parse www.google.com? 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.
 
 
 
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:
 
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 http://www.520hack.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:
 
 
 
Source address: ns.google.com
 
Destination address: ns.victim.com
 
Source port: 53
 
Destination port: 1256
 
Data: The IP of http://www.bkjia.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:
 
 
 
# 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 use www.google.com as an example, not because I am really interested in its 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.
 
Encryption technologies such as SSL are used, so even if attacked, it will be more difficult.