Chehade says “no delay” as Verisign drops a security bomb on ICANN

Verisign today said that the new gTLD program presents risks to the security of the internet, but ICANN CEO Fadi Chehade told DI that he’s not expecting any new delays.
The .com behemoth tonight delivered a scathing review of the security and stability risks of launching new gTLDs on ICANN’s current timetable.
The new Verisign report catalogs the myriad ways in which ICANN is not ready to start approving new gTLDs, and the various security problems they could cause if launched without due care.
It strongly suggests that ICANN should delay the program until its concerns are addressed.
But Chehade, in an exclusive interview with DI tonight, rebutted the already-emerging conspiracy theories and said: “There’s nothing new here that would cause me to predict a new delay.”
What does the Verisign report say?
It’s a 21-page document, and it covers a lot of ground.
The gist of it is that ICANN is rushing to launch new gTLDs without paying enough attention to the potential security and stability risks that a vast influx of new gTLDs could cause.
It covers about a dozen main points, but here are the highlights:

• Certificate authorities and browser makers are not ready. CAs have long issued certificates for use on organizations’ internal networks. In many cases, these certs will use TLDs that only exist on that internal network. A company might have a private .mail TLD, for example, and use certs to secure those domains for its users. The CA/Browser Forum, which coordinates CAs and browser makers, has decided (pdf) to deprecate these certs, but not until October 2016. This, Verisign says, creates a “vulnerability window” of three years during which attackers could exploit clashes between certs on internal TLDs and new gTLDs.
• Root server operators are not ready. The organizations that run the 13 DNS root servers do not currently coordinate their performance metrics, Verisign said. This makes it difficult to see what impact new gTLDs will have on root server stability. “The current inability to view the root server system’s performance as a whole presents a risk when combined with the impending delegation of the multitude of new gTLDs,” Verisign said.
• Root zone automation isn’t done yet. ICANN, Verisign and the US Department of Commerce are responsible for adding new gTLDs to the root zone, and work on automating the “TLD add” process is not yet complete. Verisign reckons this could cause “data integrity” problems at the root.
• The Trademark Clearinghouse is not ready. Delays in finalizing the TMCH technical specs mean registries haven’t had sufficient time to build their interfaces and test them, and the TMCH itself is a potential single point of failure with an unknown attack profile.
• Universal acceptance of new TLDs. Verisign points out that new gTLDs won’t be immediately available to users when they go live due to lack of software support. It points specifically to the ill-maintained Public Suffix List, used by browsers to set cookie boundaries, as a potential risk factor.
• A bunch of other stuff. The report highlights issues such as zone file access, data escrow, Whois and pre-delegation testing where Verisign reckons ICANN has not given registries enough time to prepare.

Basically, Verisign has thrown pretty much every risk factor it can think of into the document.
Some of the issues of concern have been well-discussed in the ICANN community at large, others not so much.
Yeah, yeah, but what did Fadi say?
Chehade told DI this evening that he was surprised by the report. He said he’s been briefed on its contents today and that there’s “nothing new” in it. The program is “on track”, he said.
“What is most surprising here is that there is nothing new,” he said. “I’m trying to get my finger on what is new here and I can’t find it.”
“It was very surprising to see this cornucopia of things put together,” he said. “I’m struggling to see how the Trademark Clearinghouse has a security impact, for example.”
He added that some of Verisign’s other concerns, such as the fact that the Emergency Back-End Registry Operator is not yet up and running, are confusing given that existing TLDs don’t have EBEROs.
The report could be divided into two buckets, he said: those things related to ICANN’s operational readiness and those things related to the DNS root.
“Are these operational issues really security and stability risks, and given that we can only launch TLDs when these things are done… what’s the issue there?” he said.
On the DNS root issues, he pointed to a November 2012 report, signed by Verisign, that said the root is ready to take 1,000 new gTLDs a year or 100 a week.
So the Conspiracy Theory is wrong?
When ICANN held a webinar for new gTLD applicants earlier this week, Chehade spent an inordinate amount of time banging home the point that security and stability concerns underpin every stage of the new gTLD program’s timetable.
As this slide from his presentation (click to enlarge) illustrates, security, stability and resiliency or “SSR” is the foundation of every timing assumption.
He said during the webinar:

Nothing will trump the gTLD process, nothing, but the SSR layer. The SSR layer is paramount. It is our number one responsibility to the internet community. Nothing will be done that jeopardizes the security and stability of the internet, period.
At any time if we as a community do not believe that all relevant security and stability matters have been addressed, if we do not believe that’s the case, the program freezes, period.
There is too much riding on the DNS. Hundreds of billions of dollars of commerce. Some may say livelihoods. We will not jeopardize it, not on my watch, not during my administration.

