One in three organizations hit by DDoS attacks experienced an attack against their DNS server. Why is DNS such an attractive target? What are the challenges associated with keeping it secure? What attack vectors represent the worse of the worst when it comes to DNS assaults? Based on research from Radware’s 2017-2018 Global Application & Network Security Report, this piece answers all those questions and many more.

The Domain Name System (DNS) functions as the Internet’s phone book, mapping human-readable host names into machine-readable IP addresses. Any Internet request performed by a user or a connected device uses DNS. When the DNS service is degraded or stopped, online businesses are disrupted, they lose revenue and their reputation is on the line.

Attackers have developed techniques that exploit both recursive DNS servers (which look for IP addresses  for end users) and authoritative DNS servers (which provide the IP address answer to the recursive DNS server). Service providers typically own and manage their own authoritative and recursive DNS servers. Some enterprises also own and manage authoritative DNS servers. Small to medium enterprises typically offload that responsibility to a managed DNS service.

Recent attacks have shown that assaults targeting the DNS infrastructure can be destructive to the service no matter where the DNS function resides. DNS protection is now mandatory to ensure service availability and normal communication.

[You might also like: DNS and DNS attacks]

DNS Security Challenges

DNS was designed for its core operation with a focus on performance and scalability. In the early days of the internet, security and privacy were not top priorities since they were not as critical as they are today. The result? Inherent characteristics of DNS make it an ongoing security challenge. These characteristics include:

1. Stateless protocol. Because the DNS service must be very fast, it was designed as a stateless protocol. That makes it very attractive to attackers who can easily hide their identity to launch attacks over DNS.

2. No authentication required. The DNS does not have means to authenticate the source of the request or validate the correctness of the response. In other words, DNS has no way to evaluate whether the IP address to which it connects the user or device is “good” or “bad.” Attackers exploit this unprotected infrastructure and design sophisticated attacks using fake queries and/or fake responses.

3. Open access. In most cases, firewalls do not inspect DNS port 53. That gives open access to everyone, including attackers.

4. Amplification effect. A DNS query may result in a large response—sometimes even 10x times larger. Attackers use this design to amplify attacks over DNS and achieve higher attack volumes.

5. Lack of validation. DNS cannot validate a query to ensure it is legitimate. As long as the query name is RFC compliant, the DNS will forward it. Attackers take advantage of this design and use fake DNS queries to launch attacks, such as cache poisoning, tunneling and random subdomain attacks for more information). Most security solutions cannot accurately distinguish between legitimate and fake DNS queries. DNS infrastructure remains vulnerable to an increasing variety of attacks even as carriers and service providers deploy newer security solutions. DNS may be staying the same, but these attacks are becoming highly sophisticated, highly volumetric and increasingly difficult to detect and mitigate.

DNS infrastructure remains vulnerable to an increasing variety of attacks even as carriers and service providers deploy newer security solutions. DNS may be staying the same, but these attacks are becoming highly sophisticated, highly volumetric and increasingly difficult to detect and mitigate.

Key Trends and Recent Attacks

In the past, large DDoS floods—particularly large DNS floods—were typically carried out by amplification and reflection techniques. The recent proliferation of the IoT has empowered attackers to enslave insecure devices to form large IoT botnets. Hackers can leverage these botnets to invest in sophisticated application-layer attacks, specifically in DNS.

One example is the Mirai botnet, which was used in a massive DDoS attack on October 21, 2016.1 Mirai is a multi-vector malware that infects IoT devices (mainly IP cameras) to form a botnet. The common belief is that the Mirai botnet was used to launch a coordinated DNS DDoS attack using a DNS attack vector known as DNS Water Torture. DNS Water Torture is essentially a recursive random-subdomain attack technique that floods a target’s authoritative name servers. This DNS flood caused popular sites to become unreachable for hours despite being up and running normally.

Since Mirai, Radware has observed a surge of new and improved IoT botnets. According to Gartner, by 2020  the number of connected devices will exceed 20 billion.2 This presents as a serious challenge as Internet infrastructure capacity is not growing at the same pace. Consequently, Radware foresees advanced and sophisticated attacks in DNS and other applications and believes we are likely to witness higher volumes as botnets grow in size and reach. These new realities require different thinking when it comes to securing the DNS infrastructure. Protection must be able to withstand high volumes—and detect advanced threats—including zero-day threats.

[You might also like: DNS Reflective Attacks]

Why Current Protections Fail (and What to Do About It)

New specifications were defined in 2005 to address DNS’s lack of security. DNS Security Extensions (DNSSEC3) provides origin authentication, data integrity and authenticated denial of existence. However, the specifications do not address availability or confidentiality. The main goal of DNSSEC was to preclude DNS spoofing or DNS cache poisoning.

DNSSEC adoption remains a long-term challenge and implementation has been slow. According to ISOC4, only about 0.5% of zones in .com are signed. That’s because when compared to DNS, DNSSEC is complex, introduces computation and communication overhead to DNS and requires significant infrastructure changes for organizations.

IT organizations should make DNS infrastructure protection top of mind due to the absence of built-in security mechanisms in the DNS protocol. Specifically, DNS security requires rethinking perimeter security. Many organizations address DNS security by provisioning a DNS firewall and/or competent DNS servers, leaving the perimeter unattended. This approach is insufficient for these reasons:

