21 ms·

Taking control of all .io domains with a targeted registration

1404 points by koenrh 9y ago

justboxing 9y ago
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).
runnr_az 9y ago
That's amazing! Nice find, man!
- andai 9y ago
  Trying to figure out why you were downvoted. Was it the positivity? The exclamation marks? The lack of pretending to contribute to the conversation?
  - chriswarbo 9y ago
    I downvoted because it doesn't raise any questions or add any information to the discussion. BTW, neither does commenting about votes ;) As per https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html "Please resist commenting about being downvoted. It never does any good, and it makes boring reading."
    - andai 9y ago
      I was merely puzzled that my favorite comment was downvoted to the bottom of the thread! I am sure the author (who appeared in the discussion here) would have appreciated the positive feedback. Are you suggesting it would have been better to contact the author directly?
  - alexdumitru 9y ago
    It looks like it's been written by a spam bot.
    - andai 9y ago
      How so?
walrus01 9y ago
This is a huge screwup on the part of the people who run the 'root' of .IO, and their entire operation should be severely scrutinized by ICANN. In my opinion almost all of the 'weird' TLDs which are country codes that are actually operated by a third party commercial service are 95% spam and junk registrations. .TV is a good example. Technical screwups aside, the existence of .IO and the fact that it "belongs" to the UK government is morally questionable, since the entire country code only exists because the British and American militaries forcibly removed the original inhabitants of islands such as Diego Garcia so that they could use the area as naval and air force bases. https://en.wikipedia.org/wiki/British_Indian_Ocean_Territory https://en.wikipedia.org/wiki/British_Indian_Ocean_Territory https://en.wikipedia.org/wiki/Diego_Garcia https://en.wikipedia.org/wiki/Diego_Garcia If I had been able to successfully register these names and get live traffic going to a BIND9 instance, my first instinct would not be to alert the company through its first tier customer support levels, but to immediately post a summary of the problem to ARIN, RIPE, APNIC and ICANN mailing lists. This would get the issue in front of people who immediately understand how serious the problem is, and hopefully one of them would be able to contact the principals of .IO directly.
- peterwwillis 9y ago
  Bad actors are on those mailing lists too. What you describe would be the equivalent of mailing fulldisclosure with "Hi all, there might be more unregistered nameservers at .IO (or another 101domains-serviced TLD) that could be used to attack live traffic if anyone wants to grab those, kthx"
  - walrus01 9y ago
    I'm fine with that happening, because the people who run .IO need to be spanked. If their customers are subsequently unhappy that their domain names have been hijacked, they can take it up with whatever corporate entity runs .IO. Same problem as publicly disclosing serious flaws with an SSL/TLS root CA.
    - peterwwillis 9y ago
inetknght 9y ago
> After sending the email I immediately received a bounce message indicating that the adminstrator@nic.io was not an email address that existed at all > This was not a strong vote of confidence that someone was going to see this notice. Honestly though, this seems like common practice to me.
- JorgeGT 9y ago
  I though ICANN was supposed to be getting serious against fake contact data on domain registrations? The fact that even a TLD's NIC admin info is fake is pretty spectacular.
michaelbuckbee 9y ago
So, the real question is: "How much should we freak out about this?" If you scroll back a few months to Cloudbleed/Cloudflare we sort of collectively decided that because cache data containing sensitive info (passwords, tokens, whatever) might be accessible for your site using Cloudflare that everything should be revoked, force password resets, etc. Now we have this vuln, which I'll dub "IOgate" because it's the cool thing to name these. We don't know if this has ever happened before, there clearly were not adequate safeguards in place, etc. Should anyone operating a service using a ".io" TLD consider everything potentially compromised?
- lwansbrough 9y ago
  Well, if it's any consolation.. the domains weren't registered..
  - tedmiston 9y ago
    The post states that they were registered, used, then revoked.
    - andypants 9y ago
      Registered by the author. What lwansbrough means is that they weren't already registered, which means it's unlikely this was previously exploited unless the previous registrant let those domains expire afterwards.
      - CydeWeys 9y ago
        The registry (and many other people who have downloaded zone files and such) would have records of these having previously been registered. If it was exploited then it would easily be possible to find that out.
      - deleted 9y ago
        [deleted]
  - michaelbuckbee 9y ago
jshelly 9y ago
Complicated by the fact that the .io domain has recently become popular for startups
ChuckMcM 9y ago
I am really super happy that the root domain serving the largest IOT population on the planet wasn't co-opted by the MIRAI bot writers. That could have been a net killing event.
- gboudrias 9y ago
  There's an IOT population? I thought it was just a dumb trend everyone hates? I'm not trying to diss anyone, I just thought the whole "IoT" concept was dead in the water?
