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’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.
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.
The US House of Representatives has passed the DOTCOM Act, which would prevent the Department of Commerce from walking away from its oversight of the DNS root zone.
The bill was approved as an amendment to a defense authorization act, with a 245-177 vote that reportedly saw 17 Democrats vote in line with their Republican opponents.
The DOTCOM Act has nothing whatsoever to do with .com. Rather, it’s a response to the National Telecommunications and Information Administration’s plan to relinquish its role in root zone management.
The bill as passed (pdf) would prevent NTIA from agreeing to any multistakeholder community-created IANA transition proposal until the Government Accountability Office had issued a study on the proposal.
The GAO would have one year from the point ICANN submits the proposal to come up with this report.
That means that if ICANN and NTIA want to stick to their September 2015 target date for the transition, either the ICANN community would need to produce a proposal at unprecedented and unlikely speed or the GAO would need to take substantially less than a year to write its report.
I don’t think it’s an impossible target, but it’s certainly looking more likely that NTIA will have to exercise one of the two-year automatic renewal options in the current IANA contract.
That’s all assuming that a matching bill passes through the Democrat-controlled Senate and then receives a presidential signature, of course, which is not a certainty.
Assuming a bloc vote by the 47 Republican Senators, only four Democrats (or independents) would need to switch sides in order for the DOTCOM Act to become, barring an unlikely presidential veto, law.
To the best of my knowledge there is not currently a matching bill in the Senate.
Verisign should stay in its key role in root zone management after the IANA transition process is complete, according to ICANN CEO Fadi Chehade.
The company currently acts as “maintainer”, alongside the US government as “administrator” and ICANN/IANA as “operator”.
This means Verisign is responsible for actually making changes — adding, deleting or amending the records for TLDs — in the root zone file.
In a blog post yesterday, Chehade said that ICANN will “establish a relationship directly with the third-party Maintainer”, adding:
As a means to help ensure stability, ICANN’s recommended implementation option is to have Verisign continue its role as the Maintainer. However, we will be working closely with all relevant parties including the Root Zone Operators to ensure there are contingency options in place to meet our absolute commitment to the stability, security and resiliency of the Domain Name System.
I wholeheartedly agree that Verisign should stay in its role, or at the very least that ICANN should not take over.
As we’ve learned over the last couple of years of software glitches in the new gTLD program, some of them security-related, ICANN would be a poor choice today to maintain this critical resource.
Chehade noted that the US National Telecommunications and Information Administration would be replaced in its “administrator” role by whatever mechanism the ICANN community comes up with during the transition process.
ICANN has killed off Amazon’s application for the new gTLD .amazon, based on longstanding but extremely controversial advice from its Governmental Advisory Committee.
According to a New gTLD Program Committee resolution passed on Wednesday and published last night, the applications for .amazon and Chinese and Japanese translations “should not proceed”.
That basically means all three applications are frozen until Amazon withdraws them, wins some kind of appeal, manages to change the GAC’s mind, or successfully sues.
Here’s the last bit of the resolution:
Resolved (2014.05.14.NG03), the NGPC accepts the GAC advice identified in the GAC Register of Advice as 2013-07-18-Obj-Amazon, and directs the President and CEO, or his designee, that the applications for .AMAZON (application number 1-1315-58086) and related IDNs in Japanese (application number 1-1318-83995) and Chinese (application number 1-1318-5581) filed by Amazon EU S.à r.l. should not proceed. By adopting the GAC advice, the NGPC notes that the decision is without prejudice to the continuing efforts by Amazon EU S.à r.l. and members of the GAC to pursue dialogue on the relevant issues.
The NGPC noted that it has no idea why the GAC chose to issue consensus advice against .amazon, but based its deliberations on the mountain of correspondence sent by South American nations.
Peru and Brazil, which share the Amazonia region of the continent, led the charge against the bids, saying they would “prevent the use of this domain for the purposes of public interest related to the protection, promotion and awareness raising on issues related to the Amazon biome”.
Amazon had argued that “Amazon” is not a geographic term and that it was against international law for governments to intervene and prevent it using its trademark.
ICANN commissioned a legal analysis that concluded that the organization was under no legal obligation to either reject or accept the applications.
Under the rules of the new gTLD program, the NGPC could have rejected the GAC’s advice, which would have led to a somewhat lengthy consultation process to resolve (or not) their differences.
The big question now is what Amazon, which has invested heavily in the new gTLD program, plans to do next.
A Reconsideration Request would be the simplest option for appeal, though almost certainly a futile gesture. An Independent Review Process complaint might be slightly more realistic.
There’s always the courts, though all new gTLD applicants have to sign legal waivers when they apply.
A fourth option would be for Amazon to negotiate with the affected governments in an attempt to get the GAC advice reversed. The company has already attempted this — offering to protect certain key words related to the region at the second level, for example — but to no avail.