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

>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.

Unless I'm missing something if you own the DNS it should be trivial to get a valid HTTPS certificate for any .io domain. Then the only thing that can save you is certificate pinning.

That makes me think: I wonder if you could "trick" a CA into giving you a wildcard *.io certificate when you own the TLD. Would that even be accepted by the browsers?

I believe the major web browsers all reject wildcard certs for TLDs. For more discussion: https://security.stackexchange.com/questions/6873/can-a-wild...

>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.

I'm confused, how would that help? Could the attacker (the author, in this case) not get a valid https certificate for these domains, returning spoofed DNS responses when the CA goes to validate it?

Depends, but for DV certificates, most likely. Certificate Transparency could/would help alert the original site if that was the case.

yes, but HTTPS + HSTS would not enforce a certain validation level, eg you can't enforce EV certs only in HSTS (as far as I know), so a DV cert would be sufficient

Very easy to do. You can even automate it with Let's Encrypt since you can serve whatever DNS records you want.

I feel any mention of HTTP Public Key Pinning should have the words "WARNING" surrounding it.

It can take down your site if you screw it up - https://www.smashingmagazine.com/be-afraid-of-public-key-pin...

I also believe it is one of the more difficult security features to implement & doesn't work well with Let's Encrypt https://community.letsencrypt.org/t/hpkp-best-practices-if-y...

I'm not against it and this case does seem to make me reconsider my prior risk balance assessment of implementing it.

Couldn't you just use letsencrypt to create arbitrary SSL certs for the io domains you now own? Then https isn't going to help you much.

HSTS (correction: HPKP) preloading would help avoid that, and Certificate Transparency monitoring would help detect it, but yes, in general, if you control DNS for a domain, you can get a valid certificate for the domain.

HSTS preloading doesn't help if you can get a Domain Validated certificate. HPKP preloading helps, but only if you pin to a CA that won't issue a DV certificate to someone who controls 4 out of 7 of the nameservers for the TLD your domain is in. And also only helps if the incident is cleaned up before the browser preload process catches the malicious server when confirming the preload. It might be a good idea to require DV certificate issuance to respect DNSSEC -- in this case, the poison nameservers wouldn't be able to sign the responses properly, and .io is DNSSEC enabled.

Certificate transparency should help you know what's going on, but only if you're getting notifications through a method that's not compromised (email to your domain may not make it to you).

Edited in a correction, thanks. But also: you can pin to a specific certificate, not just a CA.

> It might be a good idea to require DV certificate issuance to respect DNSSEC -- in this case, the poison nameservers wouldn't be able to sign the responses properly, and .io is DNSSEC enabled.

That seems like a good idea. DNSSEC isn't perfect, but for this purpose it's better than nothing.

(That said, I'd love to know where we stand on getting a better replacement for it.)

> Certificate transparency should help you know what's going on, but only if you're getting notifications through a method that's not compromised (email to your domain may not make it to you).

Definitely a good idea to point domain-related notifications of any kind to an email that doesn't go through that domain.

> But also: you can pin to a specific certificate, not just a CA.

I think the general best practices for pinning are to pin a CA or two, and a backup key; in case your keys get compromised, you can reissue with your preferred CA; in case your CA gets delisted, you can get a cert issued with your backup key from a still trusted CA. You could have a series of keys and trust those, but it seems like that would be an easy way for you to shoot yourself in the foot.

HTTPS + HSTS + HPKP with restrictive settings might help against the attacker just getting another certificate.

Without preloading, HSTS and HPKP still have the trust-on-first-use problem.

> 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

I'm not sure that's true. From a CA's perspective the attacker would own the redirected domain 4/7 tries, so they could probably convince at least one CA to issue them a valid certificate for it.

The best way to protect yourself against this kind of attack is DNSSEC. Plain and simple.

I dispute this, even though this seems like the one case where we're talking about an attack that actually lines up with what DNSSEC actually does.

The reason is, what we're talking about is a massive misconfiguration. It's not an elaborate technical spoofing attack that takes advantage of the weakness of the underlying DNS. The mistake the .IO team made is just as easy to make in DNSSEC as it is with vanilla DNS.

But if the attacker is unable to sign DNS responses, and you're validating those responses, then you're not going to have a bad time.

I don't really understand your argument. I'm talking specifics and you seem to be talking about some hypothetical.

The underlying "vulnerability" here is misconfiguration. DNSSEC doesn't defend against misconfiguration. That's the simple point I'm making.

Only if your resolver fails closed. Otherwise, an attacker can just return non-signed responses. This is all client side, as a domain owner you simply need to trust your TLD.

As long as most clients don't run tight DNSSEC, you're screwed if the TLD fucks up.

.io is signed and it has a DS record in the root zone. If you're using a DNSSEC validating recursive resolver(e.g., Google, Comcast) they should replace their cached NS records from auth resolvers that don't return signed respones, with cache entries that do return signed responses. If a stub tells a recursive resolver to return a DNSSEC signed response(by setting the DO bit to 1 in the query) that recursive should keep trying to find a signed response until it has exhausted all possible NS records in the parent zone.

This assumes of course that the second-level zones are also signed. So it would only protect people going to example.io if example.io was signed. If you have a .io child zone then you should sign it.

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.

Nameservers have always been the premiere MITM attack vector for domains, that's been known for sometime. Sad we need to keep relearning these same basic security lessons.

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.

Treat this like:

> I was able to hack/gain control over the majority of the servers that serve up authoritative information about who owns what records on the .IO ccTLD.

A "poisoning" if DNS is serving up untrue information via DNS records. This could point your bank site to a phishing site, or it could just point your bank site to a blackhole (or just point it at Google.com or something).

The poisoning / redirecting was able to be done because the domains were available to be registered. Not sure why that was the case, but they no longer are, so it's no longer an issue.

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

It's been mitigated already.

Phew! Thanks.

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.

Yes, it allowed redirecting DNS for any .io domain wherever they wanted, unless the resolver making the request used DNSSEC.

This can be mitigated primarily by the .io registry not giving the domain names registered for their nameservers to random people! And partially by DNSSEC, but I'm not sure about the exact guarantees that brings.