During the webinar, I was lurking on an unofficial chat room of registries, registrars and others, where the mood at that point could be encapsulated by: “Shit, what does Chehade know that he’s not telling us?”
Most people listening to the webinar were immediately suspicious that Chehade was expecting to receive some last-minute security and stability advice and that he was preparing the ground for delay.
The Verisign report was immediately taken as confirmation that their suspicions were correct.
It seemed quite likely that ICANN knew in advance that the report was coming down the pike and was not-so-subtly readying applicants for a serious SSR discussion in Beijing a little over a week from now.
When I asked Chehade a few times whether he knew the Verisign report was coming in advance, he declined to give a straight answer.
My feeling is he probably did, though he may not have known precisely what it was going to say. The question is perhaps less relevant given what he said about its contents.
But what Chehade thinks right now is probably not the biggest concern for new gTLD applicants.
The GAC’s reaction is now critical
The Verisign document could be seen as pure GAC fodder. How the Governmental Advisory Committee reacts to the report, which was CC’d to the US Department of Commerce, is now key.
The GAC has been banging on about root system stability for years and will, in my view, lap up anything that seems to prove that it was right all along.
The GAC will raise the Verisign report with ICANN in Beijing and, if it doesn’t like what it hears, it might advise delay. GAC advice is a lot harder for ICANN’s board to ignore than a self-serving Verisign report.
What’s Verisign playing at?
So why did Verisign issue the report now? I’ve been unable to get the company on the phone at this late hour, but I’ve asked some other industry folk for their responses.
Verisign’s super-lucrative .com contract is the obvious place to start theorizing.
Even though the company has over 200 new gTLD back-end contracts — largely with dot-brand applicants — .com is its cash cow and new gTLDs are a potential threat to that business.
The company has sounded a little more aggressive — talking about enforcing its patents and refusing to comply with ICANN’s audits — since the US Department of Commerce ordered a six-year .com price freeze last November.
But Chehade would not speculate too much about Verisign’s motives.
“I can’t read why this report and why now,” Chehade said. “Especially when there’s nothing new in it. That’s not for me to figure out. It’s for me to look at this report with a critical eye and understand if there’s something we’re not addressing. If there is, and we find it, we’ll address it.”
He pointed to a flurry of phone calls and emails to his desk after the Initial Evaluation results started getting published last week for a possible reason for the report’s timing.
“I think the real change that’s happened in the last few months is that the new gTLD program is now on track and for the first time people are seeing it coming,” he said.
Competitors were more blunt.
“It’s a bloody long report,” said ARI Registry Services CEO Adrian Kinderis. “Had they put the same amount of effort into working with ICANN, we’d be a lot better off on the particular issues.”

Hackers may have stolen .edu domain passwords

Owners of .edu domain names have been told to change their passwords after hackers compromised a server belonging to registry manager Educause.
The registry said today that it has deactivated the admin passwords for all .edu domains after discovering a “security breach” that gave attackers access to hashed passwords for .edu registrants.
The attack also compromised passwords for users of the Educause web site, the organization said.
The .edu domain is of course reserved for US-based educational institutions, and is considered one of the most secure and prestigious TLDs available.
Educause said it “immediate steps to contain this breach and is working with Federal law enforcement, investigators, and security experts to make sure this incident is properly addressed.”
The registry did not say whether the attack is related to the attack against the Massachusetts Institute of Technology last month, which reportedly was enabled via an Educase hack.

Is .home back on ICANN’s new gTLD risk list?

While most new gTLD applicants were focused on delays to the program revealed during last Friday’s ICANN webinar, another bit of news may also be a cause for concern for .home applicants.
As Rubens Kuhl of Nic.br spotted, ICANN revealed that 11 applications have not yet passed their DNS Stability check.

That’s a reversal from November, when ICANN said that all new gTLD applications had passed the stability review.
As I noted at the time, that was good news for .home, which some say may cause security problems if it is delegated.
As Kuhl observed, there are exactly 11 applications for .home, the same as the number of applications that now appear to have un-passed the DNS Stability check.
So is ICANN taking a closer look at .home, or is it just a numerical coincidence?
The string is considered risky by many because .home already receives a substantial amount of DNS traffic at the root servers, which will be inherited by whichever company wins the contention set.
It’s on a list of frequently requested invalid TLDs produced by ICANN’s Security and Stability Advisory Committee which was incorporated by reference in the new gTLD Applicant Guidebook.
Some major ISPs, notably BT in the UK, use .home as a pseudo-TLD in their residential routers.

