Latest news of the domain name industry

Recent Posts

Most ICANN new gTLD breaches were over a year ago

Almost three quarters of the security breaches logged against ICANN’s new gTLD portal occurred over a three-month period in early 2014, DI can reveal.

Almost every incident of a new gTLD applicant coming across data they weren’t supposed to see — 322 of the 330 total — happened before the end of October last year, ICANN told DI.

Most — 244 of the 330 — happened before April 30 last year.

The first breach, discovered by an independent audit of the portal, was January 22 2014.

ICANN says it was first notified of there being a problem on February 27, 2015.

The improper data disclosures were announced by ICANN last week.

As we reported, a simple configuration error by ICANN in third-party software allowed users of the Global Domains Division portal — all new gTLD applicants — to view confidential data belonging to other applicants.

Documents revealed could have included sensitive financial projections and registry technical details.

My first assumption was that the majority of the incidents — which have been deliberate or accidental — were relatively recent, but that turns out not to be the case.

In fact, if anyone did download data they weren’t supposed to see, most of them did it over a year ago.

ICANN has been notifying applicants and registries about whether their own data was compromised and expects to have told each affected applicant which other applicants could have seen their data before May 27.

Ninety-six applicants and 21 registries were affected.

Dumb ICANN bug revealed secret financial data to new gTLD applicants

Kevin Murphy, April 30, 2015, Domain Registries

Secret financial projections were among 330 pieces of confidential data revealed by an ICANN security bug.

Over the last two years, a total of 19 new gTLD applicants used the bug to access data belonging to 96 applicants and 21 registry operators.

That’s according to ICANN, which released the results of a third-party audit this afternoon.

Ashwin Rangan, ICANN’s new chief information and innovation officer, confirmed to DI this afternoon that the data revealed to unauthorized users included private financial and technical documents that gTLD applicants attached to their applications.

It would have included, for example, documents that dot-brand applicants reluctantly submitted to demonstrate their financial health.

But Rangan said it was not clear whether the glitch had been exploited deliberately or accidentally.

While saying the situation was “very deeply regrettable”, he added that applicant data deemed confidential when it was submitted back in 2012 may not be considered as such today.

The vulnerability was in ICANN’s Global Domains Division Portal, which was taken offline for three days at the end of February and early March after the bug was reported by a user.

Two outside consulting firms were brought in to scan access logs going back to the launch of the new gTLD portal back in April 2013.

What they found was that any user of the portal could access any attachment to any application, whether it belonged to them or a third-party applicant, simply by checking a radio button in the advanced search feature.

It was a misconfiguration by ICANN of the Salesforce.com software used by GDD, rather than a coding error, Rangan said.

“The public/private data sharing setting can be On or Off and here it was set to On,” he said.

On 330 occasions, starting “in earliest part of when the portal first became available” two years ago, these 19 users would have been exposed to data they were not supposed to be able to see.

The audit has been unable to determine whether the users actually downloaded confidential data on those occasions.

What’s confirmed is that only new gTLD applicants were able to use the glitch. No third-party hackers were involved.

The 19 users who, whether they meant to or not, exploited this vulnerability are now going to be sent letters asking them to explain themselves. They’ll also be asked to delete anything they downloaded and to not share it with third parties.

Before May 27, ICANN will also contact those applicants whose secret data was exposed, telling them which rival applicants could have seen it.

Rangan said that there have been almost 600,000 GDD sessions in the last two years, and that only 36 of them revealed data to unauthorized users.

“It’s a small fraction,” he said. “The question is whether they just stumbled across something they were not even aware of… Looking at the log files it is not clear what is the case.”

ICANN seems to be giving the 19 users the benefit of the doubt so far, but still wants them to explain their actions.

As CIO, Rangan was not able to comment on whether the breach exposes ICANN or applicants to any kind of legal liability.

It’s not the first time sensitive applicant data has been exposed. Back in 2012, DI discovered that the home addresses of the directors of applicants had been published, despite promises that they would remain private.

At the time of the original GDD portal misconfiguration, ICANN had noted security expert Jeff “The Dark Tangent” Moss as its chief security officer.

Earlier this week, ICANN’s board of directors authorized expenses of over $500,000 to carry out security audits of ICANN’s code.

Adware dominating popular new gTLD ranks

Kevin Murphy, March 11, 2015, Domain Registries

Afilias’ .kim has become the latest victim (beneficiary?) of adware, as robo-registrations boost the gTLD’s zone file and apparent popularity.

It’s the latest new gTLD, after .xyz and .country, to see its rankings soar after hundreds of gibberish, bulk-registered domains started being used to serve ads by potentially unwanted software.