mrkrab 9y ago
>Technical screwups aside, the existence of .IO and the fact that it "belongs" to the UK government is morally questionable, since the entire country code only exists because the British and American militaries forcibly removed the original inhabitants of islands such as Diego Garcia so that they could use the area as naval and air force bases. Since you're getting political there for no reason at all, let me say this: might is right. Get over it.
- moonbug22 9y ago
  Ladies and gentleman: Hacker News.
- rhizome 9y ago
  Surprising behavior from a green username.
- rspeer 9y ago
  > might is right. Get over it. That's a good summary of the UK's response to the UN, but we are allowed to disagree. We are allowed to have moral values that are not enforced at the end of a gun. I'm sad that you don't. And when it comes to the global organization of the Internet, politics is important. Politics is why the fad for .ly domains in link shorteners allowed links to be censored by Gaddafi's government. And politics is presumably why the UK controls this ugly stepchild of a TLD* and doesn't care about it enough to put competent people in charge of it. *Unfortunately, I use it too. .com and .org are in an end-game where everything belongs to the domain squatters.
- ben_jones 9y ago
  This comment is in terrible taste but it isn't wrong. We can't just shove our hands in the sand and say it isn't fair so it isn't true.
  - panglott 9y ago
    Might makes the rules, but that doesn't mean the rules are right. We can definitely shove our hands in the sand and say that they are not fair.
mreithub 9y ago
Wow, I don't think I would've even considered such an attack... DNSSEC, HSTS and Certificate Pinning would've made it more difficult to abuse this, but I guess it would've been pretty easy to get valid SSL certificates for all your favourite .io domains. Let's try to play malicious party here: Phase A: First set up a simple DNS forwarder playing by the rules and answering requests as we should (as to not get any unwanted attention). Gather usage statistics. Phase B: Crawl the list of most-used domains to see if there are any valuable targets without HTTPS (port 443 is closed). Alternatively/additionally see if there are API subdomains used by software other than browsers (of which a few won't have annoying features like Cert Pinning - golang's DNS resolver for example afaik doesn't do DNSSEC). Pick some medium to high level targets where the attack might go undetected for at least some time. Phase C: MitM time! Get certificates for the target domain(s) of your choice and get to work. Start with only a few percent of the requests to not draw too much attention (and to avoid the majority of their traffic coming from a single IP (range) all of a sudden) Obfuscate the attack by acting like a third party app or something simply doing requests for their users. Congratulations on finding the vulnerability (and thanks for looking for that kinda stuff in the first place).
- mandatory 9y ago
  Author here, thanks - glad you liked the post! :)
- btown 9y ago
  Or, in Phase C, an attacker could proxy traffic through a botnet to avoid the single-ip-range issue; they could even find botnet participants geographically close to each user, so they might not even trigger any red flags from a close look at IP logs. Setting aside DNS hijacking altogether, the idea that phishing sites could do something like this, perfectly proxy i.e. a bank's content and remain largely undetectable, makes me very concerned that we're only just seeing the beginning of sophisticated phishing attacks.
- djrogers 9y ago
  Your missing a ton of potential here by assuming that all DNS is good for is Web traffic. For one thing, taking over or intercepting email (remember, you now control the DNS, so you also control SPF and DKIM records) becomes trivial. you could even leverage that control of email to get SSL certificates for domains you really want to do https for (letsencrypt will even generate a wildcard cert using only dns based verification). You could also be much more surgical, and target specific people/organizations using that .tld, ignoring dns requests for everyone that you don’t want to alert to your control. Hijack their email, and you control access to things like account recovery for domain users, and have a great method for phishing account credentials for the domains customers. Honestly, the list of what you could do here is almost only limited by your imagination
