Several security questions about DNS

Several security questions about DNS

Author: demonalex

In the TCP/IP architecture, the most insecure is the data security at the application layer.Program/The remote buffer overflow and Script Injection of the operating system occur at this layer. Do you know how insecure it is ?! Today, I want to talk about the security of the DNS service, a protocol that is closely related to your daily network connections.

Recently, we have summarized four security issues for the DNS service.

1) named service program defects

2) Regional file Leakage

3) DNS Suppression

4) Local DNS File Spoofing

The first and second threats are for DNS servers, and the third and fourth threats are for DNS clients.

The defect of the named service program mainly refers to the fact that the developer of the Service has a type buffer overflow at the application layer during the development stage, which causes the attacker to obtain rootshell or D. o. s causes problems such as service or system errors. For details about the defects, refer to the local CERT website. Working with patches or upgrading the named service program is the best solution to this problem.

The regional file leakage problem occurred a long time ago. The status is that when the client uses a tool like NSLookup to replace the primary query DNS server, the primary server will assume that the client is a local slave DNS server, this allows the client to query the content of the entire DNS region. The following is a typical example (/**/for illustration ):

Bytes ------------------------------------------------------------------------------------------------------

C: \> NSLookup

Default Server: tempdns2.guangzhou.gd.cn

Address: 61.144.56.101

> Set q = All/* Set query to all here */

> Super1.com.cn

Server: tempdns2.guangzhou.gd.cn

Address: 61.144.56.101

Non-Authoritative Answer:

Super1.com.cn

Primary name server = ns.xinnetdns.com/* The Master Domain Name Server address of the domain is obtained here */

Responsible mail ADDR = hostmaster.xinnetdns.com

Serial = 1090836369

Refresh = 3600 (1 hour)

Retry = 1800 (30 mins)

Expire = 604800 (7 days)

Default TTL = 7200 (2 hours)

Super1.com.cn MX preference = 10, mail exchanger = newmail-g1.xinnetdns.com

Super1.com.cn Internet address = 210.51.170.68

Super1.com.cn nameserver = ns.xinnetdns.com

Super1.com.cn nameserver = ns.xinnet.cn

super1.com.cn nameserver = ns.xinnet.cn
super1.com.cn nameserver = Shanghai
newmail-g1.xinnetdns.com Internet address = 210.51.172.171
newmail-g1.xinnetdns.com Internet address = Shanghai

newmail-g1.xinnetdns.com Internet address = 210.51.172.173
newmail-g1.xinnetdns.com Internet address = 210.51.172.174
ns.xinnet.cn Internet address = 202.106.124.195
limit Internet address = 210.51.170.66
server ns.xinnetdns.com/* use the server command to switch to the master query server */
Default Server: ns.xinnetdns.com
address: 210.51.170.66

> Ls super1.com.cn/* query the content of the zone from the master server */

[Ns.xinnetdns.com]

Super1.com.cn. Ns Server = ns.xinnetdns.com

Super1.com.cn. A 210.51.170.68

Super1.com.cn. Ns Server = ns.xinnet.cn

>

Bytes ------------------------------------------------------------------------------------------------------

Check that the content of the zone file (FQDN, DNS record type address) is returned immediately ). However, most DNS servers impose such restrictions to prevent information leakage, such:

Bytes ------------------------------------------------------------------------------------------------------

C: \> NSLookup

Default Server: tempdns2.guangzhou.gd.cn

Address: 61.144.56.101

> Set q = all

> Demonalex.net

Server: tempdns2.guangzhou.gd.cn

Address: 61.144.56.101

Non-Authoritative Answer:

Demonalex.net nameserver = ns1.dns-diy.com

Demonalex.net nameserver = ns2.dns-diy.com

Demonalex.net nameserver = ns2.dns-diy.com

Demonalex.net nameserver = ns1.dns-diy.com

Ns1.dns-diy.com Internet address = 210.51.187.81

