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.

Infrastructure Security

// // //

Protect DNS: A Conversation With Dave Dufour of Webroot

DNS is vulnerable and must be protected. An interview with Dave Dufour explains the vulnerabilities and some of the protection.

The guts of the Internet -- the bolts, baling wire, chewing gum and electronic duct tape that hold the whole thing together -- can be the largest of "black box" technologies even to many IT professionals. Most of the basic services were developed years ago, before the Internet was the primary communication conduit for the developed world. Within the mystery, though, dangers lurk.

DNS is one of the basic services on which the web is based and it has proven to be robust and scalable to an astounding degree. Unfortunately, it's also vulnerable to hacking and can be a serious attack vector if left unprotected. Dave Dufour, director of cybersecurity and engineering at Webroot, is an expert on DNS and its implications in network security. Security Now talked with Dufour about the issues with DNS and what organizations should be doing to protect their networks, employees and customers from DNS-based threats.

What follows is an edited version of a telephone interview between editor Curtis Franklin and Dufour.

CF: DNS is all about names and addresses. Why is it involved in security at all?

DD: Ironically DNS was one of the first things that malware delivery folks figured out how to tamper with because it's the phone book of the Internet. There are a lot of ways to affect DNS where you can take over a local DNS server. You can insert your own IP addresses behind you in what's called poisoning. I can adjust the IP addresses so that if you do a DNS lookup that it'll route you to the wrong site.

Another thing we've seen in the last six to eight months are homoglyph attacks, which are using Unicode characters to register a URL but when those Unicode characters are converted to ASCII it actually will appear to be a very reputable website because maybe the browser can't translate those Unicode characters accurately so it displays something that looks like a site that you're not actually on.

CF: Given the evil nature of what you're talking about, why is this something that the registrars will allow to happen?

DD: There's a question of should they be blocking things that could be legitimate. Let's say I register something in Unicode that is a set of Chinese characters. It happens to convert [in ASCII] to the name of a bank. Well I could legitimately want those Chinese characters because it represents a URL that I want to have a legitimate business at.

A reasonable argument would be we don't want to block legitimate things in an effort to prevent malicious things. The right answer is to start displaying these in Unicode and not have to convert them to ASCII.

The explosion of the Internet made us realize we need to have things in Unicode because it is a global environment and the 128 characters available to us in an ASCII format don't meet the needs of four fifths of the world. So it was important that we went to Unicode. But there are still some lingering considerations.

CF: For most organizations DNS is two things: DNS is primarily a service but in order to deliver that for many organizations it is also a server. From a protecting DNS standpoint are most organizations going to be most concerned with protecting the service or the server? Or is it impossible to really distinguish between the two?

DD: If I'm an attacker I'm going to typically try to attack DNS services in the wild because they get more bang for my buck. If I penetrate a service I can in fact poison, take over or shut down large swaths of the Internet. I'm trying to get to service providers that provide the services. When you see the DNS servers being taking control of, most of the time those are your pointed attacks where somebody has an interest in affecting an institution or a location.


Get real-world answers to virtualization challenges from industry leaders. Join us for the NFV & Carrier SDN event in Denver. Register now for this exclusive opportunity to learn from and network with industry experts -- communications service providers get in free!

CF: It seems to me that up to a particular organization size companies are largely going to be getting their DNS service from a service provider. From their perspective, is DNS protection someone else's responsibility? Or do you still have a responsibility even if you're working with a DNS provider?

DD: Yes, it is your responsibility. I would argue almost no one thinks about it, because the expectation is your provider is providing that security for you. So I guess what I'm saying is that you need to -- from a risk perspective -- ensure you're signing up with a provider that has adequate security with their DNS service. That's where your responsibility lies and it is that provider's responsibility to ensure they are doing everything in their power to provide a secure service.

You need to understand your risk profile. Whenever I speak I have this fictitious welding shop somewhere in the middle Oklahoma. So if you're in a welding shop in the middle of Oklahoma and you don't have any intellectual property or any PII, then your diligence needs to go to the extent that you're pretty reasonably sure this service is going to do what you need and you're probably OK.

If you're a large medical facility with lots of patient information someone is going to try to attack you and maybe they want to reroute the DNS when they find out who your provider is, so that when you're sending a patient information they can man-in-the-middle and start scrubbing off that data and capturing it in some sophisticated way. Your liability is not like the welding shop in Oklahoma.

Even a smallish 20-person company you might have an internal DNS server that lets them route stuff through the internal network. They have some level of responsibility ensuring that the DNS server is secured because it would be possible to add DNS records to that server and have an impact on backups or data routed to the cloud.

CF: Is protecting DNS something that requires a security professional or should it be within the grasp of a good IT professional?

DD: A good, solid professional who understands how to properly secure things with proper credential access to certain environments and who has done the diligence looking into external services if you're using one should have the fundamental knowledge to protect DNS because they understand how networks work. Absolutely.

A qualified, good professional could quickly google how to secure a DNS server and be able to do this. This isn't some deep deep deep security thing now. The general securing and making reliably secure DNS can be done by by a qualified professional, yes.

Related posts:

— Curtis Franklin is the editor of SecurityNow.com. Follow him on Twitter @kg4gwa.

Comment  | 
Print  | 
More Insights
Comments
Threaded  |  Newest First  |  Oldest First
Edge-DRsplash-10-edge-articles
I Smell a RAT! New Cybersecurity Threats for the Crypto Industry
David Trepp, Partner, IT Assurance with accounting and advisory firm BPM LLP,  7/9/2021
News
Attacks on Kaseya Servers Led to Ransomware in Less Than 2 Hours
Robert Lemos, Contributing Writer,  7/7/2021
Commentary
It's in the Game (but It Shouldn't Be)
Tal Memran, Cybersecurity Expert, CYE,  7/9/2021
Register for Dark Reading Newsletters
White Papers
Video
Cartoon
Current Issue
Black Hat USA 2022 Attendee Report
Black Hat attendees are not sleeping well. Between concerns about attacks against cloud services, ransomware, and the growing risks to the global supply chain, these security pros have a lot to be worried about. Read our 2022 report to hear what they're concerned about now.
Flash Poll
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2017-2597
PUBLISHED: 2022-08-08
** REJECT ** DO NOT USE THIS CANDIDATE NUMBER. ConsultIDs: none. Reason: This candidate was in a CNA pool that was not assigned to any issues during 2017. Notes: none.
CVE-2017-2631
PUBLISHED: 2022-08-08
** REJECT ** DO NOT USE THIS CANDIDATE NUMBER. ConsultIDs: none. Reason: This candidate was in a CNA pool that was not assigned to any issues during 2017. Notes: none.
CVE-2017-2657
PUBLISHED: 2022-08-08
** REJECT ** DO NOT USE THIS CANDIDATE NUMBER. ConsultIDs: none. Reason: This candidate was in a CNA pool that was not assigned to any issues during 2017. Notes: none.
CVE-2017-7527
PUBLISHED: 2022-08-08
** REJECT ** DO NOT USE THIS CANDIDATE NUMBER. ConsultIDs: none. Reason: This candidate was in a CNA pool that was not assigned to any issues during 2017. Notes: none.
CVE-2021-41615
PUBLISHED: 2022-08-08
websda.c in GoAhead WebServer 2.1.8 has insufficient nonce entropy because the nonce calculation relies on the hardcoded onceuponatimeinparadise value, which does not follow the secret-data guideline for HTTP Digest Access Authentication in RFC 7616 section 3.3 (or RFC 2617 section 3.2.1). NOTE: 2.1...