Capture all .io domains with targeted registration

In the previous article, we discussed the seizure of the domain extensions .na , .co.ao, and .it.ao using various DNS tricks. Now consider the threat of compromising a top-level domain (TLD) and how an attacker needs to act in order to achieve the goal. One of the rather simple methods is to register the domain name of one of the authoritative name servers for this TLD. Since TLD authoritative servers can be located on arbitrary domains, there is a chance to register such a domain, taking advantage of an error due to incorrect configuration, expiration or other errors. Then this server can be used to issue new DNS records in the whole domain zone.

I will cite here the corresponding quote from the previous article:

This option seemed like the right way to win, so I spent a lot of time developing tools for checking this type of error. In essence, this process consists in recording all the name server hosts for a given domain - and checking when the registration of any of the root domains expires and it becomes available for registration. The main problem is that many registrars do not say that the domain is completely free until you really try to buy it. In addition, there were several cases when the server expired on registration, but for some reason the domain was not available for registration, although it was not marked as reserved. As a result of such a scan, it was possible to fix many interceptions of domains in closed zones (.gov, .edu, .int, etc.), but not the TLDs themselves.

As it turned out, this method is not only suitable for attacking TLDs, but in reality has led to the largest seizure of TLDs to date.

Anomaly .io

On Friday evening, compiling a schedule of DNS delegation for various TLDs, my script produced an unexpected result for the .io zone:
')


One of the functions of this script (called TrustTrees ) is that it can transfer the Gandi API key to it - and it will check if there are any domain names in the delegation chain with domain names free for registration. The script showed that in the .io zone, many name server domains are available for purchase! However, this does not mean that they really can be bought. Previously, I repeatedly encountered the fact that a free domain name cannot be registered because it is “reserved”. I decided to go to the website of the registrar NIC.IO and check. Having quickly looked for the domain name ns-a1.io , I was surprised to find that it was put up for sale at a price of $ 90.00. Since it was about midnight ( probably, the author considers this a “childish” time - approx. Per. ), I decided to continue and really try to buy this domain. Soon a letter arrived confirming that the registration of the domain name was “being processed”:



It's not entirely clear why the letter came from 101Domain. She is probably engaged in the registration of domains in the .io zone (perhaps, she manages the entire registry?). At that time, well past midnight, I shrugged and went to bed, and forgot about this incident until such a letter arrived on Wednesday morning when I was about to leave for work:



Then I remembered my Friday investigation and all registration details. I had to go back to the computer: I wonder, did I really get control of the domain name server .io? I quickly ran the dig command for the domain - and made sure that my test DNS name servers ( ns1 / ns2.networkobservatory.com ) are really recorded on ns-a1.io :

 bash-3.2$ dig NS ns-a1.io ; <<>> DiG 9.8.3-P1 <<>> NS ns-a1.io ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 8052 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;ns-a1.io. IN NS ;; ANSWER SECTION: ns-a1.io. 86399 IN NS ns2.networkobservatory.com. ns-a1.io. 86399 IN NS ns1.networkobservatory.com. ;; Query time: 4 msec ;; SERVER: 2604:5500:16:32f9:6238:e0ff:feb2:e7f8#53(2604:5500:16:32f9:6238:e0ff:feb2:e7f8) ;; WHEN: Wed Jul 5 08:46:44 2017 ;; MSG SIZE rcvd: 84 bash-3.2$ 

I requested one of the root DNS servers and again made sure that this domain was specified as an authoritative name server for the first-level domain zone .io:

 bash-3.2$ dig NS io. @k.root-servers.net. ; <<>> DiG 9.8.3-P1 <<>> NS io. @k.root-servers.net. ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 19611 ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 7, ADDITIONAL: 12 ;; WARNING: recursion requested but not available ;; QUESTION SECTION: ;io. IN NS ;; AUTHORITY SECTION: io. 172800 IN NS ns-a1.io. io. 172800 IN NS ns-a2.io. io. 172800 IN NS ns-a3.io. io. 172800 IN NS ns-a4.io. io. 172800 IN NS a0.nic.io. io. 172800 IN NS b0.nic.io. io. 172800 IN NS c0.nic.io. ;; ADDITIONAL SECTION: ns-a1.io. 172800 IN AAAA 2001:678:4::1 ns-a2.io. 172800 IN AAAA 2001:678:5::1 a0.nic.io. 172800 IN AAAA 2a01:8840:9e::17 b0.nic.io. 172800 IN AAAA 2a01:8840:9f::17 c0.nic.io. 172800 IN AAAA 2a01:8840:a0::17 ns-a1.io. 172800 IN A 194.0.1.1 ns-a2.io. 172800 IN A 194.0.2.1 ns-a3.io. 172800 IN A 74.116.178.1 ns-a4.io. 172800 IN A 74.116.179.1 a0.nic.io. 172800 IN A 65.22.160.17 b0.nic.io. 172800 IN A 65.22.161.17 c0.nic.io. 172800 IN A 65.22.162.17 ;; Query time: 70 msec ;; SERVER: 2001:7fd::1#53(2001:7fd::1) ;; WHEN: Wed Jul 5 08:46:14 2017 ;; MSG SIZE rcvd: 407 

