Security: DNS, or “the weakest ring of the chain” #7
Good evening my maliciously redirected Reader,
As the second last Article of our Security excursus we’d like to focus on DNS today: we love DNS and agree that most people overlook it when it comes to hardening their assets: still, DNS represents the first and weakest step in most Client to Server communications!
We’ll therefore cater for an Introduction to DNS Attack Vectors and tell you about DNSSEC, with a keener eye on Security this time.
As mentioned, a very large portion of us underestimates the importance of DNS. During our time spent on the Internet, we use an army of Applications that automatically connect to the Internet, without entering an Internet host name to resolve. Even when we type a URL in our Browser, we tend not to think what’s happening in the back end to ensure that the name typed in the Browser resolves to the correct IP address.
When you think about it, the ability to use names instead of series of numbers known as IP addresses is a colossal convenience. Humans can remember names way easier than numbers. Imagine having to remember the IPv4 addresses of all your favorite websites. That would be mind-blowing!
Man-in-the-Middle Attacks on DNS
In 2014, the government of Turkey decided to block Twitter within the country. They conducted it at the DNS level by ordering Turkish ISPs to redirect records for twitter.com to the government website. People immediately realized what was going on and, by using foreign resolvers, bypassed the restrictions and continued to Twitter’s real IP address. This resulted in people spray painting Google’s public DNS server address on public spaces and buildings.
This outlines the first significant Security issue with DNS: there is no authentication. Anyone with a privileged network position (simply put, anyone who controls the Router between two sides of a connection) can modify DNS Records to lead wherever they want. This is the notorious “man-in-the-middle” attack and DNS remains very vulnerable to this type of attack.
Back in 2008, Dan Kaminsky discovered an attack on the DNS Framework which can trick DNS recursive resolvers into storing incorrect DNS Records. When the Nameserver has saved the incorrect Record, it will gladly return it to everyone who requests it until the cache entry expires. This attack allows attackers to trick DNS and redirect Browsers and Applications to incorrect Servers in order to hijack traffic and often lead it to malicious Websites. DNS Poisoning is easy to portray, but difficult to perform.
DNS Poisoning depends on the fact that UDP is a stateless Protocol and that IP addresses are blindly trusted. Every UDP request contains requests to and responses from IP addresses. Any attacker connected to the Network that does not filter outbound packets can create a UDP message that claims to be from the legitimate Server and pass it to the recursive resolver.
Furthermore, the recursive resolver will accept the first answer that matches its question. So, if an Attacker can answer the query faster than the legitimate Server, the recursive resolver will accept his answer as the truth. This is the basic of the attack:
– Pick a domain whose DNS records you want to redirect.
– Send a request to the recursive resolver for the record you want to hijack.
– Send a bunch of fake UDP responses pretending to be the legitimate server with the answer of your choosing (point the record to the IP of your choice).
If just one of your fake responses comes before the real response, the recursive resolver will cache your Record for as long as the TTL is set. Afterwards, any User requesting the poisoned record will be directed to your Servers.
DNS Client Flooding (DDoS)
When it comes to Denial of Service (DoS), if you have never been subjected to a DNS Denial of Service attack then consider yourself very lucky. Since DNS queries are not authenticated, the DNS Server will always try to answer to the DNS queries received; truth be told, that’s what is it designed to do.
This implies that is fairly easy to dispatch a Distributed Denial of Service Attack disabling the DNS Server for long enough for the Attacker to place a rogue DNS Server which will start answering the queries instead of a legitimate DNS. Victims have no reliable way to know that the new DNS is actually malicious one and they will be redirected to malicious Sites often owned by the Attacker. These Websites are often designed to copy genuine Sites and use the trust that victims have in those genuine Websites, with an end goal to gain access to Personal Information that can be later used for all kinds of frauds.
Zone File Compromission
In a Windows DNS Server environment, the DNS Server is usually hosted on one of various versions of the Windows Server Operating System. The DNS Administrator has complete control over DNS. One of the most common and easiest ways your DNS can be compromised is by someone who is able to access DNS directly and edit the Server Configuration or the Records themselves at the DNS Server level. This sort of attack is not “hacking for pros”, quite the contrary indeed, pretty much anybody with just a little knowledge of DNS (and access to the Server) can conduct this Attack successfully.
The attacker can be physically in front of the Server, logged on over Telnet or connected over RDP. This could be a malicious insider, or even a well-meaning Administrator who makes a critical error. It’s very important to keep your DNS Server locked so that only Authorized Personnel can access to the DNS configuration and forbid or limit any remote access to the DNS Server, too.
Zone Information Leakage
The DNS Zone Files on your DNS Server contain the names of the Computers in that Zone. Zone Information Leakage can happen when an intruder acquires sensitive data about possible Server roles on your Network, based on the names of those Servers. For instance, if you have a Server that is accessible by the name PAYROLL, that information could be very significant to the Attacker. This is called “foot printing”.
The Crook can find out the names on your Network using a mix of different techniques. Per instance, if you enable Zone Transfer for all machines, then the Attacker can download your entire Database by Zone Transfer mechanism. Even if the Zone Transfer mechanism is disabled, a patient Attacker can use reverse DNS queries to go through your addresses and find the names used in your Network. Also, the Hacker can use this data to create a detailed diagram of your Network.
The Security extensions to DNS add protection for DNS Records and allow resolvers as well as Applications to authenticate the received information. This means that all answers from DNS can be trusted. The purpose of DNSSEC is to give a way for DNS Records to be trusted by whoever receives them. The main innovation of DNSSEC is the utilization of public key cryptography to ensure that DNS Records are authenticated. DNSSEC likewise allows the assertion of “non-existence of records”. The DNSSEC trust chain is a succession of Records that recognize either a public key or a signature of a set of resource records. The root of this chain of trust is the root key which is kept and overseen by the operators of the DNS root. There are several important new Record types:
DNSKEY: a public key used for signing a set of resource records (RRset).
DS: delegation signer, a hash of a key.
RRSIG: a signature of an RRset that share class/type/name.
A DNSKEY Record is a cryptographic public key and can be classified into two roles, which can be managed by separate keys or a single key.
KSK (key signing key): used to sign DNSKEY records.
ZSK (zone signing key): used to sign all other records in the domain authorization.
The set of all Records of a certain type for a domain is called an RRset. An RRSIG is a digital signature of an RRset. Each RRSIG is connected with a DNSKEY. The RRset of DNSKEYs are signed with the KSK. All others are signed with ZSK. Trust chain goes from the DNSKEY to the Record though the RRSIG meaning
– if you trust a DNSKEY, they you can trust the Records that are accurately signed by that key.
On the other hand, ZSK is signed by itself, making it hard to trust. To verify that the DSNKEY for example.com is valid, you need to ask the .com Server. This is where DS records step in: they act as a bridge of trust to the parent level of the DNS. The DS record is a hash of a DNSKEY.
This goes all the way back to the root, making all of the Records trustworthy and to prove the integrity of a resource Record. But that isn’t enough by itself; something else is required to prove that a Record doesn’t exist. This is the time when two additional records, NSEC and NSEC3 play their part.
If there is no Record for a certain request, a DNS server answers with a NODATA response. These empty answers are unauthenticated and can be easily forged by third party. DNSSEC resolves this problem by creating NSEC, which tells what names exist and what types lay at each name. An NSEC is often
signed by DNSSEC and validated up to the root.
This article was made to introduce you to the DNS Security and present you possible Attack Vectors and Threats. DNSSEC is a important tool for improving the DNS Servers and the backbone of the Internet as we know it. DNSSEC is still being adopted and we hope that DNSSEC will lead to the safer Internet.
Do you have any questions about DNS security? DNSSEC implementation maybe? Feel free to ask us, we’re here for you.