ZoneTransfer.me

• Home
• Projects
• General
• Zone Transfer Me

When teaching, and when talking to clients, I sometimes have to explain the security problems related to DNS zone transfer. The problem usually comes when trying to demonstrate how it works and what information can be leaked, trying to remember which domains have zone transfer enabled and then hoping that they still have it turned on can make it hard. So, to ease both of these problems I've registered zonetransfer.me, a domain which is easy to remember and which will always have zone transfer enabled.

So, the domain is zonetransfer.me and the two name servers are nsztm1.digi.ninja and nsztm2.digi.ninja. Feel free to use this domain in your training and when talking to clients, hopefully it will help educate people as to why it should be disabled in almost all cases on public DNS servers.

To help with the education here is what I've set up and how I would read it.

First the full output from a transfer using dig:

dig axfr @nsztm1.digi.ninja zonetransfer.me

; <<>> DiG 9.9.5-3ubuntu0.6-Ubuntu <<>> axfr @nsztm1.digi.ninja zonetransfer.me
; (1 server found)
;; global options: +cmd
zonetransfer.me.        7200    IN      SOA     nsztm1.digi.ninja. robin.digi.ninja. 2014101601 172800 900 1209600 3600
zonetransfer.me.        300     IN      HINFO   "Casio fx-700G" "Windows XP"
zonetransfer.me.        301     IN      TXT     "google-site-verification=tyP28J7JAUHA9fw2sHXMgcCC0I6XBmmoVi04VlMewxA"
zonetransfer.me.        7200    IN      MX      0 ASPMX.L.GOOGLE.COM.
zonetransfer.me.        7200    IN      MX      10 ALT1.ASPMX.L.GOOGLE.COM.
zonetransfer.me.        7200    IN      MX      10 ALT2.ASPMX.L.GOOGLE.COM.
zonetransfer.me.        7200    IN      MX      20 ASPMX2.GOOGLEMAIL.COM.
zonetransfer.me.        7200    IN      MX      20 ASPMX3.GOOGLEMAIL.COM.
zonetransfer.me.        7200    IN      MX      20 ASPMX4.GOOGLEMAIL.COM.
zonetransfer.me.        7200    IN      MX      20 ASPMX5.GOOGLEMAIL.COM.
zonetransfer.me.        7200    IN      A       217.147.180.162
zonetransfer.me.        7200    IN      NS      nsztm1.digi.ninja.
zonetransfer.me.        7200    IN      NS      nsztm2.digi.ninja.
_sip._tcp.zonetransfer.me. 14000 IN     SRV     0 0 5060 www.zonetransfer.me.
164.180.147.217.IN-ADDR.ARPA.zonetransfer.me. 7200 IN PTR www.zonetransfer.me.
asfdbauthdns.zonetransfer.me. 7900 IN   AFSDB   1 asfdbbox.zonetransfer.me.
asfdbbox.zonetransfer.me. 7200  IN      A       127.0.0.1
asfdbvolume.zonetransfer.me. 7800 IN    AFSDB   1 asfdbbox.zonetransfer.me.
canberra-office.zonetransfer.me. 7200 IN A      202.14.81.230
cmdexec.zonetransfer.me. 300    IN      TXT     "\; ls"
contact.zonetransfer.me. 2592000 IN     TXT     "Remember to call or email Pippa on +44 123 4567890 or pippa@zonetransfer.me when making DNS changes"
dc-office.zonetransfer.me. 7200 IN      A       143.228.181.132
deadbeef.zonetransfer.me. 7201  IN      AAAA    dead:beaf::
dr.zonetransfer.me.     300     IN      LOC     53 20 56.558 N 1 38 33.526 W 0.00m 1m 10000m 10m
DZC.zonetransfer.me.    7200    IN      TXT     "AbCdEfG"
email.zonetransfer.me.  2222    IN      NAPTR   1 1 "P" "E2U+email" "" email.zonetransfer.me.zonetransfer.me.
email.zonetransfer.me.  7200    IN      A       74.125.206.26
Info.zonetransfer.me.   7200    IN      TXT     "ZoneTransfer.me service provided by Robin Wood - robin@digi.ninja. See http://digi.ninja/projects/zonetransferme.php for more information."
internal.zonetransfer.me. 300   IN      NS      intns1.zonetransfer.me.
internal.zonetransfer.me. 300   IN      NS      intns2.zonetransfer.me.
intns1.zonetransfer.me. 300     IN      A       167.88.42.94
intns2.zonetransfer.me. 300     IN      A       167.88.42.94
office.zonetransfer.me. 7200    IN      A       4.23.39.254
ipv6actnow.org.zonetransfer.me. 7200 IN AAAA    2001:67c:2e8:11::c100:1332
owa.zonetransfer.me.    7200    IN      A       207.46.197.32
robinwood.zonetransfer.me. 302  IN      TXT     "Robin Wood"
rp.zonetransfer.me.     321     IN      RP      robin.zonetransfer.me. robinwood.zonetransfer.me.
sip.zonetransfer.me.    3333    IN      NAPTR   2 3 "P" "E2U+sip" "!^.*$!sip:customer-service@zonetransfer.me!" .
sqli.zonetransfer.me.   300     IN      TXT     "' or 1=1 --"
sshock.zonetransfer.me. 7200    IN      TXT     "() { :]}\; echo ShellShocked"
staging.zonetransfer.me. 7200   IN      CNAME   www.sydneyoperahouse.com.
alltcpportsopen.firewall.test.zonetransfer.me. 301 IN A 127.0.0.1
testing.zonetransfer.me. 301    IN      CNAME   www.zonetransfer.me.
vpn.zonetransfer.me.    4000    IN      A       174.36.59.154
www.zonetransfer.me.    7200    IN      A       217.147.180.162
xss.zonetransfer.me.    300     IN      TXT     "'><script>alert('Boo')</script>"
zonetransfer.me.        7200    IN      SOA     nsztm1.digi.ninja. robin.digi.ninja. 2014101601 172800 900 1209600 3600
;; Query time: 21 msec
;; SERVER: 81.4.108.41#53(81.4.108.41)
;; WHEN: Fri Feb 05 08:58:44 GMT 2016
;; XFR size: 47 records (messages 1, bytes 1846)

