Security.com

DNS Security: Defending the Domain Name System

By Syngress and SearchSecurity

The following is an excerpt from DNS Security: Defending the Domain Name System by authors Allan Liska and Geoffrey Stowe and published by Syngress. This section from chapter two explores the importance of DNS security and the common DNS security problems that plague organizations.

Ask any security professional what keeps her awake at night and you will most likely get a response about protecting the organization against phishing attacks. Dive a little deeper and she might express concerns about security challenges with BYOD (bring your own device) or worry over some of the web applications that network users have access to, or that run on the organization's web site. After a few beers she might express concern about the fact that there are more alerts than she can keep up with, or that she does not have a clear picture of everything that is happening on the network.

It is very rare that a discussion about security issues reaches the point where DNS comes up as a topic. That seems like an odd statement to make in a book about DNS security, but it tends to be true. Unless there has been a recent breach in the news involving DNS, generally DNS does not come up as a topic.

DNS is also one of the most outsourced services. Many organizations recognize that they do not have DNS expertise in-house so let their domain registrar or another third party manage the organization's and only run recursive DNS services internally (though, often even that is outsourced to the ISP providing connectivity to the organization). With little or no control of the DNS infrastructure residing within the organization it is easy to see how DNS can become an afterthought in security plans.

But, DNS security needs to be at the forefront of every discussion about network security. DNS attacks are more common than most people realize and failures in DNS security can be crippling to an organization. How much money does an organization lose every hour that it is unreachable via email? How about when a fully functioning web site is invisible to the Internet, or worse visitors to a web site are redirected to a malicious web site? A 2014 study done by Vanson Bourne found that 75% of organizations in the United States and the United Kingdom had been impacted by a DNS attack and 49% had uncovered some sort of DNS-based attack in the previous 12 months. So, DNS attacks are prevalent, but they are not necessarily getting the attention they deserve.

DNS falls into a category of "utility protocols" that underpin communications on the Internet. These are robust protocols that help keep traffic flowing and servers talking and that most users do not know exist. Protocols like the Border Gateway Protocol, Network Time Protocol, and of course DNS are critical to keeping the Internet up and running, but generally fall well outside the purview of security teams. The administrators who do configure and manage the systems that run these protocols do not usually think about the security concerns inherent in these protocols.

This lack of security insight combined with the relative obscurity of these protocols makes them ripe for potential exploitation and hackers have figured that out. The result of this perceived utility is that within the black hat community there has been a sizeable increase in exploitation and vulnerability research in these protocols. There has also been a lot of research done by the security community into ways to better protect these protocols. Unfortunately, there is a big gap between the work done by researchers and the people who handle the day-to-day administration of these protocols.

A prime example of this is with DNSSEC (discussed in detail in Chapter 10). RFC 3833, which a way to better secure DNS infrastructure, was released in 2004. Even in 2016 very few domain names have added DNSSEC signing to their file and many domain registrars still do not support it.

In the end DNS security is important because a failure in DNS can render an organization completely unreachable and because attackers are actively looking for ways to exploit the DNS protocol and the DNS infrastructure itself. Understanding key issues in DNS security is critical to maintaining a strong security posture within an organization.

COMMON DNS SECURITY PROBLEMS

Before a security team can effectively protect an organization's DNS infrastructure they must determine what the risks to its DNS infrastructure are. When performing a risk assessment of a DNS infrastructure it is important to take a very broad view of what constitutes a security risk. The goal of a DNS security is to make sure the DNS infrastructure is available as much as possible and that the proper information is propagated to machines making queries.

Based on the definition above, anything that impacts availability or causes faulty data to be disseminated could be considered a security breach. Some would consider this definition problematic because it expands the definition of security beyond its traditional meaning. However, given the importance of DNS to an organization an expanded definition of security is reasonable and, arguably, essential.

One of the reasons an expanded definition of DNS security is essential is that there are so many points of security failure within a DNS framework. In addition to failures traditionally associated with data security such as hardware failure, unauthorized server access, and DDoS attacks, there are also registrar administrative issues, sleazy marketing, and other types of security breaches unique to DNS. The distributed nature of DNS automatically requires a different set of security concerns and adds a layer of complexity to security plans.

Here is an all-too-common example of the unique problems facing anyone attempting to secure a DNS infrastructure: It is Monday, everyone stumbles into the office and realizes that they cannot check mail, the corporate web site is also unreachable. Internet connectivity is fine, and people are able to send mail and access other web sites. The DNS administrator is asked (usually frantically) to fix the DNS problem. But the DNS servers are working fine. Both the primary and secondary servers are responding as expected, data has not been changed and there is no sign of unauthorized access.

