Vulnerabilities / Threats
7/11/2013
02:00 AM
50%
50%

Generic TLDs Threaten Name Collisions, Information Leakage

Security problems could ensue if common internal TLDs -- such as .corp and .exchange -- are allowed to be registered

As the Internet Corporation for Assigned Names and Numbers (ICANN) continues its march toward the eventual approval of hundreds, if not more than 1,000, generic top-level domains (gTLDs), security experts warn that some of the proposed names could weaken network security at many companies.

Two major issues could cause problems for companies: If domain names that are frequently used on a company's internal network -- such as .corp, .mail, and .exchange -- become accepted gTLDs, then organizations could inadvertently expose data and server access to the Internet. In addition, would-be attackers could easily pick up certificates for domains that are not yet assigned and cache them for use in man-in-the-middle attacks when the specific gTLD is deployed.

"You will have a lot of people ending up at places [domains] where they do not expect to be," says Jeremy Rowley, associate general counsel for certificate authority DigiCert and a member of the Certificate Authority Security Council (CASC).

Among the most common internal company domain names that are also candidates to become generic TLDs are .home, .corp, .mail, and .exchange. A survey of CASC members found that between 11,000 and 15,000 certificates have been issued for nonroutable domains and could potentially be used to attack, Rowley says.

In addition, information leakage by these systems could cause problems as well. Currently, 25 percent of queries to the domain name system are for devices and computers that do not exist, suggesting the companies are already leaking information to the Internet, according to Danny McPherson, Verisign's chief security officer. While Verisign has its own applications in for global TLDs, the company has arguably more to lose if the rollout of top-level domains goes poorly because it could impact the performance of other facets of the domain-name infrastructure, he says.

"Nobody is providing any adult supervision, and that makes me -- in my role -- very nervous," he says.

The security issues underscore that the ICANN process for creating gTLDs has mainly focused on the companies applying for a specific top-level domain and not on the Internet users who could be impacted by that application, according to two members of PayPal's Information Risk Management group.

[PayPal is among the organizations invited to join a new working group that ultimately will build the framework for the proposed .secure top-level Internet domain. See Selling A Secure Internet Domain.]

ICANN's "analysis and recommendations fall short of what is needed by primarily considering the potential impact of the widespread use of such names to the applicants for these names," wrote Paypal's Brad Hill and Bill Smith in a March letter to ICANN. "The considerable security and operational risks to users of these names is not given adequate consideration. Delegating these names will put millions of users and high value systems at considerable risk."

Another problem hindering any solution: Because the organizations managing the root name servers assiduously maintain their independence from one another, there is little sharing of data about what Internet issues are impacting those servers. When the global TLD systems is turned on, the response to any issue will likely be slowed because of the lack of collaboration and information sharing, he says.

"We need an early warning system," McPherson says. "We need to have visibility across the root. We don't currently have the capability across the root system to say, 'Here is the rate of queries for a certain string and who are asking for it.'"

While any adoption of gTLDs will initially be slow, companies should prepare by moving away from internal names that match any put forth in the gTLD application process, says David Ulevitch, CEO for OpenDNS, a provider of security and DNS services.

"There is going to be a lot of short-term pain because of generic TLDs," Ulevitch says. "Lots of security appliances will not expect to see them, and that will cause the security to break."

The concerns may, in the end, be moot. ICANN could take the feedback from security companies and certificate firms and not approve popular internal naming schemes, such as .corp and .exchange.

"Even though they may not allow those to be registered, it pays to be prepared," says DigiCert's Rowley.

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. Robert Lemos is a veteran technology journalist of more than 16 years and a former research engineer, writing articles that have appeared in Business Week, CIO Magazine, CNET News.com, Computing Japan, CSO Magazine, Dark Reading, eWEEK, InfoWorld, MIT's Technology Review, ... View Full Bio

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
cjturner
50%
50%
cjturner,
User Rank: Apprentice
7/11/2013 | 8:28:21 PM
re: Generic TLDs Threaten Name Collisions, Information Leakage
Another important aspect; the costs related to the use/ownership of well-known names. Many well-known companies and organizations have had to buy up their names in all TLDs. This could get kind of expensive for those guys.
Register for Dark Reading Newsletters
White Papers
Cartoon
Current Issue
Dark Reading December Tech Digest
Experts weigh in on the pros and cons of end-user security training.
Flash Poll
Video
Slideshows
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2014-4807
Published: 2014-11-22
Sterling Order Management in IBM Sterling Selling and Fulfillment Suite 9.3.0 before FP8 allows remote authenticated users to cause a denial of service (CPU consumption) via a '\0' character.

CVE-2014-6183
Published: 2014-11-22
IBM Security Network Protection 5.1 before 5.1.0.0 FP13, 5.1.1 before 5.1.1.0 FP8, 5.1.2 before 5.1.2.0 FP9, 5.1.2.1 before FP5, 5.2 before 5.2.0.0 FP5, and 5.3 before 5.3.0.0 FP1 on XGS devices allows remote authenticated users to execute arbitrary commands via unspecified vectors.

CVE-2014-5395
Published: 2014-11-21
Multiple cross-site request forgery (CSRF) vulnerabilities in Huawei HiLink E3276 and E3236 TCPU before V200R002B470D13SP00C00 and WebUI before V100R007B100D03SP01C03, E5180s-22 before 21.270.21.00.00, and E586Bs-2 before 21.322.10.00.889 allow remote attackers to hijack the authentication of users ...

CVE-2014-7137
Published: 2014-11-21
Multiple SQL injection vulnerabilities in Dolibarr ERP/CRM before 3.6.1 allow remote authenticated users to execute arbitrary SQL commands via the (1) contactid parameter in an addcontact action, (2) ligne parameter in a swapstatut action, or (3) project_ref parameter to projet/tasks/contact.php; (4...

CVE-2014-7871
Published: 2014-11-21
SQL injection vulnerability in Open-Xchange (OX) AppSuite before 7.4.2-rev36 and 7.6.x before 7.6.0-rev23 allows remote authenticated users to execute arbitrary SQL commands via a crafted jslob API call.

Best of the Web
Dark Reading Radio
Archived Dark Reading Radio
Now that the holiday season is about to begin both online and in stores, will this be yet another season of nonstop gifting to cybercriminals?