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...
