Attacks/Breaches

1/30/2018
10:30 AM
Cricket Liu
Cricket Liu
Commentary
Connect Directly
Twitter
LinkedIn
RSS
E-Mail vvv
50%
50%

DNS Hijacking: The Silent Threat That's Putting Your Network at Risk

The technique is easy to carry out and can cause much damage. Here's what you need to know about fighting back.

In its bag of tricks, the recently discovered MaMi malware has the ability to modify the DNS configuration of an infected device. This is a good reminder that DNS hijacking is an ongoing threat that needs to be taken seriously by corporate IT organizations. DNS hijacking is easy to carry out, can be tough to detect, and is surprisingly damaging. Here's what you ought to know  and what you can do to combat it.

DNS hijacking is simple enough: one only needs to rewrite the configuration of a device on the Internet so that it sends DNS queries to malicious DNS servers. Many species of malware do this, often as just one of many consequences of infecting a device. And virtually any malware can do this — modifying DNS settings generally doesn't require any special privileges. Perhaps the most famous malware in this category is DNSChanger, which may have infected more than 4 million computers. Although DNSChanger was taken down in 2011, there are likely still hundreds of thousands of infected computers on the Internet.

So why change a device's DNS configuration? In the case of DNSChanger, it was primarily to substitute advertising on websites with advertising sold by the bad guys running the rogue DNS servers. That perhaps doesn't sound too alarming, but DNS hijacking can have much more serious effects, too. Take, for instance, the malicious DNS servers David Dagon and company discovered and wrote about in their 2008 study, "Corrupted DNS Resolution Paths: The Rise of a Malicious Resolution Authority." Dagon discovered a small but significant percentage of open recursive DNS servers on the Internet that, no matter what domain name you looked up, would always lie in the response. Some, for example, would always reply with the same set of IP addresses, none of which were the correct addresses. The address of www.nytimes.com? Addresses A, B, and C. The address of www.bankofamerica.com? That same set of addresses: A, B, and C.

What purpose could that serve? Well, it turned out that the hosts at those IP addresses (A, B and C, in our example) ran open Web proxies. As a result, users whose devices queried those DNS servers would unwittingly have all of their access to the Web directed through those open Web proxies, where their traffic could be snooped. And the DNS servers could just as easily have directed users to websites that looked identical to their bank's or brokerage's, where they'd unknowingly enter their authentication credentials and have them captured for the bad guys' later use.

Fortunately, there's a simple way to mitigate the threat of these DNS hijacking attacks: don't allow arbitrary internal IP addresses on your enterprise network to send DNS queries to arbitrary IP addresses on the Internet.

In most DNS architectures, only a subset of your DNS servers (referred to as Internet forwarders) actually need to be able to query DNS servers on the Internet. You should explicitly allow only their IP addresses to exchange DNS messages with IP addresses on the Internet. If some of your internal devices become infected with malware that modifies their DNS configurations, they'll simply stop resolving domain names, which should alert their users to the fact that something is wrong. Hopefully, that would induce them to take their devices to IT where, with any luck, the infection would be detected.

Related Content:

Cricket Liu is a leading expert on the Domain Name System (DNS) and EVP and Senior Fellow at Infoblox. With more than 25 years of experience with enterprise-scale DNS infrastructure, technical writing, training, and course development experience, Cricket serves as a liaison ... View Full Bio
Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
Microsoft President: Governments Must Cooperate on Cybersecurity
Kelly Sheridan, Staff Editor, Dark Reading,  11/8/2018
To Click or Not to Click: The Answer Is Easy
Kowsik Guruswamy, Chief Technology Officer at Menlo Security,  11/14/2018
Veterans Find New Roles in Enterprise Cybersecurity
Kelly Sheridan, Staff Editor, Dark Reading,  11/12/2018
Register for Dark Reading Newsletters
White Papers
Video
Cartoon
Current Issue
Flash Poll
Online Malware and Threats: A Profile of Today's Security Posture
Online Malware and Threats: A Profile of Today's Security Posture
This report offers insight on how security professionals plan to invest in cybersecurity, and how they are prioritizing their resources. Find out what your peers have planned today!
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2018-19279
PUBLISHED: 2018-11-14
PRIMX ZoneCentral before 6.1.2236 on Windows sometimes leaks the plaintext of NTFS files. On non-SSD devices, this is limited to a 5-second window and file sizes less than 600 bytes. The effect on SSD devices may be greater.
CVE-2018-19280
PUBLISHED: 2018-11-14
Centreon 3.4.x has XSS via the resource name or macro expression of a poller macro.
CVE-2018-19281
PUBLISHED: 2018-11-14
Centreon 3.4.x allows SNMP trap SQL Injection.
CVE-2018-17960
PUBLISHED: 2018-11-14
CKEditor 4.x before 4.11.0 allows user-assisted XSS involving a source-mode paste.
CVE-2018-19278
PUBLISHED: 2018-11-14
Buffer overflow in DNS SRV and NAPTR lookups in Digium Asterisk 15.x before 15.6.2 and 16.x before 16.0.1 allows remote attackers to crash Asterisk via a specially crafted DNS SRV or NAPTR response, because a buffer size is supposed to match an expanded length but actually matches a compressed lengt...