.kim is today the 4th most-popular new gTLD, with 85 domains in the top 100,000 on the internet and 264 in the top one million.

A month ago, it had a rank of 223, with just 16 domains in the top one million.

The domain names involved — gems such as oatmealsmoke.kim, vegetableladybug.kim and tubhaircut.kim — have seen a boat-load of traffic and rocketing Alexa rank.

The reason for the boost seems to be a one-off bulk registration of about 1,000 meaningless .kim domain names in early February, which now appear to be being used to serve ads via adware.

In this chart (click to enlarge), we see .kim’s zone file growth since the start of 2015.

The spike on February 5, which represents over 1,000 names, is the date almost all of the .kim names with Alexa rank were first registered.

They all appear to be using Uniregistry as the registrar and its free privacy service to mask their Whois details.

These domains often do not resolve if you type them into your browser. They’re also using robots.txt to hide themselves from search engines.

But they’ve been leaving traces of their activity elsewhere on the web, strongly suggesting their involvement in adware campaigns.

It seems that the current (ab?)use of .kim domains is merely the latest in a series of possibly linked campaigns.

I noted in January that gibberish .country domains — at the time priced at just $1 at Uniregistry — were suddenly taking over from .xyz in the popularity charts.

The following three charts, captured from DI PRO’s TLD Health Check, show how the three TLDs’ Alexa popularity rose and fell during what I suspect were related adware campaigns..

First, .xyz, which was the first new gTLD to show evidence of having robo-registrations used in adware campaigns, saw its popularity spike at the end of 2014 and start of 2015:

Next, Minds + Machines’ .country, which saw its zone file spike by 1,500 names around January 6, starts to see its Alexa-ranked total rocket almost immediately.

.country peaks around February 9, just a few days after the .kim robo-registrations were made.

Finally, as .country’s use declines, .kim takes over. Its popularity has been growing day by day since around February 13.

I think what we’re looking at here is one shadowy outfit cycling through bulk-registered, throwaway domain names to serve ads via unwanted adware programs.

It seems possible that domains are retired when they become sufficiently blocked by security countermeasures, and other domains in other TLDs are then brought online to take over.

None of this necessarily reflects badly on any of the new gTLDs in question, or even new gTLDs as a whole, of course.

For starters, I’ve reason to believe that TLDs such as .eu and .biz have previously been targeted by the same people.

The “attacks”, for want of a better word, are only really noticeable because the new gTLDs being targeted are young and still quite small.

It takes much longer to build up genuine popularity for a newly launched web site than it does to merely redirect exist captive traffic to a newly registered domain.

What it may mean, however, is that .kim and .country are going to be in for statistically significant junk drops about a year from now, when the first-year registrations expire.

For .kim, 1,000 names is about 14% of its current zone file. For .country, it’s more like a quarter.

The daily-updated list of new gTLD domains with Alexa rank can be explored by DI PRO subscribers here. The charts in this post were all captured from the respective TLD’s page on TLD Health Check.

More security issues prang ICANN site

Kevin Murphy, March 3, 2015, Domain Tech

ICANN has revealed details of a security problem on its web site that could have allowed new gTLD registries to view data belonging to their competitors.

The bug affected its Global Domains Division customer relationship management portal, which registries use to communicate with ICANN on issues related to delegation and launch.

ICANN took GDD down for three days, from when it was reported February 27 until last night, while it closed the hole.

The vulnerability would have enabled authenticated users to see information from other users’ accounts.

ICANN tells me the issue was caused because it had misconfigured some third-party software — I’m guessing the Salesforce.com platform upon which GDD runs.

A spokesperson said that the bug was reported by a user.

No third parties would have been able to exploit it, but ICANN has been coy about whether any it believes any registries used the bug to access their competitors’ accounts.

ICANN has ‘fessed up to about half a dozen crippling security problems in its systems since the launch of the new gTLD program.

Just in the last year, several systems have seen downtime due to vulnerabilities or attacks.

A similar kind of privilege escalation bug took down the Centralized Zone Data Service last April.

The RADAR service for registrars was offline for two weeks after being hacked last May.

A phishing attack against ICANN staff in December enabled hackers to view information not normally available to the public.

Domain hijacking bug found in Go Daddy

Kevin Murphy, January 22, 2015, Domain Registrars

Go Daddy has rushed out a fix to a security bug in its web site that could have allowed attackers to steal valuable domain names.

Security engineer Dylan Saccomanni found several “cross site request forgery” holes January 17, which he said could be used to “edit nameservers, change auto-renew settings and edit the zone file entirely”.

