User:NoName Intern/sandbox

Zone poisoning is a form of a cybersecurity attack, wherein a miscreant takes advantage of a non-secure dynamic updates protocol extension to load fake DNS entries into the zone file of the authoritative server.

DNS
DNS (Domain Name System) is a hierarchical, network-distributed database system that is used to pass information about domain names. It provides Internet users with an additional service for automatic conversion of requests made in a human-friendly text format (e.g., www.example.com) to the digital IP address of the computer (e.g., 192.1.1.1), where the desired resource is located.

The primary components of the DNS are the domain name space, name servers, resource records, and DNS resolvers.

DNS Zone
A DNS zone is a part of the domain name space in the Domain Name System (DNS) for which administrative responsibility has been delegated to a specific organization. It is an administrative space that allows more detailed control of DNS components. It is used to set boundaries within which a server may process incoming requests. Any server that maintains a zone is an authoritative name server for the domain.

Zone files contain authoritative information about zones. A zone file is a text-based file with a format defined in RFC 1035 and 1034. It comprises Resource Records (RRs) and Directives. It is stored on a DNS name server.

Dynamic updates
Dynamic DNS updates are used to add or delete resource records or sets of them from a specified zone without manually editing zone files. The DNS update process is described in RFC 2136.

Zone poisoning attack
A zone can become poisoned if it contains incorrect data. To execute an attack, a malicious user needs to send an RFC-compliant dynamic update request. It can be done by using nsupdate tool. An attacker can either add a new resource record to the zone file or update an existing one. To create a new DNS entry, a dynamic update request with a new sub-domain name and an IP address is sent to an authoritative name server. After receiving the request, the name server creates a new resource record in the requested zone using the address provided in the request. To change an existing resource record, an attacker needs to send two requests: first, to delete the previous record, and second, to provide an IP address and a real sub-domain.

The success of a zone poisoning attack depends on the permission for non-secure dynamic updates. When users send a dynamic update request with invalid data, the corrupted data gets saved in zone files on the authoritative name server. It is at this point that the DNS zone is poisoned. Attempts to use a corrupted sub-domain will be redirected to a malicious host controlled by the attacker. The attack will remain active until the deletion of the resource record in the poisoned zone.

After updating the DNS record and publishing the zone file, the changes will percolate throughout the Internet. The master DNS server will push updates to slave DNS servers for a chosen domain. Other DNS servers will pull updated information about the domain when they make the next query for the new/changed DNS record. This act will poison the DNS cache of the DNS servers, thereby linking the zone poisoning attack to the DNS cache poisoning.

Variants
To implement the attack, a malicious user only needs to know the name of the vulnerable name server and the name of the zone.

Denial of Service (DoS)
A Denial of Service (DoS) attack is an attempt to cause harm by making a DNS server inaccessible to normal end-users. Attackers can generate a significant amount of DNS update requests, which eventually overload the target system. To perform a distributed DoS (DDoS) attack, the attacker can use a variety of controlled sources.

The goal of an attacker is to stop the operation of a web resource. The attacker can also demand money for stopping the attack. Sometimes, a DDoS attack may be an attempt to discredit or destroy an organisation’s business. This type of attack would be detected fairly quickly as the domain becomes unresponsive.

Before issuing a patch in 2009, the BIND9 server was susceptible to DoS attacks by specially crafted dynamic updates.

DNS hijacking
Another option for poisoning the DNS zone involves redirecting network traffic, emails, and other important network data to a host under the attacker’s control. It requires deletion of an old record and insertion of a new resource record into the DNS zone.

For example, an attacker can request a change of an A record of an existing domain name.

Man-in-the-Middle (MITM)
This attack expands the previous one. After redirecting the traffic to a malicious computer, an attacker can forward the information back to the attacked machine. This improvement makes it more difficult to detect the attack. It is used to capture the traffic between the victim’s server and its clients.

Domain shadowing
The next variant of zone poisoning leads to the creation of illegitimate sub-domains for malicious purposes. The new sub-domain uses the reputation of the root domain to trick the unsuspected users.

An attacker can use the new sub-domains in the following ways:

This attack involves the insertion of a record with a name for the new sub-domain.
 * hosting phishing pages;
 * distribution of malware;
 * redirecting the users to another criminal resource.

Compromising Domain Control Validation (DCV)
To issue an SSL certificate, the CA must verify that the requester has the authority to use the domain. This procedure is known as Domain Control Validation or DCV. It prevents anyone but the owner from gaining access to the domain’s security settings.

There are different methods for performing DCV:


 * email validation (traditional);
 * HTTP-based DCV;
 * file validation;
 * DNS Record validation (CNAME, TXT, etc.).

Spoofing the corresponding DNS records will bypass the domain control check. The attack only requires a temporary change in the zone files when requesting a certificate.

Prevention and mitigation
To prevent zone poisoning attacks, DNS server administrator should use secure dynamic updates or similar security mechanisms.

Secure dynamic updates were first described in RFC 2137. This method coincides with the DNSSEC method for securing queries. The standard outlined how to use DNSSEC digital signatures to secure DNS updates and restrict access to those with the corresponding cryptographic keys. RFC 3007 proposed a more flexible solution to secure update requests and obsoleted this method. Keep in mind that DNSSEC was not created to secure dynamic updates. However, most DNS servers have implemented DNSSEC in such a way that it prevents zone poisoning attacks.

Another prevention technique that DNS servers implement is Access Control Lists (ACLs). This solution limits the access to dynamic updates based on the IP addresses of the requesting machines. As dynamic updates are UDP-based, it is easy to forge the source address of the update packet. Thus, this method is insecure by design.

For secure client authentication, it is recommended to implement TSIG technology, which uses a shared secret key with a one-way hash algorithm. The disadvantage of this method is that the key must be distributed to each host which will make updates and the server.

DNS servers
The table below shows the authoritative DNS server solutions and their features related to DNS dynamic updates.

Dynamic updates
Servers that support dynamic updates allow updates for the zone initiated by another computer. See above.

Non-secure dynamic updates
Servers with this feature can be configured so that unauthenticated users can send dynamic updates to the DNS zone.

Update Access Control List (ACL)
User-defined list, see above. Servers with this feature provide control over which clients are permitted dynamic updates.

ACL default settings
The default settings for enabled ACL.

TSIG
Security mechanism, see above. Servers with this feature support TSIG signed dynamic updates.