The DNS administrator spends all morning attempting to determine the problem. She checks and rechecks system settings, verifies that DNS information has not been altered with the registrar searches various DNS web sites all to no avail. Finally, she posts a description of the problem to a DNS-related mailing list. Within a few minutes someone replies with output of whois data and points out that the domain name has expired. Shaking her head in disbelief the administrator contacts the accounting department to find out if they received a from the registrar and if they did, had the been paid? The accounting department says that the was never received. Further investigation shows that the billing point of contact that the registrar has on file left the company 8 months ago, so the renewal notice was sent to a nonexistent email account and the domain registrar does not have an effective method to deal with bounced emails.

The example above, while somewhat exaggerated is not too far from the truth. Many a large company has been crippled because someone in the accounting department did not pay the registrar bill on time. The example above also does not advise on the possibility that someone is waiting to squat on the domain is a payment is missed and registration expires. Image the embarrassment a company would have to go through if their domain was purchased out from underneath their noses. Ensuring that bills are paid on time would not normally qualify as a security issue, but in this case it certainly could be considered an aspect of availability: If an organization does not make sure the registrar is paid in a timely fashion the domain can be removed from the root servers and no one will be able to access the domain.

Even after the bill has been paid and the registrar has reinstated the domain, it can take up to 48 hours before the domain is again available to the Internet. In other words, this type of mistake can result in an outage that lasts several days - and there is not anything that can be done to speed up the process. This is why it is important to consider all aspects of availability when developing a DNS security .

Taking a broad view of security, a DNS security event is anything that impacts the availability of the DNS service, whether that is an internal or an external event. An internal event is one that is caused by an employee or a contractor of the organization, regardless of whether or not the event is accidental or intentional.

This is important to remember: a security breach does not necessarily have to be intentional. An administrator who enters an incorrect IP Address or accidentally deletes an important file has still created a security situation. These type of events need to planned for with as much concern as hostile events.

Internal nonhostile events can include a mistaken entry in a file, misconfigured ACLs, firewall rules which prevent access to DNS or grant more access than desired, deleting files, and of course not renewing a domain name in a timely fashion.

Internal events can also be hostile. A disgruntled employee might redirect the organization's web site, might attempt to disrupt mail service by removing entries, may change domain contact information so he is listed as the authority over the domain, or may remove a file completely, wreaking havoc within the network. Each of these problems can be prevented if the right checks are put in place. Again, once potential attack vectors are known it is easier to prepare for them, and in the case of internal attacks implementing stronger DNS processes goes a long way toward limiting the problem.

DNS Security: Defending the Domain Name System

Authors: Allan Liska and Geoffrey Stowe

Learn more about DNS Security from publisher Syngress

At checkout, use discount code PBTY25 for 25% off this and other Elsevier titles

External security breaches are another matter; it is very rare that an external breach will be accidental. Most external attacks against DNS servers are either an instance where an organization is specifically targeted or they are random. A random attack occurs when an attacker is scanning a range of IP Addresses and encounters a DNS server with a known vulnerability. The attacker will launch an attack against that server and attempt to gain access not because the attacker has a particular grudge against the organization, but simply because it is possible. Note, an attack can be targeted and still have collateral damage. For example, in 2012 a hacker going by the name AnonymousOwn3r launched a DDoS attack against Domain Registrar. The DDoS attack not only rendered GoDaddy's web site unreachable it also impacted the ability of GoDaddy's authoritative DNS servers to respond to queries. Degrading the service of GoDaddy's customers - who were not the intended target.

Random attacks are relatively easy to defend against. Most script kiddies do not have the depth of knowledge required to launch a serious attack against a well-protected DNS infrastructure, so they will generally bypass those and focus on DNS infrastructures with weaker security measures in place. In many ways it is the same as car thieves. Someone just looking for a joyride will focus on the easiest car to grab - one that is unlocked or with a weak alarm system. On the other hand, a skilled car thief has a greater knowledge of cars and will know how to defeat the security precautions of the car he wants.

A script kiddie is a lot like a joyriding car thief. Of course as anyone who has had his or her car stolen knows, even a novice car thief can inflict a great deal of damage - especially if it is your car stolen. Likewise, just because a script kiddie is not sophisticated technically does not make the damage inflicted any less painful.