The information starts with the SOA record:

zonetransfer.me.        7200    IN      SOA     nsztm1.digi.ninja. robin.digi.ninja. 2014101601 172800 900 1209600 3600

This entry shows information about the primary name server, contact details for the administrator and other key information, this is how it breaks down:

• nsztm1.digi.ninja. - Primary name server
• robin.digi.ninja. - Responsible person, this is the email address (swap first . for an @) of the person in charge of the domain
• 2014101601 - The current serial number for the domain. This is a value which is checked by secondary name servers to see if any entries have changed when performing an incremental transfer (IXFR). This value is usually based in some way on the date the change was made
• 172800 - The time (seconds) secondary name servers should wait between making requests for changes
• 900 - The retry time (seconds) a primary name server should wait if it fails to refresh properly
• 1209600 - The time (seconds) that a secondary name server can claim to have authoritative information
• 3600 - The minimum TTL for this domain

What security information can we gather from this? There are two bits I would say could be useful, the responsible person field gives an email address which could be used as part of other attacks, and from the current serial number, if it is date based and checked regularly, a change could indicate some activity in the company.

zonetransfer.me.        7200    IN      NS      nsztm1.digi.ninja.
zonetransfer.me.        7200    IN      NS      nsztm2.digi.ninja.

The name servers for this domain. It is always worth checking for zone transfers on all available name servers, I've seen a number of clients with multiple servers where, for an unknown reason, a single server has zone transfer enabled. You can also look for differences in output which may leak useful information.

zonetransfer.me.	7200	IN	MX	0 ASPMX.L.GOOGLE.COM.
zonetransfer.me.	7200	IN	MX	10 ALT1.ASPMX.L.GOOGLE.COM.
zonetransfer.me.	7200	IN	MX	10 ALT2.ASPMX.L.GOOGLE.COM.
zonetransfer.me.	7200	IN	MX	20 ASPMX2.GOOGLEMAIL.COM.
zonetransfer.me.	7200	IN	MX	20 ASPMX3.GOOGLEMAIL.COM.
zonetransfer.me.	7200	IN	MX	20 ASPMX4.GOOGLEMAIL.COM.
zonetransfer.me.	7200	IN	MX	20 ASPMX5.GOOGLEMAIL.COM.

The MX records indicate where mail should be sent, these are the standard mail servers for Google indicating the company uses GMail or Google Apps to handle their email. From this you know that there is a minimum of spam and virus checking in place which helps when sending email for SE or client side attacks.

dr.zonetransfer.me.	300	IN	LOC	53 20 56.557 N 1 38 33.525 W 0.00m 1m 10000m 10m

LOC is short for LOCation and can be used to record a latitude/longitude value. The values are stored in degrees/minutes/seconds and if you want to view these in Google Maps then you will need to convert them to decimal first. There are many online sites which do this, the one I used when setting this up is the one from the FCC. The values here convert to 53.349044,-1.642646 and this is how it looks on Google Maps. Now we know where staff are to go in a major disaster.

