By Ben Nahorney You’ve probably heard the stories by now: one of the fundamental technologies that keeps the internet working has recently become a regular target for attackers.
Earlier this month, the UK’s National Cyber Security Centre released an advisory warning of DNS hijacking attacks across multiple regions and sectors. (This was their second such advisory in six months.) Last month, in their 2019 Global DNS Threat Report, IDC highlighted an increased number of DNS attacks and the subsequent costs. And earlier this year, ICANN warned of “ongoing and significant risk to key parts” of the internet’s DNS infrastructure, calling for the adoption of more robust security implementations.
Cisco Talos, Cisco’s threat intelligence group, had been watching DNS closely during this time. Talos spotted multiple attacks relying on DNS hijacking and manipulation as their main infection vector, releasing research that prompted many of these warnings.
Attacks against DNS is of significant concern. But what exactly is DNS? How is it being attacked? And what can be done to protect against these attacks?
DNS basics
Let’s start with a brief explanation of the technology. The Domain Name System (DNS) is the core technology that directs users to different web sites and other locations on the internet. Think of it like asking a librarian for help locating a book. Only instead of asking about a book, you ask for a particular web site. DNS checks its records, and then tells your computer where the web site is located.
DNS also works as a translator of sorts. It takes the human-readable domains (e.g. www.example.com) and matches it to the site’s IP address, the number that computers use to identify the location of the domain. In short, the user asks, “What is the IP address of this domain?” and DNS tells you.
Figure 1- How DNS works
The standard process for looking up domains is a little more complicated than described, involving more than one DNS server. The first server contacted, the DNS Resolver, is much like the librarian. The process from there often goes as follows:
The resolver will ask the DNS Root Server where the web site resides in much the same way the librarian will consult the card catalog for the location in the library.
The root server will send the resolver to the Top Level Domain server (TLD)—the DNS servers broken down by .com, .net, .org, etc. Think of this as a digital Dewey Decimal System.
The TLD server will know where the DNS Name Server is—the official DNS server of the domain you are trying to reach—and will tell the resolver the IP address. The name server is the card for the book.
The resolver tells your computer the IP address of the domain, and your computer goes to the site. This is the location of the book printed on the card.
Figure 2- How DNS works (detailed)
Where it all goes wrong
The thing about DNS attacks is that they don’t go directly after their intended target. Rather, they attack the librarian.
This attack is commonly referred to as “DNS hijacking” or “DNS redirection.” You are asking for the location of a particular book, but the information the librarian has is compromised. Instead of sending you to the correct location where your book resides, the librarian instead sends you to a dark, spiderweb-infested corner of the library. Even the book you pull off the shelf may look like what you wanted, but actually be something entirely different—the supposed children’s book turns out to be the Anarchist Cookbook instead.
The attack comes down to altering the route to a legitimate website to lead to a malicious one, ultimately compromising the target. You ask for the IP address of a particular domain you want to visit, but the DNS records have been changed so that you are sent to a malicious IP address instead.
Figure 3 – DNS redirection
There are a number of points at which a malicious actor can compromise DNS records. To name a few:
The DNS administrator may be phished, giving up his or her credentials, and the attackers log into the DNS interface and change the site’s IP address.
The DNS hosting interface—where records are managed and updated—may be compromised, allowing the attacker to change records for the domain.
Any of the DNS servers or infrastructure along the DNS request chain could be compromised, leading to a redirection.
A decade of redirection attacks
While various flaws and weaknesses in the DNS system had been known for a while, the first notable DNS attacks began in 2009. At the time, attackers managed to briefly change the DNS records for twitter.com to point to a hacktivist website for the Iranian Cyber Army.
Over the course of the next few years, a number of DNS-related attacks occurred:
In 2011 a Turkish hacker managed to redirect roughly 186 domains to point to a “you’ve been hacked”-type page.
The Syrian Electronic Army managed to redirect The New York Times, Twitter, and The Huffington Post to a hacktivist web site, and then attempted the same against Facebook, in attacks carried out in 2013 and 2014. (The Facebook attack was stopped in part thanks to multi-factor authentication.)
In 2015, regional Google sites for Vietnam and Malaysia were hijacked via DNS redirection.
The cryptocurrency company, Blockchain, had its DNS records hijacked in 2016. (Fortunately, the record change was quickly spotted by OpenDNS and restored.)
There have been many more such attacks during this 10-year timespan, some successfully, some not. However, Talos researchers discovered DNS attacks had reached a whole new level in late 2018.
DNSpionage
It all started with a LinkedIn message. The DNS administrator, thinking it was from a recruiter who was impressed with their work, clicked on a link that lead to a document that they thought they could fill out to apply for an open position.
Figure 4 – Malicious document used in DNSpionage
However, the document was actually infected with malicious macros. The administrator’s machine was compromised as a result, allowing the attackers to steal DNS login information.
Having gained the ability to control the domain, the attackers subsequently redirected a webmail server to a malicious IP address, and registered valid certificates to “legitimize” the redirected domain. Any visitor to this site would be wholly unaware that anything was out of the ordinary.
Figure 5 – DNSpionage attack process
In the process of investigating the tactics, techniques, and procedures of the DNSpionage attackers, Talos Intelligence discovered another separate, and arguably more concerning, attack against TLD DNS servers.
Sea Turtle
While having a similar end-goal as DNSpionage—stealing information—the attackers behind Sea Turtle went after the network infrastructure where the TLD servers were hosted, exploiting known vulnerabilities in these servers to gain access. Once the TLD servers where compromised, they modified the IP addresses of the name servers for particular domains.
This approach gave the attackers more control over the redirection. Setting up a malicious name server, the attacker can choose when requests for a particular domain is sent to the legitimate site or a malicious site.
Figure 6 – Sea Turtle attack process
Similar to DNSpionage, Sea Turtle changed records of webmail servers, where they can intercept and steal the information that they were after, and then send the target on to the legitimate system when done.
Other related attack techniques
In this blog we’ve focused on various DNS redirection attacks and techniques. There is far, far more to the attacks than is covered here. Talos has published multiple blogs on the attack that include details on payloads and the malicious techniques used by the attackers. Links to these blogs are included in the “Additional Reading” section below.
There are a few other ways that attackers have used DNS to perform malicious activities. Some threats, such as DNSpionage and DNSMessenger, communicate with command and control (C2) systems using DNS. DNSMessenger, along with other threats, has also been seen tunneling through DNS in order to exfiltrate stolen data.
Another recent area of concern is threats using the DNS over HTTPS (DoH) protocol. The purpose of this protocol is to increase the security of DNS queries, preventing eavesdropping and MitM attacks. However, earlier this month, a malware family named Godlua was found using the protocol for malicious communications. Given DoH’s ability to mask traffic, it’s possible more threats will follow suit.
How to protect against DNS attacks
Unfortunately, as a end-target of a DNS attack, there isn’t too much you can do. From a user’s standpoint, the DNS communication to get to a web site appears legitimate, especially when the attacker creates valid certificates for the malicious sites after compromising the DNS records.
The responsibility to defend in this case falls to those who administer and host DNS services. Fortunately, there are steps that can be taken at this level.
Monitor your DNS records. Tools like Umbrella Investigate allow you to quickly look up changes to DNS records.
Require multi-factor authentication (MFA) for DNS record changes. MFA solutions, such as those offered by Cisco Duo, can prevent arbitrary changes to your records without authentication.
Use tools such as BGPmon to monitor for DNS hijacking attempts, changes to TLD records, or traffic redirection and interception.
Keep your systems patched. In the case of Sea Turtle, attackers got in by exploiting vulnerabilities, some of which were 10 years old.
Implement DNSSEC in your environment. DNSSEC adds digital signatures to DNS communications, allowing for origin authentication and ensuring the request hasn’t been modified.
Finally, if you host a web site or domain, be sure to confirm that your DNS provider’s security posture includes the above.
Additional reading
DNSpionage Campaign Targets Middle East
DNSpionage brings out the Karkoff
DNS Hijacking Abuses Trust In Core Internet Service
Sea Turtle keeps on swimming, finds new victims, DNS hijacking techniques
Covert Channels and Poor Decisions: The Tale of DNSMessenger
Spoofed SEC Emails Distribute Evolved DNSMessenger
Detecting DNS Data Exfiltration
Like this post? Subscribe to the Threat of the Month blog series and get alerted when the next blog post is released.
Source:: Cisco Security Notice