It is important to do everything possible to keep a DNS infrastructure safe from common script kiddie attacks. At the same time DNS administrators must remain watchful for more skilled attackers.

A skilled attacker is more likely to target a specific organization for attack. The attacker may have a grudge against a company, hope to gain access to sensitive data for personal gain, or even be paid by a rival organization.

Two important qualities that good DNS administrators share are vigilance and paranoia; actually, all security administrators share those qualities. As the saying goes, "Just because you are paranoid doesn't mean they are not out to get you." Initially, it is often difficult to distinguish between an attack launched by a skilled attacker and one launched by a novice, an experienced administrator will be able to quickly determine the difference and act appropriately.

A targeted DNS attack can take many forms, depending on the intention of the attacker. If the intention of the attacker is to redirect DNS services away from an organization, then the attacker may not even target that organization's DNS servers directly. In fact, if an attacker wants to take over a domain - also known as domain hijacking a direct attack against an organization's DNS servers is often the last resort.

A domain hijacker will take advantage of weak DNS security practices within an organization or that organization's registrar to assume ownership of a domain name. Generally, this involves some sort of social engineering. Social engineering is a form of attack that involves manipulating people rather than data. An attacker will take advantage of the willingness of people to share information, even if that information is sensitive.

There are several types of domain hijacking scenarios, and again, these scenarios may not even involve dealing directly with the organization whose domain the hijacker is trying to take over. One way to do hijack a domain is to look for one that was registered using a now-defunct mailing address from a free-mail account. The hijacker reactivates the defunct address and uses it to change the password and contact information for domain. In effect, the hijacker assumes ownership of the domain.

A second type of hijacking revolves around getting information from the domain registrar directly, and this is where social engineering really comes into play. A hijacker calls up a registrar and claims to be the administrator for a domain. The hijacker presents the registrar with a plausible crisis. Perhaps she explains that the company that is hosting her organization's mail servers has abruptly shut down, leaving them without access to their mail. She has signed up with a company, but she needs to update her domain information and she cannot remember her password to the registrar's control panel.

She would use the password-reset option, but obviously, with her mail unavailable, she will not receive the password. This is a real problem, and the president of the company is calling her every 5 minutes demanding to know what the status is and even threatening to fire her. Is not there any way the registrar can reset the password over the phone - she will happily fax over a signed request on company letterhead?

At this point many support people will acquiesce and change the password "this one time," over the phone. If the hijacker does encounter resistance at this level, she will escalate it to a manager, sounding increasingly upset. Eventually, she finds someone who is willing to allow her to change the password over the phone and now she has full control over the domain without having to touch the target network.

This ploy does not always work, but remember that the primary role of the customer service person is to help people; therefore, they are naturally inclined to aid a customer in trouble. A registrar that takes security seriously would have other methods of verifying the person's identity. It is important to remember that registrars, like most service companies, depend on happy customers for repeat and business. If the person on the other end of the phone is really a distraught customer not changing the password may result in a loss of business.

Social engineering attacks are often the most difficult to defend against, especially when an organization has to rely on a vendor to maintain the same level of security. But even within an organization not all staff members will have the same level of urgency when it comes to security, and even the best security plans are useless if people within the organization do not adhere to it.

Other types of attacks involve more traditional, computer-based, methods of aggression. These attacks generally serve to overwhelm a server making it unreachable from the network, exploit weaknesses in the DNS daemon to gain access to the server, or redirect traffic from its intended destination to a server owned by the attacker.

The type of attack, overwhelming a server with requests making it impossible to serve legitimate requests, is what is commonly referred to as a DoS attack. The requests can be requests for DNS information, but they can also be ICMP requests, or even another service that is housed on the server.

Because DNS uses the UDP as its primary method of communication, it is especially susceptible to attacks. Unlike a Tranmission Control Protocol (TCP) packet, a UDP packet does not require a handshake to ensure that there is good communication between the two hosts. This makes UDP-based protocols especially susceptible to attack, because it is relatively trivial for an attacker to forge UDP packets. More importantly, it is trivial for an attacker to forge hundreds, thousands, or even hundreds of thousands of packets. Forged packets are sent to the target DNS server, they look like legitimate requests, so the DNS server responds to all of them, filling up all available UDP sockets and preventing the server from responding to legitimate requests.

An Internet Control Message Protocol (ICMP) DDoS attack uses the same methodology. An attacker targets a server, but instead of launching DNS packets against the server, he uses ICMP packets. These packets can all be launched from a single server or from multiple servers. Either way, the goal is the same, overwhelm the DNS server and make it unresponsive to valid requests from other hosts.