He reported it to Go Daddy (evidently with some difficulty) and blogged it up, with attack code samples, January 18. Go Daddy reportedly patched its site the following day.

A CSRF vulnerability is where a web site fails to adequately validate data submitted via HTTP POST. Basically, in this case Go Daddy apparently wasn’t checking whether commands to edit name servers, for example, were being submitted via the correct web site.

Mitigating the risk substantially, attackers would have to trick the would-be victim domain owner into filling out a web form on a different site, while they were simultaneously logged into their Go Daddy accounts, in order to exploit the vulnerability, however.

In my experience, Go Daddy times out logged-in sessions after a period, reducing the potential attack window.

Being phishing-aware would also reduce your chance of being a victim.

I’m not aware of any reports of domains being lost to this attack.

Human glitch lets hackers into ICANN

Kevin Murphy, December 17, 2014, Domain Policy

It’s 2014. Does anyone in the domain name business still fall for phishing attacks?

Apparently, yes, ICANN staff do.

ICANN has revealed that “several” staff members fell prey to a spear-phishing attack last month, resulting in the theft of potentially hundreds of user credentials and unauthorized access to at least one Governmental Advisory Committee web page.

According to ICANN, the phishers were able to gather the email passwords of staff members, then used them to access the Centralized Zone Data Service.

CZDS is the clearinghouse for all zone files belonging to new gTLD registries. The data it stores isn’t especially sensitive — the files are archives, not live, functional copies — and the barrier to signing up for access legitimately is pretty low.

But CZDS users’ contact information and login credentials — including, as a matter of disclosure, mine — were also accessed.

While the stolen passwords were encrypted, ICANN is still forcing all CZDS users to reset their passwords as a precaution. The organization said in a statement:

The attacker obtained administrative access to all files in the CZDS. This included copies of the zone files in the system, as well as information entered by users such as name, postal address, email address, fax and telephone numbers, username, and password. Although the passwords were stored as salted cryptographic hashes, we have deactivated all CZDS passwords as a precaution. Users may request a new password at czds.icann.org. We suggest that CZDS users take appropriate steps to protect any other online accounts for which they might have used the same username and/or password. ICANN is providing notices to the CZDS users whose personal information may have been compromised.

As a victim, this doesn’t worry me a lot. My contact details are all in the public Whois and published on this very web site, but I can imagine other victims might not want their home address, phone number and the like in the hands of ne’er-do-wells.

It’s the second time CZDS has been compromised this year. Back in April, a coding error led to a privilege escalation vulnerability that was exploited to view requests by users to new gTLD registries.

Also accessed by the phishers this time around were several pages on the GAC wiki, which is about as interesting as it sounds (ie, not very). ICANN said the only non-public information that was viewed was a “members-only index page”.

User accounts on the ICANN blog and its Whois information portal were also accessed, but apparently no damage was caused.

In summary, the hackers seem to have stolen quite a lot of information they could have easily obtained legitimately, along with some passwords that may allow them to cause further mischief if they can be decrypted.

It’s embarrassing for ICANN, of course, especially for the staff members gullible enough to fall for the attack.

While the phishers made their emails appear to come from ICANN’s own domain, presumably their victims would have had to click through to a web page with a non-ICANN domain in the address bar order to hand over their passwords.

That’s not the kind of practice you’d expect from the people tasked with running the domain name industry.

As .trust opens for sunrise, Artemis dumps .secure bid

Kevin Murphy, December 16, 2014, Domain Registries

Amazon is now the proud owner of the .secure new gTLD, after much smaller competing applicant Artemis Internet withdrew its bid.

Coincidentally, the settlement of the contention set came just yesterday, the day before Artemis took its .trust — which I’ve described as a “backup plan” — to sunrise.

I assume .secure was settled with a private deal. I’ve long suspected Artemis — affiliated with data escrow provider NCC Group — had its work cut out to win an auction against Amazon.

It’s a shame, in a way. Artemis was one of the few new gTLD applicants that had actually sketched out plans for something quite technologically innovative.

Artemis’ .secure was to be a “trust mark” for a high-priced managed security service. It wasn’t really about selling domain names in volume at all.

The company had done a fair bit of outreach work, too. As long ago as July 2013, around 30 companies had expressed their interest in signing up as anchor tenants.

But, after ICANN gave Amazon a get-out-of-jail-free card by allowing it to amend its “closed generic” gTLD applications, it looked increasingly unlikely Artemis would wind up owning the gTLD it was essentially already pre-selling.