Ns2.dns-diy.com Internet address = 218.107.207.123

> Server ns1.dns-diy.com

Default Server: ns1.dns-diy.com

Address: 210.51.187.81

> Ls demonalex.net

Ls: CONNECT: no error

* ** Can't list domain demonalex.net: unspecified error

>

Bytes ------------------------------------------------------------------------------------------------------

Do not underestimate the information obtained from this experiment. Sometimes it can obtain the first-hand audit resource host/distribution information for you. Most of the ways to restrict this type of penetration are solved by "restriction from DNS Server IP Address" and "Communication restriction on encrypted channels.

DNS blocking (DNS blocking oning) is a type of spoofing attach attack. You can use this attack to implement the purpose of spoofing after the ARP cache attack is used. (I will discuss the specific operation method of the ARP suppression + DNS suppression tool "Cain". introduction ). Let's talk about the principle. First, we need to successfully hijack a P2P session through a "man-in-the-middle attack" (ARP cache suppression attack is the best method ), then, an "DNS package modifier" is used to process the DNS query requests of the attacked client, and then a maliciously modified DNS request is returned to the attacked client DNS plug-in, in this way, we can complete a perfect DNS suppression and deception process. The best way to prevent such attacks is to use an encrypted channel or add the "ip address <=> MAC address" binding policy to the Intranet's central data switch.

Local DNS File spoofing is the most popular attack method against clients in recent years. Some people often ask me if a website has been hacked or revised? (Not actually) or ask why script Trojans are often used, and if they are killed again, and so on. If you are sure you are not blocked by DNS, it is very likely that you have been cheated by the local DNS. Local DNS spoofing? Isn't it possible to cheat yourself ?! Let's talk about the principle: in fact, these attacks can only be exploited by attackers to browse a website that joins the script (or other similar methods, such as adding the script to the CHM after compilation ), modify the corresponding value of the local DNS table file hosts (% SystemRoot % \ system32 \ drivers \ etc \ hosts), for example:

By default, hosts only has one record about the "loopback address:

127.0.0.1 localhost

But if we add one

127.0.0.1 www.163.com

To test the effect, save the hosts file, and then under NSLookup:

Bytes ------------------------------------------------------------------------------------------------------

C: \> NSLookup

Default Server: tempdns2.guangzhou.gd.cn

Address: 61.144.56.101

> Www.163.com

Server: tempdns2.guangzhou.gd.cn

Address: 61.144.56.101

Non-Authoritative Answer:

Name: www.163.com

Addresses: 202.108.36.155, 202.108.36.156, 202.108.36.167, 202.108.36.172

202.108.36.196, 202.106.168.103, 202.106.168.104, 202.106.168.109, and 202

. 106.168.121

202.108.36.153

>

Bytes ------------------------------------------------------------------------------------------------------

The DNS test is okay ?! Try to browse the http://www.163.com with IE...

Bytes ------------------------------------------------------------------------------------------------------

C: \> netstat-an | find "TCP"

TCP 0.0.0.0: 80 0.0.0.0: 0 listening

TCP 0.0.0.0: 135 0.0.0.0: 0 listening

TCP 0.0.0.0: 1025 0.0.0.0: 0 listening

TCP 0.0.0.0: 1485 0.0.0.0: 0 listening

TCP 127.0.0.1: 80 127.0.0.1: 1485 established

TCP 127.0.0.1: 1485 127.0.0.1: 80 established

TCP 192.168.1.5: 139 0.0.0.0: 0 listening

Bytes ------------------------------------------------------------------------------------------------------

The results of this experiment tell us that the role level of % SystemRoot % \ system32 \ drivers \ etc \ hosts is higher than that of DNS, therefore, even if your DNS is correct, the hosts file may be attacked if it is maliciously modified. The solution is to set the attribute of the file % SystemRoot % \ system32 \ drivers \ etc \ hosts to "read-only" to prevent most attacks of this type.