Taking control of all .io domains with a targeted registration

I read this, but still don't fully understand the implications or impact for .IO TLD services and domain owners.

From the OP's "Impact" section.

> Given the fact that we were able to take over four of the seven authoritative nameservers for the .io TLD we would be able to poison/redirect the DNS for all .io domain names registered. Not only that, but since we have control over a majority of the nameservers it’s actually more likely that clients will randomly select our hijacked nameservers over any of the legitimate nameservers even before employing tricks like long TTL responses, etc to further tilt the odds in our favor.

What does this mean? Is the "poisoning" / "redirecting" of traffic for ALL .IO domains possible through this "hack" because of some flaw at the .IO registrar, or at 101domains.com or at Nameservers that .IO registrars are using, or something else?

How can this be mitigated? Or am I over-reacting since I don't fully understand this story?

Because he proved he could control the majority of name servers, that means that he could change what server his nameservers respond with and have a good chance of getting his bad DNS records used

So any site hosted on the io tld could be duplicated and hosted on a bad box that could steal credentials, install malware, without impunity and without much detection.

---

It can't be mitigated in the long-term as far as I know. There might be some short term solution but once your browser needs to look up the IP, he has got you.

The solution is not allowing nameservers to be registered as far as I know.

It wasn't immediately clear to me, but here is my guess as someone having worked in a registry. DNS itself is decoupled from registration. It sounds like .io manually entered it's NS records and associated A/AAAA records, but never put those domains themselves into their registry. This would mean when a registrar(101domains) queries, they show as available and worse, allowed registration.

The impact, however, is likely implementation dependent. Glue records exist at the parent nameserver, and aren't typically checked again at the auth. So in short, I don't believe this could be used to legitimately steal traffic, but perhaps I haven't thought it through enough.

Yes. It does.

Someone noticed that the 4 of the 7 hostnames that were assigned for authoritative names servers for .IO were available for registration. They registered them, and started receiving DNS lookups for .IO hosts from what appears to be actual internet users. Since the user had 4 or the 7, its possible that the majority of DNS lookups for .IO hosts would be sent and answer by the author's systems.

The author could have started replying with malicious lookups. "Oh some-sexy-saas.io? yeah, that's [evil IP]." "oh, billing.otherapp.io? what a surprise that site is also available at the same [evil IP]!"

How could .io sites have avoiding getting spoofed? HTTPS + HSTS would prevent the author from spoofing the DNS of that those sites and sending them to a server over HTTP thus avoiding the certificate errors.

update: I overlooked that sites would also need to leverage Public Key Pinning to be protected, since getting a valid DV cert for a spoofed cite when you control DNS would be likely.

https://en.wikipedia.org/wiki/HTTP_Public_Key_Pinning

Yes, your initial summary is my understanding as well. Basically, top-level domains use fairly arbitrary domains as authoritative nameservers (in this case ns-a[1-4].io), and the company that manages all the .io registrations (101Domain) was allowing any arbitrary user to register four of the seven nameserver domains. So a malicious user could have purchased all of them and pointed ALL .io domains to any arbitrary server (for at least 4 out of 7 DNS requests).

It can't really be mitigated at the user level but it's already been mitigated by the registrar. Still though, jfc.