tbarbugli 9y ago
Not the first time .io TLD messes things pretty bad. A few months ago they had a couple of name servers poisoning internet with false negatives, that made a few hours very "interesting"
rmoriz 9y ago
Originally, .io, .sh and .tm were operated by ICB PLC, later ICB LLC (owned by Paul Kane[1]). Just a couple of weeks ago .io and .sh changed hands to Afilias which swapped out all turning parts over a weekend. They really screwed up a lot of things including losing my balance, manipulating domain information and extortion attemps: I was a reseller with ICB and have a contract. Without a cancellation period (which as defined in the contract) they wanted to take over the contract, introduce new contract details and probably a new pricing scheme. Around 20 pages of legal stuff and a window of <10 days to "decide"/comply. I'm done with them (Afilias). I'll never ever spend a dime and advise anyone not doing any business with them. (But also the old technology backed (which still runs .tm) is far from secure and reliable. At least it supports IPv6 whereas the Afilias infrastructure still is not IPv6 ready…) [1] https://en.wikipedia.org/wiki/Paul_Kane_(entrepreneur) https://en.wikipedia.org/wiki/Paul_Kane_(entrepreneur)
mdellabitta 9y ago
Just to add some color to this: There was an attack last Friday on a few geo TLDs that ended up hijacking a bunch of traffic for a few hours, including .la, .es, and .jp: https://news.gandi.net/en/2017/07/report-on-july-7-2017-incident/ https://news.gandi.net/en/2017/07/report-on-july-7-2017-inci...
- sirn 9y ago
  I'm one of the unlucky few that were affected by this (I own .ch). One of my site user's reported that the website is inaccessible on Friday. I went to check and observed the DNS changing. Then went to check Route 53 status page[2] in which I learn that this is not specific to my site. The behavior is exactly the same as what is described in the SWITCH report[1]. Luckily that I have HSTS on my site, so the damage is limited (users not getting redirected), and Gandi seems to fixed this quick enough (I was in the middle of commuting back home by the time of the attack.) [1]: https://securityblog.switch.ch/2017/07/07/94-ch-li-domain-names-hijacked-and-used-for-drive-by/ https://securityblog.switch.ch/2017/07/07/94-ch-li-domain-na... [2]: http://status.aws.amazon.com/ http://status.aws.amazon.com/ (The blue icon for Amazon Route 53 Domain Registration)
  - jontro 9y ago
    We were also affected by this on a major e-commerce site. It was a .se domain. Their post mortem isn't really convincing ( https://news.gandi.net/en/2017/07/report-on-july-7-2017-incident/ https://news.gandi.net/en/2017/07/report-on-july-7-2017-inci... ) since they do not state what really happened and how it can be prevented again. I issued a support ticket to aws today to see what measures can be taken, otherwise we might need to change registrar.
    - vbernat 9y ago
      There is a more detailed followup today: https://news.gandi.net/en/2017/07/detailed-incident-report/ https://news.gandi.net/en/2017/07/detailed-incident-report/
      - 9y ago
felipeerias 9y ago
Who would have thought that adminstrator@nic.io registered in a small overseas territory in the middle of the Indian Ocean might not be entirely reliable?
hk__2 9y ago
Side note: Please don’t use such gray and thin fonts. I had to modify the CSS to use black instead of #555 for the text color.
- iDemonix 9y ago
  You might want to see an optician.
- HalfwayToDice 9y ago
  I had to use the "Reader" feature of my browser to read the text, for maybe the first time ever.
- hanspeter 9y ago
  #555 is still quite dark and should be easy to read. The real culprit is the 300 font weight - when set to 400 it's quite another matter.
- CrystalLangUser 9y ago
  I don't mean this pejoratively, but how old are you? I'm just curious as I had no problems with the color / font weight. For my sites I usually use something like #232323 instead of pure black.
  - narrowtux 9y ago
    I'm 25 and had to zoom to read and even then it wasn't comfortable. (not the OP)
    - CrystalLangUser 9y ago
      Ah I see, upping the font-weight to 400 helped when viewing it on my laptop screen. I didn't really have that issue on mobile, though.
  - hk__2 9y ago
    I’m 25. I agree with other commenters that the issue is more with the font-weight than the color; I don’t have issues reading e.g. text in #666 or even #999.
redthrowaway 9y ago
Considering there are a grand total of 2500 people in the BIOT, all of whom are British or American military personnel, it might not be a great idea to route a good chunk of the world's tech traffic through them. The disparity between how important the .io TLD is for the Internet and how few resources must go to running it is pretty appalling.
- mino 9y ago
  "route"? That's not how DNS works.
  - andai 9y ago
    How does DNS work?
    - walrus01 9y ago
      when one packet loves another packet very much....
