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

9/15/2017
04:28 PM
Curtis Franklin
Curtis Franklin
Curt Franklin
50%
50%

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
Newest First  |  Oldest First  |  Threaded View
COVID-19: Latest Security News & Commentary
Dark Reading Staff 9/17/2020
Cybersecurity Bounces Back, but Talent Still Absent
Simone Petrella, Chief Executive Officer, CyberVista,  9/16/2020
Meet the Computer Scientist Who Helped Push for Paper Ballots
Kelly Jackson Higgins, Executive Editor at Dark Reading,  9/16/2020
Register for Dark Reading Newsletters
White Papers
Video
Cartoon
Current Issue
Special Report: Computing's New Normal
This special report examines how IT security organizations have adapted to the "new normal" of computing and what the long-term effects will be. Read it and get a unique set of perspectives on issues ranging from new threats & vulnerabilities as a result of remote working to how enterprise security strategy will be affected long term.
Flash Poll
How IT Security Organizations are Attacking the Cybersecurity Problem
How IT Security Organizations are Attacking the Cybersecurity Problem
The COVID-19 pandemic turned the world -- and enterprise computing -- on end. Here's a look at how cybersecurity teams are retrenching their defense strategies, rebuilding their teams, and selecting new technologies to stop the oncoming rise of online attacks.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2020-5421
PUBLISHED: 2020-09-19
In Spring Framework versions 5.2.0 - 5.2.8, 5.1.0 - 5.1.17, 5.0.0 - 5.0.18, 4.3.0 - 4.3.28, and older unsupported versions, the protections against RFD attacks from CVE-2015-5211 may be bypassed depending on the browser used through the use of a jsessionid path parameter.
CVE-2020-8225
PUBLISHED: 2020-09-18
A cleartext storage of sensitive information in Nextcloud Desktop Client 2.6.4 gave away information about used proxies and their authentication credentials.
CVE-2020-8237
PUBLISHED: 2020-09-18
Prototype pollution in json-bigint npm package < 1.0.0 may lead to a denial-of-service (DoS) attack.
CVE-2020-8245
PUBLISHED: 2020-09-18
Improper Input Validation on Citrix ADC and Citrix Gateway 13.0 before 13.0-64.35, Citrix ADC and NetScaler Gateway 12.1 before 12.1-58.15, Citrix ADC 12.1-FIPS before 12.1-55.187, Citrix ADC and NetScaler Gateway 12.0, Citrix ADC and NetScaler Gateway 11.1 before 11.1-65.12, Citrix SD-WAN WANOP 11....
CVE-2020-8246
PUBLISHED: 2020-09-18
Citrix ADC and Citrix Gateway 13.0 before 13.0-64.35, Citrix ADC and NetScaler Gateway 12.1 before 12.1-58.15, Citrix ADC 12.1-FIPS before 12.1-55.187, Citrix ADC and NetScaler Gateway 12.0, Citrix ADC and NetScaler Gateway 11.1 before 11.1-65.12, Citrix SD-WAN WANOP 11.2 before 11.2.1a, Citrix SD-W...