DNS data integrity
The purpose of every DNS is to deliver correct data in an orderly manner to every query.
To maintain the data integrity of the DNS zone content it needs to be monitored, otherwise it is just a phrase without meaning.
To monitor DNS data integrity is one of two main features of our service.
Background
Due to the ever increasing hacker activity and the fact that the exploits seems never ending we need to up the ante on security monitoring to keep pace with current events.
Even though we take good care of our systems with regular patching and security updates we will never be entirely secure. It's the name of the game. Our DNS servers are in the front line, always exposed to the brute force of what the hackers all over the Internet can throw at them.
We have always known that the DNS is a highly valued target for hackers, mainly due to its exposure on the Internet. We also know that the DNS servers rarely are the end target for any hacker, but, by gaining control of a DNS server a hacker can create a platform from which he can mount numerous attacks against a target, often bypassing perimeter security systems. This became alarmingly obvious when the details of the 2019 DNS hijacking campaign were exposed.
The threat from hackers should never be taken lightly. Many of them have more in-depth knowledge about networks and systems than the people running the systems have. In combination with funding and motivation our adversaries make our jobs to protect our computer environments a monumental tasks. Phrases like "It's never going to happen to us" and "We have nothing of value or interest for hackers" are not only naive but also very dangerous because they are often used by organisations looking to avoid spending time and money on security. It's bound to end very badly.
The DHS CISA issued the Emergency Directive 19-01 when the DNS Hijacking campaign were exposed in early 2019. The directive gave American authorities and agencies only ten working days to complete the following 4 steps to mitigate the effects of the attack. They were:
- Audit all DNS resource records
- Change DNS account password
- Add MFA (Multi-Factor Authentication) to DNS accounts
- Monitor Certificate Transparency logs
This article will focus on the first step. Steps 2 to 4 are more or less basic security hygiene and should be fairly easy to implement. The first step is a bit more challenging.
It's quite a bit of work to audit all DNS resource records. First of all, you need to know the exact IP addresses that goes with every record. Second, you need to repeat this process on every name server used. And third, which is not explicitly submitted in the Emergency Directive, you have to repeat this audit. Regularly. With the lessons learned from the hijacking campaigns, at least a couple of times every hour.
Why do the records need to be audited several times every hour? To explain this we need to go into more detail what DNS Hijacking is and what the hackers typically did after successfully hijacked a DNS server.
DNS hijacking is basically that an unauthorised person or entity (hacker, adversary, threat actor) gains administrative access to a system that runs a DNS service. The hacker is then free to do whatever he wants on that system with his administrative privileges, like changing host resource records to point to new IP addresses, usually to systems under the hackers control. One of the first tasks a hacker perform once he gains control over a system is to make sure he maintains that control, like installing backdoors that will allow him continuous access to the system. So, once in he's hard to get rid of.
By modifying host resource records to point to systems under the hacker control, all traffic intended for the original host is now redirected to the hacker controlled system. That system is usually set up to record incoming traffic and then pass it on to the original target. This is called a "Man-in-the-middle" or MIM attack and is extremely hard to detect. The goal is of course to record information that will help the hacker to venture further into the targets environment, like account names and passwords, but could very well be other information like credit card numbers and so on depending on the hackers intentions and the targets profession. But it get worse!
By issuing new certificates through services like Let's encrypt, and install it on his server, a hacker is able to cheat the web browsers (ie cheat the user using the web browser) into thinking that the new IP address is legit which gives a user little or no chance to identify the ongoing attack. Validation of the certificate request is usually done by entering a TXT string into the zone file on the DNS (which the hacker controls). By modifying resource records like MX, mail exchanger and NS, Name Server, the hacker is able to redirect incoming emails and DNS queries to or through his own servers. And there is more!
To avoid detection the researchers found that the hijackers modified resource records only for a short period of time before reverting the changed records back to its original form. This time could be as low as one hour or even less. When the hijackers modify a resource record they usually manipulate the TTL of that record either so it will remain in resolver caches longer or not at all depending on circumstances. Most resolvers allow TTLs up to one week (even though DNS protocol specifications allows for TTLs up to approximately 68 years). A resource record with 0 TTL will not be cached at all.
Mobile phones usually connects to its mail server several times every hour, sending its credentials every time...
DNSSEC
DNSSEC protects us from these types of unauthorised modifications, doesn't it?
The answer is both "Yes it does" and "No, it doesn't".
DNSSEC will protect against this type of unauthorised modification if:
- the zone is signed (only 3% are) - and -
- the resolver used is DNSSEC aware and will discard invalid responses - and -
- the hijacked DNS server is not a master
DNSSEC is of no use if:
- the zone is unsigned (97% are) - or -
- the resolver is unaware of DNSSEC - or -
- the hijacking happened on a master
If DNSSEC were properly deployed on all zones and all DNS resolvers would be DNSSEC aware, the outcome would be very different! But with the current situation on the Internet the conclusion here is that DNSSEC is very unlikely to be of any help.
Read my article on DNSSEC here!
How to detect DNS hijacking
The key to detect if your DNS servers have been hijacked is to constantly look for unauthorised modifications of your DNS resource records. DNS monitor checks for these type of changes every 5 minutes* on all authoritative name servers. And we do it from outside the organisation!
When a domain is set up and configured DNS monitor looks up (among other things) the MX and NS resource records as well as the corresponding A and AAAA records for each NS and store the initial result in the configuration database. These records are then checked every 5 minutes* and compared with the stored initial values in the database.
Each domain can be completed with additional host resource records by the administrator (the account holder) that will be stored and checked the same way the MX, NS and its corresponding A/AAAA RR's are.
Since an unauthorised modification of a resource record could indicate a successful DNS hijacking the DNSmonitor service will issue an ERROR message if a modified resource record is detected.
*/ Premium and Basic domain subscriptions are checked every 5 minutes. Free domain subscriptions are checked once every hour.