IEDR admits blame for hack that brought down Google and Yahoo

IEDR, the Irish ccTLD registry, has admitted that an attack on its own web servers was responsible for google.ie and yahoo.ie being hijacked last month.
In a detailed statement, the registry said that hackers spent 25 days probing for weaknesses in its systems, before eventually breaking in through a vulnerability in the Joomla content management software.
This enabled the attackers to upload malicious PHP scripts and access the back-end database, according to the statement. They then redirected yahoo.ie and google.ie to an Indonesian web site.
It’s a reverse of position for IEDR, which had appeared to blame one of its registrars (believed to be Mark Monitor) for the lapse in security when the hack was discovered last month.
IEDR told ZDNet October 11: “an unauthorised change was made to two .ie domains on an independent registrar’s account which resulted in a change of DNS nameservers”.
But today it said instead: “The IEDR investigation also confirmed that neither the Registrar of the affected domains nor its systems had any responsibility for this incident.”
The registry has filed a complaint with the Irish police over the incident, and apologized to its customers for the disruption.
It also said it plans to roll out a Domain Lock service to help prevent hijacking in future, though I doubt such a service would have prevented this specific incident.

Only 2% of phishing attacks use cybersquatted domain names

The number of cybersquatted domain names being used for phishing is falling sharply and currently stands at just 2% of attacks, according to the Anti-Phishing Working Group.
The APWG’s first-half 2012 report (pdf) identified 64,204 phishing domains in total.
Of those, the group believes that only 7,712 (12%) were actually registered by the phishers themselves. The rest belonged to innocent third parties and had been compromised.
That’s a steep drop from 12,895 domains in the second half of 2011 and 14,650 in the first half of 2011.
Of the 7,712 phisher-owned domains, about 66% were being use to phish Chinese targets, according to the APWG.
The group’s research found only 1,350 that contained a brand name or a misspelling of a brand name.
That’s down from 2,232 domains in the second-half of 2011, representing just 2% of all phishing domains and 17% of phisher-owned domains.
The report states:

Most maliciously registered domain strings offered nothing to confuse a potential victim. Placing brand names or variations thereof in the domain name itself is not a favored tactic, since brand owners are proactively scanning Internet zone files for such names.
As we have observed in the past, the domain name itself usually does not matter to phishers, and a domain name of any meaning, or no meaning at all, in any TLD, will usually do.
Instead, phishers almost always place brand names in subdomains or subdirectories. This puts the misleading string somewhere in the URL, where potential victims may see it and be fooled. Internet users are rarely knowledgeable enough to be able to pick out the “base” or true domain name being used in a URL.

Taken as a percentage of attacks, brand-jacking is clearly a pretty low-occurrence offence, according to the APWG’s numbers.
In absolute numbers, it works out to about 7.5 domain names per day that are being use to phish and contain a variation of the brand name being targeted.
Unsurprisingly, the APWG found that Freedom Registry’s .tk — which offers free registration — is the TLD being abused most often to register domains for phishing attacks.
More than half of the phisher-owned domains were in .tk, according to the report.

What the hell happened to Go Daddy last night?

Thousands — possibly millions — of Go Daddy customers suffered a four-hour outage last night, during a suspected distributed denial of service attack.
The company has not yet revealed the cause of the downtime, which started at 1725 UTC last night, but it bears many of the signs of DDoS against the company’s DNS servers.
During the incident, godaddy.com was inaccessible. DI hosts with Go Daddy; domainincite.com and secureserver.net, the domain Go Daddy uses to provide its email services, were both down.
The company issued the following statement:

At 10:25 am PT, GoDaddy.com and associated customer services experienced intermittent outages. Services began to be restored for the bulk of affected customers at 2:43 pm PT. At no time was any sensitive customer information, such as credit card data, passwords or names and addresses, compromised. We will provide an additional update within the next 24 hours. We want to thank our customers for their patience and support.