Wow! I immediately connected via SSH to my test DNS server, to which this domain was now linked, and quickly killed the working BIND server. If DNS traffic hits me, I definitely don’t want to return bad answers to people who have legitimate access to their .io domains. Since the BIND server no longer processes requests for port 53, all DNS requests are automatically redirected to other name servers of this TLD and do not affect traffic too much (except for a small delay in resolving, until DNS clients reach a working name server). To see if DNS requests really went to me, I quickly started recording tcpdump dump of all DNS traffic to a file - and right there hundreds of requests from random IPs from all over the Internet rushed to the screen. It seems that I really handled the traffic for the entire domain zone. And even worse: it was probably only the beginning, because many DNS clients were still guided by cached old DNS records, which will be updated soon.

Report Security Issue in a TLD

Since my server no longer responded to DNS requests, I was only thinking about how to fix the situation as quickly as possible. What bothered me most was that there were still a lot of domains for name servers that anyone who had the money and the knowledge of what to do could register. I searched for .io TLD admin contacts in the IANA root database :



Then he made a description of the problem and sent letters to both addresses, noting the need for an urgent solution. I indicated that domains for other TLD name servers are still available for registration and that if the problem is not resolved within a few hours, I will register them to protect the zone. Immediately after sending the letter, I received a bounce from the mail server with the indication that the address adminstrator@nic.io does not exist:



This obviously did not add confidence that someone would read my letter. So I decided to spend some money and buy the rest of the name server domains so that nobody hacked the TLD. As in the first case, I explicitly configured the DNS server not to accept incoming requests, so I did not interfere with normal .io traffic. These purchase orders were issued fairly quickly:



Whew! At least, some random hacker won't hack them, and I can go to work with a pure heart.

Later that day, I phoned in support of NIC.IO and asked for the valid email address of someone from the security department staff for the TLD. The agent assured me that the appropriate address for such a request would be abuse@101domain.com (I asked him twice for that matter for sure). Although this address does not look appropriate, I sent a report describing the problem and hoped that it would at least be sent to a competent specialist. Since it was not possible to find out other addresses, I waited for an answer.

"Oops" - correction by canceling domain registration

Around noon the next day, a series of notifications from 101Domains came that the domain registrations were canceled, the money was returned to the card, and my “ticket in the support” was answered and closed:



Surprisingly, it seems that the abuse @ address really turned out to be the right address to solve the problem. Logging in to your 101Domain account, I discovered such a letter from the 101Domain legal department:



Everything was done fairly quickly and correctly (although usually I get just a letter with the notice instead of the answer of the legal department). Making sure that these domains were not available for registration, it was possible to conclude that the situation was completely corrected.

Possible consequences

Given that we registered four of the seven authoritative name servers for the .io domain zone, we could change / redirect DNS records for all registered .io domains. Moreover, since we controlled more than half of the name servers, DNS queries were more likely to come to us without any additional tricks like long TTL responses and others that increase our chances even more. Even under the condition of an immediate reaction to this kind of attack, it will take some time until the cached records are completely erased from all the world's DNS resolvers.

To remedy the situation, it would help that DNSSEC technology is supported in the .io domain zone. This means that if your resolver also supports this technology, you can protect yourself from such attacks with fake DNS records. But as I said in the last article, almost no one uses DNSSEC . I rarely see any support for this technology, unless I specifically set up a resolver myself.

* One note that is not related to the topic: it is important not to forget to stop tcpdump after starting. If you do not do this, then you have a good chance to fill all the disk space on the VPS with DNS data. Please note that all DNS data recorded for debugging purposes is cleared of confidential user information.

TLD Protection and Security

I wrote in some detail how TLDs can avoid some of these problems (for more information, see “Conclusions and Recent Thoughts” in the article “ Hacking a National TLD — The Hidden Risks of Domain Name Extensions .” In the future, I’m going to put together more extensive guidelines TLD and domain name extension operators to monitor and prevent such situations.

Greetings

I promised my friend that I would give him a hacker greeting in the next blog post, so I must fulfill my promise :). Special thanks to these guys for moral and "immoral" support (as the one and only HackerBadger said ).

Hi, HackerBadger , EngSec (you know who you are), Hacke the planet , the gibson and all that.