davisonio 9y ago
Wow this is quite shocking. A very nice find, this is all the more concerning considering many high profile startups including financial ones are using .io domains (I'm using one too).
Mizza 9y ago
NIC.io are a terrible, terrible registrar. I reported an account takeover security vulnerability to them 6 years ago that they only fixed after 4ish years.
belorn 9y ago
As the article mention, this is a nice example where DNSSEC would had prevented malicious activity for users which has DNSSEC validation enabled. There are also countries like Sweden were almost all ISP has this, so a rather large group of people in the world would likely have noticed if a majority of .io nameservers was responding with unsigned data.
7ewis 9y ago
I had a similar issue with the .IM domain three months ago. One of the four NS for the domain was not responding. Two of the guys at Cloudflare diagnosed it for me: https://twitter.com/xxdesmus/status/855858441289572353 https://twitter.com/xxdesmus/status/855858441289572353
- addedlovely 9y ago
  One Cofounder of cloudflare, pretty impressed they picked up tweets directly.
  - 7ewis 9y ago
    They really are great guys, it's not the first time they've tweeted me either! The CEO is active on HN too. Great customer service.
  - jgrahamc 9y ago
    Many people at Cloudflare (including myself, Matthew, Justin and others) monitor Twitter, HN and other forums carefully and reply quickly to folks. Personally, I run a script that emails me for every HN comment that mentions Cloudflare and use Tweetdeck to monitor @cloudflare/cloudflare mentions.
- Symbiote 9y ago
  At least that name is not at risk of subversion. JA.NET is the Joint Academic Network, the university / academic Internet infrastructure for the UK.
mpounsett 9y ago
While it's definitely an error on the part of the backend registry operator for .io, this is not the major security issue the author describes. He couldn't have hijacked any DNS traffic this way. I've written in detail about why this is the case at https://mpounsett.blogspot.ca/2017/07/the-io-error-problem-with-bad-optics.html https://mpounsett.blogspot.ca/2017/07/the-io-error-problem-w...
- deleted 9y ago
  [deleted]
- mandatory 9y ago
  Author here, responding here like I did on Twitter. DNS resolver implementations matter here greatly. I received so many DNS queries (without me actually responding to any of them) that I quickly filled up my VPS with gigabytes of data from IP addresses of DNS resolvers across the Internet. Saying "this is not the major security issue the author describes. He couldn't have hijacked any DNS traffic this way." seems a bit dishonest. You're saying that you have personally vetting all the DNS implementations of various DNS resolvers and have verified all of them take the resolution steps you've described exactly? If this is the case why did I receive so many queries (such as A, AAAA for the NS hostnames - which I assumed/assume was to cached these IP addresses for future resolution of the TLD's IPs). The way dig resolves things is different from how many production resolvers would do so, etc. I can certainly see that some resolvers may take different steps for resolution which would make them unaffected by this issue (I'd have to think on it some more). A big issue here is of course that I didn't actually attempt to poison a bunch of the DNS resolvers which were hitting my server because I didn't want to affect any actual users. "Proving the point" in this case would've been dangerous and probably illegal as well. That being said, mapping out how various DNS resolvers would perform their full resolution is an interesting side project and I've added it to my TODO list :)
- lightedman 9y ago
  "He couldn't have hijacked any DNS traffic this way." That is entirely untrue. If I have control of the majority of DNS server routes/domains, I can hijack plenty of traffic. This is basic N+ certification-level stuff, not even advanced networking.
swetabhsuman8 9y ago
REGISTRATION STARTED FOR HACKERS BASIC EXAM https://hackernucleus.com/registration-for-hbe/ https://hackernucleus.com/registration-for-hbe/ HACKERS ARE USING THIS NEW ATTACK METHOD TO TARGET POWER COMPANIES https://hackernucleus.com/hackers-are-using-this-new-attack-method-to-target-power-companies/ https://hackernucleus.com/hackers-are-using-this-new-attack-... BEST HACKING TOOLS OR SOFTWARE WITH EXPLANATION https://hackernucleus.com/best-hacking-tools-or-software-with-explanation/ https://hackernucleus.com/best-hacking-tools-or-software-wit...
_eht 9y ago
This sounds an awful lot like what happened to the .sr ccTLD on 06/23/17. Part of my business runs on a .sr and we were down several days. Any way to look up a history of such an event?
mgalka 9y ago
Wow! That is one scary vulnerability. Glad we have smart people like this to find such problems before the bad guys do. Well done!
tannhaeuser 9y ago
Good grief! I've always found using vanity domains for your project/company to be tasteless at best. Now .io is even associated with deportation, dispute of territory, and security screwups. Using an .io domain only serves to demonstrate that you care about pretending to be a 2010-ish startup at the expense of everything else at this point.
chmike 9y ago
Not even a "thank you" message from the TLD managers ? That is the most shameful behavior.
cnkk 9y ago
seems to be a bad idea to get domains from strange small countries just because they look cool.
too_optimistic 9y ago
Damn. I didn't realize this mattered. I looked outside of .com because it's practically impossible to find a decent domain.
superjisan 9y ago
I need like a dumbed-down version of what went wrong here.