Several Go Daddy sites I checked remained accessible from some parts of the world initially, only to disappear later.
Others reported that they were able to load their Go Daddy webmail, but that no new emails were getting through.
This all points to a problem with Go Daddy’s DNS, rather than with its hosting infrastructure. People able to view affected sites were likely using cached copies of DNS records.
Close to 34 million domains use domaincontrol.com, Go Daddy’s primary name server, for their DNS. The company says it has over 10 million customers.
Reportedly, Go Daddy started using Verisign’s DNS for its home page during the event, which would also point to a DNS-based attack.
The outage was so widespread that the words “GoDaddy” and “DNS” quickly became trending topics on Twitter.
The web site downforeveryoneorjustme.com, which does not use Go Daddy, also went down as thousands of people rushed to check whether their web sites were affected.
Some outlets reported that Anonymous, the hacker group, had claimed credit for the attack via an anonymous (small a) Twitter account.
Companies the size of Go Daddy experience DDoS attacks on a daily basis, and they build their infrastructure with sufficient safeguards and redundancies to handle the extra traffic.
This leads me to believe that either yesterday’s attack was either especially enormous, or that somebody screwed up.
The fact that the company has not yet confirmed that external malicious forces were at work is worrying.
Either way it’s embarrassing for Go Daddy, which is applying for three new gTLDs which it plans to self-host.
Several reports have already speculated that the attack could be revenge for one or more of Go Daddy’s recent PR screw-ups.
The company has promised an update later today.

Architelos launches new gTLD anti-abuse tool

Architelos, having consulted on about 50 new gTLD applications, has refocused on its longer-term software-based game plan with the recent launch of a new anti-abuse tool for registries.
NameSentry is a software-as-a-service offering, currently being trialed by an undisclosed number of potential customers, designed to make it easier to track abusive domains.
Architelos gave us a demo of the web site yesterday.
The service integrates real-time data feeds from up to nine third-party blocklists – such as SURBL and SpamHaus – into one interface, enabling users to see how many domains in their TLD are flagged as abusive.
Users can then drill down to see why each domain has been flagged – whether it’s spamming, phishing, hosting malware, etc – and, with built-in Whois, which registrar is responsible for it.
There’s also the ability to generate custom abuse reports on the fly and to automate the sending of takedown notices to registrars.
CEO Alexa Raad and CTO Michael Young said the service can help streamline the abuse management workflow at TLD registries.
Currently, Architelos is targeting mainly ccTLDs – there’s more of them – but before too long it expects start signing new gTLD registries as they start coming online.
With many new gTLD applicants promising cleaner-than-clean zones, and with governments leaning on their ccTLDs in some countries, there could be some demand for services such as this.
NameSentry is priced on a subscription basis, based on the size of the TLD zone.

ICANN fixes new gTLD portal bugs

ICANN has brought its new gTLD program customer service portal back online after about five days of patching-related downtime.

In a notice posted late last night, ICANN said the delay was due to the wait for a vendor patch. ICANN said:

A recent, proactive review of the CSC system identified potential vulnerabilities. To address these vulnerabilities, the CSC portal was taken offline while vendor-provided patches were applied. There have been no known compromises to any data.

New gTLD applicants will now have to log in to their TLD Application System accounts, which use the Citrix remote terminal software, to use their customer service tools.
Non-applicants will be able to ask customer service questions via email.
The Knowledge Base — essentially a program FAQ — is still offline, but ICANN said it hopes to bring it back up within a few days.

ICANN takes down gTLD apps after revealing applicants’ home addresses

ICANN has temporarily blocked access to its newly revealed new gTLD applications after accidentally publishing the home addresses of many applicants.
Some applicants noticed today that the personal contact information of their named primary and secondary contacts had been published during yesterday’s Big Reveal.
In many cases this included these employees’ home addresses, despite the fact that the Applicant Guidebook specifically states that this information would not be published.
After being notified of the snafu by DI, ICANN confirmed that the addresses were published by mistake.
It’s taken down all the applications and will republish them later with the private data removed.
“This was an oversight and the files have been pulled down,” ICANN’s manager of gTLD communications Michele Jourdan said. “We are working on bringing them back up again without this information.”
It’s another big data leakage embarrassment for ICANN, following the recent outage caused by the TLD Application System bug.
It’s not likely to win ICANN any friends in the dot-brand community, where ICANN’s demands for background information on applicants’ directors caused huge procedural problems for many companies.
For applicants for controversial gTLDs, the revelation of this private data may carry its own set of risks.

Chinese DDoS knocks 123-reg offline

Customers of major UK domain registrar 123-reg suffered a couple of hours of downtime this afternoon due to an apparently “massive” denial of service attack.
The attack targeted its DNS servers and originated in China, according to a report in The Register.
Users reported sites offline or with spotty availability, but the company managed to mitigate the effects of the attack fairly quickly. It’s now reporting mostly normal service.
123-reg, part of the Host Europe Group, has hundreds of thousands of domains under management in the gTLD space alone.