Bloke takes over every .io domain by snapping up crucial name servers
IO, IO, it's off the 'net you go
A blunder during a handover of the .io registry allowed a security researcher to potentially take control of more than 270,000 .io domains.
Late Friday, Matthew Bryant noticed an unusual response to some test code he was using to map top-level domains: several of the .io authoritative name servers were available to register.
Out of interest, he tried to buy them and was amazed to find the registration went through – leaving him potentially in control of hundreds of thousands of websites.
These crucial name servers – specifically, a0.nic.io, b0.nic.io, c0.nic.io, ns-a1.io, ns-a2.io, ns-a3.io, and ns-a4.io – are like the telephone directories of the .io space. If your web browser wants to connect to, say, github.io, it may have to go out to one of these authoritative name servers to convert github.io into a public IP address to connect to.
Those nic.io and ns-aX.io addresses should be owned and maintained by .io's operators. But Bryant was able to purchase and register ns-a1.io, ns-a2.io, ns-a3.io, and ns-a4.io, and point them at his own DNS servers, allowing him to, if he wanted, potentially redirect connections to any .io domain to a server of his choosing.
He immediately tried to contact the operators of the .io registry, but its official administration email bounced and he ended up calling the registry's support line to report his control over their top-level domain. They asked him to send an email to their abuse@ email address.
Despite firing off an email immediately, Bryant remained in control of ns‑a1.io, ns‑a2.io, ns‑a3.io and ns‑a4.io for about 24 hours – during which time he could have potentially directed hundreds of thousands of requests for .io websites to his own servers – until the registry finally acted and revoked his registration of the domains.
Bryant told The Register via email that the registry has yet to contact him or inquire what he did with the vast number of DNS queries for .io websites his domains handled. He told us he deleted the logs and forced the name servers he was in control of not to respond.
The potential for criminal activity such as redirecting people to phishing websites or installing malware on people's systems was enormous. And it is unclear that the hijacking would have been noticed if he hadn't reported it.
As such, the slip-up will be a significant embarrassment to the .io registry, which promotes itself as a home for startups and internet companies and boasts 272,000 active addresses.
How this works
Every top-level domain – like dot‑com – lists a number of name servers that the rest of the internet uses to query and find out on what server specific websites exist. It's a registry's address book and is critical to the functioning of the domain name system.
The .io registry lists seven such name servers – and Bryant managed to take control of four of them for $95.99 apiece.
Even more extraordinarily, the name servers had likely been available to register for several weeks: .io was lucky that the first person to discover the fact was an internet security researcher rather than a hacker or cybercriminal.
It's worth pointing out that owning four of the seven authoritative name servers doesn't grant full control over .io. These name servers are often selected at random to spread the load, meaning some look-ups would have gone to the .io operator and some to Bryant. For example, we just queried github.io from the B root server and was offered ns-a4.io as the authority on github.io:
dig github.io @b.root-servers.net ;; AUTHORITY SECTION: io. 172800 IN NS ns-a4.io. io. 172800 IN NS c0.nic.io. io. 172800 IN NS ns-a1.io. io. 172800 IN NS a0.nic.io. io. 172800 IN NS ns-a3.io. io. 172800 IN NS b0.nic.io. io. 172800 IN NS ns-a2.io.
Also, it's doubly worth pointing out that DNS lookups are often cached, so the chances that a lookup will go all the way to the authoritative servers, and hit one of the hijacked ones, is low. And software tends to go straight to a domain's A record, bypassing the authoritative name servers, thus limiting the damage of hijacked systems.
Still, it's a rather embarrassing blunder. Bryant told us he received "gigabytes" in DNS queries from clients.
So what happened? At the root of the problem was a transition last month of the top-level domain from the operators of the registry, .IO TLD, to third party Afilias, which runs the backend for over 25 other top-level domains, including .org, .info and .eco.
Somewhat unusually, .IO TLD decided it wanted to continue to run the .IO name servers, but outsourced the rest of the registry operations to Afilias. Afilias locked down the three main name server addresses – A0.nic.io, B0.nic.io and C0.nic.io – but failed to do the same for the other four, leaving them available for registration.
"Ordinarily, when a TLD transitions to the Afilias system, 100 per cent of the DNS is also moved to Afilias nameservers," the company told The Register in a statement.
"Last week, Afilias discovered that some of the nameservers associated with the .IO TLD were not blocked when the TLD was transitioned to Afilias' systems in June ... Upon discovery, Afilias promptly reassigned and blocked the domains associated with ICBs nameservers, and the DNS for .IO is now working as expected."
As Bryant noted in a blog post, the fact that .io has DNSSEC enabled would probably have limited the worst dangers in having a malicious actor in charge of a piece of the core internet infrastructure. But the security risks were enormous nonetheless.
Afilias told The Reg that its transition procedures had been updated and that it was "unaware of any issues arising from this brief exposure." ®
Sponsored: Becoming a Pragmatic Security Leader