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
Newest First  |  Oldest First  |  Threaded View
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
Everything You Need to Know About DNS Attacks
It's important to understand DNS, potential attacks against it, and the tools and techniques required to defend DNS infrastructure. This report answers all the questions you were afraid to ask. Domain Name Service (DNS) is a critical part of any organization's digital infrastructure, but it's also one of the least understood. DNS is designed to be invisible to business professionals, IT stakeholders, and many security professionals, but DNS's threat surface is large and widely targeted. Attackers are causing a great deal of damage with an array of attacks such as denial of service, DNS cache poisoning, DNS hijackin, DNS tunneling, and DNS dangling. They are using DNS infrastructure to take control of inbound and outbound communications and preventing users from accessing the applications they are looking for. To stop attacks on DNS, security teams need to shore up the organization's security hygiene around DNS infrastructure, implement controls such as DNSSEC, and monitor DNS traffic
Flash Poll
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2023-33196
PUBLISHED: 2023-05-26
Craft is a CMS for creating custom digital experiences. Cross site scripting (XSS) can be triggered by review volumes. This issue has been fixed in version 4.4.7.
CVE-2023-33185
PUBLISHED: 2023-05-26
Django-SES is a drop-in mail backend for Django. The django_ses library implements a mail backend for Django using AWS Simple Email Service. The library exports the `SESEventWebhookView class` intended to receive signed requests from AWS to handle email bounces, subscriptions, etc. These requests ar...
CVE-2023-33187
PUBLISHED: 2023-05-26
Highlight is an open source, full-stack monitoring platform. Highlight may record passwords on customer deployments when a password html input is switched to `type="text"` via a javascript "Show Password" button. This differs from the expected behavior which always obfuscates `ty...
CVE-2023-33194
PUBLISHED: 2023-05-26
Craft is a CMS for creating custom digital experiences on the web.The platform does not filter input and encode output in Quick Post validation error message, which can deliver an XSS payload. Old CVE fixed the XSS in label HTML but didn’t fix it when clicking save. This issue was...
CVE-2023-2879
PUBLISHED: 2023-05-26
GDSDB infinite loop in Wireshark 4.0.0 to 4.0.5 and 3.6.0 to 3.6.13 allows denial of service via packet injection or crafted capture file