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.
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.
Just so no one is misled: "original inhabitants" does not mean "indigenous peoples" with respect to the BIOT. The islands were not populated prior to late-18th Century European colonization. The depopulation was of post-colonial people.
> Just so no one is misled: "original inhabitants" does not mean "indigenous peoples" with respect to the BIOT. ... The depopulation was of post-colonial people.
Oh that's fine then. They only lived there for what 100 years, totally fine to do these things to those 1000 some people:
first tactics were implemented to decrease the population of Diego Garcia. Those who left the island - either for vacation or medical purposes - were not allowed to return, and those who stayed could obtain only restricted food and medical supplies. This tactic was in hope that those that stayed would leave "willingly".[26] One of the tactics used was that of the killings of Chagossian pets. Dogs were carried into sheds where they were gassed in front of their owners.[26]
It isn't anywhere near the worst thing the UK has done (in this case for the US so, I think they share a bit of the blame). The key issue here is that it is ongoing - the UK still isn't allowing them back or properly compensating them. The UK government should recognise that what it did was wrong, establish that the land belongs to the Chagossians and, broker an agreement where the US tries to try to buy the land needed for the base from them. There will be a price that the US government is willing to pay to keep the base there, that the Chagossians will accept, I suspect. If there is not, the base should have to be moved over a period of five years. An alternative might be the construction of an artificial island nearby. It is also possible that the value to the Chagossians, and the cost of building an artificial island, are both greater than the value to the US of having the base, in which case they should just abandon it. This is the only fair solution IMHO.
Why is that an important distinction? Is forcible expulsion and dispropriration more acceptable if the people were brought to the island as slaves and laborers in the mid-1700s?
Are you being deliberately obtuse? It's a pretty important distinction that these were not some native tribesmen with millennia of ancestral history tied up in the lands.
100s of years though, so from the perspective of an individual on the island it's exactly the same -- their entire life was on that island. So, the distinction is pointless and reeks of apologetics IMO.
"Sir Bruce Greatbatch, KCVO, CMG, MBE, governor of the Seychelles, ordered all the dogs on Diego Garcia to be killed. More than 1000 pets were gassed with exhaust fumes. "They put the dogs in a furnace where the people worked", Lisette Talatte, in her 60s, told me, "and when their dogs were taken away in front of them our children screamed and cried". Sir Bruce had been given responsibility for what the US called "cleansing" and "sanitising" the islands; and the killing of the pets was taken by the islanders as a warning."
By that logic, ethnic Europeans are the 'original inhabitants' of North America.
I'm also unclear on why you quoted what the British did in your post - how does it relate to whether or not calling those people 'original inhabitants' is misleading? Do you believe that, if the British did something sufficiently wrong to them, that calling them 'original inhabitants' will be less misleading?
Not everything is a contest. It doesn't matter how "original" natives are if they're natives.
The reason "ethnic Europeans" aren't "the original inhabitants of North America" is that European settlers violently displaced (or killed) the previous inhabitants.
Heck, the "original" inhabitants of North America (as far as we know) actually originated in what is now mostly Russia if you go back a few dozen millenia. And if you go back further than that (according to mainstream scientific consensus) we all likely originated in Africa. Defining the term "original inhabitants" as an absolute is blatantly begging the question (specifically it only works if you're a creationist).
People were subjected to physical and psychological violence to be forcibly removed from their home and birthplace. That's bad enough, no matter how many generations lived in the same place before. This isn't about who's had it worse.
They were expelled in 1965. The current year is 2017. If we wait a few more decades this discussion will be pointless either way.
I'm not opposing clarifications. I'm opposing quibbling over the semantics of "original" as if the distinction adds anything to the conversation.
Their parents lived there, they were born there, they were violently expelled and suffered emotional abuse. The number of dead ancestors (or lack thereof) in the ground does not invalidate the suffering these people were forced to endure.
By European standards the US is mostly inhabited by non-natives. So I guess it'd be okay to forcibly expel everyone but the Natives because they don't have millennia of ancestral history?
I'd hope the more important distinction is how people are removed, not how many generations of dead people there were before them.
If a man shows up with a gun to run me off my land, it doesn't matter whether it was my father that bought it or my grandfather or my great-grandfather. What's important is the forcible dispropriation itself.
Cases like this just make a mockery of the Lockean natural rights theory of property.
For a conversation to happen, everyone should be on the same page. Distinction for the sake of clarity should always be welcomed and not confused with endorsing a specific action or behavior.
It doesn't really matter at all. The land didn't come with a .io ccTLD. It's dervived from a name the British chose, so it's not like they stole the domain name from those people, right?
IANA allows delegation of country-code TLDs for all countries and territories represented in the ISO 3166-1 standard.
The thing to bear in mind is this standard is used for a number of different purposes historically that has informed territories and other "non"-countries being added.
For example, it is used by postal services for routing physical mail. A lot of far flung island dependencies are coded individually because their mail wouldn't route through their mother country but through other ports.
The addition of "EU", while not a country, reflected the needs of the "EUR" currency code when the Euro was introduced (the first two letters of ISO 4217 currency codes are derived from the ISO 3166-1 standard).
I think the morally questionable problem is this: I am highly doubtful that the original inhabitants of the islands are receiving any revenue whatsoever from the corporation which runs .IO. At least the small pacific island nation states that have hired third parties to run their ccTLD have contracts and agreements in place for a revenue share.
Why should they get any revenue from .io? The .io is an invention of the government and has nothing to do with the original inhabitants. The "original" people were removed well before .io even existed.
Might as well demand they get paid for any inventions the military makes while testing stuff out there.
And if the British hadn't done this and gave control over to the people living there 50 years ago, they wouldn't get .io either, because they wouldn't call themselves British Indian Ocean Territories. They'd have used something reflecting the name in their language.
So again, this is a "resource" purely created by the British government being there.
Maybe it's terribly unfair and bad what they've done to those peoples, but .io doesn't figure into that at all.
Edit: I suppose if they had their own nation state, they could make some money that they couldn't otherwise. But why stop at domain names (which, again, wouldn't be .io, it'd be .cx or something for Chagossians)? They can't issue passports, a potentially valuable resource, not being a sovereign nation. They can't run "tax haven" schemes, etc. Seems like getting upset over .io itself is pointless compared to all the other stuff they could do with an internationally recognized government.
.SU is actually the only former country with a TLD still delegated, and quite a few have been removed. In recent years .AN, .TP, .YU, .ZR have been phased out representing former countries.
I am similarly outraged that I haven't had any cheques from Nominet come through the post recently and as a UK tax paying citizen I am outraged at this oversight.
Of course, the difference between the Indian Ocean Territory and India, is that people lived in India before. When the French showed up, the atolls were uninhabited.
I'd say that using the land of your own country - owned by people in your country - for military purposes, while sketchy, is definitely more acceptable than taking an island from its indigenous occupants by force. The UK ownership then seems at least to be legitimate.
I'm in the TLD space (we run a fair number of gTLDs). If a gTLD operator screwed up like this then there could be consequences. A ccTLD, however, runs with very few restrictions. I don't see much of consequence happening to it as a result of this.
I will, however, say that gTLDs are generally more secure and well-run than smaller ccTLDs, and are worth preferring for that reason. It's a weird historical quirk that .io randomly became popular in the developer community, but there are better options. And, as you point out, it's morally suspect, which is why we don't use it for new domain names.
There are a few ccTLDs that differ from that, though. DENIC and CZNIC are two that are generally very well-run, DENIC even offering better security and safety than many gTLDs (while also being a cooperative, not a commercial NIC, so prices are very low, too)
It is really nice, that the .de domain is seen more as infrastructure than some business. But there are a few downsides to DENIC as well.
1. you need to have a person (juridicial or natural) with an address in Germany to register and list that person as ADMIN-C
2. if you run a website that provide contents which COULD generate revenue, you have to have an Impressum [1] which includes the address, names, etc. of the website owner.
This is pretty annoying if you are sensitive about privacy and do not want your details out in the open.
Agree to disagree. Of the top of my head I can think of several useful things where a public (private) address would be problematic:
1. you want to do something like wiki leaks
2. you want to publish your thoughts anonymously, let's say you are from the LGTB spectrum and want to engage with people by building a forum or blog to communicate with them -> this could lead to potential problems with family, friends and work
3. you have political views and publish them. Now say someone disagrees with your views and is potentially aggressive. Do you want them to know where your family lives?
4. you do not wan't annoying calls by people who crawl the DENIC records (happens to me regularly)
I agree with you that a person should be liable for the stuff they do, but should also be able to engage in open discussion while protecting their privacy. FWIW If someone does bad stuff on a .de domain there are several options:
a) take down the domain via DENIC, or b) take down the domain via ISP or c) take down the domain via Hosting provider
If you really did illegal stuff, I am with you and someone (DENIC, ISP or Host) probably should have the knowledge of the domain owner which could be subpoenaed to lawfully prosecute someone.
making a single person personally liable for content that's hosted on a domain is problematic, to say the least. Go down that path and you eventually end up where the chinese government is now. Where you need a "license" from some ministry to operate an http daemon and you need to hire censors to police all user generated content that disagrees with an authoritarian regime's politics.
I think it's more than a dozen. I would expect all wealthy, tech-savvy democracies to have fairly competently run ccTLDs. It's just that there's about 200 countries in the world, and quite a lot of those are a complete mess.
given the incredible importance to global internet infrastructure of things like the DE-CIX in frankfurt, I am not surprised that the Germans have their shit together when running critical back end systems.
if .ca was not competently run, I'm pretty sure the federal government would step in and put it into the hands of people with real DNS/network engineering credibility.
Unlike the rarely used .us for the USA, it is used for the vast majority of canadian domestic corporations' web identities.
ccTLDs are pretty much the most sensible thing in DNS hierarchy. The "original" TLDs (.com, .net, .org etc) had mostly lost their meaning by late 90s (iirc), and were heavily biased towards the US anyways and as such would have made far more sense as second-level domains for .us, where enforcing the separation could have at least hypothetically worked in some reasonable way.
ccTLDs don't appear to be held to very high standards. For example the .AF top level domain (which is controlled by the government's ministry of communications) doesn't even have a working website, www.nic.af
They're not held to any standards, really. Some of the smaller ccTLDs are basically just run using hand-edited zone files and spreadsheets to track ownership and expiration thereof.
There are also issues like the .LY ccTLD being owned by whatever government claims to be in control of Libya this month, and occasionally revoking domains for things they don't agree with. If I recall correctly for a long time there were several commercial services reselling .LY, but its stability is questionable at best.
We just used ai.google instead of google.ai as the canonical domain name for Google's AI initiative for precisely this reason. (We run .google and you can see the source code at https://nomulus.foo )
If I'm reading https://whois.ai/cgi-bin/register.py? correctly, I'm not sure it's strictly required - it might just delay our account by a month (it's not 100% clear IMO):
> We will email you a password after which you need to login and pay the $100, unless you are resident in Anguilla.
> After this we will send you a letter, fax and short text message (SMS) with codes on them. Please, be sure your information is correct so you can receive verifiaction codes. When you get these you need to login and enter them.
> We will also wait 3 months to make sure there is no problem with your credit card. But each successfully verification will decrease this period by one month, so if you pass all of them you do not need to wait 3 month.
Shame it's so arcane/expensive ($100 for account, then $100/2 years per domain) - there's a couple of joke domains I might have picked up if they were cheap enough (gomennas.ai / ebihara.ai [character from Persona4]).
I do appreciate that the TLD alone resolves though: http://ai./
FWIW, 101 Domains allows you to register a .ai domain (I registered zuse.ai there) and you don't have to do anything with a fax, etc. Now, maybe 101 has to fax something to somebody in Anguilla, but as the end user, you're isolated from that. Unless things have changed since I registered my domain.
Wouldn't that work like the old Compuserve or Prodigy email addresses? And if it would, wouldn't most email clients have to have "back-compatibility" with it?
because that's the URL that the admins of .AF publish. It could be http://whatever.af if they wanted that, but if it had an httpd not showing any content, would be equally as suspect.
what's wrong with the traditional .net ? software projects are pretty much all network related these days. or use the new gTLD .network which is pretty cheap to buy.
In the mid 90's I got to spend a quiet and frankly wonderful 60 days on Diego Garcia while I was enlisted in the USAF. It is a wonderful island, you can bike around the whole thing in a couple hours, the rec facilities were great, beer was incredibly cheap, and the Internet (on such a remote island, in 1995!) was the best/fastest I had seen at that point.
That all said, the forced expulsion thing (which I just caught up on) is news to me now. I guess bullies will always exist. It reminds me of forcibly relocating people in the US via eminent domain to build a highway. It's possible that an ethical argument can be made that if the security of the USA actually did depend on total control of that island, the cost in dollars and emotion of "strongly encouraging" people to move elsewhere might be justifiable (and I do believe they were compensated... the gassing of pets thing is shocking, though).
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"
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.
I own an .IO domain. Do I deserve to have fake LetsEncrypt certs issued against me and my domain hijacked because some engineer forgot to remove some critical NS records or forgot to register some aliases?
"Responsible disclosure" is a coercive term. It implies that it's irresponsible to do anything else. "Coordinated disclosure" is far better.
That said, coordinated disclosure is the neighborly thing to do, but it's by no means a moral obligation. It would be perfectly fine for the author to tweet about it, for example.
No moral obligation? I don't think many people would agree with you on that.
If you are actively poking around at someone's home and you find an unlocked window, you don't think there is a moral obligation to inform the owner of the security issue? No moral issues if you then find a group of hoodlums down the street and announce that house 123 has an unlocked window?
I can see if you were just driving by and saw the window open, you don't really have any obligation (unless you plan to announce it publicly) but if you are actively seeking out security flaws in someone else's property, not disclosing it to the owner and then announcing it or worse, selling it to potentially bad actors seems morally reprehensible.
This isn't equivalent to "If I leave my door unlocked..." scenarios. It's perfectly legal to register any .io name you want. You can't go poking around someone's house.
The situation is more analogous to discovering that a certain type of door offers no protection, even though it seems to lock. It's perfectly fine to tweet about that, regardless of how many people have that door. The blame lies on the company, not the messenger.
That would still be unethical. An ethical person would not commit acts which they know have the potential to cause harm to innocent people.
If you're a black hat and you don't give a shit about potential legal ramifications or any injury to anyone (partly because you fear no consequence), there's probably nothing unethical to you about fucking over a bunch of innocent people just so you can "spank" some douchebag management company into following best practices.
If you're a professional, or even a non-douchebag adult, who finds value in the ideal of protecting the innocent customers of a dangerously irresponsible corporation, you would want to work first toward protecting those individuals, and then focus on disciplining the corporation.
This moral judgement is mistaken because its premise is false. The moral blame lies on the company that allowed the problem to happen, not the person calling attention to it. It's not at all the same as "if I leave my door unlocked..." type scenarios. It's perfectly legal to register .io's nameservers.
That's a cop out. If your actions reasonably cause harm to other people, regardless if those actions are "calling attention to" or actually pulling the trigger, that's a moral evil.
If someone goes around the town telling everyone that you leave your door unlocked, while they can't be legally held responsible, they're still morally responsible if someone goes in and steals your stuff armed with that knowledge.
Companies fixing their stuff before that happens is in everyone's best interests at the end of the day - hence responsible disclosure.
Frankly, yes, a little bit. You're choosing to run your website/infrastructure/etc with a dependency on a sketchy service with no oversight (the ccTLD system in general, but .io in particular). Unless you suffer for this choice, the market for provider competence will be broken.
That nobody had any idea was sketchy or un-oversighten until recently. It was not a choice to run their website/infrastructure/etc on sketchy services at all.
No. People who care about internet-scale infrastructural issues have known about these issues for a very long time. However, most people who utilize (and depend on) these services have not taken the time to understand how they work.
Because it's a simple transaction. I pay someone for a domain, I get said domain.
Jimmy Throwawaysite shouldn't have to take the time to understand how DNS works above knowing how to set DNS records, the oversight should come from above. If ICANN wants to let anyone with a couple hundred thou run a TLD they should be making sure that entity can technically manage the TLD.
Is a pretty misleading phrase: they were 1000 or so slaves brought by the French to otherwise unoccupied islands. They should have been compensated like any other group of people whose government wants to build a military base, or a dam, or a highway on their land - but it's not like it was some kind of genocide. Much worse things have happened in pretty much every country on the globe.
The idea that there should be a breakdown of domains by country is a bad one. There's this situation. There are many other situations where countries don't have the resources or drive to maintain what they have been allocated. And then there's the fact that there are enough domains conflicting with this structure that it makes no intuitive sense.
The fact is that there is nothing that can be derived by an end user from most top level TLDs. EDU is one of the few, but then anybody can have a subdomain in an edu environment for any purpose.
Maybe the time isn't now, but somebody should be thinking about how to replace the current domain management system and with what.
People make mistakes. This seems like some manual configuration/technical debt issues. Don't get me wrong, mistakes for these big, highly used TLDs is pretty massive. The scale of this is could have been devastating.
Responsible disclosure to the company that runs the TLD seems like the right first step. This should probably posted on ICANN, ARIN, etc mailing lists even now, but I think the writer's original response is the right one.
The people that make this sort of mistake should not be responsible for a TLD. This is one of the worst possible blunders imaginable.
Considering they control the .io TLD these should have been registered and locked as reserved. That this wasn't the policy is but one of the many failings that lead to this outcome.
If I were ICANN I'd slap them with a huge fine to send a message.
To say they stole it from Ukraine in the same way they stole the .io TLD would mean that they would have to take over the entire country of Ukraine. Maybe the Russian government will have control of the .ua TLD someday.
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…)
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).
If you control the root DNS servers for .io, you can simply not answer the DNSSEC queries. Many resolvers will fail open.
HSTS requires the site is HTTPS with a valid cert. If you own all .io, you can use LetsEncrypt to get that for free. They now even support Wildcard Certs! :-) That said, you would have to choose your targets carefully and/or load balance your requests to LetsEncrypt. There is a rate limit. There are browser plugins that can tell you if a cert just changed, assuming you have been to that site prior.
Then there is Public Key Pinning. This would be great, but I suspect the number of big companies implementing this are low. I don't have numbers, but you can test your favorite sites in Qualys[1] or using testssl.sh[2] that only depends on openssl and bash.
You could proxy all requests to the real root servers for .io and only become authoritative for the ones you wish to target.
Given the small number of zones, I think a modest server could keep up, or you could balance the load on a bunch of VM's. It may take a while for anyone to notice. I am curious actually, how many fellow geeks have nagios/sensu alerts that would tell them if the root server IP's changed.
All of this said, there are BGP attacks you can do that accomplish the same thing for any TLD and the IP's wouldn't even have to change. Only more advanced monitoring tools that keep an eye on route path might notice, but probably would not alert anyone.
Let's assume an attacker who selectively hijacks .io traffic in such a magical* way that the owners of the relevant domain names do not notice the attack is happening. Assuming that, what exactly would the CT monitors notice? I assume there would be new LetsEncrypt certificates entered into the append-only log, but then what?
That could certainly be useful in the follow-up investigation and forensics. Hopefully our attacker did not spin up those VM's using a burner card or stolen CC and proxies.
There isn't anything magical about selectively targeting domains. One simply creates multiple recursors and sets the upstream forwarder to the proper IP's of the original root servers. Then one adds zones for the domains or individual records they wish to modify. Unbound DNS is great for taking over individual records. I use it for this very purpose to block advertisements and trackers. In this case however, we are just acting as a root server, so there isn't much to take over. We just point the victims to ourselves for the domains we wish to hijack. We could then have a second level of recursors to perform the above selective attacks.
I don't know if LetsEncrypt would issue that, even if you control it. That would be a good exercise to validate if there is an "easy mode" for state sponsored fun.
I've read that browsers are said to block such wildcards, but I don't know to what they are referring. I create wildcard TLD self signed certs all the time. I've never had one signed by a proper CA, so I can't tell you if the browsers have any logic to ignore them.
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
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.
Thanks for this; as very-much-not-a-security guy, the alarm sounded by the original post was surprisingly clear, but fleshing out a plausible attack scenario like this really helps drive the point home while also teaching me a bit.
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?
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 + 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?
>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?
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
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 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.
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.
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.
> 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?
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.
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:
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.)
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-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.
> These credentials were likewise not obtained by a breach of our systems and we strongly suspect they were obtained from an insecure connection to our technical partner’s web portal (the web platform in question allows access via http).
This makes no sense - how did the attacker get between gandi.net and their technical partner in order to MITM them? MITMs aren't magic - simply sending an unencrypted password somewhere doesn't result in it becoming public knowledge unless a router or switch in the path is malicious.
If it's BGP hijacking, there'll be evidence somewhere.
And no, don't trust the network, but "the network isn't trustworthy" is not a diagnosis, only a potential risk factor. "X entity used BGP hijacking to situate their router between me and Y" is a diagnosis.
I doubt changing the registra would change anything, as this seems more likely a problem on the TLD backend side than a problem on the registra itself, since it affect not only Gandi but also Route 53 Domain Registration. I'm under a serious consideration to switch from .ch to something else.
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?
Cloudbleed was different in a lot of ways, not least of which because it could have been passively exploited by an unknowable number of attackers even after the bug was fixed. Here, this is an active attack that leaves a trail. The question is more like "do you trust the author?"
You make a really good point about the post patch exploitation from Cloudbleed putting that in a different category. I guess my thinking was: Is this guy the first? Are the authoritative IO domain servers compromised some other way? Are the other servers legit?
>I'll dub "IOgate" because it's the cool thing to name these.
FWIW, I've found that whenever major news outlets use the "gate" postfix for anything other than Watergate, it's an indicator that they're being manipulative (it's tabloid bullshit). The certainly didn't call it Snowdengate or Trump/Russiagate.
Yes but [per the article] they weren't registered before he bought them. Obviously somebody could have done this before and stopped, or could control some of the other servers.
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.
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.
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.
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.
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.
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"
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.
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.
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.
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).
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.
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 :)
>The author assumes that because he's able to register a domain name that matches several of the authoritative name server names for the .io TLD that it is "likely that clients will randomly select our hijacked nameservers over any of the legitimate nameservers..." This is wrong.
It is definitely not wrong for a large number of resolvers. This bears out in his traffic.
It is very common for a resolver to take the list of nameservers from the root and resolve them rather than using the A records provided by the root. Quite wrong, but common. If they didn't, he would have received zero traffic.
Thus it would have been quite easy to redirect traffic for bit.io by also supplying a different set of NS records for it.
"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.
We've banned this account for trolling. If you don't want to be banned on HN, you're welcome to email hn@ycombinator.com and give us reason to believe that you'll only post civilly and substantively in the future. But please (re)-read the following first:
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.
Next time summon the courage to express your moral nihilism on your real account.
It almost feels like a mistake to dignify this with the obvious response: might is might, but might is not right. Moral criticism like that of the GP is subject to debate, but not to the blanket claim that injustice as a thing doesn't exist and power is the only reality.
Thanks for asking that question. My original comment was made quickly and perhaps unintelligently. I don't mean to imply force makes something "right" where "right" is good or best society. I meant from a historical perspective success and strength often makes things culturally acceptable.
A pop culture reference I like to make is the protagonist in Wolf of Wall Street who defrauded many innocent and vulnerable people, is seen as a hero.
Relating back to OP and his American comment, we can reopen Guantanamo Bay for the purpose of torture yet every time our president sets foot in a foreign country he receives a celebration: partly due to the might of the American military and economy.
Relating back to tech and software in general: How do we feel about Microsoft, Bill Gates, after what they did in the 90s? How do we feel about the way Steve Jobs treated his employees and bought his higher placement on the organ transplant list?
He definitely isn't. Neither is Gordon Gecko except by those people who fail to understand the slightly deeper meaning of the telling of those stories.
> How do we feel about the way Steve Jobs treated his employees and bought his higher placement on the organ transplant list?
Or his partner for that matter. But that wasn't the subject, even so plenty of people detest Jobs for or even all of the above.
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?
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?
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.
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/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.