ICANN will alert gTLD security bug victims

ICANN plans to inform each new top-level domain applicant whether they were affected by the security vulnerability in its TLD Application System, according to its latest update.
The organization has also confirmed that it is still targeting April 30 for the Big Reveal day, when it publishes (deliberately) the gTLDs being applied for and the names of the applicants.
This morning’s TAS status update, penned by chief operating officer Akram Atallah, does not add much that we did not already know about the data leakage bug. It states:

An intensive review has produced no evidence that any data beyond the file names and user names could be accessed by other users.
We are currently reviewing the data to confirm which applicants were affected. As soon as the data is confirmed, we will inform all applicants whether they were affected.

ICANN staff and outside consultants have been working all weekend to figure out what went wrong, who it affected, and how it can be fixed.
The organization still intends to announce tonight whether it has fixed the problem to the point where it’s happy to reopen TAS to registered users tomorrow. It’s also sticking to is Friday extended submission deadline.

ICANN knew about TAS security bug last week

ICANN has known about the data leakage vulnerability in its TLD Application System since at least last week, according to one new top-level domain applicant.
The applicant, speaking to DI on the condition of anonymity today, said he first noticed another applicant’s files attached to his gTLD application in TAS last Friday, April 6.
“I could infer the applicant/string… based on the name of the file,” said the applicant.
He immediately notified ICANN and was told the bug was being looked at.
ICANN revealed today that TAS has a vulnerability that, in the words of COO Akram Atallah, “allowed a limited number of users to view some other users’ file names and user names in certain scenarios.”
The actual contents of the files are not believed to have been visible.
But other applicants, also not wishing to be identified, today confirmed that they had uploaded files to TAS using file names containing the gTLD strings they were applying for.
It’s not yet known how many TAS users were able to see files belonging to others, or for how long the vulnerability was present on the system.
However, it now does not appear to be something that was accidentally introduced during yesterday’s scheduled TAS maintenance.
This kind of data leakage could prove problematic — and possibly expensive — if it alerted applicants to the existence of competing bids, or caused new competing bids to be created.
ICANN shut down TAS yesterday and does not expect to bring it back online until Tuesday.
The window for filing applications, which had been due to close yesterday, has been extended until 2359 UTC next Friday night.
April 14 Update
ICANN today released a statement that said in part:

we are sifting through the thousands of customer service inquiries received since the opening of the application submission period. This preliminary review has identified a user report on 19 March that appears to be the first report related to this technical issue.
Although we believed the issues identified in the initial and subsequent reports had been addressed, on 12 April we confirmed that there was a continuing unresolved issue and we shut down the system.

It’s worse than you thought: TAS security bug leaked new gTLD applicant data

The bug that brought down ICANN’s TLD Application System yesterday was actually a security hole that leaked data about new gTLD applications.
The vulnerability enabled TAS users to view the file names and user names of other applicants, ICANN said this morning.
COO Akram Atallah said in a statement:

We have learned of a possible glitch in the TLD application system software that has allowed a limited number of users to view some other users’ file names and user names in certain scenarios.
Out of an abundance of caution, we took the system offline to protect applicant data. We are examining how this issue occurred and considering appropriate steps forward.

Given the level of secrecy surrounding the new gTLD application process, this vulnerability ranks pretty highly on the This Is Exactly What We Didn’t Want To Happen scale.
It’s not difficult to imagine scenarios in which a TAS user name or file name contains the gTLD string being applied for.
This is important, competition-sensitive data. If it’s been leaked, serious questions are raised about the integrity of the new gTLD program.
How long was this vulnerability present in TAS? Which applicants were able to look at which other applicants’ data? Did any applicants then act on this inside knowledge by filing competing bids?
If it transpires that any company filed a gTLD application specifically in order to shake down applicants whose data was revealed by this vulnerability, ICANN is in for a world of hurt.

Verisign: our DNS was not hacked

Verisign today reiterated that the recently revealed 2010 security breaches on its corporate network did not affect its production domain name system services.
In a statement, Verisign said:

After a thorough analysis of the attacks, Verisign stated in 2011, and reaffirms, that we do not believe that the operational integrity of the Domain Name System (DNS) was compromised.
We have a number of security mechanisms deployed in our network to ensure the integrity of the zone files we publish. In 2005, Verisign engineered real-time validation systems that were designed to detect and mitigate both internal and external attacks that might attempt to compromise the integrity of the DNS.

The statement followed several news reports that covered the hacks and speculated about the mayhem that could ensue if Verisign’s root or .com zone systems were ever breached.
The information the company has released so far suggests that the attacks were probably against back-office targets, such as user desktops, rather than its sensitive network operations centers.

Hackers stole data from Verisign, Blacknight

Hackers broke into Verisign’s corporate network and made out with sensitive data, it emerged today.
The attacks happened in 2010 and the company does not believe its all-important domain name infrastructure – which supports .com and several other top-level domains – was compromised.
Reuters broke the news today, but the attack was actually revealed in a Securities and Exchange Commission filing last October. The filing said:

