Capture all .io domains with targeted registration

Original author: Matthew Bryant
  • Transfer
In a previous article, we discussed the capture of .na , .co.ao and .it.ao domain extensions with various DNS tricks. Now we will consider the threat of compromise of the top-level domain (TLD) and how an attacker should act in order to achieve his goal. One of the rather simple methods seems to be the registration of the domain name of one of the authoritative name servers of this TLD. Since authoritative servers can be hosted on arbitrary domains in TLDs, it is possible to register such a domain using 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 quote the corresponding quote from the previous article:

Such an option seemed a sure road to victory, so I spent a lot of time developing toolkits for checking errors of this type. In essence, this process consists of recording all the host nameservers for a given domain - and checking when any of the root domains has expired and it will become 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 was running out of 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 record many domain intercepts in closed zones (.gov, .edu, .int, etc.), but not the TLDs themselves.

As it turned out, this method is not only suitable for a TLD attack, but in reality led to the largest TLD capture to date.

Anomaly .io


On Friday night, plotting the DNS delegation paths for different TLDs, my script gave an unexpected result for the .io zone: One of the functions of this script (called TrustTrees ) is that you can pass the Gandi API key to it - and it will check if there is whether there are name servers with free domain names in the delegation chain. The script showed that in the .io zone many domain names of domains are available for purchase! However, this does not mean that they can actually be bought. Previously, I have repeatedly come across the fact that a free domain name cannot be registered, because it is "reserved." I decided to go to the NIC.IO registrar website and check. Quickly looking for a domain name



ns-a1.io , was surprised to find that it was for sale at a price of $ 90.00. Since it was about midnight ( probably, the author considers this to be “childhood” time - approx. Per. ), I decided to continue and really try to buy this domain. Soon a letter arrived confirming that the domain name registration was “being processed”:



It is not entirely clear why the letter came from 101Domain. She is probably involved in the registration of domains in the .io zone (possibly managing the entire registry?). At this time, well after midnight, I shrugged my shoulders and went to bed, and forgot about this case, until such a letter arrived on Wednesday morning, when I was about to leave for work:



Then I remembered my Friday investigation and all the details of the registration. I had to return to my computer: I wonder if I really got control over the .io domain zone name servers? I quickly ran a command digfor the domain - and made sure that my test DNS name servers ( ns1 / ns2.networkobservatory.com ) were actually 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 is listed as an authoritative name server for the first level .io domain zone:

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 bound, and quickly killed a working BIND server. If DNS traffic pisses me off, then 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 queries will automatically be redirected to other name servers of this TLD and will not affect traffic too much (except for a slight delay when resolving while DNS clients reach the working name server). To see if DNS queries really came to me, I quickly started a tcpdump dump recordall DNS traffic to a file - and hundreds of requests from random IP from all over the Internet poured on the screen. It seems that I really handled traffic for the entire domain zone. And even worse: it was probably just the beginning, because many DNS clients were still guided by cached old DNS records that would be updated soon.

Report Security Issue in TLD


Since my server no longer responded to DNS queries, I only thought about how to quickly fix the situation. Most of all, I was worried that there were still a lot of domains for name servers that could be registered by anyone who had the money and the knowledge to do. I searched for contacts of .io TLD administrators in the IANA root database :



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



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



Fuh! At least some random hacker will not crack them, and I can go to work with a pure heart.

Later that day, I phoned NIC.IO support and asked for a valid TLD security email address. The agent assured me that the appropriate address for such a request would be abuse@101domain.com(I asked him twice about this for confidence). Although this address does not look suitable, I sent a report with a description of the problem there and hoped that it would at least be sent to a competent specialist. Since it was not possible to find out other addresses, I was waiting for an answer.

“Oops” - correction by canceling domain registration


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



Surprisingly, it looks like the abuse @ address really turned out to be the right address for the solution Problems. Having logged into my 101Domain account, I found such a letter from the 101Domain legal department: Everything was done fairly quickly and correctly (although usually I get just a notification letter instead of a response from the legal department). After making sure that the indicated domains are no longer available for registration, it was possible to conclude that the situation was completely corrected.





Possible consequences


Given that we have 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 would be more likely to come to us without any additional tricks like long TTL responses and others that further increase our chances. Even if there is an immediate reaction to this kind of attack, it will take some time until the cached records are completely erased from all the world DNS resolvers.

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

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

Protection and Security TLD


I wrote in some detail how TLDs can avoid some of these problems (for more information, see “Findings and Recent Thoughts” in the article “ Routing Hacking National TLDs — Hidden Risks of Domain Name Extensions .” In the future I’ll be writing a more comprehensive guide on how to TLDs and domain name extension operators to monitor and prevent such situations.

Greetings


I promised my friend that I would give him the hacker hello in the next blog post, so I have to fulfill the promise :). Special thanks to these guys for their 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.

Also popular now: