A popular joke among technologists says that it’s always DNS, even when it initially didn’t seem that way. DNS issues come in many shapes and forms, including some often-overlooked security issues.
DNS (short for the Domain Name System) continues to be described as “the phonebook of the Internet,” but many people, including most readers of this blog, will be more familiar with the basic workings of DNS than with the outdated phenomenon of paper phonebooks.
Moreover, DNS does a lot more than turning names (such as www.tripwire.com) into numbers (such as 192.229.182.232). It allows a domain owner to respond to questions only they can know the answer to, such as what the mail servers for the domain are or what public key is used for DKIM. Sometimes, DNS is simply used to give a specific answer, to simply prove ownership of a domain.
The security of DNS thus is vital to the functioning of the Internet today. The bad news is that out of the box, of the CIA triad (confidentiality, integrity and availability), DNS provides none.
DNS requests and responses are sent in the clear so that your ISP or any entity tapping the Internet cables can see the requests being made from your devices. They can also modify the responses or even block them altogether.
This isn’t a theoretical risk. The country I live in requires ISPs to send users trying to access an unlicensed or foreign gambling site to a government webpage by having their resolvers (the servers that handle DNS responses) return a different IP address. This can be easily bypassed by using a foreign resolver instead, but some countries force ISPs to modify or block even requests to resolvers beyond their control, thus effectively blocking access to certain websites and services.
This kind of censorship isn’t the only security concern with DNS, though. Changing the DNS responses when someone is trying to access a banking or webmail site would make for effective phishing. Thankfully, the ubiquity of HTTPS and related protocols means that in such cases, the browser will usually throw an error rather than display the fake website.
Still, Internet technologists have long recognized the shortcomings of DNS and have built a number of security additions on top of the insecure protocol. One of these, DNSSEC, has been around for a while. It authenticates the responses to prevent someone from being sent to an incorrect website.
More recently, DNS requests are increasingly being sent over TLS or HTTPS, which handles both authentication and encryption. The recently announced ODOH (Oblivious DNS-over-HTTPS) goes one step further and anonymizes the IP address that made the request from the resolver, making DNS truly private.
While these additions aren’t entirely without controversy, (Organizations that filter malicious DNS traffic will need to do so at a local resolver rather than relying on DNS being sent in the clear.) they do turn DNS into a fully encrypted and authenticated protocol with some optional anonymity added on top.
That is great. Unfortunately, it is not all that matters.
When a DNS request is made, the answer ultimately comes from what is called an authoritative nameserver, or a server which is authorized to give DNS responses. Using the interface of a domain registrar (the entity where a domain is registered), the domain owner can assign one or (usually) more servers to be authoritative. They can also set the answers to be given—for example, what IP address the domain’s website is hosted on or which its mail servers are.
The security risk here is in the “they.” What if not the domain owner but a rogue individual or entity has obtained access to the registrar’s interface?
As mentioned, just being able to send users to a fake website often isn’t enough to phish them because of other protections that are in place. But it turns out that many of these protections ultimately rely on DNS too.
In particular, to obtain a TLS certificate, which is used to prove to browsers that an HTTPS-supported website is the real one, one needs to be able to send a specific DNS response, host a specific file on a website, or reply to an email sent to an address on the domain. Here it is crucial that the adversary is able to control all DNS responses, not just those sent over a specific network, but this is exactly what happens when they have control of the account at a registrar. Access for only a short period of time would suffice here.
In 2017, a prominent Dutch security firm revealed they had been the victim of such a hack, which led an adversary to perform a MitM-attack on the company’s client portal. Access to the registrar account was likely obtained through a stolen password, with two-factor authentication lacking. While this may look like an obvious mistake, registrar accounts are rarely logged into and thus may be forgotten during an internal security assessment.
More recently, a number of cryptocurrency providers were also hacked through their registrar. In this case, employees at the registrar fell victim to a phishing scam that gave malicious actors inside access to accounts, allowing them to make the changes required to take over the services.
Though there are ways to secure registrar accounts, (Using two-factor authentication is an obvious one.) protecting against insider attacks at a registrar is notoriously difficult. Those organizations for whom these kinds of attacks are a serious risk may want to consider running their own authoritative name servers so that at least they fully control their DNS security.
That doesn’t stop an adversary with access to a registrar account from changing the authoritative name servers (which would make rolling back any changes significantly harder), but this is something where a registry lock can make a big difference.
DNS are the screws that hold the Internet together. Recent additions have made it pretty secure. But there remains an often overlooked weak point that could lead to your whole Internet presence being compromised. Any organization that cares about security should therefore take this seriously.
About the Author: Martijn Grooten is a cybersecurity expert based in Europe, who is passionate about making sure the most vulnerable are prioritized when it comes to digital security. Previously the editor of Virus Bulletin, he currently does consulting work for a number of organizations. He is a Special Advisor to the Coalition Against Stalkerware and a Fellow of the Civilsphere Lab.
Editor’s Note: The opinions expressed in this guest author article are solely those of the contributor, and do not necessarily reflect those of Tripwire, Inc.
Meet Fortra™ Your Cybersecurity Ally™
Fortra is creating a simpler, stronger, and more straightforward future for cybersecurity by offering a portfolio of integrated and scalable solutions. Learn more about how Fortra’s portfolio of solutions can benefit your business.