1404 points by koenrh 9y ago

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

runnr_az 9y ago

That's amazing! Nice find, man!

andai 9y ago
Trying to figure out why you were downvoted. Was it the positivity? The exclamation marks? The lack of pretending to contribute to the conversation?
- chriswarbo 9y ago
  I downvoted because it doesn't raise any questions or add any information to the discussion. BTW, neither does commenting about votes ;) As per https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html "Please resist commenting about being downvoted. It never does any good, and it makes boring reading."
  - andai 9y ago
    I was merely puzzled that my favorite comment was downvoted to the bottom of the thread! I am sure the author (who appeared in the discussion here) would have appreciated the positive feedback. Are you suggesting it would have been better to contact the author directly?
- alexdumitru 9y ago
  It looks like it's been written by a spam bot.
  - andai 9y ago
    How so?

walrus01 9y ago

This is a huge screwup on the part of the people who run the 'root' of .IO, and their entire operation should be severely scrutinized by ICANN. In my opinion almost all of the 'weird' TLDs which are country codes that are actually operated by a third party commercial service are 95% spam and junk registrations. .TV is a good example. Technical screwups aside, the existence of .IO and the fact that it "belongs" to the UK government is morally questionable, since the entire country code only exists because the British and American militaries forcibly removed the original inhabitants of islands such as Diego Garcia so that they could use the area as naval and air force bases. https://en.wikipedia.org/wiki/British_Indian_Ocean_Territory https://en.wikipedia.org/wiki/British_Indian_Ocean_Territory https://en.wikipedia.org/wiki/Diego_Garcia https://en.wikipedia.org/wiki/Diego_Garcia If I had been able to successfully register these names and get live traffic going to a BIND9 instance, my first instinct would not be to alert the company through its first tier customer support levels, but to immediately post a summary of the problem to ARIN, RIPE, APNIC and ICANN mailing lists. This would get the issue in front of people who immediately understand how serious the problem is, and hopefully one of them would be able to contact the principals of .IO directly.

peterwwillis 9y ago
Bad actors are on those mailing lists too. What you describe would be the equivalent of mailing fulldisclosure with "Hi all, there might be more unregistered nameservers at .IO (or another 101domains-serviced TLD) that could be used to attack live traffic if anyone wants to grab those, kthx"
- walrus01 9y ago
  I'm fine with that happening, because the people who run .IO need to be spanked. If their customers are subsequently unhappy that their domain names have been hijacked, they can take it up with whatever corporate entity runs .IO. Same problem as publicly disclosing serious flaws with an SSL/TLS root CA.
  - peterwwillis 9y ago

inetknght 9y ago

> After sending the email I immediately received a bounce message indicating that the adminstrator@nic.io was not an email address that existed at all > This was not a strong vote of confidence that someone was going to see this notice. Honestly though, this seems like common practice to me.

JorgeGT 9y ago
I though ICANN was supposed to be getting serious against fake contact data on domain registrations? The fact that even a TLD's NIC admin info is fake is pretty spectacular.

michaelbuckbee 9y ago

So, the real question is: "How much should we freak out about this?" If you scroll back a few months to Cloudbleed/Cloudflare we sort of collectively decided that because cache data containing sensitive info (passwords, tokens, whatever) might be accessible for your site using Cloudflare that everything should be revoked, force password resets, etc. Now we have this vuln, which I'll dub "IOgate" because it's the cool thing to name these. We don't know if this has ever happened before, there clearly were not adequate safeguards in place, etc. Should anyone operating a service using a ".io" TLD consider everything potentially compromised?

lwansbrough 9y ago
Well, if it's any consolation.. the domains weren't registered..
- tedmiston 9y ago
  The post states that they were registered, used, then revoked.
  - andypants 9y ago
    Registered by the author. What lwansbrough means is that they weren't already registered, which means it's unlikely this was previously exploited unless the previous registrant let those domains expire afterwards.
    - CydeWeys 9y ago
      The registry (and many other people who have downloaded zone files and such) would have records of these having previously been registered. If it was exploited then it would easily be possible to find that out.
    - deleted 9y ago
      [deleted]
- michaelbuckbee 9y ago

jshelly 9y ago

Complicated by the fact that the .io domain has recently become popular for startups

ChuckMcM 9y ago

I am really super happy that the root domain serving the largest IOT population on the planet wasn't co-opted by the MIRAI bot writers. That could have been a net killing event.

