Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

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
 

Recommended Reading:

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
News
Former CISA Director Chris Krebs Discusses Risk Management & Threat Intel
Kelly Sheridan, Staff Editor, Dark Reading,  2/23/2021
Edge-DRsplash-10-edge-articles
Security + Fraud Protection: Your One-Two Punch Against Cyberattacks
Joshua Goldfarb, Director of Product Management at F5,  2/23/2021
News
Cybercrime Groups More Prolific, Focus on Healthcare in 2020
Robert Lemos, Contributing Writer,  2/22/2021
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Write a Caption, Win an Amazon Gift Card! Click Here
Latest Comment: This comment is waiting for review by our moderators.
Current Issue
2021 Top Enterprise IT Trends
We've identified the key trends that are poised to impact the IT landscape in 2021. Find out why they're important and how they will affect you today!
Flash Poll
Building the SOC of the Future
Building the SOC of the Future
Digital transformation, cloud-focused attacks, and a worldwide pandemic. The past year has changed the way business works and the way security teams operate. There is no going back.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2021-27225
PUBLISHED: 2021-03-01
In Dataiku DSS before 8.0.6, insufficient access control in the Jupyter notebooks integration allows users (who have coding permissions) to read and overwrite notebooks in projects that they are not authorized to access.
CVE-2021-27132
PUBLISHED: 2021-02-27
SerComm AG Combo VD625 AGSOT_2.1.0 devices allow CRLF injection (for HTTP header injection) in the download function via the Content-Disposition header.
CVE-2021-25284
PUBLISHED: 2021-02-27
An issue was discovered in through SaltStack Salt before 3002.5. salt.modules.cmdmod can log credentials to the info or error log level.
CVE-2021-3144
PUBLISHED: 2021-02-27
In SaltStack Salt before 3002.5, eauth tokens can be used once after expiration. (They might be used to run command against the salt master or minions.)
CVE-2021-3148
PUBLISHED: 2021-02-27
An issue was discovered in SaltStack Salt before 3002.5. Sending crafted web requests to the Salt API can result in salt.utils.thin.gen_thin() command injection because of different handling of single versus double quotes. This is related to salt/utils/thin.py.