zonetransfer.me.	301	IN	TXT	"Remember to call or email Pippa on +44 123 4567890 or pippa@zonetransfer.me when making DNS changes"
zonetransfer.me.	301	IN	TXT	"google-site-verification=tyP28J7JAUHA9fw2sHXMgcCC0I6XBmmoVi04VlMewxA"
dzc.zonetransfer.me.	7200	IN	TXT	"AbCdEfG"
info.zonetransfer.me.	7200	IN	TXT	"ZoneTransfer.me service provided by Robin Wood - robin@digininja.org. See www.digininja.org/blog/zonetransferme.php for more information."

TXT records are text information and should always be checked for valuable information. The first one here leaks a phone number and email address of someone who is obviously something to do with system administration. The second shows the site has been verified for use in a Google Apps account. Number three is a way that GoDaddy uses to check that someone applying for an SSL certificate owns the domain, this kind of information could be useful if it leaks information on services being used or affiliations.

The last one, I've got to get credit for this project somehow!

testing.zonetransfer.me. 301	IN	CNAME	www.zonetransfer.me.
staging.zonetransfer.me. 7200	IN	CNAME	www.sydneyoperahouse.com.

The company has a test site which sits on the same server as the main web site. Test sites are often less secured than main sites so could be a better attack vector. The company also has a staging server which should also be looked at.

164.180.147.217.in-addr.arpa.zonetransfer.me. 7200 IN PTR www.zonetransfer.me.

A PTR record maps an IP address back to a domain name.

_sip._tcp.zonetransfer.me. 14000 IN	SRV	0 0 5060 www.zonetransfer.me.

An SRV record is a service record, it is used to identify a service by showing the protocol, host and port it is running on. This is often used in VOIP setups to indicate the location of SIP servers but can be used for any type of service. SRV records can show some very useful information about what services a target company is running.

The record breaks down as follows:

• _sip._tcp.zonetransfer.me - The name of the service, which includes the name of the protocol and TCP/UDP, here it is SIP running over TCP
• 14000 IN SRV - Standard DNS values, the TTL, DNS class and type
• 0 - Priority of the services, if there are multiple services this indicates which to try first
• 0 - Weight, when two services have the same priority this indicates which is preferred
• 5060 - The port on which the services is listening
• www.zonetransfer.me. - The host providing the service

zonetransfer.me.	7200	IN	A	217.147.177.157
www.zonetransfer.me.	7200	IN	A	217.147.177.157
vpn.zonetransfer.me.	4000	IN	A	174.36.59.154
owa.zonetransfer.me.	7200	IN	A	207.46.197.32
office.zonetransfer.me.	7200	IN	A	4.23.39.254
canberra_office.zonetransfer.me. 7200 IN A	202.14.81.230
dc_office.zonetransfer.me. 7200	IN	A	143.228.181.132

A records are the main type of DNS records and usually make up the majority of records, they map names to IP addresses. This is how I would read the ones above:

• blank and www - The main website, always good for vulnerabilities
• vpn - If you can find a way in through the VPN server then you can usually bypass any IDS/IPS that are in place
• owa - Commonly stands for Outlook Web Access, this is an interesting one as the MX records indicate that the company is using Google for their mail so this may imply that they are pulling down the mail and then republishing it using Exchange. I would also read from this that they are probably a Microsoft shop.
• office, canberra_office and dc_office - From this I would say that office is the main location and Canberra and DC were set up later. Geo location on the IP associated to office shows that the main office is in the UK. There are two things you can take from this, offices are often less well defended than data centres so could be better targets than the web or VPN servers and that using this location information you can time your attacks so that they are most efficient, for example attacking after work hours on a Friday at the start of a long weekend where defenders may not notice the attack for three days.

I'm constantly adding extra entries so not everything you will find has been described, have a look around and see what extra gems you can find. For bonus marks, see if you can dump the internal DNS records as well, all the information you need is given to you.

So, that is how I would read the information, there is a lot of useful stuff there, all leaked because of a misconfiguration. We know they are using Google for their mail but probably also using Exchange internally, we know the location of their DR site and can even get a photo of it through Google Street View. We have two email addresses and a phone number of system administrators which could be used for client side and SE attacks. They have a SIP system and we know the IP and port of the machine acting as the gateway. We have three data centre IPs and three office IPs from A records which gives six possible targets along with a testing and staging server. And we can assume they have purchased SSL certificates from GoDaddy and are using Google Apps to manage their domain.

Hopefully showing that all this information can be gathered from a simple DNS zone transfer we will be able to convince students and clients that they should never be allowed from public DNS servers.