gboudrias 9y ago
There's an IOT population? I thought it was just a dumb trend everyone hates? I'm not trying to diss anyone, I just thought the whole "IoT" concept was dead in the water?

mrkrab 9y ago

>Technical screwups aside, the existence of .IO and the fact that it "belongs" to the UK government is morally questionable, since the entire country code only exists because the British and American militaries forcibly removed the original inhabitants of islands such as Diego Garcia so that they could use the area as naval and air force bases. Since you're getting political there for no reason at all, let me say this: might is right. Get over it.

moonbug22 9y ago
Ladies and gentleman: Hacker News.
rhizome 9y ago
Surprising behavior from a green username.
rspeer 9y ago
> might is right. Get over it. That's a good summary of the UK's response to the UN, but we are allowed to disagree. We are allowed to have moral values that are not enforced at the end of a gun. I'm sad that you don't. And when it comes to the global organization of the Internet, politics is important. Politics is why the fad for .ly domains in link shorteners allowed links to be censored by Gaddafi's government. And politics is presumably why the UK controls this ugly stepchild of a TLD* and doesn't care about it enough to put competent people in charge of it. *Unfortunately, I use it too. .com and .org are in an end-game where everything belongs to the domain squatters.
ben_jones 9y ago
This comment is in terrible taste but it isn't wrong. We can't just shove our hands in the sand and say it isn't fair so it isn't true.
- panglott 9y ago
  Might makes the rules, but that doesn't mean the rules are right. We can definitely shove our hands in the sand and say that they are not fair.

mreithub 9y ago

Wow, I don't think I would've even considered such an attack... DNSSEC, HSTS and Certificate Pinning would've made it more difficult to abuse this, but I guess it would've been pretty easy to get valid SSL certificates for all your favourite .io domains. Let's try to play malicious party here: Phase A: First set up a simple DNS forwarder playing by the rules and answering requests as we should (as to not get any unwanted attention). Gather usage statistics. Phase B: Crawl the list of most-used domains to see if there are any valuable targets without HTTPS (port 443 is closed). Alternatively/additionally see if there are API subdomains used by software other than browsers (of which a few won't have annoying features like Cert Pinning - golang's DNS resolver for example afaik doesn't do DNSSEC). Pick some medium to high level targets where the attack might go undetected for at least some time. Phase C: MitM time! Get certificates for the target domain(s) of your choice and get to work. Start with only a few percent of the requests to not draw too much attention (and to avoid the majority of their traffic coming from a single IP (range) all of a sudden) Obfuscate the attack by acting like a third party app or something simply doing requests for their users. Congratulations on finding the vulnerability (and thanks for looking for that kinda stuff in the first place).

mandatory 9y ago
Author here, thanks - glad you liked the post! :)
btown 9y ago
Or, in Phase C, an attacker could proxy traffic through a botnet to avoid the single-ip-range issue; they could even find botnet participants geographically close to each user, so they might not even trigger any red flags from a close look at IP logs. Setting aside DNS hijacking altogether, the idea that phishing sites could do something like this, perfectly proxy i.e. a bank's content and remain largely undetectable, makes me very concerned that we're only just seeing the beginning of sophisticated phishing attacks.
djrogers 9y ago
Your missing a ton of potential here by assuming that all DNS is good for is Web traffic. For one thing, taking over or intercepting email (remember, you now control the DNS, so you also control SPF and DKIM records) becomes trivial. you could even leverage that control of email to get SSL certificates for domains you really want to do https for (letsencrypt will even generate a wildcard cert using only dns based verification). You could also be much more surgical, and target specific people/organizations using that .tld, ignoring dns requests for everyone that you don’t want to alert to your control. Hijack their email, and you control access to things like account recovery for domain users, and have a great method for phishing account credentials for the domains customers. Honestly, the list of what you could do here is almost only limited by your imagination

tbarbugli 9y ago

Not the first time .io TLD messes things pretty bad. A few months ago they had a couple of name servers poisoning internet with false negatives, that made a few hours very "interesting"

rmoriz 9y ago

Originally, .io, .sh and .tm were operated by ICB PLC, later ICB LLC (owned by Paul Kane[1]). Just a couple of weeks ago .io and .sh changed hands to Afilias which swapped out all turning parts over a weekend. They really screwed up a lot of things including losing my balance, manipulating domain information and extortion attemps: I was a reseller with ICB and have a contract. Without a cancellation period (which as defined in the contract) they wanted to take over the contract, introduce new contract details and probably a new pricing scheme. Around 20 pages of legal stuff and a window of <10 days to "decide"/comply. I'm done with them (Afilias). I'll never ever spend a dime and advise anyone not doing any business with them. (But also the old technology backed (which still runs .tm) is far from secure and reliable. At least it supports IPv6 whereas the Afilias infrastructure still is not IPv6 ready…) [1] https://en.wikipedia.org/wiki/Paul_Kane_(entrepreneur) https://en.wikipedia.org/wiki/Paul_Kane_(entrepreneur)

