DNS

DNSnitch – Reverse NS Lookups & Zone Transfers

The recent DDoS drama with Dyn has had me reading up on Domain Name Systems (DNS). Time and time again, bad guys have proved that one of the best ways to execute a successful Distributed Denial of Service (DDoS) is to hit DNS servers.

As a pentester,  name servers do come up a lot during assessments, especially during the reconnaissance phases. We still come across a few public name servers allowing zone transfers every now and then, which is always a treat, but I hardly ever look at DNS servers as an actual target. I still haven’t come across a client that’s actually willing to pay anyone to bring their services down.

The DDoS against Dyn was particularly troublesome because Dyn is a major DNS provider and the attacks caused serious outages to a number of popular sites; Twitter, Paypal, Reddit, Github, Spotify and more.

Which got me thinking; if I was a bad guy doing my recon, looking for the best name servers to hit, how would I go about it? Which name servers would I pick? Querying a domain for the name server(s) it uses is pretty straight forward, but if the name server was my target and a denial of service was my goal, I’d want to find out the opposite; how many domain names are using the target name server?

 Reverse NS Lookups:

Some googling led me to reverse name server lookups, which is taking a single name server and looking up all the individual domains that use it. But how do reverse NS lookups actually work? The best answer I found was on Server Fault:

  1. Zone file access: Some registries grant access to their zone files to their registrars and other entities. This makes it pretty easy to determine which domains in those zones are delegated to a given DNS server. But from what I’ve been reading, registries providing access to zone files isn’t very common these days. So even though this is the most reliable method, it’s not so widespread anymore.
  2. Passive DNS: This involves examining traffic through recursive DNS servers at ISPs and reconstructing zone data based on what’s seen. This takes up a lot of resources and also runs the risk of having outdated entries in your domain database, but it still works and there are providers that offer such services, which is what I’m going to talk about next.

Reverse NS Lookup Tools:

The first thing I did was look for any command line tools that can perform reverse NS lookups; either my Google-Fu sucks, or it’s really hard to find tools that do this. I did find a number of websites that offer the service; both free and paid. Because I’m a security professional (broke), I tend to be partial to free tools, so I spent most of my time playing around with those.

1. gwebtools – gwebtool’s name server spy came up first. It works just as promised, feed it a name server and it will list all the domains it can find that use it. The only catch with it is that it only produces results for .com and .net domains. How does it work? They have systems running that monitor changes on .com and .net domains, these systems updates their domain database monthly.

gwebtools_ns-spy

2. viewdns.info – Next I came across viewDNS.info’s reverse NS lookup tool. I came to prefer this tool because it monitors more domains than gwebtool’s ns-spy, meaning it will tend to get a lot more results than gwebtool does. They offer an API that allows people to integrate their tools into their own sites and they even sell lists of all the domain information their tools have collected.

viewdnsinfo_lookup

 

3. Domain Tools Last up was Domain Tool’s reverse NS lookup. Now this isn’t free, you can run the lookup for free and preview a tiny sample of the results, but you either need to buy the report or register for a domain tools account to get access to the lookup results (at the time of writing, a personal domain tools membership is $99 a month and buying the report as a non-member is $70).

domain_tools_lookup1 

As far as I could tell, it produced a lot more results per reverse name server lookup than either of the 2 tools above. For example, for the name server ns1.safaricombusiness.co.ke:

1. gwebtools found 1017 domains:

gwebtools_safaricom

2. viewdns.info found 2563 domains:

viewdnsinfo_safaricom

3. Domain Tools found 9814 domains:

domaintools_safaricom

 

DNSnitch:

The tools above are great, but I still wanted to find a tool that could perform reverse NS lookups without forcing me to leave my terminal. Since asking registries to give me access to their zone files was out of the question, I figured that the next best solution is utilising one of the sites above to get the results I wanted.

I had to make a choice between gwebtool’s ns-spy and viewdns.info’s reverse NS lookup tool. I settled on viewdns.info for 2 primary reasons:

  1. It monitors more domains than gwebtools and this gives us more results. You can see this in the lookup examples above.
  2. Its output is a lot easier to parse. viewdns.info outputs all its lookup results on a single page while gwebtool’s output is displayed on multiple pages, which would be more troublesome to parse and print to terminal.

Enter DNSnitch; a simple Python script that takes a name server as input, makes a request to viewdns.info’s reverse NS lookup tool, parses the results and outputs them to terminal.

DNSnitch_lookup1

DNSnitch_lookup2

Zone transfers:

While I was running tests on some public name servers used by a number of local sites (including numerous banks) I came across 2 name servers from a popular service provider that were allowing zone transfers on all the domains using them (told you it still happens 🙂 ).

A great practical explanation of what zone transfers are and why people should never enable them on public name servers can be found here. In summary, zone transfers make recon on an organisation a lot easier than it should be; it’s almost the equivalent of walking into an organisation, asking the lead network administrator for a list of all the public IP addresses the organisation has and walking right out of the front door. It won’t get you hacked immediately, but it will give bad guys a lot of information to work with in the later phases of an attack. Zone transfers have been a known issue for a very long time, which is why it’s pretty surprising to see it still happening these days.

The name servers I found were serving more than 2000 domains across Africa according to a lookup from viewdns.info. A lookup with Domain Tools was reporting well over 7000 domains using the name servers.

domain_tools_lookup2

Because of this, I thought it be fun to add a little extra functionality to DNSnitch; if you run DNSnitch with the ‘-zt’ switch, it won’t just stop at listing all the domains it found. It will list them, then use dig (domain information groper; a popular DNS utility installed on most Linux systems) to attempt zone transfers on all of the discovered domains (zone transfers on the domains will only be attempted using the specified name server).

I tested it out on the name servers above and the results were pretty great. It didn’t work for every single domain on the list, but it certainly got a lot of them.

DNSnitch_lookup3 DNSnitch_lookup4

DNSnitch_lookup5

dnsnitch_lookup6

axfr.py:

I wrote another script that takes a list of domains as input and attempts zone transfers on all of them against a specified name server. I figured that this might come in handy if someone already has a list of domains (say from Domain Tools) and wants to test all of them for zone transfers. You can download axfr.py here.

axfr_test

Conclusion:

Our troubles with DNS are far from over; whether it’s DDoS attacks bringing down major sites and services or name servers giving up an organisation’s public infrastructure in a matter of seconds.

So if you’re a DNS administrator, harden your servers against Denial-of-Service attacks and disallow zone transfers on all public facing name servers; it’s 2016 and we really shouldn’t be seeing this anymore. I’ll shoot a mail to the admin of the name servers above and hope they fix it. Happy hunting 🙂

2 Comments

Leave a Reply

Your email address will not be published. Required fields are marked *