DNS Spoofing tutorial

Source: Internet
Author: User
Tags domain name server dns names dns spoofing

Definition: DNS Spoofing is a spoofing behavior by attackers impersonating domain name servers.

Principle: If you can impersonate a Domain Name Server and set the queried IP address as the attacker's IP address, you can only view the attacker's homepage on the Internet, instead of the website you want to obtain, this is the basic principle of DNS spoofing. In fact, DNS Spoofing does not actually "black out" the website of the other party. Instead, it is a fake name or a scam.

Most of the existing DNS servers on the Internet are set up using bind. The BIND version is mainly earlier than bind 4.9.5 + p1 and BIND 8.2.2-P5. these binds share a common feature, that is, they cache all the results that have been queried. This problem causes the following problems.
1>. DNS Spoofing
Before the DNS Cache expires, if a record already exists in the DNS cache, the DNS server will directly return the record in the cache once the customer queries it.
Here is an example:
A Unix-running Internet host that provides the rlogin service. its IP address is 123.45.67.89. It uses the DNS server (that is,/etc/resolv. the IP address of the DNS server pointed to in conf is 98.76.54.32. A client (IP Address: 38.222.74.2) tries to connect to the rlogin port of the UNIX host, assuming the/etc/hosts of the UNIX host. in the equiv file, DNS names are used to allow access to the target host. Then, the unix host sends a PTR record query to the DNS server whose IP address is 98.76.54.32:
123.45.67.89-> 98.76.54.32 [query]
Nqy: 1 NAN: 0 NNS: 0 sad: 0
QY: 2.74.222.38.in-ADDR. Arpa PTR
The DNS server whose IP address is 98.76.54.32 does not have information about this reverse query domain. After some queries, the DNS server finds 38.222.74.2 and 38.222.74.10 as 74.222.38.in-ADDR. ARPA. so it will send PTR query to 38.222.74.2:

98.76.54.32-> 38.222.74.2 [query]
Nqy: 1 NAN: 0 NNS: 0 sad: 0
QY: 2.74.222.38.in-ADDR. Arpa PTR
Please note that 38.222.74.2 is the IP address of our client, that is, this host is completely in our hands. We can change its DNS record and let it return the results we need:

38.222.74.2-> 98.76.54.32 [Answer]
Nqy: 1 NAN: 2 NNS: 2 NADINE: 2
QY: 2.74.222.38.in-ADDR. Arpa PTR
An: 2.74.222.38.in-ADDR. Arpa PTR trusted.host.com
An: trusted.host.com A 38.222.74.2
NS: 74.222.38.in-ADDR. Arpa NS ns.sventech.com
NS: 74.222.38.in-ADDR. Arpa NS ns1.sventech.com
AD: ns.sventech.com A 38.222.74.2
AD: ns1.sventech.com A 38.222.74.10
When the DNS server of 98.76.54.32 receives this response, it will forward the result to 123.45.67.98, which is the unix host with the rlogin service (which is also our goal ), the DNS server 98.76.54.32 caches the query results.

At this time, the unix host considers the Host Name of the IP address 38.222.74.2 to be trusted.host.com, and then the unix host queries the local/etc/hosts. the equiv file is used to check whether the host is allowed to use the rlogin service. Obviously, our deception has reached.
In a Unix environment, another technique is provided to prevent such spoofing: query the PTR record, query the record of the Host Name returned by PTR, and then compare whether the two IP addresses are the same:
123.45.67.89-> 98.76.54.32 [query]
Nqy: 1 NAN: 0 NNS: 0 sad: 0
QY: trusted.host.com
Unfortunately, the DNS server of 98.76.54.32 does not query this record, but directly returns the information obtained when 2.74.222.38.in-ADDR. Arpa is queried and the information in the cache exists:
98.76.54.32-> 123.45.67.89 [query]
Nqy: 1 NAN: 1 NNS: 2 NADINE: 2
QY: trusted.host.com
An: trusted.host.com A 38.222.74.2
NS: 74.222.38.in-ADDR. Arpa NS ns.sventech.com
NS: 74.222.38.in-ADDR. Arpa NS ns1.sventech.com
AD: ns.sventech.com A 38.222.74.2
AD: ns1.sventech.com A 38.222.74.10
Now the unix host thinks 38.222.74.2 is the real trusted.host.com, and our goal is achieved!
The condition for this IP spoofing is: You must have an authorized DNS server on the Internet, and you can control this server, at least modify the DNS records of this server, we can only cheat.

2>. Denial of Service Attack Denial of Service
In the above example, if we change the record at 38.222.74.2, then issue a 2.74.222.38.in-ADDR. Arpa query to the DNS server at 98.76.54.32, and make the query result as follows:
Because 74.222.38.in-ADDR. Arpa is completely controlled by us, we can easily modify this information for our purpose.
38.222.74.2-> 98.76.54.32 [Answer]
Nqy: 1 NAN: 2 NNS: 2 NADINE: 2
QY: 2.74.222.38.in-ADDR. Arpa PTR
An: 2.74.222.38.in-ADDR. Arpa PTR trusted.host.com
An: www.company.com A 0.0.0.1
NS: 74.222.38.in-ADDR. Arpa NS ns.sventech.com
NS: 74.222.38.in-ADDR. Arpa NS ns1.sventech.com
AD: ns.sventech.com A 38.222.74.2
AD: ns1.sventech.com A 38.222.74.10
In this way, users using the DNS server 98.76.54.32 will not be able to access www.company.com, because this IP address does not exist at all!
3>. Steal the service theft of services
In the preceding example, the query result is changed as follows:
38.222.74.2-> 98.76.54.32 [Answer]
Nqy: 1 NAN: 3 NNS: 2 NADINE: 2
QY: 2.74.222.38.in-ADDR. Arpa PTR
An: 2.74.222.38.in-ADDR. Arpa PTR trusted.host.com
An: www.company.com cname www.competitor.com
An: company.com MX 0 mail.competitor.com
NS: 74.222.38.in-ADDR. Arpa NS ns.sventech.com
NS: 74.222.38.in-ADDR. Arpa NS ns1.sventech.com
AD: ns.sventech.com A 38.222.74.2
AD: ns1.sventech.com A 38.222.74.10

In this way, a user who wants to visit http://www.competitor.com will be taken to another place, even the bamboo of a rival company (think about what it feels like to connect Huawei and Nortel .). in addition, emails sent to company.com will be sent to mail.compertitor.com. (I feel more and more insecure on the Internet! Xxbin ).
4>. Restrictions
There are also some restrictions on these attacks.
First, attackers cannot replace existing records in the cache. for example, if a cname record of www.company.com already exists on the DNS server 98.76.54.32, attackers attempt to replace it with www.competitor.com. however, some records can be accumulated. For example, if a record of www.company.com already exists in the DNS cache, however, attackers have spoofed the DNS server to say that the record of www.company.com is 4.3.2.1, so www.company.com will have two A records, and one of them will be randomly returned during client query. (isn't this loading balance ?)
Second, the DNS server has a cache refresh time problem. If the TTL of www.netbuddy.org is 7200, the DNS server will only cache the information of www.netbuddy.org for 7200 seconds or two hours. if an attacker puts a tll 604800 a record, the record will be saved in the cache for one week. After the default two days, this DNS server will "Distribute" fake records from attackers everywhere.
Below are several common records that can be accumulated and cannot be accumulated:
A can add
NS can add
MX can add
PTR cannot add

Contact Us

The content source of this page is from Internet, which doesn't represent Alibaba Cloud's opinion; products and services mentioned on that page don't have any relationship with Alibaba Cloud. If the content of the page makes you feel confusing, please write us an email, we will handle the problem within 5 days after receiving your email.

If you find any instances of plagiarism from the community, please send an email to: info-contact@alibabacloud.com and provide relevant evidence. A staff member will contact you within 5 working days.

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.