Also known as DNS Spoofing focuses on corrupting the cached answers on the recursive name servers with bogus data such as rogue addresses, either through software exploits or protocol weaknesses.
An older-style attack involved attaching malicious answers to the ADDITIONAL section of a DNS response. A less secure recursive name server would not only accept the RRset in the ANSWER section, but also accept the RRset in the ADDITIONAL section, even if those records were unrelated to the question being answered.
Kaminsky attack: a more recent type of attack which takes advantage of weakness in the DNS protocol itself. When a recursive name server makes a query, it sets the value of five fields. If it receives a response with matching values for these fields, with an answer to the question that it asked, then it accepts the answer and stores it in its cache. As it turns out, four of the fields are easy to figure out and spoof, so only one field (the Query ID) is actually meaningful. This field is a randomly generated 16 bit number, making it possible for an attacker to try random numbers.
Here is how this attack works; An attacker initiates a DNS request. While the recursive name server asks the next server up the tree, the attacker tries his luck firing a lot of responses at the recursive name sever (spoofing them so that they look like they came from the authoritative server). If the attacker gets lucky and guesses the right query ID, the original server stores the corrupt data from the attacker’s bogus response in cache and passes it on if another server asks for it.
A well-crafted Kaminsky attack can insert a bogus entry in the cache within minutes. It is also possible for the attacker to poison an NS record, thus taking command of an entire domain rather than just a single entry.
The most common fix to this vulnerability is to send queries from random source ports. Since the response has to arrive at the same random port, the attacker must guess two values. The real fix however is to implement the enhanced DNSSEC.
Malware and Exfiltration (DNS tunnelling)
This is identical to any other type of malware and data exfiltration attack. Data Exfiltration (when the malware sends sensitive data out of your network) done over DNS is also referred to as DNS tunnelling.
Using DNS tunnelling software, victim machines break sensitive data down into query-sized chunks, disguising it as DNS queries. They then send the “queries” to malicious DNS servers which will unpack these queries and reconstruct the data.
As an example, an attacker will register domain name youreattacked.com. The victim’s PC (with malware installed already) sends sensitive data in small chunks – such as subdomain name sensitivedata.youreattacked.com – to its DNS server. This will ultimately be sent to the authoritative DNS server for youreattacked.com, at which point the attacker recognises the subdomain value to be the a chunk of the sensitive data he/she is after.
DNS Security Solutions
Response Rate Limiting (RRL)
This is used to mitigate a portion of DDoS attacks by separating valid queries from malicious queries. It relies on the concept of a token bucket to limit how many responses the DNS server will send to any single client. A configuration on the DNS server creates a token bucket for each client and adds a number of buckets per time internal. If a client uses up its tokens in a time internal, it has to wait until the bucket is refilled with new tokens. The server can also choose to send truncated responses while the bucket is being filled thereby preventing amplification style attacks.
DNSSEC (DNS Security Extensions)
DNSSEC is set of protocols that adds a layer of security to the domain name system (DNS) lookup and exchange processes. It provides Answer validation using public key cryptography. Keys are used to sign zones and provide both message authentication and message integrity. Although DNSEC uses both public and private keys, they’re only used for authentication purposes. Someone eavesdropping on the wire, can still see all the DNS messages in plaintext.
When a DNS resolver is looking for blog.testsite.com, the root DNS name servers help verify .com. The .com name servers help the resolver verify the records returned for testsite, and testsite helps verify the records returned for blog.
DNSSEC must be deployed on both the recursive and authoritative name servers. The recursive name servers ask for additional security information and perform validation checks, while authoritative name servers provide signed resource records in response. This effectively mitigates the cache poisoning attacks because attacks can no longer impersonate authoritative name servers.
Response Policy Zones
RPZs provide a method for you to control what your queriers can and cannot look up using a recursive DNS server. With RPZ, you create policies for how to handle specific queries (or responses) and then choose which of a number of possible actions to take. You can store those policies in special authoritative zones on your DNS servers. You can also share these zones by transferring them from DNS server to DNS server using conventional DNS protocols.
RPZs are created based on a concept called reputation. Reputation describes a zone’s history of offering malicious content. Several reputation services track and analyse the providers of malicious content. These services chase the attackers, predict their next move and determine the algorithms they use to generate new bad domains. The reputation data created by these services is then published for everyone to use.
The event that determines whether a query or a response matches a specific entry in an RPZ policy is called a trigger. Once a trigger matches a record in an RPZ, you can take a number of actions.
There are a number of other actions you must take to increase the security of your DNS Servers. These include;
- Keeping DNS Server software up to date
- Have an onsite DNS backup
- Avoid single points of failure
- Run Authoritative DNS Servers inside DMZs
- Turn off Recursion
- Use Threat Intelligence
- Automate security tasks whenever possible
The automation of security tasks is an interesting topic. Here are two suggestions relevant to DNS security;
- When your DNS security solution detects a DNS-based data exfiltration or malware from an infected host, it is to notify an endpoint security solution to clean the infected endpoint
- When a new device joins the network, your DNS security solution is to trigger a vulnerability scan