mdellabitta 9y ago

Just to add some color to this: There was an attack last Friday on a few geo TLDs that ended up hijacking a bunch of traffic for a few hours, including .la, .es, and .jp: https://news.gandi.net/en/2017/07/report-on-july-7-2017-incident/ https://news.gandi.net/en/2017/07/report-on-july-7-2017-inci...

sirn 9y ago
I'm one of the unlucky few that were affected by this (I own .ch). One of my site user's reported that the website is inaccessible on Friday. I went to check and observed the DNS changing. Then went to check Route 53 status page[2] in which I learn that this is not specific to my site. The behavior is exactly the same as what is described in the SWITCH report[1]. Luckily that I have HSTS on my site, so the damage is limited (users not getting redirected), and Gandi seems to fixed this quick enough (I was in the middle of commuting back home by the time of the attack.) [1]: https://securityblog.switch.ch/2017/07/07/94-ch-li-domain-names-hijacked-and-used-for-drive-by/ https://securityblog.switch.ch/2017/07/07/94-ch-li-domain-na... [2]: http://status.aws.amazon.com/ http://status.aws.amazon.com/ (The blue icon for Amazon Route 53 Domain Registration)
- jontro 9y ago
  We were also affected by this on a major e-commerce site. It was a .se domain. Their post mortem isn't really convincing ( https://news.gandi.net/en/2017/07/report-on-july-7-2017-incident/ https://news.gandi.net/en/2017/07/report-on-july-7-2017-inci... ) since they do not state what really happened and how it can be prevented again. I issued a support ticket to aws today to see what measures can be taken, otherwise we might need to change registrar.
  - vbernat 9y ago
    There is a more detailed followup today: https://news.gandi.net/en/2017/07/detailed-incident-report/ https://news.gandi.net/en/2017/07/detailed-incident-report/
    - 9y ago

felipeerias 9y ago

Who would have thought that adminstrator@nic.io registered in a small overseas territory in the middle of the Indian Ocean might not be entirely reliable?

hk__2 9y ago

Side note: Please don’t use such gray and thin fonts. I had to modify the CSS to use black instead of #555 for the text color.

iDemonix 9y ago
You might want to see an optician.
HalfwayToDice 9y ago
I had to use the "Reader" feature of my browser to read the text, for maybe the first time ever.
hanspeter 9y ago
#555 is still quite dark and should be easy to read. The real culprit is the 300 font weight - when set to 400 it's quite another matter.
CrystalLangUser 9y ago
I don't mean this pejoratively, but how old are you? I'm just curious as I had no problems with the color / font weight. For my sites I usually use something like #232323 instead of pure black.
- narrowtux 9y ago
  I'm 25 and had to zoom to read and even then it wasn't comfortable. (not the OP)
  - CrystalLangUser 9y ago
    Ah I see, upping the font-weight to 400 helped when viewing it on my laptop screen. I didn't really have that issue on mobile, though.
- hk__2 9y ago
  I’m 25. I agree with other commenters that the issue is more with the font-weight than the color; I don’t have issues reading e.g. text in #666 or even #999.

redthrowaway 9y ago

Considering there are a grand total of 2500 people in the BIOT, all of whom are British or American military personnel, it might not be a great idea to route a good chunk of the world's tech traffic through them. The disparity between how important the .io TLD is for the Internet and how few resources must go to running it is pretty appalling.

mino 9y ago
"route"? That's not how DNS works.
- andai 9y ago
  How does DNS work?
  - walrus01 9y ago
    when one packet loves another packet very much....

davisonio 9y ago