In February this year, it emerged that it had acquired the rights to .trust from Deutsche Post, which had applied for the gTLD unopposed.

This Plan B was realized today when .trust began its contractually mandated sunrise period.

Don’t expect many brands to apply for their names during sunrise, however — .trust’s standard registration policies are going to make cybersquatting non-existent.

Not only will .trust registrants have their identities manually vetted, but there’s also a hefty set of security standards — 123 pages (pdf) of them at the current count — that registrants will have to abide by on an ongoing basis in order to keep their names.

As for Amazon, its .secure application, as amended, is just as vague as all of its other former bids for closed, single-registrant generic strings (to the point where I often wonder if they’re basically still just closed generics).

It’s planning to deploy a small number of names to start with, managed by its own intellectually property department. After that, its application all gets a bit hand-wavey.

Russian hackers breaking in to NameCheap accounts

Kevin Murphy, September 2, 2014, Domain Registrars

If you have an account at NameCheap, now might be a good time to think about changing your password.

According to the registrar, hackers based in Russia are using a haul of a reported 4.5 billion username/password combinations to attempt to break into its customers’ accounts.

Some attempts have been successful, NameCheap warned.

The attackers are using credentials stolen from third-party sources in a large-scale, automated attempt to log in to user accounts, disguised as regular users, the company said in a blog post.

NameCheap said:

The vast majority of these login attempts have been unsuccessful as the data is incorrect or old and passwords have been changed. As a precaution, we are aggressively blocking the IP addresses that appear to be logging in with the stolen password data. We are also logging these IP addresses and will be exporting blocking rules across our network to completely eliminate access to any Namecheap system or service, as well as making this data available to law enforcement.

While the vast majority of these logins are unsuccessful, some have been successful. To combat this, we’ve temporarily secured the Namecheap accounts that have been affected and are currently contacting customers involved requesting they improve the security for these accounts.

Affected users have been emailed, the company said.

NameCheap suspects the attack is linked to a reported cache of 1.2 billion unique username/password combinations amassed by a hacker group from databases vulnerable to SQL injection.

The registrar pointed out that its own systems haven’t been hacked. Customers should only be vulnerable if they use the same username and password at NameCheap as they use on other sites.

RADAR to be down at least two weeks after hack

ICANN expects its RADAR registrar database to be offline for “at least two weeks” following the discovery of a security vulnerability that exposed users’ login names and encrypted passwords.

ICANN seems to have been quick to act and to disclose the hack.

The attack happened last weekend and ICANN was informed about it by an “internet user” on Tuesday May 27, according to an ICANN spokesperson. RADAR was taken offline and the problem disclosed late May 28.

The spokesperson added that “we do not believe the user is affiliated with a current or previously accredited registrar.”

ICANN isn’t disclosing the nature of the vulnerability, but said RADAR will be offline for some time for a security audit. The spokesperson told DI in an email:

It will be at least two weeks. It is more important to complete a thorough security assessment of the site than to rush this process. First of all, we’re keeping the system offline until we complete a thorough audit of the system. We are also currently engaged in a security review of all systems and procedures at ICANN to assess and implement ongoing improvements as appropriate.

RADAR is a database used by registrars to coordinate stuff like emergency contacts and IP address whitelisting for bulk Whois access.

The downtime is not expected to impact registrants, according to ICANN. The spokesperson said: “Nothing that occurred has raised any concerns that registrants could or would be adversely affected.”

ICANN registrar database hacked

ICANN’s database of registrar contact information has been hacked and user data has been stolen.

The organization announced this morning that the database, known as RADAR, has been taken offline while ICANN conducts a “thorough review” of its security.

ICANN said:

This action was taken as a precautionary measure after it was learned that an unauthorized party viewed data in the system. ICANN has found no evidence of any unauthorized changes to the data in the system. Although the vulnerability has been corrected, RADAR will remain offline until a thorough review of the system is completed.

Users of the system — all registrars — have had their usernames, email addresses and encrypted passwords compromised, ICANN added.

ICANN noted that it’s possible to brute-force a hashed password into plaintext, so it’s enforcing a password reset on all users, but it has no evidence of any user accounts being accessed.

RADAR users may want to think about whether they have the same username/password combinations at other sites.

RADAR is a database used by registrars in critical functions such as domain name transfers.

Registrars can use it, for example, to white-list the IP addresses of rival registrars, enabling them to execute large amounts of Whois queries that would usually be throttled.

The news follows hot on the heels of a screwup in the Centralized Zone Data Service, which enabled any new gTLD registry to view data belonging to rival registries and other CZDS users.