In 2010, the Company faced several successful attacks against its corporate network in which access was gained to information on a small portion of our computers and servers. We have investigated and do not believe these attacks breached the servers that support our Domain Name System (“DNS”) network. Information stored on the compromised corporate systems was exfiltrated.

The filing, which was required under recent SEC disclosure rules, goes on to say that the attacks were “not sufficiently reported to the Company’s management” until September 2011.
It adds that Verisign does not know whether the “exfilitrated” – ie, stolen – data was used by the attackers. The filing does not say what was taken.
Back in 2010, Verisign was still a security company. It did not sell off its SSL business to Symantec until August that year. The filing does not say whether SSL data was breached.
As one of the logical single points of failure on the internet, Verisign is of course the subject of regular attacks, mainly of the performance-degrading distributed denial of service variety.
The bigger worry, as Reuters rather breathlessly notes, is that if hackers could compromise the integrity of the DNS root or .com/.net zones, it could lead to mayhem.
In unrelated news, the domain name registrar Blacknight today revealed that it got hacked on Tuesday.
The attackers may have got away with contact information – including email addresses and telephone numbers – for up to 40,000 customers, the company said.
Financial information such as credit card numbers was not compromised, Blacknight said.
The company has contacted Irish data protection regulators and will also inform the police. Customers are advised to change their passwords.
If you’re a Blacknight customer you’ll also want to be on the lookout for “spear-phishing” attacks in the near future. When the bad guys know your name, it can lead to a more convincing phish.

High-security .bank spec published

BITS, the technology arm of the Financial Services Roundtable, has published a set of specifications for new “high-security” generic top-level domains such as .bank and .pay.
The wide-ranging spec covers 31 items such as registration and acceptable use policies, abusive conduct, law enforcement compliance, registrar relations and data security.
It would also ban Whois proxy/privacy services from financial gTLDs and oblige those registries to verify that all Whois records were fully accurate at least once every six months.
The measures could be voluntarily adopted by any new gTLD applicant, but BITS wants them made mandatory for gTLDs related to financial services, which it calls “fTLDs”.
A letter sent by BITS and the American Bankers Association to ICANN management in late December (pdf) is even a bit threatening on this point:

We strongly urge that ICANN accept the [Security Standards Working Group’s] proposed standards and require their use in the evaluation process. We request notification by 31 January 2012 that ICANN commits to use these fTLD standards in the evaluation of the appropriate gTLD applications. BITS, the American Bankers Association (ABA), and the organizations involved in this effort are firmly committed to ensuring fTLDs are operated in a responsible and secure manner and will take all necessary steps to ensure that occurs.

BITS, it should be pointed out, is preparing its own .bank bid (possibly also .invest and .insure) so the new specs give a pretty good indication of what its own gTLD applications will look like.
ICANN’s Applicant Guidebook does not currently mandate any security standard, but it does say that security practices should be commensurate with the level of trust expected from the gTLD string.
Efforts within ICANN to create a formal High Security Zone Top Level Domain (HSTLD) standard basically fizzled out in late 2010 after ICANN’s board said it would not endorse its results.
That said, any applicant that chooses to adopt the new spec and can demonstrate it has the wherewithal to live up to its very strict requirements stands a pretty good chance of scoring maximum points in the security section of the gTLD application.
Declining to implement these new standards, or something very similar, is likely to be a deal-breaker for any company currently thinking about applying for a financial services gTLD.
Even if ICANN does not formally endorse the BITS-led effort, it is virtually guaranteed that the Governmental Advisory Committee will be going through every financial gTLD with a fine-toothed comb when the applications are published May 1.
The US government, via NTIA chief Larry Strickling, said this week that the GAC plans to reopen the new gTLD trademark protection debate after the applications are published.
It’s very likely that any dodgy-looking gTLDs purporting to represent regulated industries will find themselves under the microscope at that time.
The new spec was published by BITS December 20. It is endorsed by 17 companies, mostly banks. Read it in PDF format here.

Typosquatting is huge but not dangerous, study finds

A study of typosquatted domain names has found that the practice is reaching pandemic levels for the largest brands, but that there’s surprisingly little malware distribution going on.
The security company Sophos surveyed 2,249 domains that were one letter different to the .com sites of Facebook, Google, Twitter, Apple and Microsoft, and found that two thirds resolved.
Not all of those 1,502 sites were malicious typosquats; some were legitimate sites that just happened to have similarly spelled names (such as goole.com and witter.com) Sophos noted.
Apple was the most-squatted company, according to this method: resolving Microsoft typos were at 61%, Twitter at 74%, Facebook at 81%, Google at 83% and Apple at 86%.
Sophos concluded that “there is a significant typosquatting ecosystem around high-profile, often-typed domain names.”
But it did not find as much malware as it was expecting, with only one domain leading to a malware site, 0.07% of the total.
However, 2.7% of the URLs “fell into the loose category of cybercrime”, which “means they are, or have been, associated with hacking, phishing, online fraud or spamming”.
The report, which also fingers parking services from Demand Media, Sedo, Oversee and Bodis as the recipients of 37% of the typo traffic, contains much more data and is well worth a read.
Annoyingly, it appears that Sophos only surveyed .com domains, so the data doesn’t really tell us much about the impact of TLDs (such as .co) on the typosquatting problem.

