5 ms·

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 f

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?

strictnein 9y ago
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.
- justboxing 9y ago
  Phew! Thanks.
madamelic 9y ago
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.
detaro 9y ago
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.
axaxs 9y ago
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.
billyhoffman 9y ago
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://en.wikipedia.org/wiki/HTTP_Public_Key_Pinning
- Kenji 9y ago
  When I skimmed your message, I read some-sexy-ass.io. I think that would be a more likely domain for people to look up ;) EDIT: C'mon, you know I'm not wrong.
- nvarsj 9y ago
  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.
  - JoshTriplett 9y ago
    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.
    - toast0 9y ago
      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).
deleted 9y ago
[deleted]
schneidmaster 9y ago
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.
- Danihan 9y ago
  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.
pyre 9y ago
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).

strictnein 9y ago

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.

justboxing 9y ago
Phew! Thanks.

madamelic 9y ago

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.

detaro 9y ago

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.

axaxs 9y ago

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.

billyhoffman 9y ago

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://en.wikipedia.org/wiki/HTTP_Public_Key_Pinning

Kenji 9y ago
When I skimmed your message, I read some-sexy-ass.io. I think that would be a more likely domain for people to look up ;) EDIT: C'mon, you know I'm not wrong.
nvarsj 9y ago
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.
- JoshTriplett 9y ago
  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.
  - toast0 9y ago
    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).

deleted 9y ago

[deleted]

schneidmaster 9y ago

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.

Danihan 9y ago
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.

pyre 9y ago

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