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.


Domain Security Needs More Than Registry Locks

Protecting domains requires registry locks as well as other measures, including two-factor authentication and administrative access control

Today's networking infrastructure relies on the domain name system -- not only a company's public-facing Web servers and Internet appliances, but much of its private infrastructure as well.

But enterprises need to better protect their DNS environments, as last week's attack on a reseller of domain registrar MelbourneIT and the subsequent redirection of The New York Times, the Huffington Post, and two subsidiary Twitter domains demonstrated. While the attacks should not have come as a surprise, the vast majority of companies are unprepared for such malicious attention.

Only a small fraction of companies are taking the security measures necessary to protect their domains from attack, says Danny McPherson, vice president and chief security officer for VeriSign. Even companies and individuals that are conscious of security issues tend to give their domain name registrations short shrift, he says.

"People invest tens or even hundreds of millions of dollars on content distribution infrastructure, data centers, and other things, and they use a fixed password with their registrar and a $10 domain name," he says.

Following last week's compromise, companies jumped to protect their domains from changes using a registry security feature known as a registry lock. Yet McPherson and others point out that a registry lock, while an essential step to protecting a business's domain, is not sufficient. Companies need to take an in-depth look at how they handle their domains, who has access to those domains, and the vetting of their registrars, he says.

Two documents produced by the Internet Corporation for Assigned Names and Numbers (ICANN) are a good starting point for companies. Produced by ICANN's Security and Stability Advisory Committee, the documents -- SAC040 and SAC044 -- inform companies about the measures their registrar uses to protect registration services against misuse and advises businesses about how to protect their own domain names.

As described, a registry lock protects domains against changes, deletion, and transfers using registrar status codes. But security experts and the documents recommend other steps as well:

1. Check out your registrar
By all accounts, MelbourneIT is a responsible, security-conscious registrar. Despite that good reputation, hacktivists circumvented the company's business processes to gain control of its domain administration system for a short time.

Like any third party, registrars should be quizzed on their security measures, says Jaime Blasco, director of research for unified-security provider AlienVault. While smaller firms may not have the clout of larger firms, they can still shop around and ask for additional security measures for their domain, he says.

"If you are a big company, ask the registrar what security mechanisms do they have in place as part of your risk-assessment process," Blasco says. "Taking into account how secure the registrar is should be one of the priorities for companies right now."

2. Passwords are not good enough
Securing the foundation of business infrastructure with a simple password, no matter how complex, is dangerous. Any business that does not take more stringent security measures is a single phishing attack away from losing their domains, says Rodney Joffe, senior vice president and technologist at domain-registry Neustar.

Companies should have at least two-factor authentication in place, so that any change to the domain records requires a passcode sent or generated through another channel. Because e-mail accounts tend to be a first target of attackers, using two-factor authentication that relies on e-mail is not good enough, Joffe says.

"Obviously if a domain holder's email account has been compromised, the hijacker can still get the second factor and make changes, so the better systems typically utilize text messages to cell phone numbers," he says.

3. Track access to DNS records
While two-factor authentication can shrink the attack surface area that leads to a company's domain records, businesses also need to minimize the number of employees with the ability to change a domain records. At the same time, having multiple points of contact can add redundancy that is important in an emergency.

Overall, companies should make sure that each step of the domain name system has adequate points of contact and verify that only the people who need to access the systems have authorization, says VeriSign's McPherson.

"It's important for people to consider the ecosystem, all the way from the registrant, all the way forward to something like DNSSEC to even validating recursive name servers in the infrastructure," he says. "It helps you to minimize your attack surface in the active infrastructure."

[A report has sparked a new round of discussions about policing the Internet ecosystem and whether the Internet Corporation for Assigned Names and Numbers (ICANN) is doing enough to combat the problem. See Rogue Domain Registrars Pose Challenges.]

4. Monitor your DNS records for changes
Registry locks, DNS Security and other technologies are not infallible protections against attackers, but are methods of raising the bar higher. But just as important, in circumventing the protections, attackers will essentially set off alarms.

For that reasons, companies need to be monitoring their DNS records to any unauthorized changes, says AlienVault's Blasco.

"Implementing monitoring and health checks of the infrastructure is one of the key things that companies can do," he says.

Have a comment on this story? Please click "Add Your Comment" below. If you'd like to contact Dark Reading's editors directly, send us a message. Veteran technology journalist of more than 20 years. Former research engineer. Written for more than two dozen publications, including CNET News.com, Dark Reading, MIT's Technology Review, Popular Science, and Wired News. Five awards for journalism, including Best Deadline ... View Full Bio

Comment  | 
Print  | 
More Insights
Newest First  |  Oldest First  |  Threaded View
Mobile Banking Malware Up 50% in First Half of 2019
Kelly Sheridan, Staff Editor, Dark Reading,  1/17/2020
Active Directory Needs an Update: Here's Why
Raz Rafaeli, CEO and Co-Founder at Secret Double Octopus,  1/16/2020
New Attack Campaigns Suggest Emotet Threat Is Far From Over
Jai Vijayan, Contributing Writer,  1/16/2020
Register for Dark Reading Newsletters
White Papers
Cartoon Contest
Current Issue
The Year in Security: 2019
This Tech Digest provides a wrap up and overview of the year's top cybersecurity news stories. It was a year of new twists on old threats, with fears of another WannaCry-type worm and of a possible botnet army of Wi-Fi routers. But 2019 also underscored the risk of firmware and trusted security tools harboring dangerous holes that cybercriminals and nation-state hackers could readily abuse. Read more.
Flash Poll
How Enterprises are Attacking the Cybersecurity Problem
How Enterprises are Attacking the Cybersecurity Problem
Organizations have invested in a sweeping array of security technologies to address challenges associated with the growing number of cybersecurity attacks. However, the complexity involved in managing these technologies is emerging as a major problem. Read this report to find out what your peers biggest security challenges are and the technologies they are using to address them.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
PUBLISHED: 2020-01-23
In Secure Headers (RubyGem secure_headers), a directive injection vulnerability is present in versions before 3.9.0, 5.2.0, and 6.3.0. If user-supplied input was passed into append/override_content_security_policy_directives, a newline could be injected leading to limited header injection. Upon seei...
PUBLISHED: 2020-01-23
In Secure Headers (RubyGem secure_headers), a directive injection vulnerability is present in versions before 3.8.0, 5.1.0, and 6.2.0. If user-supplied input was passed into append/override_content_security_policy_directives, a semicolon could be injected leading to directive injection. This could b...
PUBLISHED: 2020-01-23
In PrivateBin versions 1.2.0 before 1.2.2, and 1.3.0 before 1.3.2, a persistent XSS attack is possible. Under certain conditions, a user provided attachment file name can inject HTML leading to a persistent Cross-site scripting (XSS) vulnerability. The vulnerability has been fixed in PrivateBin v1.3...
PUBLISHED: 2020-01-23
A timing vulnerability in the Scalar::check_overflow function in Parity libsecp256k1-rs before 0.3.1 potentially allows an attacker to leak information via a side-channel attack.
PUBLISHED: 2020-01-22
An issue was discovered on Eaton 5P 850 devices. The Ubicacion SAI field allows XSS attacks by an administrator.