Wow this is quite shocking. A very nice find, this is all the more concerning considering many high profile startups including financial ones are using .io domains (I'm using one too).

Mizza 9y ago

NIC.io are a terrible, terrible registrar. I reported an account takeover security vulnerability to them 6 years ago that they only fixed after 4ish years.

belorn 9y ago

As the article mention, this is a nice example where DNSSEC would had prevented malicious activity for users which has DNSSEC validation enabled. There are also countries like Sweden were almost all ISP has this, so a rather large group of people in the world would likely have noticed if a majority of .io nameservers was responding with unsigned data.

7ewis 9y ago

I had a similar issue with the .IM domain three months ago. One of the four NS for the domain was not responding. Two of the guys at Cloudflare diagnosed it for me: https://twitter.com/xxdesmus/status/855858441289572353 https://twitter.com/xxdesmus/status/855858441289572353

addedlovely 9y ago
One Cofounder of cloudflare, pretty impressed they picked up tweets directly.
- 7ewis 9y ago
  They really are great guys, it's not the first time they've tweeted me either! The CEO is active on HN too. Great customer service.
- jgrahamc 9y ago
  Many people at Cloudflare (including myself, Matthew, Justin and others) monitor Twitter, HN and other forums carefully and reply quickly to folks. Personally, I run a script that emails me for every HN comment that mentions Cloudflare and use Tweetdeck to monitor @cloudflare/cloudflare mentions.
Symbiote 9y ago
At least that name is not at risk of subversion. JA.NET is the Joint Academic Network, the university / academic Internet infrastructure for the UK.

mpounsett 9y ago

While it's definitely an error on the part of the backend registry operator for .io, this is not the major security issue the author describes. He couldn't have hijacked any DNS traffic this way. I've written in detail about why this is the case at https://mpounsett.blogspot.ca/2017/07/the-io-error-problem-with-bad-optics.html https://mpounsett.blogspot.ca/2017/07/the-io-error-problem-w...

deleted 9y ago
[deleted]
mandatory 9y ago
Author here, responding here like I did on Twitter. DNS resolver implementations matter here greatly. I received so many DNS queries (without me actually responding to any of them) that I quickly filled up my VPS with gigabytes of data from IP addresses of DNS resolvers across the Internet. Saying "this is not the major security issue the author describes. He couldn't have hijacked any DNS traffic this way." seems a bit dishonest. You're saying that you have personally vetting all the DNS implementations of various DNS resolvers and have verified all of them take the resolution steps you've described exactly? If this is the case why did I receive so many queries (such as A, AAAA for the NS hostnames - which I assumed/assume was to cached these IP addresses for future resolution of the TLD's IPs). The way dig resolves things is different from how many production resolvers would do so, etc. I can certainly see that some resolvers may take different steps for resolution which would make them unaffected by this issue (I'd have to think on it some more). A big issue here is of course that I didn't actually attempt to poison a bunch of the DNS resolvers which were hitting my server because I didn't want to affect any actual users. "Proving the point" in this case would've been dangerous and probably illegal as well. That being said, mapping out how various DNS resolvers would perform their full resolution is an interesting side project and I've added it to my TODO list :)
lightedman 9y ago
"He couldn't have hijacked any DNS traffic this way." That is entirely untrue. If I have control of the majority of DNS server routes/domains, I can hijack plenty of traffic. This is basic N+ certification-level stuff, not even advanced networking.

swetabhsuman8 9y ago

REGISTRATION STARTED FOR HACKERS BASIC EXAM https://hackernucleus.com/registration-for-hbe/ https://hackernucleus.com/registration-for-hbe/ HACKERS ARE USING THIS NEW ATTACK METHOD TO TARGET POWER COMPANIES https://hackernucleus.com/hackers-are-using-this-new-attack-method-to-target-power-companies/ https://hackernucleus.com/hackers-are-using-this-new-attack-... BEST HACKING TOOLS OR SOFTWARE WITH EXPLANATION https://hackernucleus.com/best-hacking-tools-or-software-with-explanation/ https://hackernucleus.com/best-hacking-tools-or-software-wit...

_eht 9y ago

This sounds an awful lot like what happened to the .sr ccTLD on 06/23/17. Part of my business runs on a .sr and we were down several days. Any way to look up a history of such an event?

mgalka 9y ago

Wow! That is one scary vulnerability. Glad we have smart people like this to find such problems before the bad guys do. Well done!

tannhaeuser 9y ago

Good grief! I've always found using vanity domains for your project/company to be tasteless at best. Now .io is even associated with deportation, dispute of territory, and security screwups. Using an .io domain only serves to demonstrate that you care about pretending to be a 2010-ish startup at the expense of everything else at this point.

chmike 9y ago

Not even a "thank you" message from the TLD managers ? That is the most shameful behavior.

cnkk 9y ago

seems to be a bad idea to get domains from strange small countries just because they look cool.

too_optimistic 9y ago

Damn. I didn't realize this mattered. I looked outside of .com because it's practically impossible to find a decent domain.

superjisan 9y ago

I need like a dumbed-down version of what went wrong here.