If a DNS server has other services running on it then focusing on those other services is also an option. It does not matter what service is targeted, the important thing is to use up all of the available connections on the remote server and make it unresponsive.

A second type of attack is one that takes advantage of a weakness in either the DNS daemon or other software running on the server. The attacker exploits the weakness to gain administrative access to the server, once on the server the attacker can either attempt to make further inroads into the network or redirect DNS requests from users on the network to a rogue server controlled by the attacker.

An administrative compromise on a critical server, such as DNS servers, can be especially insidious because it allows an attacker to control parts of the network and redirect traffic away from its intended destination. Security precautions taken throughout the rest of the network become irrelevant, because the attacker has access to everything.

Attacks involving administrative compromise can sometimes go undetected for months. If an attacker is careful to cover her tracks properly and the server is poorly secured or monitored, then there is a good chance no one will notice there is a problem. At least not until long after it is too late.

Read an excerpt

Download the PDF of chapter two in full to learn more!

A third type of attack is not as common as it used to be, but it is still one that can occur and therefore should be protected against. An attacker will load bogus information about a popular domain into a transfer, tricking recursive servers into redirecting queries to the wrong location.

For example, an attacker may own the domain foo.com. When DNS servers request information about foo.com, the attacker's server will also send bad data for www.amazon.com. The information is embedded within the legitimate request, so the receiving DNS server just accepts the data and shares it with users.

Note that the attacker's DNS server does not send a full transfer for the targeted domain, instead it generally sends a single record, most often an A record. The idea is to redirect traffic to a server owned by the attacker. So, the attacker would set up a web site that mirrored the one at www.amazon.com, send the bad data along with requests for foo.com. Compromised DNS servers would direct users toward the attacker's site and the attacker would be able to gather credit card numbers and account information from users who visit the bogus web site. Because the site would be a mirror of Amazon's web site, users would not know what happened at , potentially giving the attacker a few weeks to exploit the gathered data.

exploits against popular DNS daemons are constantly being discovered and reported. In addition to the exploits, tools are released all the time that automate the process of exploiting security holes in DNS software. The confluence of these two trends creates a difficult situation for DNS administrators. Just about anyone with a computer and the ability to decompress a program can launch an attack against a poorly protected, or updated, DNS server. Because launching an elementary attack against a DNS server is so easy, the need for a strong DNS security policy is critical to any security .

In addition to a strong security policy, or more appropriately included as part of a strong security policy, it is important to be aware of the latest DNS exploits and understand how they impact an organization's DNS infrastructure. It is not enough to be aware of the exploit; DNS administrators must understand how the exploit works, and what it does.

Even if an exploit is not known to affect an existing DNS infrastructure - for example, an exploit is listed as being applicable to Linux servers and your DNS servers are BSD based - it cannot hurt to test the exploit against those DNS servers. Oftentimes, initial details of an exploit will be incomplete, so further research is always warranted.

Of course, even when there are no known exploits it is usually a good idea to upgrade DNS servers as soon as possible after a patch is released. Any patch should be thoroughly tested prior to upgrade, but patches generally are released to either protect against a security exploit or in anticipation of a potential security exploit.

About the authors:

Allan Liska is a Consulting Systems Engineer at FireEye Inc. and an "accidental" security expert. While Allan has always been good at breaking things, he got his start professionally working as a customer service representative at GEnie Online Services (a long defunct early competitor to AOL), where he would spend his off hours figuring out how users had gained unauthorized access to the system, booting them off, and letting the developers know what needed to be patched. Unknowingly, this was leading him down the path of becoming a security professional. Since then he has work at companies like UUNET, Symantec, and iSIGHT Partners helping companies better secure their networks. He has also worked at Boeing trying to break into that company's networks. In addition to his time spent on both sides of the security divide, Allan has written extensively on security including The Practice of Network Security and Building an Intelligence-Led Security Program. He was also a contributing author to Apache Administrator's Handbook.

Geoffrey Stowe lives in San Francisco and is an Engineering Lead at Palantir Technologies. His network security work has included vulnerability research, reverse engineering, incident response and anomaly detection. There was a time when he could translate byte code to assembly without looking at a manual. Geoff started Palantir’s commercial business in 2010 and built its platforms for distributed, large scale data analysis. He graduated from Dartmouth College with a degree in computer science.

DNS Security: Defending the Domain Name System

Reprinted with permission from Elsevier/Syngress, Copyright ©2016