Libyan registry hacked by anti-Gaddafi crackers

The official registry web site for the Libyan top-level domain has been defaced by anti-Gadaffi crackers.
Nic.ly currently looks like this (click to enlarge):

The attack appears to be limited to the web server – as bit.ly domains are still resolving I assume the culprits have not managed to take control of the registry’s more important systems.
Libya famously cut itself off from the internet in March, shortly after the ongoing rebel uprising – which today arrived on the streets of Tripoli – kicked off.
The .ly domain also went completely dark in 2004 after a communication breakdown between the registry manager and IANA.
(via Sophos)

Bit-squatting – the latest risk to domain name owners

Forget phishing, forget cybersquatting, forget typosquatting, high-value domain name owners may have a whole new threat to worry about – “bit-squatting”.
This appears to be the conclusion of fascinating new research to be presented by Artem Dinaburg at the Black Hat and DEF CON hacker conferences in Las Vegas next week.
Defective internet hardware, it turns out, may be enabling a whole new category of typosquatting that could prove worrying for companies already prone to domain name abuse.
According to a summary of Dinaburg’s research, RAM chips can sometimes malfunction due to heat or radiation, resulting in “flipped bits”, where a 1 turns into a 0 or vice-versa.
Because the DNS uses ASCII encoding, a query containing a single flipped bit could actually send the user to a completely different domain name to the one they intended to visit.
To test the theory, Dinaburg appears to have registered the typo domain name mic2osoft.com. While it’s not visually confusing or a likely typo, in binary it is only one bit different to microsoft.com.
The ASCII binary code for the digit 2 is 00110010, which is only one bit different to the lower-case letter r, 01110010.
The binary for the string “microsoft” is:

011011010110100101100011011100100110111101110011011011110110011001110100

and the binary encoding for “mic2osoft” is (with the single changed bit highlighted):

011011010110100101100011001100100110111101110011011011110110011001110100

Therefore, if that one bit were to be accidentally flipped by a dodgy chip, the user could find themselves sending data to the bit-squatter’s domain rather than Microsoft’s official home.
I would assume that this is statistically only a concern for very high-traffic domains, and only if the bit-flipping malfunction is quite widespread.
But Dinaburg, who works for the defense contractor Raytheon, seems to think that it’s serious enough to pay attention to. He wrote:

To verify the seriousness of the issue, I bit-squatted several popular domains, and logged all HTTP and DNS traffic. The results were shocking and surprising, ranging from misdirected DNS queries to requests for Windows updates.
…
I hope to convince the audience that bit-squatting and other attacks enabled by bit-flip errors are practical, serious, and should be addressed by software and hardware vendors.

His conference presentations will also discuss possible hardware and software solutions.
For large companies particularly at risk of typosquatting, the research may also present a good reason to conduct a review of their trademark enforcement strategies.
I’m not going to be in Vegas this year, but I’m looking forward to reading more about Dinaburg’s findings.
The annual Black Hat and DEF CON conferences are frequently the venues where some of the most beautifully creative DNS hacks are first revealed, usually by Dan Kaminsky.
Kaminsky is not discussing DNS this year, judging by the agendas.
The conferences were founded by Jeff Moss, aka The Dark Tangent, who joined ICANN as its chief security officer earlier this year.

.xxx domains to get free virus scans from McAfee

ICM Registry has signed up with security software outfit McAfee to provide automatic virus scanning for all web sites hosted at .xxx domain names.
Under the $8 million deal, “every .XXX domain will be scanned for vulnerabilities such as SQL injection, browser exploits and phishing sites, reputational analysis and malware”, ICM said in a press release.
The subscription, which is based on the McAfee Secure offering, will be included in the price of the domain, which is expected to start at around $75 at the cheapest registrars.
McAfee normally charges a lot more than that; ICM has basically negotiated a bulk discount for its customers.
There are two ways to take advantage of the deal.
First, webmasters can choose to put some code on their sites that displays the McAfee Secure logo, potentially increasing customer confidence and ergo sales.
McAfee reckons sales can go up by as much as 12% when sites use this “trust mark”, based on some split-testing it did a couple years ago (results may vary, it adds).
Second, because McAfee is going to automatically scan every .xxx domain every day, whether the registrant wants it or not, porn surfers will be able to use McAfee SiteAdvisor, a free browser plug-in, to verify that a .xxx site is, for want of a better word, clean.
Whether you like .xxx or not, you’ve got to admit that this probably counts as a rare example of “innovation” from a domain registry.
On the flipside, registrars that already offer such services as add-ons, such as Go Daddy, won’t get the up-sell if ICM is giving it to every registrant from the registry side.
But that doesn’t seem to have stopped any registrars from signing up to sell .xxx domains.
Oddly, the press release does not name McAfee as the service provider, but its brand is all over the ICM web site so embarrassment is probably not a factor.
McAfee currently has about 80,000 sites using the service, which could easily grow to 500,000 or more if ICM gets as many registrations as it expects to.