1. Volumetric DDoS attacks. As demonstrated by Mirai, these attacks threaten the entire infrastructure and can saturate the Internet pipe. Provisioning security solutions inside the network is useless against such threats. A competent perimeter security solution is key to protecting network
2. Risk with stateful devices. DNS firewalls and DNS servers track session state and therefore are unable to withstand and process high-volume attacks that consume all their resources and lead to failure. A stateless perimeter security solution can protect from volumetric floods.
3. Time to mitigation. Stateful DNS firewalls or DNS servers require bi-directional deployments as they track both DNS requests and DNS responses for their operation. They often rely on bad DNS responses for attack detection, which can lead to longer time to mitigation. Bad requests are allowed into the protected servers during this time. In some scenarios, it simply takes too long for bad responses to indicate an attack. That is especially true for a recursive DNS server that is overloaded with bad requests. Ingress-based detection and mitigation by the perimeter security solution prevents bad DNS requested from entering the DNS servers.
4. Detection accuracy and zero day. Any solution must make an accurate distinction in real time between good and bad DNS requests and then permit only the good DNS requests to the protected servers. Achieving high detection accuracy requires use of behavioral algorithms. Such algorithms learn normal traffic patterns and then can detect zero-day threats and mitigate emerging DNS attacks.

Not securing the DNS infrastructure properly is like leaving an open window for cyber criminals—offering them free access to your network and your resources and risking your online business availability. Is DNS always the weakest link in security? It doesn’t have to be if you understand the risks and implement the right protections.

DNS ATTACK HALL OF SHAME

1.  DNS Basic Query Flood 

Using multiple sources of compromised computers (botnets), the attacker generates a distributed volumetric denial-of-service attack that floods the DNS server (see Figure 1). According to the DNS standard, a DNS server processes every request, which then results in an overload of the DNS server. This behavior allows the attacker to successfully compromise the DNS service using a surprisingly small number of botnets. In addition, spoofing the source IP address is easy since DNS is typically carried over UDP. In a basic DNS flood attack, the botnet spoofs the source address and generates a distributed, volumetric flood composed of the same repetitive fully qualified domain name (FQDN) or multiple FQDNs.

2. DNS Recursive Flood

This is a sophisticated DNS-flood attack in which the attacker generates a distributed, volumetric flood toward the DNS servers (see Figure 2). The flood is made of random subdomains of single or multiple target domains. The attacker sends a pre-crafted DNS query to the DNS recursive server that contains a random string prepended to the victim’s domain (for example, xxxyyyy.www.VictimDomain.com). The DNS recursive server will repeatedly attempt to get an answer from the authoritative name server with no success. Sending different false subdomains with the victim’s domain name will eventually increase the DNS recursive server’s CPU utilization until it is no longer available. In addition, the victim’s authoritative DNS server will become overloaded by a flood of false requests.

[You might also like: New Threat Landscape Gives Birth to New Way of Handling Cyber Security]

In some scenarios—including the Mirai botnet—the recursive attack can be distributed via multiple recursive servers such that each server only forwards part of the fake queries without impact on its CPU. In this case, the flood of fake queries only affects the targeted authoritative server.

3. DNS Amplification Reflective Attack

A standard DNS request is smaller than the DNS reply. In a DNS amplification attack, the attacker carefully selects a DNS query that results in a lengthy reply that’s up to 80 times longer than the request (e.g., “ANY”). The attacker sends this query using a botnet to third-party DNS servers to spoof the source IP address with the victim’s IP address (see Figure 3). The third-party DNS servers send their responses to the victim’s IP address. With this attack technique, a relatively small botnet can carry out a volumetric flood of large responses toward the victim to saturate its Internet pipe.

4. DNS Brute Force Attacks

Brute force attacks use scripts or other tools to find all subdomains for a certain domain and expose the organization’s public—and possibly private—network. These attacks are usually precursors to more serious exploitation attempts. The attacker sends legitimate-looking requests and analyzes the responses to discover a known vulnerability or gain access to restricted data. This type of attack is characterized by a higher-than-usual rate of error responses from the server in terms of frequency and quantity. Blocking such attempts helps prevent more severe attacks.

5. DNS Cache Poisoning

DNS cache poisoning tries to forge the response from an authoritative name server to force a recursive server to store forged information in its internal cache. For this reason, the attack is called cache poisoning. Poisoning the cache causes all subsequent queries to be resolved with the forged information. A forged response must meet the following requirements to be accepted by the recursive server:

• The response must be delivered to the recursive server prior to the response of the authoritative server
• The response must have the same original query name
• The response must have the same transaction ID as the original query
• The source address of the forged response must match the target address of the corresponding query
• The destination port and destination address of the forged response must match the source port and source address of the recursive query

Cache poisoning can be the means to achieving other malicious goals, such as malware distribution, website defacing, phishing, stealing private information and DoS. In Figure 50, step #2 demonstrates how attackers poison the cache with a fake DNS entry by sending multiple forged responses to the original query.

RFC 54525 defines measures for making DNS more resilient to cache poisoning. All measures aim at increasing the entropy of queries that recursive servers issue to authoritative servers.