I was hosting the DNS with Zoneedit but they recently got bought out by EasyDNS whose systems are to locked down to allow the flexability I need for this project so I'm now hosting the DNS myself. This means the new DNS servers to request for transfers are nsztm1.digi.ninja and sztm2.digi.ninja. At the moment they are both the same but may split in the future. I've also added some fun new entries and will update this page with them all later.
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 ns12.zoneedit.com and ns16.zoneedit.com. 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 @ns12.zoneedit.com zonetransfer.me ; <<>> DiG 9.7.3-P3 <<>> axfr @ns12.zoneedit.com zonetransfer.me ; (1 server found) ;; global options: +cmd zonetransfer.me. 7200 IN SOA ns16.zoneedit.com. soacontact.zoneedit.com. 2011520580 2400 360 1209600 300 zonetransfer.me. 7200 IN NS ns16.zoneedit.com. zonetransfer.me. 7200 IN NS ns12.zoneedit.com. zonetransfer.me. 7200 IN A 22.214.171.124 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. 301 IN TXT "Remember to call or email Pippa on +44 123 4567890 or firstname.lastname@example.org when making DNS changes" zonetransfer.me. 301 IN TXT "google-site-verification=tyP28J7JAUHA9fw2sHXMgcCC0I6XBmmoVi04VlMewxA" testing.zonetransfer.me. 301 IN CNAME www.zonetransfer.me. 126.96.36.199.in-addr.arpa.zonetransfer.me. 7200 IN PTR www.zonetransfer.me. info.zonetransfer.me. 7200 IN TXT "ZoneTransfer.me service provided by Robin Wood - email@example.com. See www.digininja.org/blog/zonetransferme.php for more information." owa.zonetransfer.me. 7200 IN A 188.8.131.52 office.zonetransfer.me. 7200 IN A 184.108.40.206 canberra_office.zonetransfer.me. 7200 IN A 220.127.116.11 dzc.zonetransfer.me. 7200 IN TXT "AbCdEfG" dr.zonetransfer.me. 300 IN LOC 53 20 56.557 N 1 38 33.525 W 0.00m 1m 10000m 10m www.zonetransfer.me. 7200 IN A 18.104.22.168 staging.zonetransfer.me. 7200 IN CNAME www.sydneyoperahouse.com. vpn.zonetransfer.me. 4000 IN A 22.214.171.124 _sip._tcp.zonetransfer.me. 14000 IN SRV 0 0 5060 www.zonetransfer.me. dc_office.zonetransfer.me. 7200 IN A 126.96.36.199 zonetransfer.me. 7200 IN SOA ns16.zoneedit.com. soacontact.zoneedit.com. 2011520580 2400 360 1209600 300 ;; Query time: 296 msec ;; SERVER: 188.8.131.52#53(184.108.40.206) ;; WHEN: Wed Dec 28 20:19:56 2011 ;; XFR size: 26 records (messages 26, bytes 1861)
The information starts with the SOA record:
zonetransfer.me. 7200 IN SOA ns16.zoneedit.com. soacontact.zoneedit.com. 2011520580 2400 360 1209600 300
This entry shows information about the primary name server, contact details for the administrator and other key information, this is how it breaks down:
- ns16.zoneedit.com. - Primary name server
- soacontact.zoneedit.com. - Responsible person, this is the email address (swap first . for an @) of the person in charge of the domain
- 2011520580 - 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
- 2400 - The time (seconds) secondary name servers should wait between making requests for changes
- 360 - 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
- 300 - 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 ns16.zoneedit.com. zonetransfer.me. 7200 IN NS ns12.zoneedit.com.
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 firstname.lastname@example.org 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 - email@example.com. 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.
220.127.116.11.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 18.104.22.168 www.zonetransfer.me. 7200 IN A 22.214.171.124 vpn.zonetransfer.me. 4000 IN A 126.96.36.199 owa.zonetransfer.me. 7200 IN A 188.8.131.52 office.zonetransfer.me. 7200 IN A 184.108.40.206 canberra_office.zonetransfer.me. 7200 IN A 220.127.116.11 dc_office.zonetransfer.me. 7200 IN A 18.104.22.168
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.
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.