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 7/2/2020
Ripple20 Threatens Increasingly Connected Medical Devices
Kelly Sheridan, Staff Editor, Dark Reading,  6/30/2020
DDoS Attacks Jump 542% from Q4 2019 to Q1 2020
Dark Reading Staff 6/30/2020
Register for Dark Reading Newsletters
White Papers
Video
Cartoon
Current Issue
How Cybersecurity Incident Response Programs Work (and Why Some Don't)
This Tech Digest takes a look at the vital role cybersecurity incident response (IR) plays in managing cyber-risk within organizations. Download the Tech Digest today to find out how well-planned IR programs can detect intrusions, contain breaches, and help an organization restore normal operations.
Flash Poll
The Threat from the Internetand What Your Organization Can Do About It
The Threat from the Internetand What Your Organization Can Do About It
This report describes some of the latest attacks and threats emanating from the Internet, as well as advice and tips on how your organization can mitigate those threats before they affect your business. Download it today!
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2020-9498
PUBLISHED: 2020-07-02
Apache Guacamole 1.1.0 and older may mishandle pointers involved inprocessing data received via RDP static virtual channels. If a userconnects to a malicious or compromised RDP server, a series ofspecially-crafted PDUs could result in memory corruption, possiblyallowing arbitrary code to be executed...
CVE-2020-3282
PUBLISHED: 2020-07-02
A vulnerability in the web-based management interface of Cisco Unified Communications Manager, Cisco Unified Communications Manager Session Management Edition, Cisco Unified Communications Manager IM & Presence Service, and Cisco Unity Connection could allow an unauthenticated, remote attack...
CVE-2020-5909
PUBLISHED: 2020-07-02
In versions 3.0.0-3.5.0, 2.0.0-2.9.0, and 1.0.1, when users run the command displayed in NGINX Controller user interface (UI) to fetch the agent installer, the server TLS certificate is not verified.
CVE-2020-5910
PUBLISHED: 2020-07-02
In versions 3.0.0-3.5.0, 2.0.0-2.9.0, and 1.0.1, the Neural Autonomic Transport System (NATS) messaging services in use by the NGINX Controller do not require any form of authentication, so any successful connection would be authorized.
CVE-2020-5911
PUBLISHED: 2020-07-02
In versions 3.0.0-3.5.0, 2.0.0-2.9.0, and 1.0.1, the NGINX Controller installer starts the download of Kubernetes packages from an HTTP URL On Debian/Ubuntu system.